From ltru-bounces@ietf.org Wed Mar 9 15:46:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18914; Wed, 9 Mar 2005 15:46:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D986u-0002MB-6e; Wed, 09 Mar 2005 15:48:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D984C-00044X-MT; Wed, 09 Mar 2005 15:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9849-00044B-VL for ltru@megatron.ietf.org; Wed, 09 Mar 2005 15:46:03 -0500 Received: from irvbhxw01.prod.quest.corp (irvbhxw01.quest.com [12.106.87.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18911 for ; Wed, 9 Mar 2005 15:45:59 -0500 (EST) Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 12:45:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Mar 2005 12:45:24 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A8808B9@irvmbxw01.quest.com> Thread-Topic: The List is Now Active Thread-Index: AcUk6Ogi0vFHDhAVQRuLh8V7tDLoMw== From: "Addison Phillips" To: X-OriginalArrivalTime: 09 Mar 2005 20:45:24.0989 (UTC) FILETIME=[EB6032D0:01C524E8] Cc: Randy Presuhn , Mark Davis , mduerst@w3.org Subject: [Ltru] The List is Now Active X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0270111887==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 --===============0270111887== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXQgbGVhc3QsIEkgd2FzIGFibGUgdG8gc3Vic2NyaWJlIGFuZCBzZW5kIHRoaXMgbWVzc2FnZS4N Cg0KTG9va2luZyBmb3J3YXJkIHRvIGZpbmlzaGluZyBvZmYgdGhpcyB3b3JrLg0KDQpBZGRpc29u DQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBT b2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFs aXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9u YWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4gDQoNCg0K --===============0270111887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0270111887==-- From ltru-bounces@ietf.org Thu Mar 10 11:02:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28689; Thu, 10 Mar 2005 11:02:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Q9k-0007BP-Mn; Thu, 10 Mar 2005 11:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Q6Y-0006rN-LE; Thu, 10 Mar 2005 11:01:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Q6X-0006rI-QX for ltru@megatron.ietf.org; Thu, 10 Mar 2005 11:01:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28673 for ; Thu, 10 Mar 2005 11:01:38 -0500 (EST) Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Q9L-0007AU-8T for ltru@ietf.org; Thu, 10 Mar 2005 11:04:36 -0500 Received: from [192.168.167.48] (helo=wamui10.slb.atl.earthlink.net) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D9Q6O-0006NB-00 for ltru@ietf.org; Thu, 10 Mar 2005 11:01:32 -0500 Message-ID: <5406232.1110470492885.JavaMail.root@wamui10.slb.atl.earthlink.net> Date: Thu, 10 Mar 2005 10:01:32 -0600 (GMT-06:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Ltru] Editors for registry i-d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi - As co-chairs of ltru, Martin and I are happy to announce that Addison Phillips and Mark Davis have volunteered to serve as editors for the update to RFC 3066. We'd like them to submit an internet-draft as a starting point for the WG discussion. The draft name will be draft-ietf-ltru-registry-00.txt We'd like to thank them in advance for helping the WG get off to a running start. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 10 11:16:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00609; Thu, 10 Mar 2005 11:16:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QNx-0007zc-TE; Thu, 10 Mar 2005 11:19:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QKc-0000yc-Ac; Thu, 10 Mar 2005 11:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QKb-0000yW-1t for ltru@megatron.ietf.org; Thu, 10 Mar 2005 11:16:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00536 for ; Thu, 10 Mar 2005 11:16:10 -0500 (EST) Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QNQ-0007y9-Qy for ltru@ietf.org; Thu, 10 Mar 2005 11:19:09 -0500 Received: from [192.168.167.48] (helo=wamui10.slb.atl.earthlink.net) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D9QKZ-0006ir-00 for ltru@ietf.org; Thu, 10 Mar 2005 11:16:11 -0500 Message-ID: <27321256.1110471371661.JavaMail.root@wamui10.slb.atl.earthlink.net> Date: Thu, 10 Mar 2005 10:16:11 -0600 (GMT-06:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Ltru] Call for volunteers to edit matching i-d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Hi - Addison Phillips and Mark Davis have volunteered to submit an internet-draft as a starting point for the WG discussion on tag matching. The draft's name will be draft-ietf-ltru-matching-00.txt We're looking for volunteers to take on the responsibility for editing subsequent versions of the matching document. If you're uncertain about the kind of things an editor needs to do, please see section 6.3 of RFC 2418, which spells out the responsibilities. For more information on the mechanics, please see: http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ID-Checklist.html http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt To volunteer, please send a message to the ltru@ietf.org list, or directly to the working group co-chairs. Our addresses are randy_presuhn@mindspring.com and duerst@w3.org. We hope to be able to name an editor or editors within a few days so we can quickly get into the technical work. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 10 15:30:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03172; Thu, 10 Mar 2005 15:30:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ULh-0005r3-51; Thu, 10 Mar 2005 15:33:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UHb-00083i-1K; Thu, 10 Mar 2005 15:29:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UHZ-00083Z-Jd for ltru@megatron.ietf.org; Thu, 10 Mar 2005 15:29:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03029 for ; Thu, 10 Mar 2005 15:29:16 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw01.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UKN-0005jW-Lj for ltru@ietf.org; Thu, 10 Mar 2005 15:32:17 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 12:29:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Call for volunteers to edit matching i-d Date: Thu, 10 Mar 2005 12:29:04 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A9243B2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Call for volunteers to edit matching i-d Thread-Index: AcUljIoip2UqMmkpS2eb0l0E9Li83AAIghMg From: "Addison Phillips" To: X-OriginalArrivalTime: 10 Mar 2005 20:29:05.0474 (UTC) FILETIME=[CDF3D220:01C525AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Potential volunteers: The matching draft is currently authored in the XML format specified by = RFC2629/2629bis. It is then converted to TXT and HTML formats using the = xml2rfc tool. See: http://tools.ietf.org/all-tools http://xml.resource.org/ The description of this tool is: -- xml2rfc Category: Authoring The recommended tool for draft production is to write the draft using = xml markup according to RFC 2629 or a successor (rfc2629bis), and then = use Marshall Rose's xml2rfc processor to produce text and optionally = html forms of the draft. -- To actually edit the text I have been using Corel XMetaL 4 and a = stylesheet that Martin D=FCrst developed, which I can forward, although = any XML editor will work. I have been hosting all of the source materials on my personal site = (www.inter-locale.com) and would be glad to continue to host the HTML = copies of the matching draft if you don't have a site of your own (the = HTML format is not an officially supported format: it is for = informational purposes only). Please note that the .TXT versions of the = Internet-Draft on the IETF site are the only official documents. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 10 mars 2005 08:16 > To: ltru@ietf.org > Subject: [Ltru] Call for volunteers to edit matching i-d >=20 > Hi - >=20 > Addison Phillips and Mark Davis have volunteered to submit > an internet-draft as a starting point for the WG discussion > on tag matching. >=20 > The draft's name will be draft-ietf-ltru-matching-00.txt >=20 > We're looking for volunteers to take on the responsibility > for editing subsequent versions of the matching document. >=20 > If you're uncertain about the kind of things an editor needs > to do, please see section 6.3 of RFC 2418, which spells out > the responsibilities. For more information on the mechanics, > please see: > http://www.ietf.org/ietf/1id-guidelines.txt > http://www.ietf.org/ID-Checklist.html > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt >=20 > To volunteer, please send a message to the ltru@ietf.org list, > or directly to the working group co-chairs. Our addresses are > randy_presuhn@mindspring.com and duerst@w3.org. We hope > to be able to name an editor or editors within a few days so we > can quickly get into the technical work. >=20 > Randy >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 10 18:50:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22373; Thu, 10 Mar 2005 18:50:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9XTT-00077Q-Ur; Thu, 10 Mar 2005 18:53:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9XPV-0001ve-3y; Thu, 10 Mar 2005 18:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9XPT-0001uk-4c for ltru@megatron.ietf.org; Thu, 10 Mar 2005 18:49:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22314 for ; Thu, 10 Mar 2005 18:49:39 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9XSL-00075w-Ef for ltru@ietf.org; Thu, 10 Mar 2005 18:52:42 -0500 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D9XPP-0004xP-Lw for ltru@ietf.org; Thu, 10 Mar 2005 15:49:40 -0800 Message-Id: <6.1.2.0.2.20050311004258.0428ae10@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 11 Mar 2005 00:49:33 +0100 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Call for volunteers to edit matching i-d In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A9243B2@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A9243B2@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Dear Addison, the XML URL on your site seems to have a problem? Thank you also to tell whan/if the online version is released (or still a pre-draft used for the voluntary search). To know when to print it. Thanks. jfc Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 10 19:05:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23381; Thu, 10 Mar 2005 19:05:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9XhY-0007ny-5t; Thu, 10 Mar 2005 19:08:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Xc4-0004qa-5b; Thu, 10 Mar 2005 19:02:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Xc2-0004qV-TR for ltru@megatron.ietf.org; Thu, 10 Mar 2005 19:02:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23289 for ; Thu, 10 Mar 2005 19:02:39 -0500 (EST) Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Xev-0007g5-PH for ltru@ietf.org; Thu, 10 Mar 2005 19:05:43 -0500 Received: from [192.168.167.46] (helo=wamui08.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D9Xbw-0002ks-00 for ltru@ietf.org; Thu, 10 Mar 2005 19:02:36 -0500 Message-ID: <26284308.1110499356566.JavaMail.root@wamui08.slb.atl.earthlink.net> Date: Thu, 10 Mar 2005 18:02:36 -0600 (GMT-06:00) From: Randy Presuhn To: ltru@ietf.org Subject: RE: [Ltru] Call for volunteers to edit matching i-d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi - When the internet draft becomes available, the working group mailing list should get a CC of the announcement sent to ietf-announce@ietf.org. Of course, our on-list discussion should be in terms of the file made available at http://www.ietf.org/internet-drafts/ rather than the editors' working copies, which they have made available as a courtesy to those who prefer HTML. Randy -----Original Message----- From: "JFC (Jefsey) Morfin" Sent: Mar 10, 2005 5:49 PM To: ltru@ietf.org Subject: RE: [Ltru] Call for volunteers to edit matching i-d Dear Addison, the XML URL on your site seems to have a problem? Thank you also to tell whan/if the online version is released (or still a pre-draft used for the voluntary search). To know when to print it. Thanks. jfc Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 10 19:27:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25381; Thu, 10 Mar 2005 19:27:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Y3H-0000SJ-Vt; Thu, 10 Mar 2005 19:30:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9XzY-0000ut-5G; Thu, 10 Mar 2005 19:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9XzW-0000ul-EQ for ltru@megatron.ietf.org; Thu, 10 Mar 2005 19:26:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25336 for ; Thu, 10 Mar 2005 19:26:54 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Y2P-0000Lu-80 for ltru@ietf.org; Thu, 10 Mar 2005 19:29:58 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 16:26:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Call for volunteers to edit matching i-d Date: Thu, 10 Mar 2005 16:26:46 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A92451C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Call for volunteers to edit matching i-d Thread-Index: AcUly/gHzSQbRvHaTdWwRZQi3sh0lgABLSQA From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , X-OriginalArrivalTime: 11 Mar 2005 00:26:47.0268 (UTC) FILETIME=[02A4E240:01C525D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Don't know what you were expecting, but the XML link does, in fact, = retrieve the XML (editor's copy) file. You shouldn't expect to view it = in your browser. As Randy noted, these are not official documents. They are just the = editor copies. There will be announcements when an official draft is = submitted. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: jeudi 10 mars 2005 15:50 > To: ltru@ietf.org > Subject: RE: [Ltru] Call for volunteers to edit matching i-d >=20 > Dear Addison, > the XML URL on your site seems to have a problem? > Thank you also to tell whan/if the online version is released (or = still a > pre-draft used for the voluntary search). To know when to print it. > Thanks. > jfc >=20 > Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt > Charter: http://ietf.org/html.charters/ltru-charter.html >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 11 10:42:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05652; Fri, 11 Mar 2005 10:42:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mKz-0001fk-9f; Fri, 11 Mar 2005 10:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mHO-0008Uv-OT; Fri, 11 Mar 2005 10:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mHO-0008Uf-93 for ltru@megatron.ietf.org; Fri, 11 Mar 2005 10:42:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05605 for ; Fri, 11 Mar 2005 10:42:15 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw01.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mKK-0001eb-Br for ltru@ietf.org; Fri, 11 Mar 2005 10:45:25 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Mar 2005 07:42:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Call for volunteers to edit matching i-d Date: Fri, 11 Mar 2005 07:42:03 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A9247A7@irvmbxw01.quest.com> Thread-Topic: [Ltru] Call for volunteers to edit matching i-d Thread-Index: AcUl6p1NKTErJ+JCSR6qOr2+2TPehwAZcNUg From: "Addison Phillips" To: "JFC (Jefsey) Morfin" X-OriginalArrivalTime: 11 Mar 2005 15:42:03.0651 (UTC) FILETIME=[DF5BED30:01C52650] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable No. As the current editors of both documents, Mark and I are preparing an = official first draft. Changes to that draft will be done via discussion = in the Working Group. If you want something, do it publicly there (as we = will---we do not make changes in the draft to suit our personal whims). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: 2005?3?10? 19:30 > To: Addison Phillips > Subject: RE: [Ltru] Call for volunteers to edit matching i-d >=20 > On 01:26 11/03/2005, Addison Phillips said: > >As Randy noted, these are not official documents. They are just the > editor > >copies. There will be announcements when an official draft is = submitted. >=20 > Addison, > as indicated to Randy, I wanted to propose that we shared the = preparation > of the initial draft with Mark and maybe John, before he said you and = Mark > would do the job. I was obviously your main opponent during the Last = Call. > I feel that if we could work together and agree on a few points on the > initial document we might save time for all. But this is now your > show, let it be as you want. Just be aware I am at your full = disposition > (and that I will be rock blocked on a few points, but I do not think = they > should be a problem if we adhere to the charter). > jfc >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 11 11:43:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12558; Fri, 11 Mar 2005 11:43:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9nHS-00055Z-2E; Fri, 11 Mar 2005 11:46:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9nEB-0004RP-Ui; Fri, 11 Mar 2005 11:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9nEB-0004RK-FT for ltru@megatron.ietf.org; Fri, 11 Mar 2005 11:43:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12530 for ; Fri, 11 Mar 2005 11:43:05 -0500 (EST) Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9nHD-00054n-7I for ltru@ietf.org; Fri, 11 Mar 2005 11:46:16 -0500 Received: from [192.168.167.44] (helo=wamui06.slb.atl.earthlink.net) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D9nE5-0003u9-00 for ltru@ietf.org; Fri, 11 Mar 2005 11:43:01 -0500 Message-ID: <13445903.1110559380926.JavaMail.root@wamui06.slb.atl.earthlink.net> Date: Fri, 11 Mar 2005 10:43:00 -0600 (GMT-06:00) From: Randy Presuhn To: ltru@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Ltru] New to IETF? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Hi - I expect that this effort may bring in some participants who have not previously been active in the IETF. Recommended reading to help gain an understanding of the IETF standards process and working group operations: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt There is also a more holistic picture, called the "Tao". There are efforts underway to update the classic http://www.ietf.org/rfc/rfc3160.txt - see http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt I hope that this material will be helpful. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 11 15:00:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02368; Fri, 11 Mar 2005 15:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9qM2-0007bC-Ln; Fri, 11 Mar 2005 15:03:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9qFi-00086c-TV; Fri, 11 Mar 2005 14:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9qFh-00086X-4P for ltru@megatron.ietf.org; Fri, 11 Mar 2005 14:56:53 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01994 for ; Fri, 11 Mar 2005 14:56:51 -0500 (EST) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1D9q9j-0001h4-FS for ltru@lists.ietf.org; Fri, 11 Mar 2005 20:50:43 +0100 Received: from 62.80.58.179 ([62.80.58.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Mar 2005 20:50:43 +0100 Received: from nobody by 62.80.58.179 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Mar 2005 20:50:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 11 Mar 2005 20:26:12 +0100 Organization: Lines: 10 Message-ID: <4231F0D4.4D02@xyzzy.claranet.de> References: <13445903.1110559380926.JavaMail.root@wamui06.slb.atl.earthlink.net> 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: 62.80.58.179 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: New to IETF? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt The latter is really nice. Starting with your article the list is now also available as news (nntp) and news feed (RSS), see Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 12 14:31:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01381; Sat, 12 Mar 2005 14:31:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DACO8-0005bd-60; Sat, 12 Mar 2005 14:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DACIw-0008A7-GD; Sat, 12 Mar 2005 14:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DACIv-0008A2-5f for ltru@megatron.ietf.org; Sat, 12 Mar 2005 14:29:41 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01280 for ; Sat, 12 Mar 2005 14:29:39 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050312192909.NYJG7277.mta10.adelphia.net@DEWELL> for ; Sat, 12 Mar 2005 14:29:09 -0500 Message-ID: <007301c52738$bae2ba40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 12 Mar 2005 11:21:44 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Addison and Mark's new draft contains an important change: grandfathered tags are allowed to have a canonical value. This means grandfathered tags can be formally deprecated, not just marked with a comment. This is a change we've talked about for some time. The wording is still a bit inconsistent, but I expect that will be cleared up soon. Accordingly, I've updated the proposed draft registry available at: http://users.adelphia.net/~dewell/lstreg.html http://users.adelphia.net/~dewell/lstreg.txt to add canonical values to all the grandfathered tags that were previously commented as "deprecated." This update also removes the variant subtag 'lojban' and changes the status of "art-lojban" from redundant to grandfathered (with a canonical value of "jbo"). There is also a change history at http://users.adelphia.net/~dewell/lstreg-history.html. All comments within the scope of the charter are welcome. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 12 15:08:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03585; Sat, 12 Mar 2005 15:08:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DACy4-0006Jy-56; Sat, 12 Mar 2005 15:12:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DACuX-0003Bx-7K; Sat, 12 Mar 2005 15:08:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DACuW-0003Bs-6q for ltru@megatron.ietf.org; Sat, 12 Mar 2005 15:08:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03556 for ; Sat, 12 Mar 2005 15:08:30 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw01.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DACxZ-0006JU-WC for ltru@ietf.org; Sat, 12 Mar 2005 15:11:43 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Sat, 12 Mar 2005 12:08:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Update to proposed registry Date: Sat, 12 Mar 2005 12:08:04 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A924C01@irvmbxw01.quest.com> Thread-Topic: [Ltru] Update to proposed registry Thread-Index: AcUnOjRFZ4fVr1anRzO4oMHx+pR03gABKogg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 12 Mar 2005 20:08:06.0075 (UTC) FILETIME=[341E48B0:01C5273F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0064634148==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --===============0064634148== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpJIGFsc28gaW5jb3Jwb3JhdGVkIGFub3RoZXIgY2hhbmdlIHdlIHByb21pc2VkIGR1 cmluZyB0aGUgbGFzdCBjYWxsIHBlcmlvZDogY29kZXMgdGhhdCBhcmUgZGVwcmVjYXRlZCBieSB0 aGVpciBwYXJlbnQgYWdlbmN5IChJU08gNjM5LCBJU08gMzE2NiwgZXRjLikgY2FuIGJlIGRlcHJl Y2F0ZWQgaW4gdGhlIHJlZ2lzdHJ5LiBTZWUgc2VjdGlvbnMgMi40LjEgYW5kIDMuMS4NCg0KSSBh bSBzdWJtaXR0aW5nIHRoZSBvZmZpY2lhbCBmaXJzdCBkcmFmdCBub3cuIEl0IGFsc28gaW5jbHVk ZXMgdGhlIGNvcnJlY3Rpb25zIHRoYXQgRG91ZyBtZW50aW9ucyBiZWxvdyB0byBtYWtlIHRoZSB0 ZXh0IGNvbnNpc3RlbnQuDQoNCkJlc3QgUmVnYXJkcywNCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWly LCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0 cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIERvdWcgRXdlbGwNCj4gU2VudDogU2F0dXJkYXksIE1hcmNoIDEyLCAyMDA1IDExOjIy IEFNDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogW0x0cnVdIFVwZGF0ZSB0 byBwcm9wb3NlZCByZWdpc3RyeQ0KPiANCj4gQWRkaXNvbiBhbmQgTWFyaydzIG5ldyBkcmFmdCBj b250YWlucyBhbiBpbXBvcnRhbnQgY2hhbmdlOiBncmFuZGZhdGhlcmVkDQo+IHRhZ3MgYXJlIGFs bG93ZWQgdG8gaGF2ZSBhIGNhbm9uaWNhbCB2YWx1ZS4gIFRoaXMgbWVhbnMgZ3JhbmRmYXRoZXJl ZA0KPiB0YWdzIGNhbiBiZSBmb3JtYWxseSBkZXByZWNhdGVkLCBub3QganVzdCBtYXJrZWQgd2l0 aCBhIGNvbW1lbnQuICBUaGlzDQo+IGlzIGEgY2hhbmdlIHdlJ3ZlIHRhbGtlZCBhYm91dCBmb3Ig c29tZSB0aW1lLiAgVGhlIHdvcmRpbmcgaXMgc3RpbGwgYQ0KPiBiaXQgaW5jb25zaXN0ZW50LCBi dXQgSSBleHBlY3QgdGhhdCB3aWxsIGJlIGNsZWFyZWQgdXAgc29vbi4NCj4gDQo+IEFjY29yZGlu Z2x5LCBJJ3ZlIHVwZGF0ZWQgdGhlIHByb3Bvc2VkIGRyYWZ0IHJlZ2lzdHJ5IGF2YWlsYWJsZSBh dDoNCj4gDQo+IGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC9sc3RyZWcuaHRtbA0K PiBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvbHN0cmVnLnR4dA0KPiANCj4gdG8g YWRkIGNhbm9uaWNhbCB2YWx1ZXMgdG8gYWxsIHRoZSBncmFuZGZhdGhlcmVkIHRhZ3MgdGhhdCB3 ZXJlDQo+IHByZXZpb3VzbHkgY29tbWVudGVkIGFzICJkZXByZWNhdGVkLiIgIFRoaXMgdXBkYXRl IGFsc28gcmVtb3ZlcyB0aGUNCj4gdmFyaWFudCBzdWJ0YWcgJ2xvamJhbicgYW5kIGNoYW5nZXMg dGhlIHN0YXR1cyBvZiAiYXJ0LWxvamJhbiIgZnJvbQ0KPiByZWR1bmRhbnQgdG8gZ3JhbmRmYXRo ZXJlZCAod2l0aCBhIGNhbm9uaWNhbCB2YWx1ZSBvZiAiamJvIikuDQo+IA0KPiBUaGVyZSBpcyBh bHNvIGEgY2hhbmdlIGhpc3RvcnkgYXQNCj4gaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3 ZWxsL2xzdHJlZy1oaXN0b3J5Lmh0bWwuDQo+IA0KPiBBbGwgY29tbWVudHMgd2l0aGluIHRoZSBz Y29wZSBvZiB0aGUgY2hhcnRlciBhcmUgd2VsY29tZS4NCj4gDQo+IC1Eb3VnIEV3ZWxsDQo+ICBG dWxsZXJ0b24sIENhbGlmb3JuaWENCj4gIGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2Vs bC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============0064634148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0064634148==-- From ltru-bounces@ietf.org Sat Mar 12 15:12:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04006; Sat, 12 Mar 2005 15:12:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAD1p-0006Oq-FD; Sat, 12 Mar 2005 15:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DACwq-0003TL-CN; Sat, 12 Mar 2005 15:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DACwo-0003TB-0f; Sat, 12 Mar 2005 15:10:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03796; Sat, 12 Mar 2005 15:10:46 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw01.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DACzx-0006Lo-Op; Sat, 12 Mar 2005 15:14:11 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw01.prod.quest.corp with Microsoft SMTPSVC(5.0.2195.6713); Sat, 12 Mar 2005 12:10:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5273F.8C81A070" Date: Sat, 12 Mar 2005 12:10:34 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: Working Group submission: LTRU Registry Draft 00 Thread-Index: AcUnP4hW2Ht1oFPFTUm0wlFEu4xHLA== From: "Addison Phillips" To: X-OriginalArrivalTime: 12 Mar 2005 20:10:37.0119 (UTC) FILETIME=[8E25C4F0:01C5273F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf5e460db3341c7fe3b3e952a594c9ed Cc: LTRU Working Group Subject: [Ltru] Working Group submission: LTRU Registry Draft 00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 35c0f1a3b493b4fa6d384d089a2b0902 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5273F.8C81A070 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGluIHRleHQgZm9ybWF0IGRyYWZ0 LTAwIG9mICJkcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkiLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0 aGlzIHdpbGwgYmUgcHJvY2Vzc2VkIGFmdGVyIElFVEYtNjIuDQoNCkJlc3QgUmVnYXJkcywNCg0K QWRkaXNvbiAoZm9yIHRoZSBlZGl0b3JzKQ0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxp emF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoN CkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRw Oi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo= ------_=_NextPart_001_01C5273F.8C81A070 Content-Type: text/plain; name="draft-ietf-ltru-registry-00.txt" Content-Description: draft-ietf-ltru-registry-00.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IFNlcHRlbWJl ciAxMSwgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMTAsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBU aGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBzdWJqZWN0IHRvIGFsbCBw cm92aXNpb25zDQogICBvZiBTZWN0aW9uIDMgb2YgUkZDIDM2NjcuICBCeSBzdWJtaXR0aW5nIHRo aXMgSW50ZXJuZXQtRHJhZnQsIGVhY2gNCiAgIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55IGFw cGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2YNCiAgIHdoaWNoIGhlIG9yIHNo ZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2YNCiAg IHdoaWNoIGhlIG9yIHNoZSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29y ZGFuY2Ugd2l0aA0KICAgUkZDIDM2NjguDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJ RVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcw0KICAg SW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50 cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3Rz LnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVz IGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4N Cg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgMTEsIDIw MDUuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwNSkuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IHRoZSBzdHJ1Y3R1cmUsIGNvbnRlbnQsIGNvbnN0cnVjdGlvbiwgYW5kDQogICBzZW1hbnRpY3Mg b2YgbGFuZ3VhZ2UgdGFncyBmb3IgdXNlIGluIGNhc2VzIHdoZXJlIGl0IGlzIGRlc2lyYWJsZSB0 bw0KICAgaW5kaWNhdGUgdGhlIGxhbmd1YWdlIHVzZWQgaW4gYW4gaW5mb3JtYXRpb24gb2JqZWN0 LiAgSXQgYWxzbw0KICAgZGVzY3JpYmVzIGhvdyB0byByZWdpc3RlciB2YWx1ZXMgZm9yIHVzZSBp biBsYW5ndWFnZSB0YWdzIGFuZCB0aGUNCiAgIGNyZWF0aW9uIG9mIHVzZXIgZGVmaW5lZCBleHRl bnNpb25zIGZvciBwcml2YXRlIGludGVyY2hhbmdlLiAgVGhpcw0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgIFtQYWdl IDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAg ICAgICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQogICBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDMw NjYgKHdoaWNoIHJlcGxhY2VkIFJGQyAxNzY2KS4NCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAg MS4gICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICAzDQogICAyLiAgIFRoZSBMYW5ndWFnZSBUYWcgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgICAgMi4xICBTeW50YXggLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAgIDIu MS4xICBMZW5ndGggQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1DQogICAgIDIuMiAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIEludGVycHJldGF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAgIDYNCiAgICAgICAyLjIuMSAgUHJpbWFyeSBMYW5ndWFnZSBT dWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KICAgICAgIDIuMi4yICBF eHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5 DQogICAgICAgMi4yLjMgIFNjcmlwdCBTdWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDkNCiAgICAgICAyLjIuNCAgUmVnaW9uIFN1YnRhZyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMA0KICAgICAgIDIuMi41ICBWYXJpYW50 IFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQogICAg ICAgMi4yLjYgIEV4dGVuc2lvbiBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTENCiAgICAgICAyLjIuNyAgUHJpdmF0ZSBVc2UgU3VidGFncyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgICAgIDIuMi44ICBQcmUtRXhpc3Rpbmcg UkZDIDMwNjYgUmVnaXN0cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gIDEzDQogICAgICAgMi4y LjkgIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTMNCiAgICAgICAyLjIuMTAgICBDbGFzc2VzIG9mIENvbmZvcm1hbmNlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxNA0KICAgICAyLjMgIENob2ljZSBvZiBMYW5ndWFnZSBUYWcg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1DQogICAgIDIuNCAgTWVhbmlu ZyBvZiB0aGUgTGFuZ3VhZ2UgVGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYN CiAgICAgICAyLjQuMSAgQ2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAu IC4gLiAuIC4gLiAuICAxNw0KICAgICAyLjUgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVz ZSBTdWJ0YWdzIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4DQogICAzLiAgIElBTkEgQ29uc2lkZXJh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjANCiAgICAg My4xICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICAuIC4gLiAu IC4gLiAuICAyMA0KICAgICAzLjIgIFN0YWJpbGl0eSBvZiBJQU5BIFJlZ2lzdHJ5IEVudHJpZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI0DQogICAgIDMuMyAgUmVnaXN0cmF0aW9uIFByb2Nl ZHVyZSBmb3IgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjcNCiAgICAgMy40ICBF eHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIE5hbWVzcGFjZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzMA0KICAgNC4gICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDMyDQogICA1LiAgIENoYXJhY3RlciBTZXQgQ29uc2lkZXJhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzMNCiAgIDYuICAgQ2hhbmdlcyBm cm9tIFJGQyAzMDY2ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzNA0K ICAgNy4gICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDM2DQogICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzgNCiAgIEEuICAgQWNrbm93bGVkZ2VtZW50 cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzOQ0KICAgQi4g ICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkgIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDQwDQogICBDLiAgIENvbnZlcnNpb24gb2YgdGhlIFJGQyAzMDY2IExhbmd1YWdlIFRh ZyBSZWdpc3RyeSAuIC4gLiAuIC4gLiAgNDINCiAgICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuICA0NA0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MTEsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoNCg0K MS4gIEludHJvZHVjdGlvbg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZlLCBw YXN0IGFuZCBwcmVzZW50LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBUaGVyZSBh cmUgbWFueSByZWFzb25zIHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0aGUNCiAgIGxh bmd1YWdlIHVzZWQgd2hlbiBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24uDQoN CiAgIEluZm9ybWF0aW9uIGFib3V0IGEgdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2VzIGNvbW1v bmx5IG5lZWRzIHRvIGJlDQogICBpZGVudGlmaWVkIHNvIHRoYXQgYXBwcm9wcmlhdGUgcHJvY2Vz c2luZyBjYW4gYmUgYXBwbGllZC4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHVzZXIncyBsYW5ndWFn ZSBwcmVmZXJlbmNlcyBpbiBhIGJyb3dzZXIgY2FuIGJlIHVzZWQgdG8NCiAgIHNlbGVjdCB3ZWIg cGFnZXMgYXBwcm9wcmlhdGVseS4gIEEgY2hvaWNlIG9mIGxhbmd1YWdlIHByZWZlcmVuY2UgY2Fu DQogICBhbHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nIHRvb2xzIChzdWNoIGFzIGRpY3Rpb25h cmllcykgdG8gYXNzaXN0DQogICBpbiB0aGUgcHJvY2Vzc2luZyBvciB1bmRlcnN0YW5kaW5nIG9m IGNvbnRlbnQgaW4gZGlmZmVyZW50IGxhbmd1YWdlcy4NCg0KICAgSW4gYWRkaXRpb24sIGtub3ds ZWRnZSBhYm91dCB0aGUgcGFydGljdWxhciBsYW5ndWFnZSB1c2VkIGJ5IHNvbWUNCiAgIHBpZWNl IG9mIGluZm9ybWF0aW9uIGNvbnRlbnQgbWF5IGJlIHVzZWZ1bCBvciBldmVuIHJlcXVpcmVkIGJ5 IHNvbWUNCiAgIHR5cGVzIG9mIGluZm9ybWF0aW9uIHByb2Nlc3Npbmc7IGZvciBleGFtcGxlIHNw ZWxsLWNoZWNraW5nLA0KICAgY29tcHV0ZXItc3ludGhlc2l6ZWQgc3BlZWNoLCBCcmFpbGxlIHRy YW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eQ0KICAgcHJpbnQgcmVuZGVyaW5ncy4NCg0KICAg T25lIG1lYW5zIG9mIGluZGljYXRpbmcgdGhlIGxhbmd1YWdlIHVzZWQgaXMgYnkgbGFiZWxpbmcg dGhlDQogICBpbmZvcm1hdGlvbiBjb250ZW50IHdpdGggYSBsYW5ndWFnZSBpZGVudGlmaWVyLiAg VGhlc2UgaWRlbnRpZmllcnMNCiAgIGNhbiBhbHNvIGJlIHVzZWQgdG8gc3BlY2lmeSB1c2VyIHBy ZWZlcmVuY2VzIHdoZW4gc2VsZWN0aW5nDQogICBpbmZvcm1hdGlvbiBjb250ZW50LCBvciBmb3Ig bGFiZWxpbmcgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRlbnQNCiAgIGFuZCBhc3NvY2lh dGVkIHJlc291cmNlcy4NCg0KICAgVGhlc2UgaWRlbnRpZmllcnMgY2FuIGFsc28gYmUgdXNlZCB0 byBpbmRpY2F0ZSBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMNCiAgIG9mIGNvbnRlbnQgdGhhdCBhcmUg Y2xvc2VseSByZWxhdGVkIHRvIHRoZSBsYW5ndWFnZS4gIEluIHBhcnRpY3VsYXIsDQogICBpdCBp cyBvZnRlbiBuZWNlc3NhcnkgdG8gaW5kaWNhdGUgc3BlY2lmaWMgaW5mb3JtYXRpb24gYWJvdXQg dGhlDQogICBkaWFsZWN0LCB3cml0aW5nIHN5c3RlbSwgb3Igb3J0aG9ncmFwaHkgdXNlZCBpbiBh IGRvY3VtZW50IG9yDQogICByZXNvdXJjZSwgYXMgdGhlc2UgYXR0cmlidXRlcyBtYXkgYmUgaW1w b3J0YW50IGZvciB0aGUgdXNlciB0byBvYnRhaW4NCiAgIGluZm9ybWF0aW9uIGluIGEgZm9ybSB0 aGF0IHRoZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGltcG9ydGFudCBpbg0KICAgc2VsZWN0aW5nIGFw cHJvcHJpYXRlIHByb2Nlc3NpbmcgcmVzb3VyY2VzIGZvciB0aGUgZ2l2ZW4gY29udGVudC4NCg0K ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gaWRlbnRpZmllciBtZWNoYW5pc20gYW5kIGEg cmVnaXN0cmF0aW9uDQogICBmdW5jdGlvbiBmb3IgdmFsdWVzIHRvIGJlIHVzZWQgd2l0aCB0aGF0 IGlkZW50aWZpZXIgbWVjaGFuaXNtLiAgSXQNCiAgIGFsc28gZGVmaW5lcyBhIG1lY2hhbmlzbSBm b3IgcHJpdmF0ZSB1c2UgdmFsdWVzIGFuZCBmdXR1cmUgZXh0ZW5zaW9uLg0KDQogICBUaGlzIGRv Y3VtZW50IHJlcGxhY2VzIFJGQyAzMDY2LCB3aGljaCByZXBsYWNlZCBSRkMgMTc2Ni4gIEZvciBh IGxpc3QNCiAgIG9mIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVudCwgc2VlIFNlY3Rpb24gNi4NCg0K ICAgVGhlIGtleXdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDIDIxMTldIFsxMV0uDQoNCg0KDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAg ICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0 YWdzICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQoyLiAgVGhlIExhbmd1YWdl IFRhZw0KDQoyLjEgIFN5bnRheA0KDQogICBUaGUgbGFuZ3VhZ2UgdGFnIGlzIGNvbXBvc2VkIG9m IG9uZSBvciBtb3JlIHBhcnRzOiBBIHByaW1hcnkgbGFuZ3VhZ2UNCiAgIHN1YnRhZyBhbmQgYSAo cG9zc2libHkgZW1wdHkpIHNlcmllcyBvZiBzdWJzZXF1ZW50IHN1YnRhZ3MuICBTdWJ0YWdzDQog ICBhcmUgZGlzdGluZ3Vpc2hlZCBieSB0aGVpciBsZW5ndGgsIHBvc2l0aW9uIGluIHRoZSBzdWJ0 YWcgc2VxdWVuY2UsDQogICBhbmQgY29udGVudCwgc28gdGhhdCBlYWNoIHR5cGUgb2Ygc3VidGFn IGNhbiBiZSByZWNvZ25pemVkIHNvbGVseSBieQ0KICAgdGhlc2UgZmVhdHVyZXMuICBUaGlzIG1h a2VzIGl0IHBvc3NpYmxlIHRvIGNvbnN0cnVjdCBhIHBhcnNlciB0aGF0DQogICBjYW4gZXh0cmFj dCBhbmQgYXNzaWduIHNvbWUgc2VtYW50aWMgaW5mb3JtYXRpb24gdG8gdGhlIHN1YnRhZ3MsIGV2 ZW4NCiAgIGlmIHNwZWNpZmljIHN1YnRhZyB2YWx1ZXMgYXJlIG5vdCByZWNvZ25pemVkLiAgVGh1 cyBhIHBhcnNlciBuZWVkIG5vdA0KICAgaGF2ZSBhbiB1cC10by1kYXRlIGNvcHkgb2YgdGhlIHJl Z2lzdGVyZWQgc3VidGFnIHZhbHVlcyB0byBwZXJmb3JtDQogICBtb3N0IHNlYXJjaGluZyBhbmQg bWF0Y2hpbmcgb3BlcmF0aW9ucy4NCg0KICAgVGhlIHN5bnRheCBvZiB0aGlzIHRhZyBpbiBBQk5G IFtSRkMgMjIzNF0gWzEzXSBpczoNCg0KICAgTGFuZ3VhZ2UtVGFnID0gKGxhbmcNCiAgICAgICAg ICAgICAgICAgICAqKCItIiBleHRsYW5nKQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgc2NyaXB0 XQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KICAgICAgICAgICAgICAgICAgICoo Ii0iIHZhcmlhbnQpDQogICAgICAgICAgICAgICAgICAgKigiLSIgZXh0ZW5zaW9uKQ0KICAgICAg ICAgICAgICAgICAgIFsiLSIgcHJpdmF0ZXVzZV0pDQogICAgICAgICAgICAgICAgICAgLyBwcml2 YXRldXNlICAgICAgICAgOyBwcml2YXRlLXVzZSB0YWcNCiAgICAgICAgICAgICAgICAgICAvIGdy YW5kZmF0aGVyZWQgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9ucw0KDQogICBsYW5n ICAgICAgICAgICAgPSAyKjNBTFBIQSAgICAgICAgICAgOyBzaG9ydGVzdCBJU08gNjM5IGNvZGUN CiAgICAgICAgICAgICAgICAgICAvIHJlZ2lzdGVyZWQtbGFuZw0KICAgZXh0bGFuZyAgICAgICAg ID0gM0FMUEhBICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCiAgIHNjcmlw dCAgICAgICAgICA9IDRBTFBIQSAgICAgICAgICAgICA7IElTTyAxNTkyNCBjb2RlDQogICByZWdp b24gICAgICAgICAgPSAyQUxQSEEgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2RlDQogICAgICAg ICAgICAgICAgICAgLyAzRElHSVQgICAgICAgICAgICAgOyBVTiBjb3VudHJ5IG51bWJlcg0KICAg dmFyaWFudCAgICAgICAgID0gQUxQSEEgKDQqN2FscGhhbnVtKSA7IHJlZ2lzdGVyZWQgdmFyaWFu dHMNCiAgICAgICAgICAgICAgICAgICAvIERJR0lUICgzKjdhbHBoYW51bSkNCiAgIGV4dGVuc2lv biAgICAgICA9IHNpbmdsZXRvbiAxKigiLSIgKDIqOGFscGhhbnVtKSkgOyBleHRlbnNpb24gc3Vi dGFnKHMpDQogICBwcml2YXRldXNlICAgICAgPSAoIngiLyJYIikgMSooIi0iICgxKjhhbHBoYW51 bSkpIDsgcHJpdmF0ZSB1c2Ugc3VidGFnKHMpDQogICBzaW5nbGV0b24gICAgICAgPSAoImEiLSJ3 IiAvICJ5Ii0ieiIgLyAiQSItIlciIC8gIlkiLSJaIikNCiAgICAgICAgICAgICAgICAgICA7IFNp bmdsZSBsZXR0ZXJzOiB4L1ggaXMgcmVzZXJ2ZWQgZm9yIHByaXZhdGUgdXNlDQogICByZWdpc3Rl cmVkLWxhbmcgPSA0KjhBTFBIQSAgICAgICAgICA7IHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFn DQogICBncmFuZGZhdGhlcmVkICAgPSAxKjNBTFBIQSAxKjIoIi0iICgyKjhhbHBoYW51bSkpICA7 IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA7IE5vdGU6IGkgaXMgdGhlIG9ubHkgc2luZ2xldG9uIHRoYXQgc3RhcnRzDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IGEgZ3JhbmRmYXRoZXJlZCB0 YWcNCiAgIGFscGhhbnVtICAgICAgICA9IChBTFBIQSAvIERJR0lUKSAgIDsgbGV0dGVycyBhbmQg bnVtYmVycw0KDQogICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IExhbmd1YWdlIFRhZyBB Qk5GDQoNCiAgIFRoZSBjaGFyYWN0ZXIgIi0iIGlzIEhZUEhFTi1NSU5VUyAoQUJORjogJXgyRCku ICBOb3RlIHRoYXQgdGhlcmUgaXMgYQ0KICAgc3VidGxldHkgaW4gdGhlIEFCTkYgZm9yICd2YXJp YW50JzogdmFyaWFudHMgbWF5IGNvbnNpc3Qgb2Ygc2VxdWVuY2VzDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICAgW1Bh Z2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIG9mIHVwIHRvIGVpZ2h0IGNoYXJhY3Rl cnMuDQoNCiAgIFdoaXRlc3BhY2UgaXMgbm90IHBlcm1pdHRlZCBpbiBhIGxhbmd1YWdlIHRhZy4g IEZvciBleGFtcGxlcyBvZg0KICAgbGFuZ3VhZ2UgdGFncywgc2VlIEFwcGVuZGl4IEIuDQoNCiAg IE5vdGUgdGhhdCBhbHRob3VnaCBbUkZDIDIyMzRdIFsxM10gcmVmZXJzIHRvIG9jdGV0cywgdGhl IGxhbmd1YWdlDQogICB0YWdzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBzZXF1ZW5j ZXMgb2YgY2hhcmFjdGVycyBmcm9tIHRoZQ0KICAgVVMtQVNDSUkgcmVwZXJ0b2lyZS4gIExhbmd1 YWdlIHRhZ3MgbWF5IGJlIHVzZWQgaW4gZG9jdW1lbnRzIGFuZA0KICAgYXBwbGljYXRpb25zIHRo YXQgdXNlIG90aGVyIGVuY29kaW5ncywgc28gbG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MgdGhlDQog ICBVUy1BU0NJSSByZXBlcnRvaXJlLiAgQW4gZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhN TCBkb2N1bWVudA0KICAgdGhhdCB1c2VzIHRoZSBVbmljb2RlIFVURi0xNkxFIGVuY29kaW5nLg0K DQogICBUaGUgdGFncyBhbmQgdGhlaXIgc3VidGFncywgaW5jbHVkaW5nIHByaXZhdGUtdXNlIGFu ZCBleHRlbnNpb25zLCBhcmUNCiAgIHRvIGJlIHRyZWF0ZWQgYXMgY2FzZSBpbnNlbnNpdGl2ZTog dGhlcmUgZXhpc3QgY29udmVudGlvbnMgZm9yIHRoZQ0KICAgY2FwaXRhbGl6YXRpb24gb2Ygc29t ZSBvZiB0aGUgc3VidGFncywgYnV0IHRoZXNlIHNob3VsZCBub3QgYmUgdGFrZW4NCiAgIHRvIGNh cnJ5IG1lYW5pbmcuDQoNCiAgIEZvciBleGFtcGxlOg0KICAgbyAgW0lTTyA2MzldIFsxXSByZWNv bW1lbmRzIHRoYXQgbGFuZ3VhZ2UgY29kZXMgYmUgd3JpdHRlbiBpbiBsb3dlcg0KICAgICAgY2Fz ZSAoJ21uJyBNb25nb2xpYW4pLg0KICAgbyAgW0lTTyAzMTY2XSBbNF0gcmVjb21tZW5kcyB0aGF0 IGNvdW50cnkgY29kZXMgYmUgY2FwaXRhbGl6ZWQgKCdNTicNCiAgICAgIE1vbmdvbGlhKS4NCiAg IG8gIFtJU08gMTU5MjRdIFszXSByZWNvbW1lbmRzIHRoYXQgc2NyaXB0IGNvZGVzIHVzZSBsb3dl ciBjYXNlIHdpdGgNCiAgICAgIHRoZSBpbml0aWFsIGxldHRlciBjYXBpdGFsaXplZCAoJ0N5cmwn IEN5cmlsbGljKS4NCiAgIEhvd2V2ZXIsIGluIHRoZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1 bWVudCwgdGhlIHVwcGVyY2FzZSBVUy1BU0NJSQ0KICAgbGV0dGVycyBpbiB0aGUgcmFuZ2UgJ0En IChBQk5GOiAleDQxKSB0aHJvdWdoICdaJyAoQUJORjogJXg1QSkgYXJlDQogICBjb25zaWRlcmVk IGVxdWl2YWxlbnQgYW5kIG1hcHBlZCBkaXJlY3RseSB0byB0aGVpciBVUy1BU0NJSSBsb3dlcmNh c2UNCiAgIGVxdWl2YWxlbnRzIGluIHRoZSByYW5nZSAnYScgKEFCTkY6ICV4NjEpIHRocm91Z2gg J3onIChBQk5GOiAleDdBKS4NCiAgIFRodXMgdGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRp c3RpbmN0IGZyb20gIk1OLWNZUkwtbW4iIG9yDQogICAibU4tY1lyTC1NbiIgKG9yIGFueSBvdGhl ciBjb21iaW5hdGlvbikgYW5kIGVhY2ggb2YgdGhlc2UgdmFyaWF0aW9ucw0KICAgY29udmV5cyB0 aGUgc2FtZSBtZWFuaW5nOiBNb25nb2xpYW4gd3JpdHRlbiBpbiB0aGUgQ3lyaWxsaWMgc2NyaXB0 IGFzDQogICB1c2VkIGluIE1vbmdvbGlhLg0KDQogICBGb3IgaW5mb3JtYXRpdmUgZXhhbXBsZXMg b2YgbGFuZ3VhZ2UgdGFncywgc2VlIEFwcGVuZGl4IEIgYXQgdGhlIGVuZA0KICAgb2YgdGhpcyBk b2N1bWVudC4NCg0KMi4xLjEgIExlbmd0aCBDb25zaWRlcmF0aW9ucw0KDQogICBBbHRob3VnaCBu ZWl0aGVyIHRoZSBBQk5GIG5vciBvdGhlciBndWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQNCiAg IHByb3ZpZGUgYSBmaXhlZCB1cHBlciBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHNpemUgb2Ygc3Vi dGFncyBpbiBhDQogICBMYW5ndWFnZSBUYWcgYW5kIGl0IGlzIHBvc3NpYmxlIHRvIGVudmlzaW9u IHF1aXRlIGxvbmcgYW5kIGNvbXBsZXgNCiAgIHN1YnRhZyBzZXF1ZW5jZXMsIGluIHByYWN0aWNl IHRoZXNlIGFyZSByYXJlIGJlY2F1c2UgYWRkaXRpb25hbA0KICAgZ3JhbnVsYXJpdHkgaW4gdGFn cyBzZWxkb20gYWRkcyB1c2VmdWwgZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gYW5kDQogICBi ZWNhdXNlIGxvbmdlciwgbW9yZSBncmFudWxhciB0YWdzIGludGVyZWZlcmUgd2l0aCB0aGUgbWVh bmluZywNCiAgIHVuZGVyc3RhbmRpbmcsIGFuZCBwcm9jZXNzaW5nIG9mIGxhbmd1YWdlIHRhZ3Mu DQoNCiAgIEluIHBhcnRpY3VsYXIsICB2YXJpYW50IHN1YnRhZ3MgU0hPVUxEIGJlIHVzZWQgb25s eSB3aXRoIHRoZWlyDQogICByZWNvbW1lbmRlZCBwcmVmaXguICBUaGlzIGxpbWl0cyBtb3N0IHRh Z3MgdG8gYSBzZXF1ZW5jZSBvZiBmb3VyDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAgICAgICAgICAgICAg TWFyY2ggMjAwNQ0KDQoNCiAgIHN1YnRhZ3MgKGV4Y2x1ZGluZyBhbnkgZXh0ZW5zaW9ucyBvciBw cml2YXRlIHVzZSBzZXF1ZW5jZXMpLiAgU2VlDQogICBTZWN0aW9uIDIuMyBmb3IgbW9yZSBpbmZv cm1hdGlvbiBvbiBzZWxlY3RpbmcgdGhlIG1vc3QgYXBwcm9wcmlhdGUNCiAgIExhbmd1YWdlIFRh Zy4NCg0KICAgQSBjb25mb3JtYW50IGltcGxlbWVudGF0aW9uIG5lZWQgbm90IHN1cHBvcnQgdGhl IHN0b3JhZ2Ugb2YgbGFuZ3VhZ2UNCiAgIHRhZ3Mgd2hpY2ggZXhjZWVkIGEgc3BlY2lmaWVkIGxl bmd0aC4gIEZvciBhbiBleGFtcGxlLCBzZWUgW1JGQyAyMjMxXQ0KICAgWzEyXS4gIEFueSBzdWNo IGEgbGltaXRhdGlvbiBNVVNUIGJlIGNsZWFybHkgZG9jdW1lbnRlZCwgYW5kIHN1Y2gNCiAgIGRv Y3VtZW50YXRpb24gU0hPVUxEIGluY2x1ZGUgdGhlIGRpc3Bvc2l0aW9uIG9mIGFueSBsb25nZXIg dGFncyAoZm9yDQogICBleGFtcGxlLCB3aGV0aGVyIGFuIGVycm9yIHZhbHVlIGlzIGdlbmVyYXRl ZCBvciB0aGUgbGFuZ3VhZ2UgdGFnIGlzDQogICB0cnVuY2F0ZWQpLiAgSWYgdHJ1bmNhdGlvbiBp cyBwZXJtaXR0ZWQgaXQgU0hPVUxEIE5PVCBwZXJtaXQgYSBzdWJ0YWcNCiAgIHRvIGJlIGRpdmlk ZWQuDQoNCjIuMiAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIEludGVycHJldGF0aW9uDQoN CiAgIFRoZSBuYW1lc3BhY2Ugb2YgbGFuZ3VhZ2UgdGFncyBhbmQgdGhlaXIgc3VidGFncyBpcyBh ZG1pbmlzdGVyZWQgYnkNCiAgIHRoZSBJbnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0 eSAoSUFOQSkgWzE3XSBhY2NvcmRpbmcgdG8gdGhlDQogICBydWxlcyBpbiBTZWN0aW9uIDMgb2Yg dGhpcyBkb2N1bWVudC4gIFRoZSByZWdpc3RyeSBtYWludGFpbmVkIGJ5IElBTkENCiAgIGlzIHRo ZSBzb3VyY2UgZm9yIHZhbGlkIHN1YnRhZ3M6IG90aGVyIHN0YW5kYXJkcyByZWZlcmVuY2VkIGlu IHRoaXMNCiAgIHNlY3Rpb24gcHJvdmlkZSB0aGUgc291cmNlIG1hdGVyaWFsIGZvciB0aGF0IHJl Z2lzdHJ5Lg0KDQogICBUZXJtaW5vbG9neSBpbiB0aGlzIHNlY3Rpb246DQoNCiAgIG8gIFRhZyBv ciB0YWdzIHJlZmVycyB0byBhIGNvbXBsZXRlIGxhbmd1YWdlIHRhZywgc3VjaCBhcw0KICAgICAg ImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2YgdGFncyBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNs b3NlZCBpbg0KICAgICAgZG91YmxlLXF1b3RlcyAoImVuLVVTIikuDQogICBvICBTdWJ0YWcgcmVm ZXJzIHRvIGEgc3BlY2lmaWMgc2VjdGlvbiBvZiBhIHRhZywgc2VwYXJhdGVkIGJ5IGh5cGhlbiwN CiAgICAgIHN1Y2ggYXMgdGhlIHN1YnRhZyAnTGF0bicgaW4gImZyLUxhdG4tQ0EiLiAgRXhhbXBs ZXMgb2Ygc3VidGFncyBpbg0KICAgICAgdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4gc2lu Z2xlIHF1b3RlcyAoJ0xhdG4nKS4NCiAgIG8gIENvZGUgb3IgY29kZXMgcmVmZXJzIHRvIHRhZ3Mg ZGVmaW5lZCBpbiBleHRlcm5hbCBzdGFuZGFyZHMgKGFuZA0KICAgICAgd2hpY2ggYXJlIHVzZWQg YXMgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50KS4gIEZvciBleGFtcGxlLCAnTGF0bicNCiAgICAg IGlzIGFuIFtJU08gMTU5MjRdIFszXSBzY3JpcHQgY29kZSB3aGljaCB3YXMgdXNlZCB0byBkZWZp bmUgdGhlDQogICAgICAnTGF0bicgc2NyaXB0IHN1YnRhZyBmb3IgdXNlIGluIGEgbGFuZ3VhZ2Ug dGFnLiAgRXhhbXBsZXMgb2YgY29kZXMNCiAgICAgIGluIHRoaXMgZG9jdW1lbnQgYXJlIGVuY2xv c2VkIGluIHNpbmdsZSBxdW90ZXMgKCdlbicsICdMYXRuJykuDQoNCiAgIFRoZSBkZWZpbml0aW9u cyBpbiB0aGlzIHNlY3Rpb24gYXBwbHkgdG8gdGhlIHZhcmlvdXMgc3VidGFncyB3aXRoaW4NCiAg IHRoZSBsYW5ndWFnZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgZXhjZXB0aW5nIHRo b3NlDQogICAiZ3JhbmRmYXRoZXJlZCIgdGFncyBkZWZpbmVkIGluIFNlY3Rpb24gMi4yLjguDQoN CiAgIExhbmd1YWdlIHRhZ3MgYXJlIGRlc2lnbmVkIHNvIHRoYXQgZWFjaCBzdWJ0YWcgaGFzIHVu aXF1ZSBsZW5ndGggYW5kDQogICBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRoZXNlIG1ha2UgaWRl bnRpZmljYXRpb24gb2YgdGhlIHN1YnRhZydzIHR5cGUNCiAgIHBvc3NpYmxlLCBldmVuIGlmIHRo ZSBjb250ZW50IG9mIHRoZSBzdWJ0YWcgaXRzZWxmIGlzIHVucmVjb2duaXplZC4NCiAgIFRoaXMg YWxsb3dzIHRhZ3MgdG8gYmUgcGFyc2VkIGFuZCBwcm9jZXNzZWQgd2l0aG91dCByZWZlcmVuY2Ug dG8gdGhlDQogICBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMgb3Ig dGhlIElBTkEgcmVnaXN0cnkgYW5kDQogICBtYWtlcyB0aGUgYXNzb2NpYXRlZCBleGNlcHRpb24g aGFuZGxpbmcgd2hlbiBwYXJzaW5nIHRhZ3Mgc2ltcGxlci4NCg0KICAgU3VidGFncyBpbiB0aGUg SUFOQSByZWdpc3RyeSB0aGF0IGRvIG5vdCBjb21lIGZyb20gYW4gdW5kZXJseWluZw0KICAgc3Rh bmRhcmQgY2FuIG9ubHkgYXBwZWFyIGluIHNwZWNpZmljIHBvc2l0aW9ucyBpbiBhIHRhZy4NCiAg IFNwZWNpZmljYWxseSwgdGhleSBjYW4gb25seSBvY2N1ciBhcyBwcmltYXJ5IGxhbmd1YWdlIHN1 YnRhZ3Mgb3IgYXMNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMTEsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoN Cg0KICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBOb3RlIHRoYXQgc2VxdWVuY2VzIG9mIHByaXZh dGUtdXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBNVVNUIG9jY3VyDQogICBhdCB0aGUgZW5kIG9m IHRoZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFuZCBNVVNUIE5PVCBiZSBpbnRlcnNwZXJzZWQNCiAg IHdpdGggc3VidGFncyBkZWZpbmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBT aW5nbGUgbGV0dGVyIGFuZCBkaWdpdCBzdWJ0YWdzIGFyZSByZXNlcnZlZCBmb3IgY3VycmVudCBv ciBmdXR1cmUNCiAgIHVzZS4gIFRoZXNlIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBjdXJyZW50IHVz ZXM6DQoNCiAgIG8gIFRoZSBzaW5nbGUgbGV0dGVyIHN1YnRhZyAneCcgaXMgcmVzZXJ2ZWQgdG8g aW50cm9kdWNlIGEgc2VxdWVuY2UNCiAgICAgIG9mIHByaXZhdGUtdXNlIHN1YnRhZ3MuICBUaGUg aW50ZXJwcmV0YXRpb24gb2YgYW55IHByaXZhdGUtdXNlDQogICAgICBzdWJ0YWdzIGlzIGRlZmlu ZWQgc29sZWx5IGJ5IHByaXZhdGUgYWdyZWVtZW50IGFuZCBpcyBub3QgZGVmaW5lZA0KICAgICAg YnkgdGhlIHJ1bGVzIGluIHRoaXMgc2VjdGlvbiBvciBpbiBhbnkgc3RhbmRhcmQgb3IgcmVnaXN0 cnkNCiAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4NCiAgIG8gIEFsbCBvdGhlciBzaW5n bGUgbGV0dGVyIHN1YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGludHJvZHVjZQ0KICAgICAgc3RhbmRh cmRpemVkIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2VzIGFzIGRlc2NyaWJlZCBpbg0KICAgICAg U2VjdGlvbiAzLjQuDQoNCiAgIFRoZSBzaW5nbGUgbGV0dGVyIHN1YnRhZyAnaScgaXMgdXNlZCBi eSBzb21lIGdyYW5kZmF0aGVyZWQgdGFncywgc3VjaA0KICAgYXMgImktZW5vY2hpYW4iLCB3aGVy ZSBpdCBhbHdheXMgYXBwZWFycyBpbiB0aGUgZmlyc3QgcG9zaXRpb24gYW5kDQogICBjYW5ub3Qg YmUgY29uZnVzZWQgd2l0aCBhbiBleHRlbnNpb24uDQoNCjIuMi4xICBQcmltYXJ5IExhbmd1YWdl IFN1YnRhZw0KDQogICBUaGUgcHJpbWFyeSBzdWJ0YWcgaXMgdGhlIGZpcnN0IHN1YnRhZyBpbiBh IGxhbmd1YWdlIHRhZyBhbmQgY2Fubm90DQogICBiZSBlbXB0eS4gIEV4Y2VwdCBhcyBub3RlZCwg dGhlIHByaW1hcnkgc3VidGFnIGlzIHRoZSBsYW5ndWFnZQ0KICAgc3VidGFnLiAgVGhlIGZvbGxv d2luZyBydWxlcyBhcHBseSB0byB0aGUgYXNzaWdubWVudCBhbmQNCiAgIGludGVycHJldGF0aW9u IG9mIHRoZSBwcmltYXJ5IHN1YnRhZzoNCg0KICAgbyAgQWxsIDItY2hhcmFjdGVyIGxhbmd1YWdl IHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5DQogICAgICBhY2NvcmRp bmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZCBJU08gNjM5IFBhcnQg MSwNCiAgICAgICJJU08gNjM5LTE6MjAwMiwgQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBv ZiBuYW1lcyBvZg0KICAgICAgbGFuZ3VhZ2VzIC0tIFBhcnQgMTogQWxwaGEtMiBjb2RlIiBbSVNP IDYzOS0xXSBbMV0sIG9yIHVzaW5nDQogICAgICBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFk ZSBieSB0aGUgSVNPIDYzOSBQYXJ0IDEgbWFpbnRlbmFuY2UNCiAgICAgIGFnZW5jeSBvciBnb3Zl cm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCiAgIG8gIEFsbCAzLWNoYXJhY3RlciBsYW5n dWFnZSBzdWJ0YWdzIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeQ0KICAgICAgYWNj b3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBJU08gNjM5IFBhcnQgMiwgIklTTw0K ICAgICAgNjM5LTI6MTk5OCAtIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMg b2YgbGFuZ3VhZ2VzIC0tDQogICAgICBQYXJ0IDI6IEFscGhhLTMgY29kZSAtIGVkaXRpb24gMSIg W0lTTyA2MzktMl0gWzJdLCBvciBhc3NpZ25tZW50cw0KICAgICAgc3Vic2VxdWVudGx5IG1hZGUg YnkgdGhlIElTTyA2MzkgUGFydCAyIG1haW50ZW5hbmNlIGFnZW5jeSBvcg0KICAgICAgZ292ZXJu aW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQogICBvICBUaGUgc3VidGFncyBpbiB0aGUgcmFu Z2UgJ3FhYScgdGhyb3VnaCAncXR6JyBhcmUgcmVzZXJ2ZWQgZm9yDQogICAgICBwcml2YXRlIHVz ZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBjb3JyZXNwb25kIHRvIGNvZGVzDQog ICAgICByZXNlcnZlZCBieSBJU08gNjM5LTIgZm9yIHByaXZhdGUgdXNlLiAgVGhlc2UgY29kZXMg TUFZIGJlIHVzZWQNCiAgICAgIGZvciBub24tcmVnaXN0ZXJlZCBwcmltYXJ5LWxhbmd1YWdlIHN1 YnRhZ3MgKGluc3RlYWQgb2YgdXNpbmcNCiAgICAgIHByaXZhdGUtdXNlIHN1YnRhZ3MgZm9sbG93 aW5nICd4LScpLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gMi41DQogICAgICBmb3IgbW9yZSBp bmZvcm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2Ug N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIG8gIEFsbCBsYW5ndWFnZSBzdWJ0YWdzIG9m IDQgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAgcmVnaXN0cnkg d2VyZSBkZWZpbmVkIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgaW4gU2VjdGlvbiAzLjMN CiAgICAgIGFuZCBNQVkgYmUgdXNlZCB0byBmb3JtIHRoZSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRh Zy4gIEF0IHRoZSB0aW1lDQogICAgICB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3 ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgc3VidGFnIGFuZCBmdXR1cmUg cmVnaXN0cmF0aW9ucyBvZiB0aGlzIHR5cGUgd2lsbCBiZSBkaXNjb3VyYWdlZDoNCiAgICAgIHBy aW1hcnkgbGFuZ3VhZ2VzIGFyZSBTVFJPTkdMWSBSRUNPTU1FTkRFRCBmb3IgcmVnaXN0cmF0aW9u IHdpdGgNCiAgICAgIElTTyA2MzkgYW5kIHN1YnRhZ3MgcmVqZWN0ZWQgYnkgSVNPIDYzOSB3aWxs IGJlIGNsb3NlbHkNCiAgICAgIHNjcnV0aW5pemVkIGJlZm9yZSB0aGV5IGFyZSByZWdpc3RlcmVk IHdpdGggSUFOQS4NCiAgIG8gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyAneCcgYXMgdGhl IHByaW1hcnkgc3VidGFnIGluZGljYXRlcw0KICAgICAgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFnIGNv bnNpc3RzIHNvbGVseSBvZiBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMNCiAgICAgIGRlZmluZWQg YnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBGb3IgZXhhbXBsZSwgaW4gdGhlIHRhZyAieC1mci1DSCIs DQogICAgICB0aGUgc3VidGFncyAnZnInIGFuZCAnQ0gnIHNob3VsZCBub3QgYmUgdGFrZW4gdG8g cmVwcmVzZW50IHRoZQ0KICAgICAgRnJlbmNoIGxhbmd1YWdlIG9yIHRoZSBjb3VudHJ5IG9mIFN3 aXR6ZXJsYW5kIChvciBhbnkgb3RoZXIgdmFsdWUNCiAgICAgIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 KSB1bmxlc3MgdGhlcmUgaXMgYSBwcml2YXRlIGFncmVlbWVudCBpbiBwbGFjZQ0KICAgICAgdG8g ZG8gc28uICBTZWUgU2VjdGlvbiAyLjUuDQogICBvICBPdGhlciB2YWx1ZXMgTVVTVCBOT1QgYmUg YXNzaWduZWQgdG8gdGhlIHByaW1hcnkgc3VidGFnIGV4Y2VwdCBieQ0KICAgICAgcmV2aXNpb24g b3IgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5vdGU6IEZvciBsYW5ndWFnZXMgdGhh dCBoYXZlIGJvdGggYW4gSVNPIDYzOS0xIDItY2hhcmFjdGVyIGNvZGUgYW5kDQogICBhbiBJU08g NjM5LTIgMy1jaGFyYWN0ZXIgY29kZSwgb25seSB0aGUgSVNPIDYzOS0xIDItY2hhcmFjdGVyIGNv ZGUgaXMNCiAgIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgIE5vdGU6IEZvciBs YW5ndWFnZXMgdGhhdCBoYXZlIG5vIElTTyA2MzktMSAyLWNoYXJhY3RlciBjb2RlIGFuZCBmb3IN CiAgIHdoaWNoIHRoZSBJU08gNjM5LTIvVCAoVGVybWlub2xvZ3kpIGNvZGUgYW5kIHRoZSBJU08g NjM5LTIvQg0KICAgKEJpYmxpb2dyYXBoaWMpIGNvZGVzIGRpZmZlciwgb25seSB0aGUgVGVybWlu b2xvZ3kgY29kZSBpcyBkZWZpbmVkIGluDQogICB0aGUgSUFOQSByZWdpc3RyeS4gIEF0IHRoZSB0 aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIGFsbA0KICAgbGFuZ3VhZ2VzIHRoYXQgaGFk IGJvdGgga2luZHMgb2YgMy1jaGFyYWN0ZXIgY29kZSB3ZXJlIGFsc28gYXNzaWduZWQNCiAgIGEg Mi1jaGFyYWN0ZXIgY29kZTsgaXQgaXMgbm90IGV4cGVjdGVkIHRoYXQgZnV0dXJlIGFzc2lnbm1l bnRzIG9mDQogICB0aGlzIG5hdHVyZSB3aWxsIG9jY3VyLg0KDQogICBOb3RlOiBUbyBhdm9pZCBw cm9ibGVtcyB3aXRoIHZlcnNpb25pbmcgYW5kIHN1YnRhZyBjaG9pY2UgYXMNCiAgIGV4cGVyaWVu Y2VkIGR1cmluZyB0aGUgdHJhbnNpdGlvbiBiZXR3ZWVuIFJGQyAxNzY2IGFuZCBSRkMgMzA2Niwg YXMNCiAgIHdlbGwgYXMgdGhlIGNhbm9uaWNhbCBuYXR1cmUgb2Ygc3VidGFncyBkZWZpbmVkIGJ5 IHRoaXMgZG9jdW1lbnQsIHRoZQ0KICAgSVNPIDYzOSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5IEpv aW50IEFkdmlzb3J5IENvbW1pdHRlZSAoSVNPDQogICA2MzkvUkEtSkFDKSBoYXMgaW5jbHVkZWQg dGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gWzZdOg0KDQogICAiQSBsYW5ndWFnZSBjb2RlIGFs cmVhZHkgaW4gSVNPIDYzOS0yIGF0IHRoZSBwb2ludCBvZiBmcmVlemluZyBJU08NCiAgIDYzOS0x IHNoYWxsIG5vdCBsYXRlciBiZSBhZGRlZCB0byBJU08gNjM5LTEuICBUaGlzIGlzIHRvIGVuc3Vy ZQ0KICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGly ZWN0ZWQgaW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMg Y29kZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2 YWlsYWJsZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IG9mIHRoZSBjYW5v bmljYWwgZm9ybSBvZiB0YWdzLCBpZiBhDQogICAyLWNoYXJhY3RlciBjb2RlIGlzIGFkZGVkIHRv IElTTyA2MzktMSBmb3IgYSBsYW5ndWFnZSBmb3Igd2hpY2ggYQ0KICAgMy1jaGFyYWN0ZXIgY29k ZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSAyLWNoYXJhY3Rlcg0KICAg Y29kZSB3aWxsIG5vdCBiZSBhZGRlZCBhcyBhIHN1YnRhZyBpbiB0aGUgcmVnaXN0cnkuICBTZWUg U2VjdGlvbiAzLjIuDQoNCiAgIEZvciBleGFtcGxlLCBpZiBzb21lIGNvbnRlbnQgd2VyZSB0YWdn ZWQgd2l0aCAnaGF3JyAoSGF3YWlpYW4pLCB3aGljaA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDhdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAg ICAgICAgIE1hcmNoIDIwMDUNCg0KDQogICBjdXJyZW50bHkgaGFzIG5vIDItY2hhcmFjdGVyIGNv ZGUsIHRoZSB0YWcgd291bGQgbm90IGJlIGludmFsaWRhdGVkDQogICBpZiBJU08gNjM5LTEgd2Vy ZSB0byBhc3NpZ24gYSAyLWNoYXJhY3RlciBjb2RlIHRvIHRoZSBIYXdhaWlhbg0KICAgbGFuZ3Vh Z2UgYXQgYSBsYXRlciBkYXRlLg0KDQogICBGb3IgZXhhbXBsZSwgb25lIG9mIHRoZSBncmFuZGZh dGhlcmVkIElBTkEgcmVnaXN0cmF0aW9ucyBpcw0KICAgImktZW5vY2hpYW4iLiAgVGhlIHN1YnRh ZyAnZW5vY2hpYW4nIGNvdWxkIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5 IGFzIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgKGFzc3VtaW5nIHRoYXQgSVNPIDYzOSBkb2Vz IG5vdA0KICAgcmVnaXN0ZXIgdGhpcyBsYW5ndWFnZSBmaXJzdCksIG1ha2luZyB0YWdzIHN1Y2gg YXMgImVub2NoaWFuLUFRIiBhbmQNCiAgICJlbm9jaGlhbi1MYXRuIiB2YWxpZC4NCg0KMi4yLjIg IEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MNCg0KICAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBs eSB0byB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnczoNCg0KICAgbyAgVGhyZWUgbGV0dGVy IHN1YnRhZ3MgaW1tZWRpYXRlbHkgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZyBhcmUNCiAg ICAgIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLCBhbnRpY2lwYXRpbmcgd29y ayB0aGF0IGlzDQogICAgICBjdXJyZW50bHkgdW5kZXIgd2F5IG9uIElTTyA2MzkuDQogICBvICBF eHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIE1VU1QgZm9sbG93IHRoZSBwcmltYXJ5IHN1YnRhZyBh bmQNCiAgICAgIHByZWNlZGUgYW55IG90aGVyIHN1YnRhZ3MuDQogICBvICBUaGVyZSBNQVkgYmUg YW55IGFkZGl0aW9uYWwgbnVtYmVyIG9mIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MuDQogICBv ICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIHdpbGwgbm90IGJlIHJlZ2lzdGVyZWQgZXhjZXB0 IGJ5DQogICAgICByZXZpc2lvbiBvZiB0aGlzIGRvY3VtZW50Lg0KICAgbyAgRXh0ZW5kZWQgbGFu Z3VhZ2Ugc3VidGFncyBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncw0KICAg ICAgZXhjZXB0IGJ5IHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEV4YW1wbGU6IElu IGEgZnV0dXJlIHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50LCB0aGUgdGFnDQog ICAiemgtZ2FuIiAocmVnaXN0ZXJlZCB1bmRlciBSRkMgMzA2NikgbWlnaHQgYmVjb21lIGEgdmFs aWQNCiAgIG5vbi1ncmFuZGZhdGhlcmVkIHRhZyBpbiB3aGljaCB0aGUgc3VidGFnICdnYW4nIG1p Z2h0IHJlcHJlc2VudCB0aGUNCiAgIENoaW5lc2UgZGlhbGVjdCAnR2FuJy4NCg0KMi4yLjMgIFNj cmlwdCBTdWJ0YWcNCg0KICAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgc2NyaXB0 IHN1YnRhZ3M6DQoNCiAgIG8gIEFsbCA0LWNoYXJhY3RlciBzdWJ0YWdzIHdlcmUgZGVmaW5lZCBh Y2NvcmRpbmcgdG8gSVNPIDE1OTI0DQogICAgICBbM10tLSJDb2RlcyBmb3IgdGhlIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSBuYW1lcyBvZiBzY3JpcHRzIjoNCiAgICAgIGFscGhhLTQgc2NyaXB0IGNv ZGVzLCBvciBzdWJzZXF1ZW50bHkgYXNzaWduZWQgYnkgdGhlIElTTyAxNTkyNA0KICAgICAgbWFp bnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLCBkZW5v dGluZw0KICAgICAgdGhlIHNjcmlwdCBvciB3cml0aW5nIHN5c3RlbSB1c2VkIGluIGNvbmp1bmN0 aW9uIHdpdGggdGhpcw0KICAgICAgbGFuZ3VhZ2UuDQogICBvICBTY3JpcHQgc3VidGFncyBNVVNU IGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcNCiAgICAgIGFu ZCBhbGwgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhbmQgTVVTVCBvY2N1ciBiZWZvcmUgYW55 IG90aGVyDQogICAgICB0eXBlIG9mIHN1YnRhZyBkZXNjcmliZWQgYmVsb3cuDQogICBvICBUaGUg c3VidGFncyAnUWFhYScgdGhyb3VnaCAnUWFieCcgYXJlIHJlc2VydmVkIGZvciBwcml2YXRlIHVz ZSBpbg0KICAgICAgbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBj b2RlcyByZXNlcnZlZCBieSBJU08NCiAgICAgIDE1OTI0IGZvciBwcml2YXRlIHVzZS4gIFRoZXNl IGNvZGVzIE1BWSBiZSB1c2VkIGZvciBub24tcmVnaXN0ZXJlZA0KICAgICAgc2NyaXB0IHZhbHVl cy4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDIuNSBmb3IgbW9yZSBpbmZvcm1hdGlvbg0KICAg ICAgb24gcHJpdmF0ZS11c2Ugc3VidGFncy4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDA1DQoNCg0KICAgbyAgU2NyaXB0IHN1YnRhZ3MgY2Fubm90IGJlIHJlZ2lzdGVy ZWQgdXNpbmcgdGhlIHByb2Nlc3MgaW4NCiAgICAgIFNlY3Rpb24gMy4zIG9mIHRoaXMgZG9jdW1l bnQuICBWYXJpYW50IHN1YnRhZ3MgbWF5IGJlIGNvbnNpZGVyZWQNCiAgICAgIGZvciByZWdpc3Ry YXRpb24gZm9yIHRoYXQgcHVycG9zZS4NCg0KICAgRXhhbXBsZTogImRlLUxhdG4iIHJlcHJlc2Vu dHMgR2VybWFuIHdyaXR0ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdC4NCg0KMi4yLjQgIFJlZ2lv biBTdWJ0YWcNCg0KICAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcmVnaW9uIHN1 YnRhZ3M6DQoNCiAgIG8gIFRoZSByZWdpb24gc3VidGFnIGRlZmluZXMgbGFuZ3VhZ2UgdmFyaWF0 aW9ucyB1c2VkIGluIGEgc3BlY2lmaWMNCiAgICAgIHJlZ2lvbiwgZ2VvZ3JhcGhpYywgb3IgcG9s aXRpY2FsIGFyZWEuICBSZWdpb24gc3VidGFncyBNVVNUIGZvbGxvdw0KICAgICAgYW55IGxhbmd1 YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwgb3Igc2NyaXB0IHN1YnRhZ3MgYW5kIE1VU1QNCiAgICAg IHByZWNlZGUgYWxsIG90aGVyIHN1YnRhZ3MuDQogICBvICBBbGwgMi1jaGFyYWN0ZXIgc3VidGFn cyBmb2xsb3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIHdlcmUgZGVmaW5lZA0KICAgICAgaW4gdGhl IElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBJU08N CiAgICAgIDMxNjYgWzRdLS0iQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBv ZiBjb3VudHJpZXMgYW5kDQogICAgICB0aGVpciBzdWJkaXZpc2lvbnMgLSBQYXJ0IDE6IENvdW50 cnkgY29kZXMiLS1hbHBoYS0yIGNvdW50cnkgY29kZXMNCiAgICAgIG9yIGFzc2lnbm1lbnRzIHN1 YnNlcXVlbnRseSBtYWRlIGJ5IHRoZSBJU08gMzE2NiBtYWludGVuYW5jZQ0KICAgICAgYWdlbmN5 IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KICAgbyAgQWxsIDMtY2hhcmFj dGVyIGNvZGVzIGNvbnNpc3Rpbmcgb2YgZGlnaXQgKG51bWVyaWMpIGNoYXJhY3RlcnMNCiAgICAg IHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2ln bm1lbnRzDQogICAgICBmb3VuZCBpbiBVTiBTdGFuZGFyZCBDb3VudHJ5IG9yIEFyZWEgQ29kZXMg Zm9yIFN0YXRpc3RpY2FsICBVc2UNCiAgICAgIFs1XSBvciBhc3NpZ25tZW50cyBzdWJzZXF1ZW50 bHkgbWFkZSBieSB0aGUgZ292ZXJuaW5nIHN0YW5kYXJkcw0KICAgICAgYm9keS4gIE5vdGUgdGhh dCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5IGNvZGVzIGFyZSBkZWZpbmVkIGluIHRoZQ0KICAgICAg SUFOQSByZWdpc3RyeToNCiAgICAgICogIFVOIG51bWVyaWMgY29kZXMgYXNzaWduZWQgdG8gJ21h Y3JvLWdlb2dyYXBoaWNhbCAoY29udGluZW50YWwpJw0KICAgICAgICAgb3Igc3ViLXJlZ2lvbnMg bm90IGFzc29jaWF0ZWQgd2l0aCBhbiBhc3NpZ25lZCBJU08gMzE2NiBhbHBoYS0yDQogICAgICAg ICBjb2RlIF9hcmVfIGRlZmluZWQuDQogICAgICAqICBVTiBudW1lcmljIGNvZGVzIGZvciAnZWNv bm9taWMgZ3JvdXBpbmdzJyBvciAnb3RoZXIgZ3JvdXBpbmdzJw0KICAgICAgICAgYXJlIF9ub3Rf IGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQgdG8NCiAg ICAgICAgIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCiAgICAgICogIENvdW50cmllcyB3aXRoIGFtYmln dW91cyBJU08gMzE2NiBhbHBoYS0yIGNvZGVzIGFzIGRlZmluZWQgaW4NCiAgICAgICAgIFNlY3Rp b24gMy4yIGFyZSBkZWZpbmVkIGluIHRoZSByZWdpc3RyeSBhbmQgYXJlIGNhbm9uaWNhbCBmb3IN CiAgICAgICAgIHRoZSBnaXZlbiBjb3VudHJ5IG9yIHJlZ2lvbiBkZWZpbmVkLg0KICAgICAgKiAg VGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRoZSBVTiBkb2N1bWVudCBh cmUNCiAgICAgICAgIF9ub3RfIGRlZmluZWQgYW5kIE1VU1QgTk9UIGJlIHVzZWQgdG8gZm9ybSBs YW5ndWFnZSB0YWdzLiAgKEF0DQogICAgICAgICB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBj cmVhdGVkIHRoZXNlIHZhbHVlcyBtYXRjaCB0aGUgSVNPDQogICAgICAgICAzMTY2IGFscGhhLTIg Y29kZXMuKQ0KICAgbyAgVGhlcmUgbWF5IGJlIGF0IG1vc3Qgb25lIHJlZ2lvbiBzdWJ0YWcgaW4g YSBsYW5ndWFnZSB0YWcuDQogICBvICBUaGUgc3VidGFncyAnQUEnLCAnUU0nLSdRWicsICdYQSct J1haJywgYW5kICdaWicgYXJlIHJlc2VydmVkIGZvcg0KICAgICAgcHJpdmF0ZSB1c2UgaW4gbGFu Z3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29ycmVzcG9uZCB0byBjb2Rlcw0KICAgICAgcmVz ZXJ2ZWQgYnkgSVNPIDMxNjYgZm9yIHByaXZhdGUgdXNlLiAgVGhlc2UgY29kZXMgTUFZIGJlIHVz ZWQgZm9yDQogICAgICBwcml2YXRlIHVzZSByZWdpb24gc3VidGFncyAoaW5zdGVhZCBvZiB1c2lu ZyBhIHByaXZhdGUtdXNlIHN1YnRhZw0KICAgICAgc2VxdWVuY2UpLiAgUGxlYXNlIHJlZmVyIHRv IFNlY3Rpb24gMi41IGZvciBtb3JlIGluZm9ybWF0aW9uIG9uDQogICAgICBwcml2YXRlIHVzZSBz dWJ0YWdzLg0KDQogICAiZGUtTGF0bi1DSCIgcmVwcmVzZW50cyBHZXJtYW4gKCdkZScpIHdyaXR0 ZW4gdXNpbmcgdGhlIExhdGluIHNjcmlwdA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMDUNCg0KDQogICAoJ0xhdG4nKSBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kICgnQ0gn KS4NCg0KICAgInNyLUxhdG4tQ1MiIHJlcHJlc2VudHMgU2VyYmlhbiAoJ3NyJykgd3JpdHRlbiB1 c2luZyBMYXRpbiBzY3JpcHQNCiAgICgnTGF0bicpIGFzIHVzZWQgaW4gU2VyYmlhIGFuZCBNb250 ZW5lZ3JvICgnQ1MnKS4NCg0KICAgImVzLTQxOSIgcmVwcmVzZW50cyBTcGFuaXNoICgnZXMnKSBh cyB1c2VkIGluIHRoZSBVTi1kZWZpbmVkIExhdGluDQogICBBbWVyaWNhIGFuZCBDYXJpYmJlYW4g cmVnaW9uICgnNDE5JykuDQoNCjIuMi41ICBWYXJpYW50IFN1YnRhZ3MNCg0KICAgVGhlIGZvbGxv d2luZyBydWxlcyBhcHBseSB0byB0aGUgdmFyaWFudCBzdWJ0YWdzOg0KDQogICBvICBWYXJpYW50 IHN1YnRhZ3MsIGFzIGEgY29sbGVjdGlvbiBpbiB0aGUgSUFOQSByZWdpc3RyeSwgYXJlIG5vdA0K ICAgICAgYXNzb2NpYXRlZCB3aXRoIGFueSBleHRlcm5hbCBzdGFuZGFyZC4gIFZhcmlhbnQgc3Vi dGFncyBhbmQgdGhlaXINCiAgICAgIG1lYW5pbmdzIGFyZSBkZWZpbmVkIGJ5IHRoZSByZWdpc3Ry YXRpb24gcHJvY2VzcyBkZWZpbmVkIGluDQogICAgICBTZWN0aW9uIDMuMy4NCiAgIG8gIFZhcmlh bnQgc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgb2YgdGhlIG90aGVyIGRlZmluZWQgc3VidGFncywg YnV0DQogICAgICBwcmVjZWRlIGFueSBleHRlbnNpb24gb3IgcHJpdmF0ZS11c2Ugc3VidGFnIHNl cXVlbmNlcy4NCiAgIG8gIE1vcmUgdGhhbiBvbmUgdmFyaWFudCBNQVkgYmUgdXNlZCB0byBmb3Jt IHRoZSBsYW5ndWFnZSB0YWcuDQogICBvICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBiZSByZWdpc3Rl cmVkIHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQogICAgICBydWxlcyBpbiBTZWN0aW9uIDMu MyBvZiB0aGlzIGRvY3VtZW50IGJlZm9yZSBiZWluZyB1c2VkIHRvIGZvcm0NCiAgICAgIGxhbmd1 YWdlIHRhZ3MuICBJbiBvcmRlciB0byBkaXN0aW5ndWlzaCB2YXJpYW50cyBmcm9tIG90aGVyIHR5 cGVzDQogICAgICBvZiBzdWJ0YWdzLCByZWdpc3RyYXRpb25zIG11c3QgbWVldCB0aGUgZm9sbG93 aW5nIGxlbmd0aCBhbmQNCiAgICAgIGNvbnRlbnQgcmVzdHJpY3Rpb25zOg0KICAgICAgKiAgVmFy aWFudCBzdWJ0YWdzIHRoYXQgYmVnaW4gd2l0aCBhIGxldHRlciAoYS16LCBBLVopIE1VU1QgYmUg YXQNCiAgICAgICAgIGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KICAgICAgKiAgVmFyaWFu dCBzdWJ0YWdzIHRoYXQgYmVnaW4gd2l0aCBhIGRpZ2l0ICgwLTkpIE1VU1QgYmUgYXQgbGVhc3QN CiAgICAgICAgIGZvdXIgY2hhcmFjdGVycyBsb25nLg0KICAgICAgKiAgVGhlIG1heGltdW0gbGVu Z3RoIG9mIGEgdmFyaWFudCBzdWJ0YWcgaXMgZWlnaHQgY2hhcmFjdGVycw0KICAgICAgICAgbG9u Zy4NCg0KICAgImVuLWJvb250IiByZXByZXNlbnRzIHRoZSBCb29udGxpbmcgZGlhbGVjdCBvZiBF bmdsaXNoLg0KDQogICAiZGUtQ0gtMTk5NiIgcmVwcmVzZW50cyBHZXJtYW4gYXMgdXNlZCBpbiBT d2l0emVybGFuZCBhbmQgYXMgd3JpdHRlbg0KICAgdXNpbmcgdGhlIHNwZWxsaW5nIHJlZm9ybSBi ZWdpbm5pbmcgaW4gdGhlIHllYXIgMTk5NiBDLkUuDQoNCjIuMi42ICBFeHRlbnNpb24gU3VidGFn cw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIGV4dGVuc2lvbnM6DQoNCiAgIG8g IEV4dGVuc2lvbiBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3RoZXIgc3VidGFncyBk ZWZpbmVkIGluDQogICAgICB0aGlzIGRvY3VtZW50IGJ5IGEgc2luZ2xlLWxldHRlciBzdWJ0YWcg KCJzaW5nbGV0b24iKS4gIFRoZQ0KICAgICAgc2luZ2xldG9uIE1VU1QgYmUgb25lIGFsbG9jYXRl ZCB0byBhIHJlZ2lzdHJhdGlvbiBhdXRob3JpdHkgdmlhDQogICAgICB0aGUgbWVjaGFuaXNtIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNCBhbmQgY2Fubm90IGJlIHRoZSBsZXR0ZXINCiAgICAgICd4 Jywgd2hpY2ggaXMgcmVzZXJ2ZWQgZm9yIHByaXZhdGUtdXNlIHN1YnRhZyBzZXF1ZW5jZXMuDQog ICBvICBOb3RlOiBQcml2YXRlLXVzZSBzdWJ0YWcgc2VxdWVuY2VzIHN0YXJ0aW5nIHdpdGggdGhl IHNpbmdsZXRvbg0KICAgICAgc3VidGFnICd4JyBhcmUgZGVzY3JpYmVkIGJlbG93Lg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAg ICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFu Z3RhZ3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIG8gIEFuIGV4dGVu c2lvbiBNVVNUIGZvbGxvdyBhdCBsZWFzdCBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnLiAgVGhh dA0KICAgICAgaXMsIGEgbGFuZ3VhZ2UgdGFnIGNhbm5vdCBiZWdpbiB3aXRoIGFuIGV4dGVuc2lv bi4gIEV4dGVuc2lvbnMNCiAgICAgIGV4dGVuZCBsYW5ndWFnZSB0YWdzLCB0aGV5IGRvIG5vdCBv dmVycmlkZSBvciByZXBsYWNlIHRoZW0uICBGb3INCiAgICAgIGV4YW1wbGUsICJhLXZhbHVlIiBp cyBub3QgYSB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWcsIHdoaWxlDQogICAgICAiZGUtYS12YWx1 ZSIgaXMuDQogICBvICBFYWNoIHNpbmdsZXRvbiBzdWJ0YWcgTVVTVCBhcHBlYXIgYXQgbW9zdCBv bmUgdGltZSBpbiBlYWNoIHRhZw0KICAgICAgKG90aGVyIHRoYW4gYXMgYSBwcml2YXRlLXVzZSBz dWJ0YWcpLiAgVGhhdCBpcywgc2luZ2xldG9uIHN1YnRhZ3MNCiAgICAgIE1VU1QgTk9UIGJlIHJl cGVhdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImVuLWEtYmJiLWEtY2NjIiBpcw0KICAgICAg aW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2EnIGFwcGVhcnMgdHdpY2UuDQogICBvICBFeHRl bnNpb24gc3VidGFncyBNVVNUIG1lZXQgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0K ICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50Lg0KICAgbyAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IHdoYXRldmVyIHJlcXVpcmVt ZW50cyBhcmUgc2V0IGJ5IHRoZQ0KICAgICAgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRoZWlyIHNp bmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVyDQogICAgICByZXF1aXJlbWVudHMgYXJlIHByb3Zp ZGVkIGJ5IHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkuDQogICBvICBFYWNoIGV4dGVuc2lvbiBz dWJ0YWcgTVVTVCBiZSBmcm9tIHR3byB0byBlaWdodCBjaGFyYWN0ZXJzIGxvbmcNCiAgICAgIGFu ZCBjb25zaXN0IHNvbGVseSBvZiBsZXR0ZXJzIG9yIGRpZ2l0cywgd2l0aCBlYWNoIHN1YnRhZw0K ICAgICAgc2VwYXJhdGVkIGJ5IGEgc2luZ2xlICctJy4NCiAgIG8gIEVhY2ggc2luZ2xldG9uIE1V U1QgYmUgZm9sbG93ZWQgYnkgYXQgbGVhc3Qgb25lIGV4dGVuc2lvbiBzdWJ0YWcuDQogICAgICBG b3IgZXhhbXBsZSwgdGhlIHRhZyAidGxoLWEtYi1mb28iIGlzIGludmFsaWQgYmVjYXVzZSB0aGUg Zmlyc3QNCiAgICAgIHNpbmdsZXRvbiAnYScgaXMgZm9sbG93ZWQgaW1tZWRpYXRlbHkgYnkgYW5v dGhlciBzaW5nbGV0b24gJ2InLg0KICAgbyAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cg YWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgIHNjcmlwdCwgcmVnaW9uIGFu ZCB2YXJpYW50IHN1YnRhZ3MgaW4gYSB0YWcuDQogICBvICBBbGwgc3VidGFncyBmb2xsb3dpbmcg dGhlIHNpbmdsZXRvbiBhbmQgYmVmb3JlIGFub3RoZXIgc2luZ2xldG9uDQogICAgICBhcmUgcGFy dCBvZiB0aGUgZXh0ZW5zaW9uLiAgRXhhbXBsZTogSW4gdGhlIHRhZyAiZnItYS1MYXRuIiwgdGhl DQogICAgICBzdWJ0YWcgJ0xhdG4nIGRvZXMgbm90IHJlcHJlc2VudCB0aGUgc2NyaXB0IHN1YnRh ZyAnTGF0bicgZGVmaW5lZA0KICAgICAgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lz dHJ5LiAgSXRzIG1lYW5pbmcgaXMgZGVmaW5lZCBieQ0KICAgICAgdGhlIGV4dGVuc2lvbiAnYScu DQogICBvICBJbiB0aGUgZXZlbnQgdGhhdCBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBhcHBlYXJz IGluIGEgc2luZ2xlIHRhZywNCiAgICAgIHRoZSB0YWcgU0hPVUxEIGJlIGNhbm9uaWNhbGl6ZWQg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi40LjEuDQoNCiAgIEZvciBleGFtcGxlLCBpZiB0aGUg cHJlZml4IHNpbmdsZXRvbiAncicgYW5kIHRoZSBzaG93biBzdWJ0YWdzIHdlcmUNCiAgIGRlZmlu ZWQsIHRoZW4gdGhlIGZvbGxvd2luZyB0YWcgd291bGQgYmUgYSB2YWxpZCBleGFtcGxlOg0KICAg ImVuLUxhdG4tR0ItYm9vbnQtci1leHRlbmRlZC1zZXF1ZW5jZS14LXByaXZhdGUiDQoNCjIuMi43 ICBQcml2YXRlIFVzZSBTdWJ0YWdzDQoNCiAgIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8g cHJpdmF0ZS11c2Ugc3VidGFnczoNCg0KICAgbyAgUHJpdmF0ZS11c2Ugc3VidGFncyBhcmUgc2Vw YXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0KICAgICAgaW4gdGhpcyBkb2N1 bWVudCBieSB0aGUgcmVzZXJ2ZWQgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgJ3gnLg0KICAgbyAg UHJpdmF0ZS11c2Ugc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxh bmd1YWdlLA0KICAgICAgc2NyaXB0LCByZWdpb24sIHZhcmlhbnQsIGFuZCBleHRlbnNpb24gc3Vi dGFncyBpbiB0aGUgdGFnLg0KICAgICAgQW5vdGhlciB3YXkgb2Ygc2F5aW5nIHRoaXMgaXMgdGhh dCBhbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlDQogICAgICBzaW5nbGV0b24gJ3gnIE1VU1QgYmUg Y29uc2lkZXJlZCBwcml2YXRlIHVzZS4gIEV4YW1wbGU6IFRoZSBzdWJ0YWcNCiAgICAgICdVUycg aW4gdGhlIHRhZyAiZW4teC1VUyIgaXMgYSBwcml2YXRlIHVzZSBzdWJ0YWcuDQogICBvICBVbmxp a2UgRXh0ZW5zaW9ucywgYSB0YWcgTUFZIGNvbnNpc3QgZW50aXJlbHkgb2YgcHJpdmF0ZS11c2UN CiAgICAgIHN1YnRhZ3MuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAy MDA1DQoNCg0KICAgbyAgTm8gc291cmNlIGlzIGRlZmluZWQgZm9yIHByaXZhdGUgdXNlIHN1YnRh Z3MuICBVc2Ugb2YgcHJpdmF0ZSB1c2UNCiAgICAgIHN1YnRhZ3MgaXMgYnkgcHJpdmF0ZSBhZ3Jl ZW1lbnQgYW5kIFNIT1VMRCBOT1QgYmUgY29uc2lkZXJlZCBwYXJ0DQogICAgICBvZiB0aGlzIGRv Y3VtZW50Lg0KDQogICBGb3IgZXhhbXBsZTogVXNlcnMgd2hvIHdpc2hlZCB0byB1dGlsaXplIFNJ TCBFdGhub2xvZ3VlIGZvcg0KICAgaWRlbnRpZmljYXRpb24gbWlnaHQgYWdyZWUgdG8gZXhjaGFu Z2UgdGFncyBzdWNoIGFzDQogICAiYXotQXJhYi14LUFaRS1kZXJiZW5kIi4gIFRoaXMgZXhhbXBs ZSBjb250YWlucyB0d28gcHJpdmF0ZS11c2UNCiAgIHN1YnRhZ3MuICBUaGUgZmlyc3QgaXMgJ0Fa RScgYW5kIHRoZSBzZWNvbmQgaXMgJ2RlcmJlbmQnLg0KDQoyLjIuOCAgUHJlLUV4aXN0aW5nIFJG QyAzMDY2IFJlZ2lzdHJhdGlvbnMNCg0KICAgRXhpc3RpbmcgSUFOQS1yZWdpc3RlcmVkIGxhbmd1 YWdlIHRhZ3MgZnJvbSBSRkMgMTc2NiBhbmQvb3IgUkZDIDMwNjYNCiAgIHRoYXQgYXJlIG5vdCBk ZWZpbmVkIGJ5IGFkZGl0aW9ucyB0byB0aGlzIGRvY3VtZW50IG1haW50YWluIHRoZWlyDQogICB2 YWxpZGl0eS4gIElBTkEgd2lsbCBtYWludGFpbiB0aGVzZSB0YWdzIGluIHRoZSByZWdpc3RyeSB1 bmRlciBlaXRoZXINCiAgIHRoZSAiZ3JhbmRmYXRoZXJlZCIgb3IgInJlZHVuZGFudCIgdHlwZS4g IEZvciBtb3JlIGluZm9ybWF0aW9uIHNlZQ0KICAgQXBwZW5kaXggQy4NCg0KICAgSXQgaXMgaW1w b3J0YW50IHRvIG5vdGUgdGhhdCBhbGwgbGFuZ3VhZ2UgdGFncyBmb3JtZWQgdW5kZXIgdGhlDQog ICBndWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQgd2VyZSBlaXRoZXIgbGVnYWwsIHdlbGwtZm9y bWVkIHRhZ3Mgb3INCiAgIHdlcmUgdmFsaWQgZm9yIHBvdGVudGlhbCByZWdpc3RyYXRpb24gdW5k ZXIgUkZDIDMwNjYuDQoNCjIuMi45ICBQb3NzaWJpbGl0aWVzIGZvciBSZWdpc3RyYXRpb24NCg0K ICAgUG9zc2liaWxpdGllcyBmb3IgcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3MgaW5jbHVkZToNCg0K ICAgbyAgUHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIGZvciBsYW5ndWFnZXMgbm90IGxpc3RlZCBp biBJU08gNjM5IHRoYXQNCiAgICAgIGFyZSBub3QgdmFyaWFudHMgb2YgYW55IGxpc3RlZCBvciBy ZWdpc3RlcmVkIGxhbmd1YWdlLCBjYW4gYmUNCiAgICAgIHJlZ2lzdGVyZWQuICBBdCB0aGUgdGlt ZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkIHRoZXJlIHdlcmUgbm8NCiAgICAgIGV4YW1wbGVz IG9mIHRoaXMgZm9ybSBvZiBzdWJ0YWcuICBCZWZvcmUgYXR0ZW1wdGluZyB0byByZWdpc3RlciBh DQogICAgICBsYW5ndWFnZSBzdWJ0YWcsIHRoZXJlIE1VU1QgYmUgYW4gYXR0ZW1wdCB0byByZWdp c3RlciB0aGUgbGFuZ3VhZ2UNCiAgICAgIHdpdGggSVNPIDYzOS4gIE5vIGxhbmd1YWdlIHN1YnRh Z3Mgd2lsbCBiZSByZWdpc3RlcmVkIGZvciBjb2Rlcw0KICAgICAgdGhhdCBleGlzdCBpbiBJU08g NjM5LTEgb3IgSVNPIDYzOS0yLCB3aGljaCBhcmUgdW5kZXINCiAgICAgIGNvbnNpZGVyYXRpb24g YnkgdGhlIElTTyA2MzkgbWFpbnRlbmFuY2Ugb3IgcmVnaXN0cmF0aW9uDQogICAgICBhdXRob3Jp dGllcywgb3Igd2hpY2ggaGF2ZSBuZXZlciBiZWVuIGF0dGVtcHRlZCBmb3IgcmVnaXN0cmF0aW9u DQogICAgICB3aXRoIHRob3NlIGF1dGhvcml0aWVzLiAgSWYgSVNPIDYzOSBoYXMgcHJldmlvdXNs eSByZWplY3RlZCBhDQogICAgICBsYW5ndWFnZSBmb3IgcmVnaXN0cmF0aW9uLCBpdCBpcyByZWFz b25hYmxlIHRvIGFzc3VtZSB0aGF0IHRoZXJlDQogICAgICBNVVNUIGJlIGFkZGl0aW9uYWwgdmVy eSBjb21wZWxsaW5nIGV2aWRlbmNlIG9mIG5lZWQgYmVmb3JlIGl0IHdpbGwNCiAgICAgIGJlIHJl Z2lzdGVyZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHRvIHRoZSBleHRlbnQgdGhhdCBpdCBpcyB2 ZXJ5DQogICAgICB1bmxpa2VseSB0aGF0IGFueSBzdWJ0YWdzIHdpbGwgYmUgcmVnaXN0ZXJlZCBv ZiB0aGlzIHR5cGUpLg0KICAgbyAgRGlhbGVjdCBvciBvdGhlciBkaXZpc2lvbnMgb3IgdmFyaWF0 aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQogICAgICBvcnRob2dyYXBoeSwgd3JpdGluZyBz eXN0ZW0sIHJlZ2lvbmFsIHZhcmlhdGlvbiwgb3IgaGlzdG9yaWNhbA0KICAgICAgdXNhZ2UgbWF5 IGJlIHJlZ2lzdGVyZWQgYXMgdmFyaWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBsZSBpcyB0aGUNCiAg ICAgICdzY291c2UnIHN1YnRhZyAodGhlIFNjb3VzZSBkaWFsZWN0IG9mIEVuZ2xpc2gpLg0KDQog ICBUaGlzIGRvY3VtZW50IGxlYXZlcyB0aGUgZGVjaXNpb24gb24gd2hhdCBzdWJ0YWdzIGFyZSBh cHByb3ByaWF0ZSBvcg0KICAgbm90IHRvIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiAzLjMuDQoNCiAgIElTTyA2MzkgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFn ZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzIGluDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAx M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJ U08gNjM5LiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24g Q2VudHJlIGZvciBUZXJtaW5vbG9neSAoSW5mb3Rlcm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIs IEFULTExMjANCiAgIFdpZW4sIEF1c3RyaWENCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQu ICAzMTIgRmF4OiArNDMgMSAyMTYgMzIgNzINCg0KICAgSVNPIDYzOS0yIGRlZmluZXMgYSBtYWlu dGVuYW5jZSBhZ2VuY3kgZm9yIGFkZGl0aW9ucyB0byBhbmQgY2hhbmdlcw0KICAgaW4gdGhlIGxp c3Qgb2YgbGFuZ3VhZ2VzIGluIElTTyA2MzktMi4gIFRoaXMgYWdlbmN5IGlzOg0KDQogICBMaWJy YXJ5IG9mIENvbmdyZXNzDQogICBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBNQVJDIFN0YW5kYXJk cyBPZmZpY2UNCiAgIFdhc2hpbmd0b24sIEQuQy4gIDIwNTQwIFVTQQ0KICAgUGhvbmU6ICsxIDIw MiA3MDcgNjIzNyAgRmF4OiArMSAyMDIgNzA3IDAxMTUNCiAgIFVSTDogaHR0cDovL3d3dy5sb2Mu Z292L3N0YW5kYXJkcy9pc282MzkNCg0KICAgVGhlIG1haW50ZW5hbmNlIGFnZW5jeSBmb3IgSVNP IDMxNjYgKGNvdW50cnkgY29kZXMpIGlzOg0KDQogICBJU08gMzE2NiBNYWludGVuYW5jZSBBZ2Vu Y3kNCiAgIGMvbyBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9u DQogICBDYXNlIHBvc3RhbGUgNTYNCiAgIENILTEyMTEgR2VuZXZhIDIwIFN3aXR6ZXJsYW5kDQog ICBQaG9uZTogKzQxIDIyIDc0OSA3MiAzMyAgRmF4OiArNDEgMjIgNzQ5IDczIDQ5DQogICBVUkw6 IGh0dHA6Ly93d3cuaXNvLm9yZy9pc28vZW4vcHJvZHMtc2VydmljZXMvaXNvMzE2Nm1hL2luZGV4 Lmh0bWwNCg0KICAgVGhlIHJlZ2lzdHJhdGlvbiBhdXRob3JpdHkgZm9yIElTTyAxNTkyNCAoc2Ny aXB0IGNvZGVzKSBpczoNCg0KICAgVW5pY29kZSBDb25zb3J0aXVtIEJveCAzOTE0NzYNCiAgIE1v dW50YWluIFZpZXcsIENBIDk0MDM5LTE0NzYsIFVTQQ0KICAgVVJMOiBodHRwOi8vd3d3LnVuaWNv ZGUub3JnL2lzbzE1OTI0DQoNCiAgIFRoZSBTdGF0aXN0aWNzIERpdmlzaW9uIG9mIHRoZSBVbml0 ZWQgTmF0aW9ucyBTZWNyZXRhcmlhdCBtYWludGFpbnMNCiAgIHRoZSBTdGFuZGFyZCBDb3VudHJ5 IG9yIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSBhbmQgY2FuIGJlDQogICByZWFjaGVk IGF0Og0KDQogICBTdGF0aXN0aWNhbCBTZXJ2aWNlcyBCcmFuY2gNCiAgIFN0YXRpc3RpY3MgRGl2 aXNpb24NCiAgIFVuaXRlZCBOYXRpb25zLCBSb29tIERDMi0xNjIwDQogICBOZXcgWW9yaywgTlkg MTAwMTcsIFVTQQ0KDQogICBGYXg6ICsxLTIxMi05NjMtMDYyMw0KICAgRS1tYWlsOiBzdGF0aXN0 aWNzQHVuLm9yZw0KICAgVVJMOiBodHRwOi8vdW5zdGF0cy51bi5vcmcvdW5zZC9tZXRob2RzL200 OS9tNDlhbHBoYS5odG0NCg0KMi4yLjEwICBDbGFzc2VzIG9mIENvbmZvcm1hbmNlDQoNCiAgIElt cGxlbWVudGF0aW9ucyBtYXkgd2lzaCB0byBleHByZXNzIHRoZWlyIGxldmVsIG9mIGNvbmZvcm1h bmNlIHdpdGgNCiAgIHRoZSBydWxlcyBhbmQgcHJhY3RpY2VzIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50LiAgVGhlcmUgYXJlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAwNQ0KDQoNCiAgIGdlbmVyYWxseSB0d28gY2xhc3NlcyBvZiBjb25mb3JtaW5nIGltcGxlbWVu dGF0aW9uczogIndlbGwtZm9ybWVkIg0KICAgcHJvY2Vzc29ycyBhbmQgInZhbGlkYXRpbmciIHBy b2Nlc3NvcnMuICBDbGFpbXMgb2YgY29uZm9ybWFuY2UgU0hPVUxEDQogICBleHBsaWNpdGx5IHJl ZmVyZW5jZSBvbmUgb2YgdGhlc2UgZGVmaW5pdGlvbnMuDQoNCiAgIEFuIGltcGxlbWVudGF0aW9u IHRoYXQgY2xhaW1zIHRvIGNoZWNrIGZvciB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWdzDQogICBN VVNUOg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGFuZCBhbGwgb2YgaXRzIHN1YnRhZ3MsIGlu Y2x1ZGluZyBleHRlbnNpb24gYW5kDQogICAgICBwcml2YXRlLXVzZSBzdWJ0YWdzLCBjb25mb3Jt IHRvIHRoZSBBQk5GIG9yIHRoYXQgdGhlIHRhZyBpcyBvbiB0aGUNCiAgICAgIGxpc3Qgb2YgZ3Jh bmRmYXRoZXJlZCB0YWdzLg0KICAgbyAgQ2hlY2sgdGhhdCBzaW5nbGV0b24gc3VidGFncyB0aGF0 IGlkZW50aWZ5IGV4dGVuc2lvbnMgZG8gbm90DQogICAgICByZXBlYXQuICBGb3IgZXhhbXBsZSwg dGhlIHRhZyAiZW4tYS14eC1iLXl5LWEtenoiIGlzIG5vdA0KICAgICAgd2VsbC1mb3JtZWQuDQoN CiAgIFdlbGwtZm9ybWVkIHByb2Nlc3NvcnMgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gaW1w bGVtZW50IHRoZQ0KICAgY2Fub25pY2FsaXphdGlvbiBydWxlcyBjb250YWluZWQgaW4gU2VjdGlv biAyLjQuMS4NCg0KICAgQW4gaW1wbGVtZW50YXRpb24gdGhhdCBjbGFpbXMgdG8gYmUgdmFsaWRh dGluZyBNVVNUOg0KICAgbyAgQ2hlY2sgdGhhdCB0aGUgdGFnIGlzIHdlbGwtZm9ybWVkLg0KICAg byAgU3BlY2lmeSB0aGUgcGFydGljdWxhciByZWdpc3RyeSBkYXRlIGZvciB3aGljaCB0aGUgaW1w bGVtZW50YXRpb24NCiAgICAgIHBlcmZvcm1zIHZhbGlkYXRpb24gb2Ygc3VidGFncy4NCiAgIG8g IENoZWNrIHRoYXQgZWl0aGVyIHRoZSB0YWcgaXMgYSBncmFuZGZhdGhlcmVkIHRhZywgb3IgdGhh dCBhbGwNCiAgICAgIGxhbmd1YWdlLCBzY3JpcHQsIHJlZ2lvbiwgYW5kIHZhcmlhbnQgc3VidGFn cyBjb25zaXN0IG9mIHZhbGlkDQogICAgICBjb2RlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3Mg YWNjb3JkaW5nIHRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzDQogICAgICBvZiB0aGUgcGFydGljdWxh ciBkYXRlIHNwZWNpZmllZCBieSB0aGUgaW1wbGVtZW50YXRpb24uDQogICBvICBTcGVjaWZ5IHdo aWNoLCBpZiBhbnksIGV4dGVuc2lvbiBSRkNzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjQNCiAg ICAgIGFyZSBzdXBwb3J0ZWQsIGluY2x1ZGluZyB2ZXJzaW9uLCByZXZpc2lvbiwgYW5kIGRhdGUu DQogICBvICBGb3IgYW55IHN1Y2ggZXh0ZW5zaW9ucyBzdXBwb3J0ZWQsIGNoZWNrIHRoYXQgYWxs IHN1YnRhZ3MgdXNlZCBpbg0KICAgICAgdGhhdCBleHRlbnNpb24gYXJlIHZhbGlkLg0KICAgbyAg SWYgdGhlIHByb2Nlc3NvciBnZW5lcmF0ZXMgdGFncywgaXQgTVVTVCBkbyBzbyBpbiBjYW5vbmlj YWwgZm9ybSwNCiAgICAgIGluY2x1ZGluZyBhbnkgc3VwcG9ydGVkIGV4dGVuc2lvbnMsIGFzIGRl ZmluZWQgaW4gU2VjdGlvbiAyLjQuMS4NCg0KMi4zICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnDQoN CiAgIE9uZSBtYXkgb2NjYXNpb25hbGx5IGJlIGZhY2VkIHdpdGggc2V2ZXJhbCBwb3NzaWJsZSB0 YWdzIGZvciB0aGUgc2FtZQ0KICAgYm9keSBvZiB0ZXh0Lg0KDQogICBJbnRlcm9wZXJhYmlsaXR5 IGlzIGJlc3Qgc2VydmVkIHdoZW4gYWxsIHVzZXJzIHVzZSB0aGUgc2FtZSBsYW5ndWFnZQ0KICAg dGFnIGluIG9yZGVyIHRvIHJlcHJlc2VudCB0aGUgc2FtZSBsYW5ndWFnZS4gIElmIGFuIGFwcGxp Y2F0aW9uIGhhcw0KICAgcmVxdWlyZW1lbnRzIHRoYXQgbWFrZSB0aGUgcnVsZXMgaGVyZSBpbmFw cGxpY2FibGUsIHRoZW4gdGhhdA0KICAgYXBwbGljYXRpb24gcmlza3MgZGFtYWdpbmcgaW50ZXJv cGVyYWJpbGl0eS4gIEl0IGlzIFNUUk9OR0xZDQogICBSRUNPTU1FTkRFRCB0aGF0IHVzZXJzIG5v dCBkZWZpbmUgdGhlaXIgb3duIHJ1bGVzIGZvciBsYW5ndWFnZSB0YWcNCiAgIGNob2ljZS4NCg0K ICAgU3RhbmRhcmRzLCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHJlZmVyZW5jZSB0 aGlzIGRvY3VtZW50DQogICBub3JtYXRpdmVseSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRv IHRoZSBvbmVzIGdpdmVuIGluIHRoaXMNCiAgIHNlY3Rpb24gTVVTVCBzcGVjaWZ5IGhvdyB0aGUg cHJvY2VkdXJlIHZhcmllcyBmcm9tIHRoZSBvbmUgZ2l2ZW4NCiAgIGhlcmUuDQoNCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAg ICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBsYW5ndGFn cyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoNCg0KICAgMS4gIFVzZSBhcyBwcmVj aXNlIGEgdGFnIGFzIHBvc3NpYmxlLCBidXQgbm8gbW9yZSBzcGVjaWZpYyB0aGFuIGlzDQogICAg ICAganVzdGlmaWVkLiAgRm9yIGV4YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBmb3IgdGFnZ2lu ZyBhbiBlbWFpbA0KICAgICAgIHdyaXR0ZW4gaW4gR2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIg aXMgcHJvYmFibHkgdW5uZWNlc3NhcmlseQ0KICAgICAgIHByZWNpc2UgZm9yIHN1Y2ggYSB0YXNr Lg0KICAgMi4gIEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUgbm90IGltcG9ydGFudCBmb3Ig ZGlzdGluZ3Vpc2hpbmcNCiAgICAgICBjb250ZW50IGluIGFuIGFwcGxpY2F0aW9uLiAgRm9yIGV4 YW1wbGUsIGluY2x1ZGluZyB0aGUgc2NyaXB0DQogICAgICAgc3VidGFnIGluICJlbi1MYXRuLVVT IiBpcyBnZW5lcmFsbHkgdW5uZWNlc3NhcnksIHNpbmNlIG5lYXJseSBhbGwNCiAgICAgICBFbmds aXNoIHRleHRzIGFyZSB3cml0dGVuIGluIHRoZSBMYXRpbiBzY3JpcHQgYW5kIGl0IGlzIGdlbmVy YWxseQ0KICAgICAgIG5vdCBpbXBvcnRhbnQgdG8gZmlsdGVyIG91dCB0aG9zZSBmZXcgdGhhdCBh cmUgbm90Lg0KICAgMy4gIFVzZSB0aGUgY2Fub25pY2FsIHN1YnRhZyBmcm9tIHRoZSBJQU5BIHJl Z2lzdHJ5IGluIHByZWZlcmVuY2UgdG8NCiAgICAgICBhbnkgb2YgaXRzIGFsaWFzZXMuICBGb3Ig ZXhhbXBsZSwgeW91IHNob3VsZCB1c2UgJ2hlJyBmb3IgSGVicmV3DQogICAgICAgaW4gcHJlZmVy ZW5jZSB0byAnaXcnLg0KICAgNC4gIFlvdSBTSE9VTEQgTk9UIHVzZSB0aGUgJ1VORCcgKFVuZGV0 ZXJtaW5lZCkgbGFuZ3VhZ2Ugc3VidGFnIHRvDQogICAgICAgbGFiZWwgY29udGVudCwgZXZlbiBp ZiB0aGUgbGFuZ3VhZ2UgaXMgdW5rbm93bi4gIE9taXR0aW5nIHRoZSB0YWcNCiAgICAgICBpcyBw cmVmZXJyZWQuICBTb21lIHByb3RvY29scyBtYXkgZm9yY2UgeW91IHRvIGdpdmUgYSB2YWx1ZSBm b3INCiAgICAgICB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUgJ1VORCcgc3VidGFnIG1heSBiZSB1 c2VmdWwgd2hlbiBtYXRjaGluZw0KICAgICAgIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFpbiBzaXR1 YXRpb25zLg0KICAgNS4gIFlvdSBTSE9VTEQgTk9UIHVzZSB0aGUgJ01VTCcgKE11bHRpcGxlKSBz dWJ0YWcgaWYgdGhlIHByb3RvY29sDQogICAgICAgYWxsb3dzIHlvdSB0byB1c2UgbXVsdGlwbGUg bGFuZ3VhZ2VzLCBhcyBpcyB0aGUgY2FzZSBmb3IgdGhlDQogICAgICAgQ29udGVudC1MYW5ndWFn ZSBoZWFkZXIgaW4gSFRUUC4NCiAgIDYuICBZb3UgU0hPVUxEIE5PVCB1c2UgdGhlIHNhbWUgdmFy aWFudCBzdWJ0YWcgbW9yZSB0aGFuIG9uY2Ugd2l0aGluDQogICAgICAgYSBsYW5ndWFnZSB0YWcu ICBGb3IgZXhhbXBsZSwgeW91IHNob3VsZCBub3QgdXNlDQogICAgICAgImVuLVVTLWJvb250LWJv b250Ii4NCg0KICAgVG8gZW5zdXJlIGNvbnNpc3RlbnQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwg dGhpcyBkb2N1bWVudCBjb250YWlucw0KICAgc2V2ZXJhbCBwcm92aXNpb25zIHRvIGFjY291bnQg Zm9yIHBvdGVudGlhbCBpbnN0YWJpbGl0eSBpbiB0aGUNCiAgIHN0YW5kYXJkcyB1c2VkIHRvIGRl ZmluZSB0aGUgc3VidGFncyB0aGF0IG1ha2UgdXAgbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIHBy b3Zpc2lvbnMgbWVhbiB0aGF0IG5vIGxhbmd1YWdlIHRhZyBjcmVhdGVkIHVuZGVyIHRoZSBydWxl cyBpbg0KICAgdGhpcyBkb2N1bWVudCB3aWxsIGJlY29tZSBvYnNvbGV0ZS4gIEluIGFkZGl0aW9u LCB0YWdzIHRoYXQgYXJlIGluDQogICBjYW5vbmljYWwgZm9ybSB3aWxsIGFsd2F5cyBiZSBpbiBj YW5vbmljYWwgZm9ybS4NCg0KMi40ICBNZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcNCg0KICAg VGhlIGxhbmd1YWdlIHRhZyBhbHdheXMgZGVmaW5lcyBhIGxhbmd1YWdlIGFzIHNwb2tlbiAob3Ig d3JpdHRlbiwNCiAgIHNpZ25lZCBvciBvdGhlcndpc2Ugc2lnbmFsZWQpIGJ5IGh1bWFuIGJlaW5n cyBmb3IgY29tbXVuaWNhdGlvbiBvZg0KICAgaW5mb3JtYXRpb24gdG8gb3RoZXIgaHVtYW4gYmVp bmdzLiAgQ29tcHV0ZXIgbGFuZ3VhZ2VzIHN1Y2ggYXMNCiAgIHByb2dyYW1taW5nIGxhbmd1YWdl cyBhcmUgZXhwbGljaXRseSBleGNsdWRlZC4NCg0KICAgSWYgYSBsYW5ndWFnZSB0YWcgQiBjb250 YWlucyBsYW5ndWFnZSB0YWcgQSBhcyBhIHByZWZpeCwgdGhlbiBCIGlzDQogICB0eXBpY2FsbHkg Im5hcnJvd2VyIiBvciAibW9yZSBzcGVjaWZpYyIgdGhhbiBBLiAgRm9yIGV4YW1wbGUsDQogICAi emgtSGFudC1UVyIgaXMgbW9yZSBzcGVjaWZpYyB0aGFuICJ6aC1IYW50Ii4NCg0KICAgVGhpcyBy ZWxhdGlvbnNoaXAgaXMgbm90IGd1YXJhbnRlZWQgaW4gYWxsIGNhc2VzOiBzcGVjaWZpY2FsbHks DQogICBsYW5ndWFnZXMgdGhhdCBiZWdpbiB3aXRoIHRoZSBzYW1lIHNlcXVlbmNlIG9mIHN1YnRh Z3MgYXJlIE5PVA0KICAgZ3VhcmFudGVlZCB0byBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFs dGhvdWdoIHRoZXkgbWF5IGJlLiAgRm9yDQogICBleGFtcGxlLCB0aGUgdGFnICJheiIgc2hhcmVz IGEgcHJlZml4IHdpdGggYm90aCAiYXotTGF0biINCiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVz aW5nIHRoZSBMYXRpbiBzY3JpcHQpIGFuZCAiYXotQ3lybCINCiAgIChBemVyYmFpamFuaSB3cml0 dGVuIHVzaW5nIHRoZSBDeXJpbGxpYyBzY3JpcHQpLiAgQSBwZXJzb24gZmx1ZW50IGluDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAg ICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFu Z3RhZ3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIG9uZSBzY3JpcHQg bWF5IG5vdCBiZSBhYmxlIHRvIHJlYWQgdGhlIG90aGVyLCBldmVuIHRob3VnaCB0aGUgdGV4dA0K ICAgbWlnaHQgYmUgaWRlbnRpY2FsLiAgQ29udGVudCB0YWdnZWQgYXMgImF6IiBtb3N0IHByb2Jh Ymx5IGlzIHdyaXR0ZW4NCiAgIGluIGp1c3Qgb25lIHNjcmlwdCBhbmQgdGh1cyBtaWdodCBub3Qg YmUgaW50ZWxsaWdpYmxlIHRvIGEgcmVhZGVyDQogICBmYW1pbGlhciB3aXRoIHRoZSBvdGhlciBz Y3JpcHQuDQoNCiAgIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdGFnIGFuZCB0aGUgaW5m b3JtYXRpb24gaXQgcmVsYXRlcyB0byBpcw0KICAgZGVmaW5lZCBieSB0aGUgc3RhbmRhcmQgZGVz Y3JpYmluZyB0aGUgY29udGV4dCBpbiB3aGljaCBpdCBhcHBlYXJzLg0KICAgQWNjb3JkaW5nbHks IHRoaXMgc2VjdGlvbiBjYW4gb25seSBnaXZlIHBvc3NpYmxlIGV4YW1wbGVzIG9mIGl0cw0KICAg dXNhZ2UuDQogICBvICBGb3IgYSBzaW5nbGUgaW5mb3JtYXRpb24gb2JqZWN0LCB0aGUgYXNzb2Np YXRlZCBsYW5ndWFnZSB0YWdzDQogICAgICBtaWdodCBiZSBpbnRlcnByZXRlZCBhcyB0aGUgc2V0 IG9mIGxhbmd1YWdlcyB0aGF0IGlzIHJlcXVpcmVkIGZvcg0KICAgICAgYSBjb21wbGV0ZSBjb21w cmVoZW5zaW9uIG9mIHRoZSBjb21wbGV0ZSBvYmplY3QuICBFeGFtcGxlOiBQbGFpbg0KICAgICAg dGV4dCBkb2N1bWVudHMuDQogICBvICBGb3IgYW4gYWdncmVnYXRpb24gb2YgaW5mb3JtYXRpb24g b2JqZWN0cywgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UNCiAgICAgIHRhZ3MgY291bGQgYmUgdGFr ZW4gYXMgdGhlIHNldCBvZiBsYW5ndWFnZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cw0KICAgICAg b2YgdGhhdCBhZ2dyZWdhdGlvbi4gIEV4YW1wbGVzOiBEb2N1bWVudCBzdG9yZXMgYW5kIGxpYnJh cmllcy4NCiAgIG8gIEZvciBpbmZvcm1hdGlvbiBvYmplY3RzIHdob3NlIHB1cnBvc2UgaXMgdG8g cHJvdmlkZSBhbHRlcm5hdGl2ZXMsDQogICAgICB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0YWdz IGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgaGludCB0aGF0IHRoZQ0KICAgICAgY29udGVudCBpcyBw cm92aWRlZCBpbiBzZXZlcmFsIGxhbmd1YWdlcywgYW5kIHRoYXQgb25lIGhhcyB0bw0KICAgICAg aW5zcGVjdCBlYWNoIG9mIHRoZSBhbHRlcm5hdGl2ZXMgaW4gb3JkZXIgdG8gZmluZCBpdHMgbGFu Z3VhZ2Ugb3INCiAgICAgIGxhbmd1YWdlcy4gIEluIHRoaXMgY2FzZSwgdGhlIHByZXNlbmNlIG9m IG11bHRpcGxlIHRhZ3MgbWlnaHQgbm90DQogICAgICBtZWFuIHRoYXQgb25lIG5lZWRzIHRvIGJl IG11bHRpLWxpbmd1YWwgdG8gZ2V0IGNvbXBsZXRlDQogICAgICB1bmRlcnN0YW5kaW5nIG9mIHRo ZSBkb2N1bWVudC4gIEV4YW1wbGU6IE1JTUUNCiAgICAgIG11bHRpcGFydC9hbHRlcm5hdGl2ZS4N CiAgIG8gIEluIG1hcmt1cCBsYW5ndWFnZXMsIHN1Y2ggYXMgSFRNTCBhbmQgWE1MLCBsYW5ndWFn ZSBpbmZvcm1hdGlvbg0KICAgICAgY2FuIGJlIGFkZGVkIHRvIGVhY2ggcGFydCBvZiB0aGUgZG9j dW1lbnQgaWRlbnRpZmllZCBieSB0aGUgbWFya3VwDQogICAgICBzdHJ1Y3R1cmUgKGluY2x1ZGlu ZyB0aGUgd2hvbGUgZG9jdW1lbnQgaXRzZWxmKS4gIEZvciBleGFtcGxlLCBvbmUNCiAgICAgIGNv dWxkIHdyaXRlIDxzcGFuIGxhbmc9IkZSIj5DJ2VzdCBsYSB2aWUuPC9zcGFuPiBpbnNpZGUgYQ0K ICAgICAgTm9yd2VnaWFuIGRvY3VtZW50OyB0aGUgTm9yd2VnaWFuLXNwZWFraW5nIHVzZXIgY291 bGQgdGhlbiBhY2Nlc3MNCiAgICAgIGEgRnJlbmNoLU5vcndlZ2lhbiBkaWN0aW9uYXJ5IHRvIGZp bmQgb3V0IHdoYXQgdGhlIG1hcmtlZCBzZWN0aW9uDQogICAgICBtZWFudC4gIElmIHRoZSB1c2Vy IHdlcmUgbGlzdGVuaW5nIHRvIHRoYXQgZG9jdW1lbnQgdGhyb3VnaCBhDQogICAgICBzcGVlY2gg c3ludGhlc2lzIGludGVyZmFjZSwgdGhpcyBmb3JtYXRpb24gY291bGQgYmUgdXNlZCB0byBzaWdu YWwNCiAgICAgIHRoZSBzeW50aGVzaXplciB0byBhcHByb3ByaWF0ZWx5IGFwcGx5IEZyZW5jaCB0 ZXh0LXRvLXNwZWVjaA0KICAgICAgcHJvbnVuY2lhdGlvbiBydWxlcyB0byB0aGF0IHNwYW4gb2Yg dGV4dCwgaW5zdGVhZCBvZiBtaXNhcHBseWluZw0KICAgICAgdGhlIE5vcndlZ2lhbiBydWxlcy4N Cg0KMi40LjEgIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KDQogICBTaW5jZSBh IHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdGFnIG1heSBiZSB1c2VkIGluIG1hbnkgcHJvY2Vzc2VzLA0K ICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3IgZ2VuZXJhdGVkIGlu IGEgY2Fub25pY2FsDQogICBmb3JtLg0KDQogICBBIGxhbmd1YWdlIHRhZyBpcyBpbiBjYW5vbmlj YWwgZm9ybSB3aGVuOg0KICAgMS4gIFRoZSB0YWcgaXMgd2VsbC1mb3JtZWQgYWNjb3JkaW5nIHRo ZSBydWxlcyBpbiBTZWN0aW9uIDIuMSBhbmQNCiAgICAgICBTZWN0aW9uIDIuMi4NCiAgIDIuICBO b25lIG9mIHRoZSBzdWJ0YWdzIGluIHRoZSBsYW5ndWFnZSB0YWcgaGFzIGEgY2Fub25pY2FsX3Zh bHVlDQogICAgICAgbWFwcGluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4x KS4gIFN1YnRhZ3Mgd2l0aCBhDQogICAgICAgY2Fub25pY2FsX3ZhbHVlIG1hcHBpbmcgTVVTVCBi ZSByZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBpbmcgaW4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDE3XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAg ICAgICAgICBNYXJjaCAyMDA1DQoNCg0KICAgICAgIG9yZGVyIHRvIGNhbm9uaWNhbGl6ZSB0aGUg dGFnLg0KICAgMy4gIElmIG1vcmUgdGhhbiBvbmUgZXh0ZW5zaW9uIHN1YnRhZyBzZXF1ZW5jZSBl eGlzdHMsIHRoZSBleHRlbnNpb24NCiAgICAgICBzZXF1ZW5jZXMgYXJlIG9yZGVyZWQgaW50byBj YXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5DQogICAgICAgc2luZ2xldG9uIHN1YnRhZy4N Cg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tQS1hYWEtQi1jY2MtYmJiLXgteHl6 IiBpcyBpbiBjYW5vbmljYWwNCiAgIGZvcm0sIHdoaWxlICJlbi1CLWNjYy1iYmItQS1hYWEtWC14 eXoiIGlzIHdlbGwtZm9ybWVkIGJ1dCBub3QgaW4NCiAgIGNhbm9uaWNhbCBmb3JtLg0KDQogICBF eGFtcGxlOiBUaGUgbGFuZ3VhZ2UgdGFnICJlbi1OSCIgKEVuZ2xpc2ggYXMgdXNlZCBpbiB0aGUg TmV3DQogICBIZWJyaWRlcykgaXMgbm90IGNhbm9uaWNhbCBiZWNhdXNlIHRoZSAnTkgnIHN1YnRh ZyBoYXMgYSBjYW5vbmljYWwNCiAgIG1hcHBpbmcgdG8gJ1ZVJyAoVmFudWF0dSkuDQoNCiAgIE5v dGU6IENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBkb2VzIG5vdCBpbXBseSBhbnl0 aGluZyBhYm91dA0KICAgdGhlIHVzZSBvZiB1cHBlciBvciBsb3dlcmNhc2UgbGV0dGVyIGluIHN1 YnRhZ3MgYXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDIuMS4gIEFsbCBjb21wYXJpc29ucyBN VVNUIGJlIHBlcmZvcm1lZCBpbiBhIGNhc2UtaW5zZW5zaXRpdmUNCiAgIG1hbm5lci4NCg0KICAg Tm90ZTogdGhlIHZhbHVlICItLSIgaW4gdGhlIGNhbm9uaWNhbF92YWx1ZSBmaWVsZCBvZiB0aGUg cmVnaXN0cnkNCiAgIGluZGljYXRlcyBhIHRhZyBvciBzdWJ0YWcgdGhhdCBoYXMgYmVlbiBkZXBy ZWNhdGVkIGFuZCBmb3Igd2hpY2ggbm8NCiAgIHJlcGxhY2VtZW50IG9yIGNhbm9uaWNhbCBlcXVp dmFsZW50IGhhcyBiZWVuIGFzc2lnbmVkLiAgVmFsaWRhdGluZw0KICAgcHJvY2Vzc29ycyBTSE9V TEQgTk9UIGdlbmVyYXRlIHRhZ3MgdGhhdCBpbmNsdWRlIHRoZXNlIHZhbHVlcy4NCg0KICAgQW4g ZXh0ZW5zaW9uIE1VU1QgZGVmaW5lIGFueSByZWxhdGlvbnNoaXBzIHRoYXQgbWF5IGV4aXN0IGJl dHdlZW4gdGhlDQogICB2YXJpb3VzIHN1YnRhZ3MgaW4gdGhlIGV4dGVuc2lvbiBhbmQgdGh1cyBN QVkgZGVmaW5lIGFuIGFsdGVybmF0ZQ0KICAgY2Fub25pY2FsaXphdGlvbiBzY2hlbWUgZm9yIHRo ZSBleHRlbnNpb24ncyBzdWJ0YWdzLiAgRXh0ZW5zaW9ucyBNQVkNCiAgIGRlZmluZSBob3cgdGhl IG9yZGVyIG9mIHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzIGFyZSBpbnRlcnByZXRlZC4gIEZvcg0K ICAgZXhhbXBsZSwgYW4gZXh0ZW5zaW9uIGNvdWxkIGRlZmluZSB0aGF0IGl0cyBzdWJ0YWdzIGFy ZSBpbiBjYW5vbmljYWwNCiAgIG9yZGVyIHdoZW4gdGhlIHN1YnRhZ3MgYXJlIHBsYWNlZCBpbnRv IEFTQ0lJIG9yZGVyOiB0aGF0IGlzLA0KICAgImVuLWEtYWFhLWJiYi1jY2MiIGluc3RlYWQgb2Yg ImVuLWEtY2NjLWJiYi1hYWEiLiAgQW5vdGhlciBleHRlbnNpb24NCiAgIG1pZ2h0IGRlZmluZSB0 aGF0IHRoZSBvcmRlciBvZiB0aGUgc3VidGFncyBpbmZsdWVuY2VzIHRoZWlyIHNlbWFudGljDQog ICBtZWFuaW5nIChzbyB0aGF0ICJlbi1iLWNjYy1iYmItYWFhIiBoYXMgYSBkaWZmZXJlbnQgdmFs dWUgZnJvbQ0KICAgImVuLWItYWFhLWJiYi1jY2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lvbiBzcGVj aWZpY2F0aW9ucyBTSE9VTEQgYmUNCiAgIGRlc2lnbmVkIHNvIHRoYXQgdGhleSBhcmUgdG9sZXJh bnQgb2YgdGhlIHR5cGljYWwgcHJvY2Vzc2VzIGRlc2NyaWJlZA0KICAgaW4gU2VjdGlvbiAzLjQu DQoNCjIuNSAgQ29uc2lkZXJhdGlvbnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAgUHJp dmF0ZS11c2Ugc3VidGFncyByZXF1aXJlIHByaXZhdGUgYWdyZWVtZW50IGJldHdlZW4gdGhlIHBh cnRpZXMNCiAgIHRoYXQgaW50ZW5kIHRvIHVzZSBvciBleGNoYW5nZSBsYW5ndWFnZSB0YWdzIHRo YXQgdXNlIHRoZW0gYW5kIGdyZWF0DQogICBjYXV0aW9uIHNob3VsZCBiZSB1c2VkIGluIGVtcGxv eWluZyB0aGVtIGluIGNvbnRlbnQgb3IgcHJvdG9jb2xzDQogICBpbnRlbmRlZCBmb3IgZ2VuZXJh bCB1c2UuICBQcml2YXRlLXVzZSBzdWJ0YWdzIGFyZSBzaW1wbHkgdXNlbGVzcyBmb3INCiAgIGlu Zm9ybWF0aW9uIGV4Y2hhbmdlIHdpdGhvdXQgcHJpb3IgYXJyYW5nZW1lbnQuDQoNCiAgIFRoZSB2 YWx1ZSBhbmQgc2VtYW50aWMgbWVhbmluZyBvZiBwcml2YXRlLXVzZSB0YWdzIGFuZCBvZiB0aGUg c3VidGFncw0KICAgdXNlZCB3aXRoaW4gc3VjaCBhIGxhbmd1YWdlIHRhZyBhcmUgbm90IGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIHVzZSBvZiBzdWJ0YWdzIGRlZmluZWQgaW4g dGhlIElBTkEgcmVnaXN0cnkgYXMgaGF2aW5nIGEgc3BlY2lmaWMNCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgIFtQYWdl IDE4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAg ICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoNCg0KICAgcHJpdmF0ZSB1c2UgbWVhbmluZyBjb252 ZXkgbW9yZSBpbmZvcm1hdGlvbiB0aGF0IGEgcHVyZWx5IHByaXZhdGUgdXNlDQogICB0YWcgcHJl Zml4ZWQgYnkgdGhlIHNpbmdsZXRvbiBzdWJ0YWcgJ3gnLiAgRm9yIGFwcGxpY2F0aW9ucyB0aGlz DQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG1heSBiZSB1c2VmdWwuDQoNCiAgIEZvciBleGFt cGxlLCB0aGUgcmVnaW9uIHN1YnRhZ3MgJ0FBJywgJ1paJyBhbmQgaW4gdGhlIHJhbmdlcw0KICAg J1FNJy0nUVonIGFuZCAnWEEnLSdYWicgKGRlcml2ZWQgZnJvbSBJU08gMzE2NiBwcml2YXRlIHVz ZSBjb2RlcykgbWF5DQogICBiZSB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcuICBBIHRhZyBz dWNoIGFzICJ6aC1IYW5zLVhRIiBjb252ZXlzIGENCiAgIGdyZWF0IGRlYWwgb2YgcHVibGljLCBp bnRlcmNoYW5nZWFibGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxhbmd1YWdlDQogICBtYXRlcmlh bCAodGhhdCBpdCBpcyBDaGluZXNlIGluIHRoZSBzaW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0IGFu ZCBpcw0KICAgc3VpdGFibGUgZm9yIHNvbWUgZ2VvZ3JhcGhpYyByZWdpb24gJ1hRJykuICBXaGls ZSB0aGUgcHJlY2lzZQ0KICAgZ2VvZ3JhcGhpYyByZWdpb24gaXMgbm90IGtub3duIG91dHNpZGUg b2YgcHJpdmF0ZSBhZ3JlZW1lbnQsIHRoZSB0YWcNCiAgIGNvbnZleXMgZmFyIG1vcmUgaW5mb3Jt YXRpb24gdGhhbiBhbiBvcGFxdWUgdGFnIHN1Y2ggYXMgIngtc29tZUxhbmciLA0KICAgd2hpY2gg Y29udGFpbnMgbm8gaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxhbmd1YWdlIHN1YnRhZyBvciBzY3Jp cHQNCiAgIHN1YnRhZyBvdXRzaWRlIG9mIHRoZSBwcml2YXRlIGFncmVlbWVudC4NCg0KICAgSG93 ZXZlciwgaW4gc29tZSBjYXNlcyBjb250ZW50IHRhZ2dlZCB3aXRoIHByaXZhdGUgdXNlIHN1YnRh Z3MgbWF5DQogICBpbnRlcmFjdCB3aXRoIG90aGVyIHN5c3RlbXMgaW4gYSBkaWZmZXJlbnQgYW5k IHBvc3NpYmx5IHVuc3VpdGFibGUNCiAgIG1hbm5lciBjb21wYXJlZCB0byB0YWdzIHRoYXQgdXNl IG9wYXF1ZSwgcHJpdmF0ZWx5IGRlZmluZWQgc3VidGFncywNCiAgIHNvIHRoZSBjaG9pY2Ugb2Yg dGhlIGJlc3QgYXBwcm9hY2ggbWF5IGRlcGVuZCBvbiB0aGUgcGFydGljdWxhcg0KICAgZG9tYWlu IGluIHF1ZXN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDExLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0K DQoNCjMuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWFscyB3aXRo IHRoZSBwcm9jZXNzZXMgYW5kIHJlcXVpcmVtZW50cyBuZWNlc3NhcnkgdG8NCiAgIG1haW50YWlu IHRoZSByZWdpc3RyeSBvZiBzdWJ0YWdzIGFuZCBleHRlbnNpb25zIGZvciB1c2UgaW4gbGFuZ3Vh Z2UNCiAgIHRhZ3MgYXMgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IGFuZCBpbiBhY2NvcmRhbmNl IHdpdGggdGhlDQogICByZXF1aXJlbWVudHMgb2YgUkZDIDI0MzQgWzE1XS4NCg0KICAgVGhlIGxh bmd1YWdlIHN1YnRhZyByZWdpc3RyeSB3aWxsIGJlIG1haW50YWluZWQgc28gdGhhdCwgZXhjZXB0 IGZvcg0KICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGl0IGlzIHBvc3NpYmxlIHRvIHZhbGlkYXRlIGFs bCBvZiB0aGUgc3VidGFncyB0aGF0DQogICBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcgdW5kZXIg dGhlIHByb3Zpc2lvbnMgb2YgdGhpcyBkb2N1bWVudCBvciBpdHMNCiAgIHJldmlzaW9ucyBvciBz dWNjZXNzb3JzLiAgSW4gYWRkaXRpb24sIHRoZSBtZWFuaW5nIG9mIHRoZSB2YXJpb3VzDQogICBz dWJ0YWdzIHdpbGwgYmUgdW5hbWJpZ3VvdXMgYW5kIHN0YWJsZSBvdmVyIHRpbWUuICAoVGhlIG1l YW5pbmcgb2YNCiAgIHByaXZhdGUtdXNlIHN1YnRhZ3MsIG9mIGNvdXJzZSwgaXMgbm90IGRlZmlu ZWQgYnkgdGhlIElBTkEgcmVnaXN0cnkuKQ0KDQogICBUaGUgcmVnaXN0cnkgZGVmaW5lZCB1bmRl ciB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIGEgY29tcHJlaGVuc2l2ZQ0KICAgbGlzdCBvZiBhbGwg b2YgdGhlIHN1YnRhZ3MgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoaXMgYWxsb3dzDQogICBp bXBsZW1lbnRlcnMgYSBzdHJhaWdodGZvcndhcmQgYW5kIHJlbGlhYmxlIHdheSB0byB2YWxpZGF0 ZSBsYW5ndWFnZQ0KICAgdGFncy4NCg0KMy4xICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5DQoNCiAgIFRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSB3 aWxsIGNvbnNpc3Qgb2YgYSB0ZXh0IGZpbGUgdGhhdCBpcw0KICAgbWFjaGluZSByZWFkYWJsZSBp biB0aGUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24sIHBsdXMgY29waWVzDQogICBv ZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGJ5IHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgaW4NCiAgIGFjY29yZGFuY2Ugd2l0aCB0aGUgcHJvY2VzcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjMuICBXaXRoIHRoZQ0KICAgZXhjZXB0aW9uIG9mIHRoZSByZWdpc3RyYXRpb24g Zm9ybXMgZm9yIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudA0KICAgdGFncywgbm8gcmVnaXN0 cmF0aW9uIHJlY29yZHMgd2lsbCBiZSBtYWludGFpbmVkIGZvciB0aGUgaW5pdGlhbCBzZXQNCiAg IG9mIHN1YnRhZ3MuDQoNCiAgIEVhY2ggcmVjb3JkIGluIHRoZSBzdWJ0YWcgcmVnaXN0cnkgd2ls bCBjb25zaXN0IG9mIGEgc2VyaWVzIG9mIGZpZWxkcw0KICAgc2VwYXJhdGVkIGJ5IHRoZSBzeW1i b2wgInwiICgleDdEKSBhbmQgdGVybWluYXRlZCBieSBhIG5ld2xpbmUuICBUZXh0DQogICBhcHBl YXJpbmcgYWZ0ZXIgdGhlIHN5bWJvbCAiIyIgKCV4MjMpIGNvbnRhaW5zIGNvbW1lbnRzLiAgV2hp dGVzcGFjZQ0KICAgc3Vycm91bmRpbmcgZmllbGRzIGluIHRoZSBmaWxlIGlzIGlnbm9yZWQuICBJ ZiBhIGZpZWxkIGNvbnRhaW5zIG1vcmUNCiAgIHRoYW4gb25lIHZhbHVlLCB0aGUgdmFsdWVzIGFy ZSBzZXBhcmF0ZWQgYnkgc2VtaWNvbG9ucyAoJXgzQikuDQoNCiAgIFRoZXJlIGlzIGEgc2luZ2xl IGRhdGUgcmVjb3JkIGF0IHRoZSBzdGFydCBvZiB0aGUgZmlsZSB3aGljaA0KICAgaW5kaWNhdGVz IHRoZSBtb3N0IHJlY2VudCBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGUgZmlsZS4gIEl0IGhhcyB0 d28NCiAgIGZpZWxkczogdGhlIHR5cGUgZmllbGQgaXMgImRhdGUiLCBhbmQgdGhlIHNlY29uZCBm aWVsZCBpcyB0aGUNCiAgIG1vZGlmaWNhdGlvbiBkYXRlLCBpbiB0aGUgImZ1bGwtZGF0ZSIgZm9y bWF0IHNwZWNpZmllZCBpbiBSRkMgMzMzOQ0KICAgWzIwXS4gIEZvciBleGFtcGxlOiAyMDA0LTA2 LTI4IHJlcHJlc2VudHMgSnVuZSAyOCwgMjAwNCBpbiB0aGUNCiAgIEdyZWdvcmlhbiBjYWxlbmRh cjoNCiAgICAgIGRhdGUgfCAyMDA0LTA2LTI4DQoNCiAgIFRoZSBmaWVsZHMgaW4gZWFjaCBzdWJ0 YWcgcmVjb3JkLCBpbiBvcmRlciwgYXJlOg0KICAgICAgdHlwZXwgc3VidGFnfCBkZXNjcmlwdGlv bnwgZGF0ZXwgY2Fub25pY2FsX3ZhbHVlfA0KICAgICAgcmVjb21tZW5kZWRfcHJlZml4ICMgY29t bWVudHMNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDExLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoN CiAgIG8gIFRoZSBjaGFyYWN0ZXIgInZlcnRpY2FsIGxpbmUiICgifCIsICV4N0QpIGRlbGltaXRz IGVhY2ggb2YgdGhlDQogICAgICBmaWVsZHMuDQogICBvICBFbXB0eSBmaWVsZHMgKGFuZCB0aGVp ciBzZXBhcmF0b3JzKSBhdCB0aGUgZW5kIG9mIHRoZSByZWNvcmQgbWF5DQogICAgICBiZSBvbWl0 dGVkLg0KICAgbyAgTGVhZGluZyBvciB0cmFpbGluZyB3aGl0ZXNwYWNlIGluIGVhY2ggZmllbGQg aXMgbm90IHBhcnQgb2YgdGhlDQogICAgICBjb250ZW50Lg0KICAgbyAgV2hlbiB0aGUgdHlwZSBp cyAiZ3JhbmRmYXRoZXJlZCIgb3IgInJlZHVuZGFudCIsIHRoZW4gdGhlIHN1YnRhZw0KICAgICAg ZmllbGQgaXMgYWN0dWFsbHkgYSB3aG9sZSB0YWcuDQogICBvICBUaGUgInJlY29tbWVuZGVkX3By ZWZpeCIgZmllbGQgaXMgZW1wdHksIGV4Y2VwdCB3aGVyZSB0aGUgdHlwZSBpcw0KICAgICAgInZh cmlhbnQiDQogICBvICBUaGUgImNvbW1lbnRzIiBmaWVsZCAgaXMgb3B0aW9uYWwgYW5kIGFwcGVh cnMgb25seSBhdCB0aGUgZW5kIG9mIGENCiAgICAgIHJlY29yZCwgZm9sbG93aW5nIGEgIm51bWJl ciBzaWduIiAoIiMiLCAleDIzKS4NCiAgIG8gIFRoZSBzZXF1ZW5jZSAnLi4nIGRlbm90ZXMgYSBy YW5nZSBvZiB2YWx1ZXMuICBTdWNoIGEgcmFuZ2UNCiAgICAgIHJlcHJlc2VudHMgYWxsIHN1YnRh Z3Mgb2YgdGhlIHNhbWUgbGVuZ3RoIHRoYXQgYXJlIGFscGhhYmV0aWNhbGx5DQogICAgICB3aXRo aW4gdGhhdCByYW5nZSwgaW5jbHVkaW5nIHRoZSB2YWx1ZXMgZXhwbGljaXRseSBtZW50aW9uZWQu ICBGb3INCiAgICAgIGV4YW1wbGUgJ2EuLmMnIGRlbm90ZXMgdGhlIHZhbHVlcyAnYScsICdiJywg YW5kICdjJy4NCg0KICAgVGhlIGZpZWxkICd0eXBlJyBNVVNUIGNvbnNpc3Qgb2Ygb25lIG9mIHRo ZSBmb2xsb3dpbmcgc3RyaW5nczoNCiAgICJsYW5ndWFnZSIsICJleHRsYW5nIiwgInNjcmlwdCIs ICJyZWdpb24iLCAidmFyaWFudCIsDQogICAiZ3JhbmRmYXRoZXJlZCIsIGFuZCAicmVkdW5kYW50 IiBhbmQgZGVub3RlcyB0aGUgdHlwZSBvZiBzdWJ0YWcgKG9yDQogICB0YWcsIGluIHRoZSBjYXNl IG9mICJncmFuZGZhdGhlcmVkIiBhbmQgInJlZHVuZGFudCIpLg0KDQogICBUaGUgZmllbGQgJ3N1 YnRhZycgY29udGFpbnMgdGhlIHN1YnRhZyBiZWluZyBkZWZpbmVkLg0KDQogICBUaGUgZmllbGQg J2Rlc2NyaXB0aW9uJyBjb250YWlucyBhIGRlc2NyaXB0aW9uIG9mIHRoZSBzdWJ0YWcNCiAgIHRy YW5zY3JpYmVkIGludG8gQVNDSUkuDQoNCiAgIE5vdGU6IERlc2NyaXB0aW9ucyBpbiByZWdpc3Ry eSBlbnRyaWVzIHRoYXQgY29ycmVzcG9uZCB0byBJU08gNjM5LA0KICAgSVNPIDE1OTI0LCAgSVNP IDMxNjYgb3IgVU4gTS40OSBjb2RlcyBhcmUgaW50ZW5kZWQgb25seSB0byBpbmRpY2F0ZQ0KICAg dGhlIG1lYW5pbmcgb2YgdGhhdCBpZGVudGlmaWVyIGFzIGRlZmluZWQgaW4gdGhlIHNvdXJjZSBz dGFuZGFyZCBhdA0KICAgdGhlIHRpbWUgaXQgd2FzIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4gIFRo ZSBkZXNjcmlwdGlvbiBkb2VzIG5vdA0KICAgcmVwbGFjZSB0aGUgY29udGVudCBvZiB0aGUgc291 cmNlIHN0YW5kYXJkIGl0c2VsZi4gIFRoZSBkZXNjcmlwdGlvbnMNCiAgIGFyZSBub3QgaW50ZW5k ZWQgdG8gYmUgdGhlIEVuZ2xpc2ggbG9jYWxpemVkIG5hbWVzIGZvciB0aGUgc3VidGFncw0KICAg YW5kIGxvY2FsaXphdGlvbiBvciB0cmFuc2xhdGlvbiBvZiBsYW5ndWFnZSB0YWcgYW5kIHN1YnRh Zw0KICAgZGVzY3JpcHRpb25zIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQog ICBUaGUgZmllbGQgJ2RhdGUnIGNvbnRhaW5zIHRoZSBkYXRlIHRoZSByZWNvcmQgd2FzIGFkZGVk IHRvIHRoZQ0KICAgcmVnaXN0cnkgaW4gdGhlICJmdWxsLWRhdGUiIGZvcm1hdCBzcGVjaWZpZWQg aW4gUkZDIDMzMzkgWzIwXS4gIEZvcg0KICAgZXhhbXBsZTogMjAwNC0wNi0yOCByZXByZXNlbnRz IEp1bmUgMjgsIDIwMDQsIGluIHRoZSBHcmVnb3JpYW4NCiAgIGNhbGVuZGFyLg0KDQogICBUaGUg ZmllbGQgJ2Nhbm9uaWNhbCB2YWx1ZScgcmVwcmVzZW50cyBhIGNhbm9uaWNhbCBtYXBwaW5nIG9m IHRoaXMNCiAgIHJlY29yZCB0byBhIHN1YnRhZyByZWNvcmQgb2YgdGhlIHNhbWUgJ3R5cGUnLCBl eGNlcHQgZm9yIHJlY29yZHMgb2YNCiAgIHR5cGUgImdyYW5kZmF0aGVyZWQiIGFuZCAicmVkdW5k YW50Ii4gIFRoaXMgZmllbGQgU0hBTEwgTk9UIGJlDQogICBtb2RpZmllZCAoZXhjZXB0IGZvciBy ZWNvcmRzIG9mIHR5cGUgImdyYW5kZmF0aGVyZWQiKTogdGhlcmVmb3JlIGENCiAgIHN1YnRhZyB3 aG9zZSByZWNvcmQgY29udGFpbnMgbm8gY2Fub25pY2FsIG1hcHBpbmcgd2hlbiB0aGUgcmVjb3Jk IGlzDQogICBjcmVhdGVkIGlzIGEgY2Fub25pY2FsIGZvcm0gYW5kIHdpbGwgcmVtYWluIHNvLiAg VGhlICdjYW5vbmljYWwNCiAgIHZhbHVlJyBmaWVsZCBpbiByZWNvcmRzIG9mIHR5cGUgImdyYW5k ZmF0aGVyZWQiIGFuZCAicmVkdW5kYW50Ig0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMDUNCg0KDQogICBjb250YWluIHdob2xlIGxhbmd1YWdlIHRhZ3MgdGhhdCBhcmUg U1RST05HTFkgUkVDT01NRU5ERUQgZm9yIHVzZSBpbg0KICAgcGxhY2Ugb2YgdGhlIHJlY29yZCdz IHZhbHVlLiAgSW4gbWFueSBjYXNlcyB0aGUgbWFwcGluZ3Mgd2VyZSBjcmVhdGVkDQogICBieSBk ZXByZWNhdGlvbiBvZiB0aGUgdGFncyBkdXJpbmcgdGhlIHBlcmlvZCBiZWZvcmUgdGhpcyBkb2N1 bWVudCB3YXMNCiAgIGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tbnluIiB3YXMg ZGVwcmVjYXRlZCBpbiBmYXZvciBvZg0KICAgdGhlIElTTyA2MzktMSBkZWZpbmVkIGxhbmd1YWdl IGNvZGUgJ25uJy4NCg0KICAgVGhlIHZhbHVlICItLSIgaW4gdGhlICdjYW5vbmljYWwgdmFsdWUn IGZpZWxkIG1lYW5zIHRoYXQgdGhlIHRhZyBvcg0KICAgc3VidGFnIGhhcyBiZWVuIGRlcHJlY2F0 ZWQgYW5kIHRoYXQgbm8gcmVwbGFjZW1lbnQgdmFsdWUgaGFzIGJlZW4NCiAgIGFzc2lnbmVkLiAg Rm9yIGV4YW1wbGUsIHRoZSAicmVnaW9uIiBjb2RlICdCUScgKEJyaXRpc2ggQW50YXJjdGljDQog ICBUZXJyaXRvcnkpIHdhcyB3aXRoZHJhd24gYnkgSVNPIDMxNjYgaW4gMTk3OS4gIEFsdGhvdWdo IHZhbGlkIGluDQogICBsYW5ndWFnZSB0YWdzLCBpdCBpcyBkZXByZWNhdGVkIGFuZCB2YWxpZGF0 aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVA0KICAgZ2VuZXJhdGUgdGhpcyBzdWJ0YWcuDQoNCiAg IFRoZSBmaWVsZCAncmVjb21tZW5kZWQgcHJlZml4JyBpcyBmb3IgdXNlIHdpdGggcmVnaXN0ZXJl ZCB2YXJpYW50cw0KICAgYW5kIGNvbnRhaW5zIGEgc2VtaWNvbG9uIHNlcGFyYXRlZCBsaXN0IG9m IGxhbmd1YWdlLXJhbmdlcyBjb25zaWRlcmVkDQogICBtb3N0IGFwcHJvcHJpYXRlIGZvciB1c2Ug d2l0aCB0aGlzIHN1YnRhZy4gIEFkZGl0aW9uYWwgdmFsdWVzIGNhbiBiZQ0KICAgYWRkZWQgdG8g dGhpcyBmaWVsZCBmb3IgdmFyaWFudHMgb25seSB2aWEgYWRkaXRpb25hbCByZWdpc3RyYXRpb24u DQogICBPdGhlciBtb2RpZmljYXRpb24gb2YgdGhpcyBmaWVsZCAoc3VjaCBhcyByZW1vdmluZyBv ciBjaGFuZ2luZw0KICAgdmFsdWVzKSBpcyBub3QgcGVybWl0dGVkLg0KDQogICBUaGUgZmllbGQg J2NvbW1lbnRzJyBtYXkgY29udGFpbiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0K ICAgc3VidGFnLCBhcyBkZWVtZWQgYXBwcm9wcmlhdGUgZm9yIHVuZGVyc3RhbmRpbmcgdGhlIHJl Z2lzdHJ5IGFuZA0KICAgaW1wbGVtZW50aW5nIGxhbmd1YWdlIHRhZ3MgdXNpbmcgdGhlIHZhcmlv dXMgc3VidGFncy4gIFRoZXNlIHZhbHVlcw0KICAgY2FuIGJlIGNoYW5nZWQgdmlhIHRoZSByZWdp c3RyYXRpb24gcHJvY2VzcyBhbmQgbm8gZ3VhcmFudGVlIG9mDQogICBzdGFiaWxpdHkgaXMgcHJv dmlkZWQuDQoNCg0KICAgIyBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KICAgIyBUaGlz IHJlZ2lzdHJ5IGxpc3RzIGFsbCB2YWxpZCBzdWJ0YWdzIGZvciBsYW5ndWFnZSB0YWdzDQogICAj IGNyZWF0ZWQgdW5kZXIgUkZDIFhYWFguDQogICBkYXRlfCAyMDA0LTA4LTA3DQoNCiAgICMgbGFu Z3VhZ2UgY29kZXM6IElTTyA2MzkgYW5kIHJlZ2lzdGVyZWQgY29kZXMNCg0KICAgIyBJU08gNjM5 LTEgKGFscGhhLTIpIGNvZGVzDQogICBsYW5ndWFnZXwgYWF8IEFmYXJ8IDIwMDQtMDctMDZ8IHwN CiAgIGxhbmd1YWdlfCBhYnwgQWJraGF6aWFufCAyMDA0LTA3LTA2fCB8DQogICBsYW5ndWFnZXwg YWV8IEF2ZXN0YW58IDIwMDQtMDctMDZ8IHwNCiAgIGxhbmd1YWdlfCBoZXwgaGVicmV3fCAyMDA0 LTA2LTI4fCB8DQogICBsYW5ndWFnZXwgaXd8IGhlYnJld3wgMjAwNC0wNi0yOHwgaGUgfCAjbm90 ZSBtYXBwaW5nDQogICBsYW5ndWFnZXwgcWFhLi5xdHp8IFBSSVZBVEUgVVNFfCAyMDA0LTA3LTA2 fCB8DQogICBsYW5ndWFnZXwgcmFqfCBSYWphc3RoYW5pfCAyMDA0LTA3LTA2fCB8DQogICBsYW5n dWFnZXwgc2V1c3N8IEh5cG90aGV0aWNhbCBMYW5ndWFnZXwgMjAwNS0wNC0wMSB8IHwjIHJlZ2lz dGVyZWQgbGFuZ3VhZ2UNCg0KICAgIyBzY3JpcHQgY29kZXM6IElTTyAxNTkyNA0KDQogICBzY3Jp cHR8IEFyYWJ8IEFyYWJpY3wgMjAwNC0wNy0wNnwgfA0KICAgc2NyaXB0fCBBcm1ufCBBcm1lbmlh bnwgMjAwNC0wNy0wNnwgfA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MDUNCg0KDQogICBzY3JpcHR8IEJhbGl8IEJhbGluZXNlfCAyMDA0LTA3LTA2fCB8DQogICAjIHJl Z2lvbiBjb2RlczogSVNPIDMxNjYgYW5kIFVOIGNvZGVzDQoNCiAgICMgSVNPIDMxNjYtMSBhbHBo YS0yIGNvZGVzDQoNCiAgIHJlZ2lvbnwgQUF8IFBSSVZBVEUgVVNFfCAyMDA0LTA4LTAxfCB8DQog ICByZWdpb258IEFEfCBBbmRvcnJhfCAyMDA0LTA3LTA2fCB8DQogICByZWdpb258IEFFfCBVbml0 ZWQgQXJhYiBFbWlyYXRlc3wgMjAwNC0wNy0wNnwgfA0KICAgcmVnaW9ufCBBRnwgQWZnaGFuaXN0 YW58IDIwMDQtMDctMDZ8IHwNCiAgIHJlZ2lvbnwgQlF8IEJyaXRpc2ggQW50YXJjdGljIFRlcnJp dG9yeSB8IDIwMDQtMDctMDYgfCAtLSB8ICMgZGVwcmVjYXRlZCAxOTc5DQogICByZWdpb258IENT fCBTZXJiaWEgYW5kIE1vbnRlbmVncm98IDIwMDMtMDctMjN8IHwNCiAgIHJlZ2lvbnwgWVV8IFl1 Z29zbGF2aWF8IDIwMDQtMDYtMjh8IHwNCg0KICAgIyBVbml0ZWQgTmF0aW9ucyBNLjQ5IG51bWVy aWMgY29kZXMNCiAgIHJlZ2lvbnwgMDAxfCBXb3JsZHwgMjAwNC0wNy0wNnwgfA0KICAgcmVnaW9u fCAwMDJ8IEFmcmljYXwgMjAwNC0wNy0wNnwgfA0KICAgcmVnaW9ufCAwMDN8IE5vcnRoIEFtZXJp Y2F8IDIwMDQtMDctMDZ8IHwNCiAgIHJlZ2lvbnwgMDA1fCBTb3V0aCBBbWVyaWNhfCAyMDA0LTA3 LTA2fCB8DQogICByZWdpb258IDIwMHwgQ3plY2hvc2xvdmFraWF8IDIwMDQtMDctMDZ8IHwgI2Zv cm1lcmx5IHVzZWQgY29kZSBDUw0KDQogICAjIyByZWdpc3RlcmVkIHZhcmlhbnRzDQoNCiAgIHZh cmlhbnR8IGJvb250fCBCb29udGxpbmd8IDIwMDMtMDItMTR8IHwgZW4NCiAgIHZhcmlhbnR8IGdh dWxpc2h8IEdhdWxpc2h8IDIwMDEtMDUtMjV8IHwgY2VsDQogICB2YXJpYW50fCBndW95dXwgTWFu ZGFyaW4gb3IgU3RhbmRhcmQgQ2hpbmVzZXwgMTk5OS0xMi0xOHwgfCB6aA0KDQogICAjIGdyYW5k ZmF0aGVyZWQgZnJvbSBSRkMgMzA2Ng0KDQogICBncmFuZGZhdGhlcmVkfCBlbi1HQi1vZWR8IEVu Z2xpc2gsIE94Zm9yZCBFbmdsaXNoIERpY3Rpb25hcnkgc3BlbGxpbmd8IDIwMDMtMDctMDl8IHwN CiAgIGdyYW5kZmF0aGVyZWR8IGktYW1pfCBBbWlzfCAxOTk5LTA1LTI1fCB8DQogICBncmFuZGZh dGhlcmVkfCBpLWJubnwgQnVudW58IDE5OTktMDUtMjV8IHwNCiAgIGdyYW5kZmF0aGVyZWR8IGFy dC1sb2piYW58IExvamJhbnwgMjAwMS0xMS0xMXxqYm8gfCAgIyBkZXByZWNhdGVkIGluIGZhdm9y IG9mICdqYm8nDQoNCiAgICMgcmVkdW5kYW50DQogICAjIFRoZSBmb2xsb3dpbmcgY29kZXMgd2Vy ZSByZWdpc3RlcmVkIGFzIGNvbXBsZXRlIHRhZ3MsIGJ1dCBjYW4gbm93IGJlDQogICAjIGNvbXBv c2VkIG9mIHJlZ2lzdGVyZWQgc3VidGFncyBhbmQgZG8gbm90IHJlcXVpcmUgcmVnaXN0cmF0aW9u Lg0KDQogICByZWR1bmRhbnR8IGF6LUFyYWJ8IEF6ZXJiYWlqYW5pIGluIEFyYWJpYyBzY3JpcHR8 IDIwMDMtMDUtMzB8IHwgICMgdXNlIGxhbmd1YWdlIGF6ICsgc2NyaXB0IEFyYWINCiAgIHJlZHVu ZGFudHwgYXotQ3lybHwgQXplcmJhaWphbmkgaW4gQ3lyaWxsaWMgc2NyaXB0fCAyMDAzLTA1LTMw fCB8ICAjIHVzZSBsYW5ndWFnZSBheiArIHNjcmlwdCBDeXJsDQogICByZWR1bmRhbnR8IGVuLWJv b250fCBCb29udGxpbmd8IDIwMDMtMDItMTR8IHwgICMgdXNlIGxhbmd1YWdlIGVuICsgdmFyaWFu dCBib29udA0KDQogICAgICAgICAgICAgICAgRmlndXJlIDI6IEV4YW1wbGUgb2YgdGhlIFJlZ2lz dHJ5IEZvcm1hdA0KDQogICBNYWludGVuYW5jZSBvZiB0aGUgcmVnaXN0cnkgcmVxdWlyZXMgdGhh dCBhcyBuZXcgY29kZXMgYXJlIGFzc2lnbmVkDQogICBieSBJU08gNjM5LCBJU08gMTU5MjQsIGFu ZCBJU08gMzE2NiwgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KICAgd2lsbCBldmFsdWF0 ZSBlYWNoIGFzc2lnbm1lbnQsIGRldGVybWluZSB3aGV0aGVyIGl0IGNvbmZsaWN0cyB3aXRoDQog ICBleGlzdGluZyByZWdpc3RyeSBlbnRyaWVzLCBhbmQgc3VibWl0IHRoZSBpbmZvcm1hdGlvbiB0 byBJQU5BIGZvcg0KICAgaW5jbHVzaW9uIGluIHRoZSByZWdpc3RyeS4NCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgIFtQ YWdlIDIzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAg ICAgICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoNCg0KICAgTm90ZTogVGhlIHJlZHVuZGFudCBh bmQgZ3JhbmRmYXRoZXJlZCBlbnRyaWVzIHRvZ2V0aGVyIGFyZSB0aGUNCiAgIGNvbXBsZXRlIGxp c3Qgb2YgdGFncyByZWdpc3RlcmVkIHVuZGVyIFJGQyAzMDY2IFsxOF0uICBUaGUgcmVkdW5kYW50 DQogICB0YWdzIGFyZSB0aG9zZSB0aGF0IGNhbiBub3cgYmUgZm9ybWVkIHVzaW5nIHRoZSBzdWJ0 YWdzIGRlZmluZWQgaW4NCiAgIFNlY3Rpb24gMi4yLiAgVGhlIGdyYW5kZmF0aGVyZWQgZW50cmll cyBhcmUgdGhvc2UgdGhhdCBjYW4gbmV2ZXIgYmUNCiAgIGxlZ2FsIHVuZGVyIHRob3NlIHNhbWUg cHJvdmlzaW9ucy4gIFRoZSBpdGVtcyBpbiBib3RoIGxpc3RzIGFyZQ0KICAgcGVybWFuZW50IGFu ZCBzdGFibGUsIGFsdGhvdWdoIGdyYW5kZmF0aGVyZWQgaXRlbXMgbWF5IGJlIGRlcHJlY2F0ZWQN CiAgIG92ZXIgdGltZS4gIFJlZmVyIHRvIEFwcGVuZGl4IEMgZm9yIG1vcmUgaW5mb3JtYXRpb24u DQoNCiAgIFJGQyAzMDY2IHRhZ3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJpb3IgdG8gdGhlIGFk b3B0aW9uIG9mIHRoaXMNCiAgIGRvY3VtZW50IGFyZSBwYXJ0IG9mIHRoZSBsaXN0IG9mIGdyYW5k ZmF0aGVyZWQgdGFncyBhbmQgdGhlaXINCiAgIGNvbXBvbmVudCBzdWJ0YWdzIHdlcmUgbm90IGlu Y2x1ZGVkIGFzIHJlZ2lzdGVyZWQgdmFyaWFudHMgKGFsdGhvdWdoDQogICB0aGV5IHJlbWFpbiBl bGlnaWJsZSBmb3IgcmVnaXN0cmF0aW9uKS4gIEZvciBleGFtcGxlLCB0aGUgdGFnDQogICAiYXJ0 LWxvamJhbiIgd2FzIGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIGxhbmd1YWdlIHN1YnRhZyAn amJvJy4NCg0KICAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNVVNUIGVuc3VyZSB0aGF0 IG5ldyBzdWJ0YWdzIG1lZXQgdGhlDQogICByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiAyLjMgb3Ig c3VibWl0IGFuIGFwcHJvcHJpYXRlIGFsdGVybmF0ZSBzdWJ0YWcNCiAgIGFzIGRlc2NyaWJlZCBp biB0aGF0IHNlY3Rpb24uICBTaGUgb3IgaGUgd2lsbCB1c2UgdGhlIGZvbGxvd2luZyBmb3JtDQog ICB0byBzdWJtaXQgdGhpcyBpbmZvcm1hdGlvbjoNCg0KICAgTEFOR1VBR0UgU1VCVEFHIFJFR0lT VFJBVElPTiBGT1JNIChORVcgUkVDT1JEKQ0KICAgUmVjb3JkIFRleHQ6DQogICBUeXBlOg0KICAg U3VidGFnOg0KICAgRGVzY3JpcHRpb246DQogICBEYXRlOg0KICAgQ2Fub25pY2FsIE1hcHBpbmc6 DQogICBSZWNvbW1lbmRlZCBQcmVmaXg6DQogICBDb21tZW50czoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGaWd1cmUgMw0KDQogICBUaGUgZmllbGQgJ3JlY29yZCB0ZXh0JyBj b250YWlucyB0aGUgZXhhY3QgcmVjb3JkIHRoYXQgSUFOQSBpcyB0bw0KICAgaW5zZXJ0IGludG8g dGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIFRoZSBjb250ZW50cyBvZiB0aGUNCiAgIHJl bWFpbmluZyBmaWVsZHMgbXVzdCBleGFjdGx5IG1hdGNoIHRob3NlIGluIHRoaXMgZmllbGQuDQoN CiAgIFdoZW5ldmVyIGFuIGVudHJ5IGlzIGNyZWF0ZWQgb3IgbW9kaWZpZWQgaW4gdGhlIHJlZ2lz dHJ5LCB0aGUgJ2RhdGUnDQogICByZWNvcmQgYXQgdGhlIHN0YXJ0IG9mIHRoZSByZWdpc3RyeSBp cyB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIG1vc3QNCiAgIHJlY2VudCBtb2RpZmljYXRpb24gZGF0 ZSBpbiB0aGUgUkZDIDMzMzkgWzIwXSAiZnVsbC1kYXRlIiBmb3JtYXQuDQoNCjMuMiAgU3RhYmls aXR5IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcw0KDQogICBUaGUgc3RhYmlsaXR5IG9mIGVudHJp ZXMgYW5kIHRoZWlyIG1lYW5pbmcgaW4gdGhlIHJlZ2lzdHJ5IGlzDQogICBjcml0aWNhbCB0byB0 aGUgbG9uZyB0ZXJtIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLiAgVGhlIHJ1bGVzIGluDQog ICB0aGlzIHNlY3Rpb24gZ3VhcmFudGVlIHRoYXQgYSBzcGVjaWZpYyBsYW5ndWFnZSB0YWcncyBt ZWFuaW5nIGlzDQogICBzdGFibGUgb3ZlciB0aW1lIGFuZCB3aWxsIG5vdCBjaGFuZ2UgYW5kIHRo YXQgdGhlIGNob2ljZSBvZiBsYW5ndWFnZQ0KICAgdGFnIGZvciBzcGVjaWZpYyBjb250ZW50IGlz IGFsc28gc3RhYmxlIG92ZXIgdGltZS4NCg0KICAgVGhlc2UgcnVsZXMgc3BlY2lmaWNhbGx5IGRl YWwgd2l0aCBob3cgY2hhbmdlcyB0byBjb2RlcyAoaW5jbHVkaW5nDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBbUGFn ZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIHdpdGhkcmF3YWwgYW5kIGRlcHJlY2F0 aW9uIG9mIGNvZGVzKSBtYWludGFpbmVkIGJ5IElTTyA2MzksIElTTw0KICAgMTU5MjQsIElTTyAz MTY2LCBhbmQgVU4gTS40OSBhcmUgcmVmbGVjdGVkIGluIHRoZSBJQU5BIExhbmd1YWdlDQogICBT dWJ0YWcgUmVnaXN0cnkuICBBc3NpZ25tZW50cyB0byB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcg UmVnaXN0cnkNCiAgIE1VU1QgZm9sbG93IHRoZSBmb2xsb3dpbmcgc3RhYmlsaXR5IHJ1bGVzOg0K ICAgbyAgVmFsdWVzIGluIHRoZSBmaWVsZHMgJ3R5cGUnLCAnc3VidGFnJywgJ2RhdGUnIGFuZCAn Y2Fub25pY2FsDQogICAgICB2YWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlIGd1YXJh bnRlZWQgdG8gYmUgc3RhYmxlIG92ZXINCiAgICAgIHRpbWUuDQogICBvICBWYWx1ZXMgaW4gdGhl ICdkZXNjcmlwdGlvbicgZmllbGQgTVVTVCBOT1QgYmUgY2hhbmdlZCBpbiBhIHdheQ0KICAgICAg dGhhdCB3b3VsZCBpbnZhbGlkYXRlIHByZXZpb3VzbHktZXhpc3RpbmcgdGFncy4gIFRoZXkgbWF5 IGJlDQogICAgICBicm9hZGVuZWQgc29tZXdoYXQgaW4gc2NvcGUsIGNoYW5nZWQgdG8gYWRkIGlu Zm9ybWF0aW9uLCBvcg0KICAgICAgYWRhcHRlZCB0byB0aGUgbW9zdCBjb21tb24gbW9kZXJuIHVz YWdlLiAgRm9yIGV4YW1wbGUsIGNvdW50cmllcw0KICAgICAgb2NjYXNpb25hbGx5IGNoYW5nZSB0 aGVpciBvZmZpY2lhbCBuYW1lczogYW4gaGlzdG9yaWNhbCBleGFtcGxlIG9mDQogICAgICB0aGlz IHdvdWxkIGJlICJVcHBlciBWb2x0YSIgY2hhbmdpbmcgdG8gIkJ1cmtpbmEgRmFzbyIuDQogICBv ICBWYWx1ZXMgaW4gdGhlIGZpZWxkICdyZWNvbW1lbmRlZCBwcmVmaXgnIE1BWSBiZSBhZGRlZCB2 aWEgdGhlDQogICAgICByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCiAgIG8gIFZhbHVlcyBpbiB0aGUg ZmllbGQgJ3JlY29tbWVuZGVkIHByZWZpeCcgTUFZIGJlIG1vZGlmaWVkLCBzbyBsb25nDQogICAg ICBhcyB0aGUgbW9kaWZpY2F0aW9ucyBicm9hZGVuIHRoZSBzZXQgb2YgcmVjb21tZW5kZWQgcHJl Zml4ZXMuDQogICAgICBUaGF0IGlzLCBhIHJlY29tbWVuZGVkIHByZWZpeCBNQVkgYmUgcmVwbGFj ZWQgYnkgb25lIG9mIGl0cyBvd24NCiAgICAgIHByZWZpeGVzLiAgRm9yIGV4YW1wbGUsIHRoZSBw cmVmaXggImVuLVVTIiBjb3VsZCBiZSByZXBsYWNlZCBieQ0KICAgICAgImVuIiwgYnV0IG5vdCBi eSB0aGUgcmFuZ2VzICJlbi1MYXRuIiwgImZyIiwgb3IgImVuLVVTLWJvb250Ii4NCiAgIG8gIFZh bHVlcyBpbiB0aGUgZmllbGQgJ3JlY29tbWVuZGVkIHByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3Zl ZC4NCiAgIG8gIFRoZSBmaWVsZCAnY29tbWVudHMnIE1BWSBiZSBhZGRlZCwgY2hhbmdlZCwgbW9k aWZpZWQsIG9yIHJlbW92ZWQNCiAgICAgIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3Ig YW55IG9mIHRoZSBwcm9jZXNzZXMgb3INCiAgICAgIGNvbnNpZGVyYXRpb25zIGRlc2NyaWJlZCBp biB0aGlzIHNlY3Rpb24uDQogICBvICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5 MjQsIGFuZCBJU08gMzE2NiB0aGF0IGRvIG5vdA0KICAgICAgY29uZmxpY3Qgd2l0aCBleGlzdGlu ZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5cGUgYW5kIHdob3NlDQogICAgICBtZWFuaW5n IGlzIG5vdCB0aGUgc2FtZSBhcyBhbiBleGlzdGluZyBzdWJ0YWcgb2YgdGhlIHNhbWUgdHlwZSBh cmUNCiAgICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVjb3JkcyBh bmQgdGhlaXIgdmFsdWUgaXMNCiAgICAgIGNhbm9uaWNhbCBmb3IgdGhlIG1lYW5pbmcgYXNzaWdu ZWQgdG8gdGhlbS4NCiAgIG8gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwg b3IgSVNPIDMxNjYgdGhhdCBhcmUNCiAgICAgIHdpdGhkcmF3biBieSB0aGVpciByZXNwZWN0aXZl IG1haW50ZW5hbmNlIG9yIHJlZ2lzdHJhdGlvbg0KICAgICAgYXV0aG9yaXR5IHJlbWFpbiB2YWxp ZCBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzDQogICAgICBNQVkg YmUgdXNlZCB0byBhZGQgYSBub3RlIGluZGljYXRpbmcgdGhlIHdpdGhkcmF3YWwgb2YgdGhlIGNv ZGUgYnkNCiAgICAgIHRoZSByZXNwZWN0aXZlIHN0YW5kYXJkLg0KICAgbyAgQ29kZXMgYXNzaWdu ZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBvciBJU08gMzE2NiB0aGF0IGRvIG5vdA0KICAgICAg Y29uZmxpY3Qgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5cGUgYnV0 IHdoaWNoDQogICAgICByZXByZXNlbnQgdGhlIHNhbWUgbWVhbmluZyBhcyBhbiBleGlzdGluZyBz dWJ0YWcgb2YgdGhhdCB0eXBlIGFyZQ0KICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJQU5BIHJlZ2lz dHJ5IGFzIG5ldyByZWNvcmRzLiAgVGhlIGZpZWxkDQogICAgICAnY2Fub25pY2FsIHZhbHVlJyBm b3IgdGhhdCByZWNvcmQgTVVTVCBjb250YWluIHRoZSBleGlzdGluZyBzdWJ0YWcNCiAgICAgIG9m IHRoZSBzYW1lIG1lYW5pbmcNCiAgICAgIEV4YW1wbGUgSWYgSVNPIDMxNjYgd2VyZSB0byBhc3Np Z24gdGhlIGNvZGUgJ0lNJyB0byByZXByZXNlbnQgdGhlDQogICAgICAgICB2YWx1ZSAiSXNsZSBv ZiBNYW4iIChyZXByZXNlbnRlZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBieSB0aGUgVU4NCiAgICAg ICAgIE0uNDkgY29kZSAnODMzJyksICc4MzMnIHJlbWFpbnMgdGhlIGNhbm9uaWNhbCBzdWJ0YWcg YW5kICdJTScNCiAgICAgICAgIHdvdWxkIGJlIGFzc2lnbmVkICc4MzMnIGFzIGEgY2Fub25pY2Fs IHZhbHVlLiAgVGhpcyBwcmV2ZW50cw0KICAgICAgICAgdGFncyB0aGF0IGFyZSBpbiBjYW5vbmlj YWwgZm9ybSBmcm9tIGJlY29taW5nIG5vbi1jYW5vbmljYWwuDQoNCg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBb UGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgICAgIEV4YW1wbGUgSWYgdGhlIHRh ZyAnZW5vY2hpYW4nIHdlcmUgcmVnaXN0ZXJlZCBhcyBhIHByaW1hcnkNCiAgICAgICAgIGxhbmd1 YWdlIHN1YnRhZyBhbmQgSVNPIDYzOSBzdWJzZXF1ZW50bHkgYXNzaWduZWQgYW4gYWxwaGEtMw0K ICAgICAgICAgY29kZSB0byB0aGUgc2FtZSBsYW5ndWFnZSwgdGhlIG5ldyBJU08gNjM5IGNvZGUg d291bGQgYmUNCiAgICAgICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBhIHN1 YnRhZyB3aXRoIGEgY2Fub25pY2FsDQogICAgICAgICBtYXBwaW5nIHRvICdlbm9jaGlhbicuICBU aGUgbmV3IElTTyBjb2RlIGNhbiBiZSB1c2VkLCBidXQgaXQgaXMNCiAgICAgICAgIG5vdCBjYW5v bmljYWwuDQogICBvICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIG9yIElT TyAzMTY2IHRoYXQgY29uZmxpY3QNCiAgICAgIHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUg YXNzb2NpYXRlZCB0eXBlIE1VU1QgTk9UIGJlIGVudGVyZWQNCiAgICAgIGludG8gdGhlIHJlZ2lz dHJ5LiAgVGhlIGZvbGxvd2luZyBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIGFwcGx5Og0KICAg ICAgKiAgRm9yIElTTyA2MzkgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVh bmluZyBpcyBub3QNCiAgICAgICAgIHJlcHJlc2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJQU5B IHJlZ2lzdHJ5LCB0aGUgTGFuZ3VhZ2UNCiAgICAgICAgIFN1YnRhZyBSZXZpZXdlciwgYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMy4zLCBzaGFsbCBwcmVwYXJlIGENCiAgICAgICAgIHByb3Bvc2Fs IGZvciBlbnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBzb29uIGFzIHByYWN0aWNhbA0K ICAgICAgICAgYSByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUgdmFs dWUgZm9yIHRoZSBuZXcNCiAgICAgICAgIGNvZGUuICBUaGUgZm9ybSBvZiB0aGUgcmVnaXN0ZXJl ZCBsYW5ndWFnZSBzdWJ0YWcgd2lsbCBiZSBhdA0KICAgICAgICAgdGhlIGRpc2NyZXRpb24gb2Yg dGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhbmQgbXVzdCBjb25mb3JtDQogICAgICAgICB0 byBvdGhlciByZXN0cmljdGlvbnMgb24gbGFuZ3VhZ2Ugc3VidGFncyBpbiB0aGlzIGRvY3VtZW50 Lg0KICAgICAgKiAgRm9yIGFsbCBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMgZGVyaXZlZCBmcm9t IGFuIGV4dGVybmFsDQogICAgICAgICBzdGFuZGFyZCAoaS5lLiAgSVNPIDYzOSwgSVNPIDE1OTI0 LCBJU08gMzE2Niwgb3IgVU4gTS40OSksIGlmIGENCiAgICAgICAgIG5ldyBtZWFuaW5nIGlzIGFz c2lnbmVkIHRvIGFuIGV4aXN0aW5nIGNvZGUgYW5kIHRoZSBuZXcgbWVhbmluZw0KICAgICAgICAg YnJvYWRlbnMgdGhlIG1lYW5pbmcgb2YgdGhhdCBjb2RlLCB0aGVuIHRoZSBtZWFuaW5nIGZvciB0 aGUNCiAgICAgICAgIGFzc29jaWF0ZWQgc3VidGFnIE1BWSBiZSBjaGFuZ2VkIHRvIG1hdGNoLiAg VGhlIG1lYW5pbmcgb2YgYQ0KICAgICAgICAgc3VidGFnIE1VU1QgTk9UIGJlIG5hcnJvd2VkLCBo b3dldmVyLCBhcyB0aGlzIGNhbiByZXN1bHQgaW4gYW4NCiAgICAgICAgIHVua25vd24gcHJvcG9y dGlvbiBvZiB0aGUgZXhpc3RpbmcgdXNlcyBvZiBhIHN1YnRhZyBiZWNvbWluZw0KICAgICAgICAg aW52YWxpZC4gIE5vdGU6IElTTyA2MzkgTUEvUkEgaGFzIGFkb3B0ZWQgYSBzaW1pbGFyIHN0YWJp bGl0eQ0KICAgICAgICAgcG9saWN5Lg0KICAgICAgKiAgRm9yIElTTyAxNTkyNCBjb2RlcywgaWYg dGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICBub3QgcmVwcmVz ZW50ZWQgYnkgYSBzdWJ0YWcgaW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZSBMYW5ndWFnZQ0KICAg ICAgICAgU3VidGFnIFJldmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMsIHNoYWxs IHByZXBhcmUgYQ0KICAgICAgICAgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZSBJQU5BIHJl Z2lzdHJ5IGFzIHNvb24gYXMgcHJhY3RpY2FsDQogICAgICAgICBhIHJlZ2lzdGVyZWQgdmFyaWFu dCBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUgbmV3DQogICAgICAgICBjb2Rl LiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgd2lsbCBiZSBhdCB0 aGUNCiAgICAgICAgIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBh bmQgbXVzdCBjb25mb3JtIHRvDQogICAgICAgICBvdGhlciByZXN0cmljdGlvbnMgb24gdmFyaWFu dCBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuDQogICAgICAqICBGb3IgSVNPIDMxNjYgY29kZXMs IGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgYXNzb2Np YXRlZCB3aXRoIHRoZSBzYW1lIFVOIE0uNDkgY29kZSBhcyBhbm90aGVyICdyZWdpb24nDQogICAg ICAgICBzdWJ0YWcsIHRoZW4gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgcmVtYWlucyBhcyB0 aGUNCiAgICAgICAgIGNhbm9uaWNhbCBlbnRyeSBmb3IgdGhhdCByZWdpb24gYW5kIG5vIG5ldyBl bnRyeSBpcyBjcmVhdGVkLiAgQQ0KICAgICAgICAgbm90ZSBNQVkgYmUgYWRkZWQgdG8gdGhlIGV4 aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgaW5kaWNhdGluZyB0aGUNCiAgICAgICAgIHJlbGF0aW9uc2hp cCB0byB0aGUgbmV3IElTTyAzMTY2IGNvZGUuDQogICAgICAqICBGb3IgSVNPIDMxNjYgY29kZXMs IGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgYXNzb2Np YXRlZCB3aXRoIGEgVU4gTS40OSBjb2RlIHRoYXQgaXMgbm90IHJlcHJlc2VudGVkIGJ5IGFuDQog ICAgICAgICBleGlzdGluZyByZWdpb24gc3VidGFnLCB0aGVuIHRoZW4gdGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciwNCiAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMywgc2hh bGwgcHJlcGFyZSBhIHByb3Bvc2FsIGZvcg0KICAgICAgICAgZW50ZXJpbmcgdGhlIGFwcHJvcHJp YXRlIG51bWVyaWMgVU4gY291bnRyeSBjb2RlIGFzIGFuIGVudHJ5IGluDQogICAgICAgICB0aGUg SUFOQSByZWdpc3RyeS4NCiAgICAgICogIEZvciBJU08gMzE2NiBjb2RlcywgaWYgdGhlcmUgaXMg bm8gYXNzb2NpYXRlZCBVTiBudW1lcmljIGNvZGUsDQogICAgICAgICB0aGVuIHRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXIgU0hBTEwgcGV0aXRpb24gdGhlIFVOIHRvDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBb UGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgICAgICAgIGNyZWF0ZSBvbmUuICBJ ZiB0aGVyZSBpcyBubyByZXNwb25zZSBmcm9tIHRoZSBVTiB3aXRoaW4gbmluZXR5DQogICAgICAg ICBkYXlzIG9mIHRoZSByZXF1ZXN0IGJlaW5nIHNlbnQsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2 aWV3ZXINCiAgICAgICAgIHNoYWxsIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4g dGhlIElBTkEgcmVnaXN0cnkgYXMNCiAgICAgICAgIHNvb24gYXMgcHJhY3RpY2FsIGEgcmVnaXN0 ZXJlZCB2YXJpYW50IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUNCiAgICAgICAgIHZhbHVlIGZvciB0 aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZiB0aGUgcmVnaXN0ZXJlZCB2YXJpYW50DQogICAgICAg ICBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFn DQogICAgICAgICBSZXZpZXdlciBhbmQgbXVzdCBjb25mb3JtIHRvIG90aGVyIHJlc3RyaWN0aW9u cyBvbiB2YXJpYW50DQogICAgICAgICBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuICBUaGlzIHNp dHVhdGlvbiBpcyB2ZXJ5IHVubGlrZWx5IHRvDQogICAgICAgICBldmVyIG9jY3VyLg0KICAgbyAg U3RhYmlsaXR5IHByb3Zpc2lvbnMgYXBwbHkgdG8gZ3JhbmRmYXRoZXJlZCB0YWdzIHdpdGggdGhp cw0KICAgICAgZXhjZXB0aW9uOiBzaG91bGQgYWxsIG9mIHRoZSBzdWJ0YWdzIGluIGEgZ3JhbmRm YXRoZXJlZCB0YWcgYmVjb21lDQogICAgICB2YWxpZCBzdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lz dHJ5LCB0aGVuIHRoZSBncmFuZGZhdGhlcmVkIHRhZw0KICAgICAgTVVTVCBiZSBtYXJrZWQgYXMg cmVkdW5kYW50LiAgTm90ZSB0aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0DQogICAgICBsYW5ndWFn ZSB0YWdzIHRoYXQgbWF0Y2ggdGhlIGdyYW5kZmF0aGVyZWQgdGFnLCBzaW5jZSB0aGVzZSB0YWdz DQogICAgICB3aWxsIG5vdyBtYXRjaCB2YWxpZCBnZW5lcmF0aXZlIHN1YnRhZyBzZXF1ZW5jZXMu ICBGb3IgZXhhbXBsZSwgaWYNCiAgICAgIHRoZSBzdWJ0YWcgJ2dhbicgaW4gdGhlIGxhbmd1YWdl IHRhZyAiemgtZ2FuIiB3ZXJlIHRvIGJlDQogICAgICByZWdpc3RlcmVkIGFzIGFuIGV4dGVuZGVk IGxhbmd1YWdlIHN1YnRhZywgdGhlbiB0aGUgZ3JhbmRmYXRoZXJlZA0KICAgICAgdGFnICJ6aC1n YW4iIHdvdWxkIGJlIGRlcHJlY2F0ZWQgKGJ1dCBleGlzdGluZyBjb250ZW50IG9yDQogICAgICBp bXBsZW1lbnRhdGlvbnMgdGhhdCB1c2UgInpoLWdhbiIgd291bGQgcmVtYWluIHZhbGlkKS4NCg0K ICAgTGFuZ3VhZ2UgdGFncyBmb3JtZWQgdW5kZXIgUkZDIDMwNjYgdGhhdCB1c2UgdGhlIHJlZ2lv biBzdWJ0YWcgJ0NTJw0KICAgd2VyZSBhbWJpZ3VvdXMsIHNpbmNlIHRhZ3MgcHJvZHVjZWQgYmVm b3JlIDIwMDMgdXNlZCB0aGF0IGNvZGUgZm9yDQogICB0aGUgKG5vdyBkaXNzb2x2ZWQpIGNvdW50 cnkgQ3plY2hvc2xvdmFraWEuICBJU08gMzE2NiBhc3NpZ25lZCB0aGlzDQogICBjb2RlIHRvIHRo ZSBjb3VudHJ5IFNlcmJpYSBhbmQgTW9udGVuZWdybyBpbiAyMDAzIGFuZCB0aGlzIGRyYWZ0DQog ICBtYWtlcyB0aGF0IHRoZSBjYW5vbmljYWwgdmFsdWUgZm9yIHRoaXMgc3VidGFnLiAgVG8gZm9y bSBhIGxhbmd1YWdlDQogICB0YWcgZm9yIHRoZSByZWdpb24gQ3plY2hvc2xvdmFraWEsIHRoZSBV TiBNLjQ5IGNvZGUgJzIwMCcgaXMgaW5jbHVkZWQNCiAgIGluIHRoZSByZWdpc3RyeS4gIEFzIGEg cHJhY3RpY2FsIG1hdHRlciwgYXBwbGljYXRpb25zIHRoYXQgZW5jb3VudGVyDQogICB0aGUgUkZD IDMwNjYgdGFnICJjcy1DUyIgb3IgInNrLUNTIiBNQVkgd2lzaCB0byBjb252ZXJ0IHRoYXQgdG8N CiAgICJjcy0yMDAiIG9yICJzay0yMDAiIChvciB1c2Ugb25lIG9mIHRoZSBzdWNjZXNzb3IgcmVn aW9uIHN1YnRhZ3MsDQogICBzdWNoIGFzICdDWicgb3IgJ1NLJyksIHNpbmNlIHRoYXQgaXMgdGhl IG1vc3QgbGlrZWx5IGludGVycHJldGF0aW9uLg0KDQozLjMgIFJlZ2lzdHJhdGlvbiBQcm9jZWR1 cmUgZm9yIFN1YnRhZ3MNCg0KICAgVGhlIHByb2NlZHVyZSBnaXZlbiBoZXJlIE1VU1QgYmUgdXNl ZCBieSBhbnlvbmUgd2hvIHdhbnRzIHRvIHVzZSBhDQogICBzdWJ0YWcgbm90IGN1cnJlbnRseSBp biB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuDQoNCiAgIE9ubHkgcHJpbWFyeSBs YW5ndWFnZSBhbmQgdmFyaWFudCBzdWJ0YWdzIHdpbGwgYmUgY29uc2lkZXJlZCBmb3INCiAgIGlu ZGVwZW5kZW50IHJlZ2lzdHJhdGlvbi4gIChTdWJ0YWdzIHJlcXVpcmVkIGZvciBzdGFiaWxpdHkg YW5kDQogICBzdWJ0YWdzIHJlcXVpcmVkIHRvIGtlZXAgdGhlIHJlZ2lzdHJ5IHN5bmNocm9uaXpl ZCB3aXRoIElTTyA2MzksIElTTw0KICAgMTU5MjQsIElTTyAzMTY2LCBhbmQgVU4gTS40OSB3aXRo aW4gdGhlIGxpbWl0cyBkZWZpbmVkIGJ5IHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0aGUgb25seSBl eGNlcHRpb25zIHRvIHRoaXMuICBTZWUgU2VjdGlvbiAzLjIuKQ0KDQogICBUaGlzIHByb2NlZHVy ZSBNQVkgYWxzbyBiZSB1c2VkIHRvIHJlZ2lzdGVyIG9yIGFsdGVyIHRoZSBpbmZvcm1hdGlvbg0K ICAgZm9yIHRoZSAiZGVzY3JpcHRpb24iLCAibm90ZSIsIG9yICJyZWNvbW1lbmRlZCBwcmVmaXgi IGZpZWxkcyBpbiBhDQogICBzdWJ0YWcncyByZWNvcmQgYXMgZGVzY3JpYmVkIGluIEZpZ3VyZSAy LiAgQ2hhbmdlcyB0byBhbGwgb3RoZXINCiAgIGZpZWxkcyBpbiB0aGUgSUFOQSByZWdpc3RyeSBh cmUgTk9UIHBlcm1pdHRlZC4NCg0KICAgSWYgcmVnaXN0ZXJpbmcgYSBuZXcgbGFuZ3VhZ2Ugc3Vi dGFnLCB0aGUgcHJvY2VzcyBzdGFydHMgYnkgZmlsbGluZw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQogICBvdXQgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIHJl cHJvZHVjZWQgYmVsb3cuICBOb3RlIHRoYXQgZWFjaCByZXNwb25zZQ0KICAgaXMgbm90IGxpbWl0 ZWQgaW4gc2l6ZSBhbmQgc2hvdWxkIHRha2UgdGhlIHJvb20gbmVjZXNzYXJ5IHRvDQogICBhZGVx dWF0ZWx5IGRlc2NyaWJlIHRoZSByZWdpc3RyYXRpb24uDQoNCiAgIExBTkdVQUdFIFNVQlRBRyBS RUdJU1RSQVRJT04gRk9STQ0KICAgMS4gTmFtZSBvZiByZXF1ZXN0ZXI6DQogICAyLiBFLW1haWwg YWRkcmVzcyBvZiByZXF1ZXN0ZXI6DQogICAzLiBTdWJ0YWcgdG8gYmUgcmVnaXN0ZXJlZDoNCiAg IDQuIFR5cGUgb2YgUmVnaXN0cmF0aW9uOg0KICAgICAgWyBdIGxhbmd1YWdlDQogICAgICBbIF0g dmFyaWFudA0KICAgNS4gRGVzY3JpcHRpb24gb2Ygc3VidGFnIChpbiBFbmdsaXNoIG9yIHRyYW5z Y3JpYmVkIGludG8gQVNDSUkpOg0KICAgNi4gSW50ZW5kZWQgbWVhbmluZyBvZiB0aGUgc3VidGFn Og0KICAgNy4gUmVjb21tZW5kZWQgcHJlZml4KGVzKSBvZiBzdWJ0YWcgKGZvciB2YXJpYW50cyk6 DQogICA4LiBOYXRpdmUgbmFtZSBvZiB0aGUgbGFuZ3VhZ2Ugb3IgdmFyaWF0aW9uICh0cmFuc2Ny aWJlZCBpbnRvIEFTQ0lJKToNCiAgIDkuIFJlZmVyZW5jZSB0byBwdWJsaXNoZWQgZGVzY3JpcHRp b24gb2YgdGhlIGxhbmd1YWdlIChib29rIG9yIGFydGljbGUpOg0KICAgMTAuIEFueSBvdGhlciBy ZWxldmFudCBpbmZvcm1hdGlvbjoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgNA0KDQogICBUaGUgc3VidGFnIHJlZ2lzdHJhdGlvbiBmb3JtIE1VU1QgYmUgc2VudCB0 bw0KICAgPGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPiBmb3IgYSB0d28gd2VlayByZXZpZXcgcGVy aW9kIGJlZm9yZSBpdCBjYW4NCiAgIGJlIHN1Ym1pdHRlZCB0byBJQU5BLiAgKFRoaXMgaXMgYW4g b3BlbiBsaXN0LiAgUmVxdWVzdHMgdG8gYmUgYWRkZWQNCiAgIHNob3VsZCBiZSBzZW50IHRvIDxp ZXRmLWxhbmd1YWdlcy1yZXF1ZXN0QGlhbmEub3JnPi4pDQoNCiAgIFZhcmlhbnQgc3VidGFncyBh cmUgZ2VuZXJhbGx5IHJlZ2lzdGVyZWQgZm9yIHVzZSB3aXRoIGEgcGFydGljdWxhcg0KICAgcmFu Z2Ugb2YgbGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxlLCB0aGUgc3VidGFnICdib29udCcgaXMg aW50ZW5kZWQNCiAgIGZvciB1c2Ugd2l0aCBsYW5ndWFnZSB0YWdzIHRoYXQgc3RhcnQgd2l0aCB0 aGUgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnICJlbiIsIHNpbmNlIEJvb250bGluZyBpcyBh IGRpYWxlY3Qgb2YgRW5nbGlzaC4gIFRodXMgdGhlDQogICBzdWJ0YWcgJ2Jvb250JyBjb3VsZCBi ZSBpbmNsdWRlZCBpbiB0YWdzIHN1Y2ggYXMgImVuLUxhdG4tYm9vbnQiIG9yDQogICAiZW4tVVMt Ym9vbnQiLiAgVGhpcyBpbmZvcm1hdGlvbiBpcyBzdG9yZWQgaW4gdGhlICJyZWNvbW1lbmRlZA0K ICAgcHJlZml4IiBmaWVsZCBpbiB0aGUgcmVnaXN0cnkgYW5kIE1VU1QgYmUgcHJvdmlkZWQgaW4g dGhlDQogICByZWdpc3RyYXRpb24gZm9ybS4NCg0KICAgQW55IHN1YnRhZyBNQVkgYmUgaW5jb3Jw b3JhdGVkIGludG8gYSB2YXJpZXR5IG9mIGxhbmd1YWdlIHRhZ3MsDQogICBhY2NvcmRpbmcgdG8g dGhlIHJ1bGVzIG9mIFNlY3Rpb24gMi4xLCBpbmNsdWRpbmcgdGFncyB0aGF0IGRvIG5vdA0KICAg bWF0Y2ggYW55IG9mIHRoZSByZWNvbW1lbmRlZCBwcmVmaXhlcyBvZiB0aGUgcmVnaXN0ZXJlZCBz dWJ0YWcuDQogICAoTm90ZSB0aGF0IHRoaXMgaXMgcHJvYmFibHkgYSBwb29yIGNob2ljZS4pIFRo aXMgbWFrZXMgdmFsaWRhdGlvbg0KICAgc2ltcGxlciBhbmQgdGh1cyBtb3JlIHVuaWZvcm0gYWNy b3NzIGltcGxlbWVudGF0aW9ucywgYW5kIGRvZXMgbm90DQogICByZXF1aXJlIHRoZSByZWdpc3Ry YXRpb24gb2YgYSBzZXBhcmF0ZSBzdWJ0YWcgZm9yIHRoZSBzYW1lIHB1cnBvc2UNCiAgIGFuZCBt ZWFuaW5nIGJ1dCBhIGRpZmZlcmVudCByZWNvbW1lbmRlZCBwcmVmaXguDQoNCiAgIFRoZSByZWNv bW1lbmRlZCBwcmVmaXhlcyBmb3IgYSBnaXZlbiByZWdpc3RlcmVkIHN1YnRhZyB3aWxsIGJlDQog ICBtYWludGFpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIGEgZ3VpZGUgdG8gdXNhZ2UuICBJ ZiBpdCBpcw0KICAgbmVjZXNzYXJ5IHRvIGFkZCBhbiBhZGRpdGlvbmFsIHByZWZpeCB0byB0aGF0 IGxpc3QgZm9yIGFuIGV4aXN0aW5nDQogICBsYW5ndWFnZSB0YWcsIHRoYXQgY2FuIGJlIGRvbmUg YnkgZmlsaW5nIGFuIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uDQogICBmb3JtLiAgSW4gdGhhdCBm b3JtLCB0aGUgIkFueSBvdGhlciByZWxldmFudCBpbmZvcm1hdGlvbjoiIGZpZWxkDQogICBzaG91 bGQgaW5kaWNhdGUgdGhhdCBpdCBpcyB0aGUgYWRkaXRpb24gb2YgYW4gYWRkaXRpb25hbCByZWNv bW1lbmRlZA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAx MSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQog ICBwcmVmaXguDQoNCiAgIFJlcXVlc3RzIHRvIGFkZCBhIHJlY29tbWVuZGVkIHByZWZpeCB0byBh IHN1YnRhZyB0aGF0IGltcGx5IGENCiAgIGRpZmZlcmVudCBzZW1hbnRpYyBtZWFuaW5nIHdpbGwg cHJvYmFibHkgYmUgcmVqZWN0ZWQuICBGb3IgZXhhbXBsZSwgYQ0KICAgcmVxdWVzdCB0byBhZGQg dGhlIHByZWZpeCAiZGUiIHRvIHRoZSBzdWJ0YWcgJ25lZGlzJyBzbyB0aGF0IHRoZSB0YWcNCiAg ICJkZS1uZWRpcyIgcmVwcmVzZW50ZWQgc29tZSBHZXJtYW4gZGlhbGVjdCB3b3VsZCBiZSByZWpl Y3RlZC4gIFRoZQ0KICAgJ25lZGlzJyBzdWJ0YWcgcmVwcmVzZW50cyBhIHBhcnRpY3VsYXIgU2xv dmVuaWFuIGRpYWxlY3QgYW5kIHRoZQ0KICAgYWRkaXRpb25hbCByZWdpc3RyYXRpb24gd291bGQg Y2hhbmdlIHRoZSBzZW1hbnRpYyBtZWFuaW5nIGFzc2lnbmVkIHRvDQogICB0aGUgc3VidGFnLiAg QSBzZXBhcmF0ZSBzdWJ0YWcgc2hvdWxkIGJlIHByb3Bvc2VkIGluc3RlYWQuDQoNCiAgIFRoZSBM YW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgaXMgcmVzcG9uc2libGUgZm9yIHJlc3BvbmRpbmcgdG8N CiAgIHJlcXVlc3RzIGZvciB0aGUgcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3MgdGhyb3VnaCB0aGUg cmVnaXN0cmF0aW9uDQogICBwcm9jZXNzICBhbmQgaXMgYXBwb2ludGVkIGJ5IHRoZSBJRVNHLg0K DQogICBXaGVuIHRoZSB0d28gd2VlayBwZXJpb2QgaGFzIHBhc3NlZCB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJldmlld2VyDQogICBlaXRoZXIgZm9yd2FyZHMgdGhlIHJlcXVlc3QgdG8gaWFuYUBpYW5h Lm9yZywgb3IgcmVqZWN0cyBpdCBiZWNhdXNlDQogICBvZiBzaWduaWZpY2FudCBvYmplY3Rpb25z IHJhaXNlZCBvbiB0aGUgbGlzdCBvciBkdWUgdG8gcHJvYmxlbXMgd2l0aA0KICAgY29uc3RyYWlu dHMgaW4gdGhpcyBkb2N1bWVudCAod2hpY2ggc2hvdWxkIGJlIGV4cGxpY2l0bHkgY2l0ZWQpLiAg VGhlDQogICByZXZpZXdlciBtYXkgYWxzbyBleHRlbmQgdGhlIHJldmlldyBwZXJpb2QgaW4gdHdv IHdlZWsgaW5jcmVtZW50cyB0bw0KICAgcGVybWl0IGZ1cnRoZXIgZGlzY3Vzc2lvbi4gIFRoZSBy ZXZpZXdlciBtdXN0IGluZGljYXRlIG9uIHRoZSBsaXN0DQogICB3aGV0aGVyIHRoZSByZWdpc3Ry YXRpb24gaGFzIGJlZW4gYWNjZXB0ZWQsIHJlamVjdGVkLCBvciBleHRlbmRlZA0KICAgZm9sbG93 aW5nIGVhY2ggdHdvIHdlZWsgcGVyaW9kLg0KDQogICBOb3RlIHRoYXQgdGhlIHJldmlld2VyIGNh biByYWlzZSBvYmplY3Rpb25zIG9uIHRoZSBsaXN0IGlmIGhlIG9yIHNoZQ0KICAgc28gZGVzaXJl cy4gIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB0aGUgb2JqZWN0aW9uIG11c3QgYmUgbWFk ZQ0KICAgcHVibGljbHkuDQoNCiAgIFRoZSBhcHBsaWNhbnQgaXMgZnJlZSB0byBtb2RpZnkgYSBy ZWplY3RlZCBhcHBsaWNhdGlvbiB3aXRoDQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFuZCBz dWJtaXQgaXQgYWdhaW47IHRoaXMgcmVzdGFydHMgdGhlIHR3bw0KICAgd2VlayBjb21tZW50IHBl cmlvZC4NCg0KICAgRGVjaXNpb25zIG1hZGUgYnkgdGhlIHJldmlld2VyIG1heSBiZSBhcHBlYWxl ZCB0byB0aGUgSUVTRyBbUkZDIDIwMjhdDQogICBbMTBdIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFz IG90aGVyIElFVEYgZGVjaXNpb25zIFtSRkMgMjAyNl0gWzIxXS4NCg0KICAgQWxsIGFwcHJvdmVk IHJlZ2lzdHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSBpbiB0aGUgZGlyZWN0b3J5 DQogICBodHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFuZ3VhZ2VzIi4N Cg0KICAgVXBkYXRlcyBvZiByZWdpc3RyYXRpb25zIGZvbGxvdyB0aGUgc2FtZSBwcm9jZWR1cmUg YXMgcmVnaXN0cmF0aW9ucy4NCiAgIFRoZSBzdWJ0YWcgcmV2aWV3ZXIgZGVjaWRlcyB3aGV0aGVy IHRvIGFsbG93IGEgbmV3IHJlZ2lzdHJhbnQgdG8NCiAgIHVwZGF0ZSBhIHJlZ2lzdHJhdGlvbiBt YWRlIGJ5IHNvbWVvbmUgZWxzZTsgbm9ybWFsbHkgb2JqZWN0aW9ucyBieQ0KICAgdGhlIG9yaWdp bmFsIHJlZ2lzdHJhbnQgd291bGQgY2FycnkgZXh0cmEgd2VpZ2h0IGluIHN1Y2ggYSBkZWNpc2lv bi4NCg0KICAgUmVnaXN0cmF0aW9ucyBhcmUgcGVybWFuZW50IGFuZCBzdGFibGUuICBPbmNlIHJl Z2lzdGVyZWQsIHN1YnRhZ3MNCiAgIHdpbGwgbm90IGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVnaXN0 cnkgYW5kIHdpbGwgcmVtYWluIHRoZSBjYW5vbmljYWwNCiAgIG1ldGhvZCBvZiByZWZlcnJpbmcg dG8gYSBzcGVjaWZpYyBsYW5ndWFnZSBvciB2YXJpYW50LiAgVGhpcw0KICAgcHJvdmlzaW9uIGRv ZXMgbm90IGFwcGx5IHRvIGdyYW5kZmF0aGVyZWQgdGFncywgd2hpY2ggbWF5IGJlY29tZQ0KICAg ZGVwcmVjYXRlZCBkdWUgdG8gcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwg dGhlIHRhZw0KICAgImktbmF2YWpvIiBpcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08g NjM5LTEgYmFzZWQgc3VidGFnICdudicuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAgICAgICAgICAgICAg TWFyY2ggMjAwNQ0KDQoNCiAgIE5vdGU6IFRoZSBwdXJwb3NlIG9mIHRoZSAicHVibGlzaGVkIGRl c2NyaXB0aW9uIiBpbiB0aGUgcmVnaXN0cmF0aW9uDQogICBmb3JtIGlzIGludGVuZGVkIGFzIGFu IGFpZCB0byBwZW9wbGUgdHJ5aW5nIHRvIHZlcmlmeSB3aGV0aGVyIGENCiAgIGxhbmd1YWdlIGlz IHJlZ2lzdGVyZWQgb3Igd2hhdCBsYW5ndWFnZSBvciBsYW5ndWFnZSB2YXJpYXRpb24gYQ0KICAg cGFydGljdWxhciBzdWJ0YWcgcmVmZXJzIHRvLiAgSW4gbW9zdCBjYXNlcywgcmVmZXJlbmNlIHRv IGFuDQogICBhdXRob3JpdGF0aXZlIGdyYW1tYXIgb3IgZGljdGlvbmFyeSBvZiB0aGF0IGxhbmd1 YWdlIHdpbGwgYmUgdXNlZnVsOw0KICAgaW4gY2FzZXMgd2hlcmUgbm8gc3VjaCB3b3JrIGV4aXN0 cywgb3RoZXIgd2VsbCBrbm93biB3b3JrcyBkZXNjcmliaW5nDQogICB0aGF0IGxhbmd1YWdlIG9y IGluIHRoYXQgbGFuZ3VhZ2UgbWF5IGJlIGFwcHJvcHJpYXRlLiAgVGhlIHN1YnRhZw0KICAgcmV2 aWV3ZXIgZGVjaWRlcyB3aGF0IGNvbnN0aXR1dGVzICJnb29kIGVub3VnaCIgcmVmZXJlbmNlIG1h dGVyaWFsLg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBub3QgaW50ZW5kZWQgdG8gZXhjbHVkZSBw YXJ0aWN1bGFyIGxhbmd1YWdlcyBvcg0KICAgZGlhbGVjdHMgZHVlIHRvIHRoZSBzaXplIG9mIHRo ZSBzcGVha2VyIHBvcHVsYXRpb24gb3IgbGFjayBvZiBhDQogICBzdGFuZGFyZGl6ZWQgb3J0aG9n cmFwaHkuICBNaW5vcml0eSBsYW5ndWFnZXMgd2lsbCBiZSBjb25zaWRlcmVkDQogICBlcXVhbGx5 IG9uIHRoZWlyIG93biBtZXJpdHMuDQoNCjMuNCAgRXh0ZW5zaW9ucyBhbmQgRXh0ZW5zaW9ucyBO YW1lc3BhY2UNCg0KICAgRXh0ZW5zaW9uIHN1YnRhZ3MgYXJlIHRob3NlIGludHJvZHVjZWQgYnkg c2luZ2xlLWxldHRlciBzdWJ0YWdzIG90aGVyDQogICB0aGFuICd4LScuICBUaGV5IGFyZSByZXNl cnZlZCBmb3IgdGhlIGdlbmVyYXRpb24gb2YgaWRlbnRpZmllcnMgd2hpY2gNCiAgIGNvbnRhaW4g YSBsYW5ndWFnZSBjb21wb25lbnQsIGFuZCBhcmUgY29tcGF0aWJsZSB3aXRoIGFwcGxpY2F0aW9u cw0KICAgdGhhdCBwcm9jZXNzIGxhbmd1YWdlIHRhZ3MgYWNjb3JkaW5nIHRvIHRoaXMgc3BlY2lm aWNhdGlvbi4gIEZvcg0KICAgZXhhbXBsZSwgdGhleSBtaWdodCBiZSB1c2VkIHRvIGRlZmluZSBs b2NhbGUgaWRlbnRpZmllcnMsIHdoaWNoIGFyZQ0KICAgZ2VuZXJhbGx5IGJhc2VkIG9uIGxhbmd1 YWdlLg0KDQogICBUaGUgc3RydWN0dXJlIGFuZCBmb3JtIG9mIGV4dGVuc2lvbnMgYXJlIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudCBzbw0KICAgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIGNy ZWF0ZWQgdGhhdCBhcmUgZm9yd2FyZCBjb21wYXRpYmxlIHdpdGgNCiAgIGFwcGxpY2F0aW9ucyB0 aGF0IG1heSBiZSBjcmVhdGVkIHVzaW5nIHNpbmdsZS1sZXR0ZXIgc3VidGFncyBpbiB0aGUNCiAg IGZ1dHVyZS4gIEluIGFkZGl0aW9uLCBkZWZpbmluZyBhIG1lY2hhbmlzbSBmb3IgbWFpbnRhaW5p bmcNCiAgIHNpbmdsZS1sZXR0ZXIgc3VidGFncyB3aWxsIGxlbmQgdG8gdGhlIHN0YWJpbGl0eSBv ZiB0aGlzIGRvY3VtZW50IGJ5DQogICByZWR1Y2luZyB0aGUgbGlrZWx5IG5lZWQgZm9yIGZ1dHVy ZSByZXZpc2lvbnMgb3IgdXBkYXRlcy4NCg0KICAgSUFOQSB3aWxsIG1haW50YWluIGEgcmVnaXN0 cnkgb2YgYWxsb2NhdGVkIHNpbmdsZS1sZXR0ZXIgc3VidGFncy4NCiAgIFRoaXMgcmVnaXN0cnkg Y29udGFpbnMgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbjogbGV0dGVyIGlkZW50aWZpZXI7DQog ICBuYW1lOyBwdXJwb3NlOyBSRkMgZGVmaW5pbmcgdGhlIHN1YnRhZyBuYW1lc3BhY2UgYW5kIGl0 cyB1c2U7IGFuZCB0aGUNCiAgIG5hbWUsIFVSTCwgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIG1h aW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAgQWxsb2NhdGlvbiBvZiBhIHNpbmdsZS1sZXR0ZXIg c3VidGFnIHNoYWxsIHRha2UgdGhlIGZvcm0gb2YgYW4gUkZDDQogICBkZWZpbmluZyB0aGUgbmFt ZSwgcHVycG9zZSwgcHJvY2Vzc2VzLCBhbmQgcHJvY2VkdXJlcyBmb3IgbWFpbnRhaW5pbmcNCiAg IHRoZSBzdWJ0YWdzLiAgVGhlIG1haW50YWluaW5nIG9yIHJlZ2lzdGVyaW5nIGF1dGhvcml0eSwg aW5jbHVkaW5nDQogICBuYW1lLCBjb250YWN0IGVtYWlsLCBkaXNjdXNzaW9uIGxpc3QgZW1haWws IGFuZCBVUkwgbG9jYXRpb24gb2YgdGhlDQogICByZWdpc3RyeSBtdXN0IGJlIGluZGljYXRlZCBj bGVhcmx5IGluIHRoZSBSRkMuICBUaGUgUkZDIE1VU1Qgc3BlY2lmeQ0KICAgZWFjaCBvZiB0aGUg Zm9sbG93aW5nOg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCByZWZlcmVuY2UgdGhlIHNw ZWNpZmljIHZlcnNpb24gb3IgcmV2aXNpb24NCiAgICAgIG9mIHRoaXMgZG9jdW1lbnQgdGhhdCBn b3Zlcm4gaXRzIGNyZWF0aW9uIGFuZCBNVVNUIHJlZmVyZW5jZSB0aGlzDQogICAgICBzZWN0aW9u IG9mIHRoaXMgZG9jdW1lbnQuDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBhbmQgYWxsIHN1YnRh Z3MgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbg0KICAgICAgTVVTVCBmb2xsb3cgdGhlIEFC TkYgYW5kIG90aGVyIHJ1bGVzIGZvciB0aGUgZm9ybWF0aW9uIG9mIHRhZ3MgYW5kDQogICAgICBz dWJ0YWdzIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIgaXQgTVVT VA0KICAgICAgc3BlY2lmeSB0aGF0IGNhc2UgaXMgbm90IHNpZ25pZmljYW50Lg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAg ICAgICBbUGFnZSAzMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3Rh Z3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAgIG8gIFRoZSBzcGVjaWZp Y2F0aW9uIE1VU1Qgc3BlY2lmeSBhIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbi4NCiAgIG8gIFRo ZSBzcGVjaWZpY2F0aW9uIG9mIHZhbGlkIHN1YnRhZ3MgTVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0 aGUNCiAgICAgIEludGVybmV0IGFuZCBhdCBubyBjb3N0Lg0KICAgbyAgVGhlIHNwZWNpZmljYXRp b24gTVVTVCBiZSBpbiB0aGUgcHVibGljIGRvbWFpbiBvciBhdmFpbGFibGUgdmlhIGENCiAgICAg IHJveWFsdHktZnJlZSBsaWNlbnNlIGFjY2VwdGFibGUgdG8gdGhlIElFVEYgYW5kIHNwZWNpZmll ZCBpbiB0aGUNCiAgICAgIFJGQy4NCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgdmVy c2lvbmVkIGFuZCBlYWNoIHZlcnNpb24gb2YgdGhlDQogICAgICBzcGVjaWZpY2F0aW9uIE1VU1Qg YmUgbnVtYmVyZWQsIGRhdGVkLCBhbmQgc3RhYmxlLg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24g TVVTVCBiZSBzdGFibGUuICBUaGF0IGlzLCBleHRlbnNpb24gc3VidGFncywNCiAgICAgIG9uY2Ug ZGVmaW5lZCBieSBhIHNwZWNpZmljYXRpb24sIE1VU1QgTk9UIGJlIHJldHJhY3RlZCBvciBjaGFu Z2UNCiAgICAgIGluIG1lYW5pbmcgaW4gYW55IHN1YnN0YW50aWFsIHdheS4NCiAgIG8gIElBTkEg TVVTVCBiZSBpbmZvcm1lZCBvZiBjaGFuZ2VzIHRvIHRoZSBjb250YWN0IGluZm9ybWF0aW9uIGFu ZA0KICAgICAgVVJMIGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KICAgVGhlIGRldGVybWluYXRp b24gb2Ygd2hldGhlciBhbiBJbnRlcm5ldC1EcmFmdCBtZWV0cyB0aGUgYWJvdmUNCiAgIGNvbmRp dGlvbnMgYW5kIHRoZSBkZWNpc2lvbiB0byBncmFudCBvciB3aXRoaG9sZCBzdWNoIGF1dGhvcml0 eSByZXN0cw0KICAgc29sZWx5IHdpdGggdGhlIElFU0csIGFuZCBpcyBzdWJqZWN0IHRvIHRoZSBu b3JtYWwgcmV2aWV3IGFuZCBhcHBlYWxzDQogICBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0aCB0aGUg UkZDIHByb2Nlc3MuDQoNCiAgIEV4dGVuc2lvbiBhdXRob3JzIGFyZSBzdHJvbmdseSBjYXV0aW9u ZWQgdGhhdCBtYW55IChpbmNsdWRpbmcgbW9zdA0KICAgd2VsbC1mb3JtZWQpIHByb2Nlc3NvcnMg d2lsbCBiZSB1bmF3YXJlIG9mIGFueSBzcGVjaWFsIHJlbGF0aW9uc2hpcHMNCiAgIG9yIG1lYW5p bmcgaW5oZXJlbnQgaW4gdGhlIG9yZGVyIG9mIGV4dGVuc2lvbiBzdWJ0YWdzLiAgRXh0ZW5zaW9u DQogICBhdXRob3JzIFNIT1VMRCBhdm9pZCBzdWJ0YWcgcmVsYXRpb25zaGlwcyBvciBjYW5vbmlj YWxpemF0aW9uDQogICBtZWNoYW5pc21zIHRoYXQgaW50ZXJmZXJlIHdpdGggbWF0Y2hpbmcgb3Ig d2l0aCBsZW5ndGggcmVzdHJpY3Rpb25zDQogICB0aGF0IG1heSBleGlzdCBpbiBjb21tb24gcHJv dG9jb2xzIHdoZXJlIHRoZSBleHRlbnNpb24gaXMgdXNlZC4gIEluDQogICBwYXJ0aWN1bGFyLCBh cHBsaWNhdGlvbnMgbWF5IHRydW5jYXRlIHRoZSBzdWJ0YWdzIGluIGRvaW5nIG1hdGNoaW5nDQog ICBvciBpbiBmaXR0aW5nIGludG8gbGltaXRlZCBsZW5ndGhzLCBzbyBpdCBpcyBSRUNPTU1FTkRF RCB0aGF0IHRoZQ0KICAgbW9zdCBzaWduaWZpY2FudCBpbmZvcm1hdGlvbiBiZSBpbiB0aGUgbW9z dCBzaWduaWZpY2FudCAobGVmdC1tb3N0KQ0KICAgc3VidGFncywgYW5kIHRoYXQgdGhlIHNwZWNp ZmljYXRpb24gZ3JhY2VmdWxseSBoYW5kbGUgdHJ1bmNhdGVkDQogICBzdWJ0YWdzLg0KDQogICBX aGVuIGEgbGFuZ3VhZ2UgdGFnIGlzIHRvIGJlIHVzZWQgaW4gYSBzcGVjaWZpYywga25vd24sIHBy b3RvY29sLCBpdA0KICAgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGF0IHRoZSBsYW5ndWFnZSB0YWcg bm90IGNvbnRhaW4gZXh0ZW5zaW9ucyBub3QNCiAgIHN1cHBvcnRlZCBieSB0aGF0IHByb3RvY29s LiAgSW4gYWRkaXRpb24sIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0DQogICBzb21lIHByb3RvY29s cyBtYXkgaW1wb3NlIHVwcGVyIGxpbWl0cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzDQog ICB1c2VkIHRvIHN0b3JlIG9yIHRyYW5zcG9ydCB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMzFdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDUN Cg0KDQo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIG9ubHkgc2VjdXJpdHkg aXNzdWUgdGhhdCBoYXMgYmVlbiByYWlzZWQgd2l0aCBsYW5ndWFnZSB0YWdzIHNpbmNlDQogICB0 aGUgcHVibGljYXRpb24gb2YgUkZDIDE3NjYsIHdoaWNoIHN0YXRlZCB0aGF0ICJTZWN1cml0eSBp c3N1ZXMgYXJlDQogICBiZWxpZXZlZCB0byBiZSBpcnJlbGV2YW50IHRvIHRoaXMgbWVtbyIsIGlz IGEgY29uY2VybiB3aXRoIGxhbmd1YWdlDQogICBpZGVudGlmaWVycyB1c2VkIGluIGNvbnRlbnQg bmVnb3RpYXRpb24gLSB0aGF0IHRoZXkgbWF5IGJlIHVzZWQgdG8NCiAgIGluZmVyIHRoZSBuYXRp b25hbGl0eSBvZiB0aGUgc2VuZGVyLCBhbmQgdGh1cyBpZGVudGlmeSBwb3RlbnRpYWwNCiAgIHRh cmdldHMgZm9yIHN1cnZlaWxsYW5jZS4NCg0KICAgVGhpcyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0 aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgeW91IHNlbmQNCiAgIGlzIHZpc2libGUg dG8gdGhlIHJlY2VpdmluZyBwYXJ0eS4gIEl0IGlzIHVzZWZ1bCB0byBiZSBhd2FyZSB0aGF0DQog ICBzdWNoIGNvbmNlcm5zIGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBUaGUgZXZhbHVh dGlvbiBvZiB0aGUgZXhhY3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBhbnkgcG9zc2li bGUNCiAgIGNvdW50ZXJtZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0aW9uIHByb3Rv Y29sLg0KDQogICBBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIGZv ciBhbiBleHRlbnNpb24gTVVTVCBiZQ0KICAgYXZhaWxhYmxlIG92ZXIgdGhlIEludGVybmV0LCBp bXBsZW1lbnRhdGlvbnMgU0hPVUxEIE5PVCBtZWNoYW5pY2FsbHkNCiAgIGRlcGVuZCBvbiBpdCBi ZWluZyBhbHdheXMgYWNjZXNzaWJsZSwgdG8gcHJldmVudCBkZW5pYWwtb2Ytc2VydmljZQ0KICAg YXR0YWNrcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAx MSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgMzJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQo1 LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgc3ludGF4IGluIHRoaXMg ZG9jdW1lbnQgcmVxdWlyZXMgdGhhdCBsYW5ndWFnZSB0YWdzIHVzZSBvbmx5IHRoZQ0KICAgY2hh cmFjdGVycyBBLVosIGEteiwgMC05LCBhbmQgSFlQSEVOLU1JTlVTLCB3aGljaCBhcmUgcHJlc2Vu dCBpbiBtb3N0DQogICBjaGFyYWN0ZXIgc2V0cywgc28gcHJlc2VudGF0aW9uIG9mIGxhbmd1YWdl IHRhZ3Mgc2hvdWxkIG5vdCBoYXZlIGFueQ0KICAgY2hhcmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAg IFJlbmRlcmluZyBvZiBjaGFyYWN0ZXJzIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIGEgbGFuZ3Vh Z2UgdGFnIGlzIG5vdA0KICAgYWRkcmVzc2VkIGluIHRoaXMgbWVtby4gIEhpc3RvcmljYWxseSwg c29tZSBsYW5ndWFnZXMgaGF2ZSByZWxpZWQgb24NCiAgIHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hh cmFjdGVyIHNldHMgb3Igb3RoZXIgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8NCiAgIGluZmVyIGhv dyBhIHNwZWNpZmljIGNoYXJhY3RlciBzaG91bGQgYmUgcmVuZGVyZWQgKG5vdGFibHkgdGhpcw0K ICAgYXBwbGllcyB0byBsYW5ndWFnZSBhbmQgY3VsdHVyZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9m IEhhbiBpZGVvZ3JhcGhzDQogICBhcyB1c2VkIGluIEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29y ZWFuKS4gIFdoZW4gbGFuZ3VhZ2UgdGFncyBhcmUNCiAgIGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4 dCwgcmVuZGVyaW5nIGVuZ2luZXMgbWF5IHVzZSB0aGF0IGluZm9ybWF0aW9uDQogICBpbiBkZWNp ZGluZyB3aGljaCBmb250IHRvIHVzZSBpbiB0aGUgYWJzZW5jZSBvZiBvdGhlciBpbmZvcm1hdGlv biwNCiAgIHBhcnRpY3VsYXJseSB3aGVyZSBsYW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5n IHRyYWRpdGlvbnMgdXNlIHRoZQ0KICAgc2FtZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAg ICBbUGFnZSAzM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3Mg ICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCjYuICBDaGFuZ2VzIGZyb20gUkZD IDMwNjYNCg0KICAgVGhlIG1haW4gZ29hbHMgZm9yIHRoaXMgcmV2aXNpb24gb2YgbGFuZ3VhZ2Ug dGFncyB3ZXJlIHRoZSBmb2xsb3dpbmc6DQoNCiAgICpDb21wYXRpYmlsaXR5LiogQWxsIHZhbGlk IFJGQyAzMDY2IGxhbmd1YWdlIHRhZ3MgIChpbmNsdWRpbmcgdGhvc2UNCiAgIGluIHRoZSBJQU5B IHJlZ2lzdHJ5KSAgcmVtYWluIHZhbGlkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRodXMNCiAg IHRoZXJlIGlzIGNvbXBsZXRlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uIHdpdGgNCiAgIGV4aXN0aW5nIGNvbnRlbnQuICBJbiBhZGRpdGlvbiwgdGhpcyBkb2N1 bWVudCBkZWZpbmVzIGxhbmd1YWdlIHRhZ3MNCiAgIGluIHN1Y2ggYXMgd2F5IGFzIHRvIGVuc3Vy ZSBmdXR1cmUgY29tcGF0aWJpbGl0eSwgYW5kIHByb2Nlc3NvcnMNCiAgIGJhc2VkIHNvbGVseSBv biB0aGUgUkZDIDMwNjYgQUJORiAoc3VjaCBhcyB0aG9zZSBkZXNjcmliZWQgaW4gWE1MDQogICBT Y2hlbWEgdmVyc2lvbiAxLjApIHdpbGwgYmUgYWJsZSB0byBwcm9jZXNzIHRhZ3MgZGVzY3JpYmVk IGJ5IHRoaXMNCiAgIGRvY3VtZW50Lg0KDQogICAqU3RhYmlsaXR5LiogQmVjYXVzZSBvZiB0aGUg Y2hhbmdlcyBpbiB1bmRlcmx5aW5nIElTTyBzdGFuZGFyZHMsIGENCiAgIHZhbGlkIFJGQyAzMDY2 IGxhbmd1YWdlIHRhZyBtYXkgYmVjb21lIGludmFsaWQgKG9yIGhhdmUgaXRzIG1lYW5pbmcNCiAg IGNoYW5nZSkgYXQgYSBsYXRlciBkYXRlLiAgV2l0aCBzbyBtdWNoIG9mIHRoZSB3b3JsZCdzIGNv bXB1dGluZw0KICAgaW5mcmFzdHJ1Y3R1cmUgZGVwZW5kZW50IG9uIGxhbmd1YWdlIHRhZ3MsIHRo aXMgaXMgc2ltcGx5DQogICB1bmFjY2VwdGFibGU6IGl0IGludmFsaWRhdGVzIGNvbnRlbnQgdGhh dCBtYXkgaGF2ZSBhbiBleHRlbnNpdmUNCiAgIHNoZWxmLWxpZmUuICBJbiB0aGlzIHNwZWNpZmlj YXRpb24sIG9uY2UgYSBsYW5ndWFnZSB0YWcgaXMgdmFsaWQsIGl0DQogICByZW1haW5zIHZhbGlk IGZvcmV2ZXIuICBQcmV2aW91c2x5LCB0aGVyZSB3YXMgbm8gd2F5IHRvIGRldGVybWluZQ0KICAg d2hlbiB0d28gdGFncyB3ZXJlIGVxdWl2YWxlbnQuICBUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlk ZXMgYSBzdGFibGUNCiAgIG1lY2hhbmlzbSBmb3IgZG9pbmcgc28sIHRocm91Z2ggdGhlIHVzZSBv ZiBjYW5vbmljYWwgZm9ybXMuICBUaGVzZQ0KICAgYXJlIGFsc28gc3RhYmxlLCBzbyB0aGF0IGlt cGxlbWVudGF0aW9ucyBjYW4gZGVwZW5kIG9uIHRoZSB1c2Ugb2YNCiAgIGNhbm9uaWNhbCBmb3Jt cyB0byBhc3Nlc3MgZXF1aXZhbGVuY3kuDQoNCiAgICpWYWxpZGl0eS4qICBUaGUgc3RydWN0dXJl IG9mIGxhbmd1YWdlIHRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50DQogICBtYWtlcyBpdCBw b3NzaWJsZSB0byBkZXRlcm1pbmUgaWYgYSBwYXJ0aWN1bGFyIHRhZyBpcyB3ZWxsLWZvcm1lZA0K ICAgd2l0aG91dCByZWdhcmQgZm9yIHRoZSBhY3R1YWwgY29udGVudCBvciAibWVhbmluZyIgb2Yg dGhlIHRhZyBhcyBhDQogICB3aG9sZS4gIFRoaXMgaXMgaW1wb3J0YW50IGJlY2F1c2UgdGhlIHJl Z2lzdHJ5IGFuZCB1bmRlcmx5aW5nDQogICBzdGFuZGFyZHMgIGNoYW5nZSBvdmVyIHRpbWUuICBJ biBhZGRpdGlvbiwgaXQgbXVzdCBiZSBwb3NzaWJsZSB0bw0KICAgZGV0ZXJtaW5lIGlmIGEgdGFn IGlzIHZhbGlkIChvciBub3QpIGZvciBhIGdpdmVuIHBvaW50IGluIHRpbWUgaW4NCiAgIG9yZGVy ICB0byBwcm92aWRlIHJlcHJvZHVjaWJsZSwgdGVzdGFibGUgcmVzdWx0cy4gIFRoaXMgcHJvY2Vz cyBtdXN0DQogICBub3QgYmUgZXJyb3ItcHJvbmU7IG90aGVyd2lzZSBldmVuIGludGVsbGlnZW50 IHBlb3BsZSB3aWxsIGdlbmVyYXRlDQogICBpbXBsZW1lbnRhdGlvbnMgdGhhdCBnaXZlIGRpZmZl cmVudCByZXN1bHRzLiAgVGhpcyBzcGVjaWZpY2F0aW9uDQogICBwcm92aWRlcyBmb3IgdGhhdCBi eSBoYXZpbmcgYSBzaW5nbGUgZGF0YSBmaWxlLCB3aXRoIHNwZWNpZmljDQogICB2ZXJzaW9uaW5n IGluZm9ybWF0aW9uLCBzbyB0aGF0IHRoZSB2YWxpZGl0eSBvZiBsYW5ndWFnZSB0YWdzIGF0IGFu eQ0KICAgcG9pbnQgaW4gdGltZSBjYW4gYmUgcHJlY2lzZWx5IGRldGVybWluZWQgKGluc3RlYWQg b2YgaW50ZXJwb2xhdGluZw0KICAgdmFsdWVzIGZyb20gbWFueSBzZXBhcmF0ZSBzb3VyY2VzKS4N Cg0KICAgKkV4dGVuc2liaWxpdHkuKiBJdCBpcyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4NCiAgIHdyaXR0ZW4gZm9ybXMgb2YgbGFuZ3VhZ2UgLS0gZm9yIG1h bnkgaW1wbGVtZW50YXRpb25zIHRoaXMgaXMgbW9yZQ0KICAgaW1wb3J0YW50IHRoYW4gZGlzdGlu Z3Vpc2hpbmcgYmV0d2VlbiBzcG9rZW4gdmFyaWFudHMgb2YgYSBsYW5ndWFnZS4NCiAgIExhbmd1 YWdlcyBhcmUgd3JpdHRlbiBpbiBhIHdpZGUgdmFyaWV0eSBvZiBkaWZmZXJlbnQgc2NyaXB0cywg c28gdGhpcw0KICAgZG9jdW1lbnQgcHJvdmlkZXMgZm9yIHRoZSBnZW5lcmF0aXZlIHVzZSBvZiBJ U08gMTU5MjQgc2NyaXB0IGNvZGVzLg0KICAgTGlrZSB0aGUgZ2VuZXJhdGl2ZSB1c2Ugb2YgSVNP IGxhbmd1YWdlIGFuZCBjb3VudHJ5IGNvZGVzIGluIFJGQw0KICAgMzA2NiwgdGhpcyBhbGxvd3Mg Y29tYmluYXRpb25zIHRvIGJlIHByb2R1Y2VkIHdpdGhvdXQgcmVzb3J0aW5nIHRvDQogICB0aGUg cmVnaXN0cmF0aW9uIHByb2Nlc3MuICBUaGUgYWRkaXRpb24gb2YgVU4gY29kZXMgcHJvdmlkZXMg Zm9yIHRoZQ0KICAgZ2VuZXJhdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHdpdGggcmVnaW9uYWwgc2Nv cGUsIHdoaWNoIGlzIGFsc28NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBT ZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDM0XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAy MDA1DQoNCg0KICAgcmVxdWlyZWQgZm9yIGluZm9ybWF0aW9uIHRlY2hub2xvZ3kuDQoNCiAgIFRo ZSByZWNhc3Qgb2YgdGhlIHJlZ2lzdHJ5IGZyb20gY29udGFpbmluZyB3aG9sZSBsYW5ndWFnZSB0 YWdzIHRvDQogICBzdWJ0YWdzIGlzIGEga2V5IHBhcnQgb2YgdGhpcy4gIEFuIGltcG9ydGFudCBm ZWF0dXJlIG9mIFJGQyAzMDY2IHdhcw0KICAgdGhhdCBpdCBhbGxvd2VkIGdlbmVyYXRpdmUgdXNl IG9mIHN1YnRhZ3MuICBUaGlzIGFsbG93cyBwZW9wbGUgdG8NCiAgIG1lYW5pbmdmdWxseSB1c2Ug Z2VuZXJhdGVkIHRhZ3MsIHdpdGhvdXQgdGhlIGRlbGF5cyBpbiByZWdpc3RlcmluZw0KICAgd2hv bGUgdGFncywgYW5kIHRoZSBidXJkZW4gb24gdGhlIHJlZ2lzdHJ5IG9mIGhhdmluZyB0byBzdXBw bHkgYWxsIG9mDQogICB0aGUgY29tYmluYXRpb25zIHRoYXQgcGVvcGxlIG1heSBmaW5kIHVzZWZ1 bC4NCg0KICAgQmVjYXVzZSBvZiB0aGUgd2lkZXNwcmVhZCB1c2Ugb2YgbGFuZ3VhZ2UgdGFncywg aXQgaXMgcG90ZW50aWFsbHkNCiAgIGRpc3J1cHRpdmUgdG8gaGF2ZSBwZXJpb2RpYyByZXZpc2lv bnMgb2YgdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiwNCiAgIGRlc3BpdGUgZGVtb25zdHJhdGVkIG5l ZWQuICBUaGUgZXh0ZW5zaW9uIG1lY2hhbmlzbSBwcm92aWRlcyBmb3IgYQ0KICAgd2F5IGZvciBp bmRlcGVuZGVudCBSRkNzIHRvIGRlZmluZSBleHRlbnNpb25zIHRvIGxhbmd1YWdlIHRhZ3MuDQog ICBUaGVzZSBleHRlbnNpb25zIGhhdmUgYSB2ZXJ5IGNvbnN0cmFpbmVkLCB3ZWxsLWRlZmluZWQg c3RydWN0dXJlIHRvDQogICBwcmV2ZW50IGV4dGVuc2lvbnMgZnJvbSBpbnRlcmZlcmluZyB3aXRo IGltcGxlbWVudGF0aW9ucyBvZiBsYW5ndWFnZQ0KICAgdGFncyBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQuICBUaGUgZG9jdW1lbnQgYWxzbyBhbnRpY2lwYXRlcw0KICAgZmVhdHVyZXMgb2YgSVNP IDYzOS0zIHdpdGggdGhlIGFkZGl0aW9uIG9mIHRoZSBleHRsYW5nIHN1YnRhZ3MuICBUaGUNCiAg IHVzZSBhbmQgZGVmaW5pdGlvbiBvZiBwcml2YXRlIHVzZSB0YWdzIGhhcyBhbHNvIGJlZW4gbW9k aWZpZWQsIHRvDQogICBhbGxvdyBwZW9wbGUgdG8gbW92ZSBhcyBtdWNoIGluZm9ybWF0aW9uIGFz IHBvc3NpYmxlIG91dCBvZiBwcml2YXRlDQogICB1c2UgdGFncywgYW5kIGludG8gdGhlIHJlZ3Vs YXIgc3RydWN0dXJlLiAgVGhlIGdvYWwgaXMgdG8NCiAgIGRyYW1hdGljYWxseSByZWR1Y2UgdGhl IG5lZWQgdG8gcHJvZHVjZSBhIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQNCiAgIGluIHRoZSBm dXR1cmUuDQoNCiAgIFRoZSBzcGVjaWZpYyBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgdG8gbWVl dCB0aGVzZSBnb2FscyBhcmU6DQogICBvICBEZWZpbmVzIHRoZSBBQk5GIGFuZCBydWxlcyBmb3Ig c3VidGFncyBzbyB0aGF0IHRoZSBjYXRlZ29yeSBvZiBhbGwNCiAgICAgIHN1YnRhZ3MgY2FuIGJl IGRldGVybWluZWQgd2l0aG91dCByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5Lg0KICAgbyAgQWRk cyB0aGUgY29uY2VwdCBvZiB3ZWxsLWZvcm1lZCB2cy4gIHZhbGlkYXRpbmcgcHJvY2Vzc29ycywN CiAgICAgIGRlZmluaW5nIHRoZSBydWxlcyBieSB3aGljaCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4g Y2xhaW0gdG8gYmUgb25lDQogICAgICBvciB0aGUgb3RoZXIuDQogICBvICBDaGFuZ2VzIHRoZSBJ QU5BIGxhbmd1YWdlIHRhZyByZWdpc3RyeSB0byBhIGxhbmd1YWdlIHN1YnRhZw0KICAgICAgcmVn aXN0cnkgdGhhdCBwcm92aWRlcyBhIGNvbXBsZXRlIGxpc3Qgb2YgdmFsaWQgc3VidGFncyBpbiB0 aGUNCiAgICAgIElBTkEgcmVnaXN0cnkuICBUaGlzIGFsbG93cyBmb3Igcm9idXN0IGltcGxlbWVu dGF0aW9uIGFuZCBlYXNlIG9mDQogICAgICBtYWludGVuYW5jZS4gIFRoZSBsYW5ndWFnZSBzdWJ0 YWcgcmVnaXN0cnkgYmVjb21lcyB0aGUgY2Fub25pY2FsDQogICAgICBzb3VyY2UgZm9yIGZvcm1p bmcgbGFuZ3VhZ2UgdGFncy4NCiAgIG8gIFByb3ZpZGVzIGEgcHJvY2VzcyB0aGF0IGd1YXJhbnRl ZXMgc3RhYmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MsIGJ5DQogICAgICBoYW5kbGluZyByZXVzZSBv ZiB2YWx1ZXMgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYgaW4NCiAgICAgIHRo ZSBldmVudCB0aGF0IHRoZXkgcmVnaXN0ZXIgYSBwcmV2aW91c2x5IHVzZWQgdmFsdWUgZm9yIGEg bmV3DQogICAgICBwdXJwb3NlLg0KICAgbyAgQWxsb3dzIElTTyAxNTkyNCBzY3JpcHQgY29kZSBz dWJ0YWdzIGFuZCBhbGxvd3MgdGhlbSB0byBiZSB1c2VkDQogICAgICBnZW5lcmF0aXZlbHkuICBB ZGRzIHRoZSBjb25jZXB0IG9mIGEgdmFyaWFudCBzdWJ0YWcgYW5kIGFsbG93cw0KICAgICAgdmFy aWFudHMgdG8gYmUgdXNlZCBnZW5lcmF0aXZlbHkuICBBZGRzIHRoZSBhYmlsaXR5IHRvIHVzZSBh IGNsYXNzDQogICAgICBvZiBVTiB0YWdzIGFzIHJlZ2lvbnMuDQogICBvICBEZWZpbmVzIHRoZSBw cml2YXRlLXVzZSB0YWdzIGluIElTTyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAzMTY2DQogICAg ICBhcyB0aGUgbWVjaGFuaXNtIGZvciBjcmVhdGluZyBwcml2YXRlLXVzZSBsYW5ndWFnZSwgc2Ny aXB0LCBhbmQNCiAgICAgIHJlZ2lvbiBzdWJ0YWdzIHJlc3BlY3RpdmVseS4NCiAgIG8gIEFkZHMg YSB3ZWxsLWRlZmluZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbS4NCiAgIG8gIERlZmluZXMgYW4gZXh0 ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLCBwb3NzaWJseSBmb3IgdXNlIHdpdGggY2VydGFpbg0KICAg ICAgYW50aWNpcGF0ZWQgZmVhdHVyZXMgb2YgSVNPIDYzOS0zLg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2Ug MzVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAg ICAgICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQogICBFZCBOb3RlOiBUaGUgZm9sbG93aW5nIGl0 ZW1zIGFyZSBwcm92aWRlZCBmb3IgdGhlIGNvbnZlbmllbmNlIG9mDQogICByZXZpZXdlcnMgYW5k IHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBmaW5hbCBkb2N1bWVudC4NCg0KICAgQ2hhbmdlcyBi ZXR3ZWVuIGRyYWZ0LXBoaWxsaXBzLWxhbmd0YWdzLTEwIGFuZCB0aGlzIHZlcnNpb24gYXJlOg0K ICAgbyAgRXhwdW5nZWQgdGhlIHRlcm1pbm9sb2d5ICJsYW5ndWFnZSByYW5nZSIsIHNpbmNlIHRo YXQgc2VjdGlvbiBnb2VzDQogICAgICB3aXRoIG1hdGNoaW5nIChBLlBoaWxsaXBzLCBNLkRhdmlz KQ0KICAgbyAgQWRkZWQgdGV4dCBkZXNjcmliaW5nIHRoZSBoYW5kbGluZyBvZiBleGlzdGluZyBS RkMgMzA2NiByZWdpc3RyeQ0KICAgICAgZW50cmllcyB0aGF0IHdlcmUgZGVwcmVjYXRlZCBwcmlv ciB0byB0aGUgYWRvcHRpb24gb2YgdGhpcw0KICAgICAgZG9jdW1lbnQuICBUaGVzZSB0YWdzIGFy ZSBub3cgZ3JhbmRmYXRoZXJlZC4gIChBLlBoaWxsaXBzLA0KICAgICAgRC5Fd2VsbCkNCiAgIG8g IE1vZGlmaWVkIHRoZSBjb252ZXJzaW9uIHJ1bGVzIGZvciB0aGUgcmVnaXN0cnkgKEFwcGVuZGl4 IEMpIHRvDQogICAgICByZWZlciB0byB0aGUgY2hhaXJzLCB0aGUgTFRSVSBtYWlsIGxpc3QgYW5k IHNvIGZvcnRoIChBLlBoaWxsaXBzKQ0KICAgbyAgQWRkZWQgdGV4dCB0byBhbGxvdyB0YWdzIGFu ZCBzdWJ0YWdzIHRvIGJlIGRlcHJlY2F0ZWQgdXNpbmcgdGhlDQogICAgICBjYW5vbmljYWwgdmFs dWUgIi0tIi4gIFRoaXMgaXMgYXBwbGllZCB0byBjb2RlcyB3aXRoZHJhd24gYnkgSVNPDQogICAg ICA2MzkgTUEgYW5kIElTTyAzMTY2IE1BLCBmb3IgZXhhbXBsZS4gIChGLkVsbGVybWFuLCBELkV3 ZWxsKQ0KDQo3LiAgUmVmZXJlbmNlcw0KDQogICBbMV0gICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXph dGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPDQogICAgICAgICA2MzktMToyMDAyLCBDb2Rl cyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcw0KICAgICAgICAg LS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiLCBJU08gU3RhbmRhcmQgNjM5LCAyMDAyLg0KDQogICBb Ml0gICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNP IDYzOS0yOjE5OTgNCiAgICAgICAgIC0gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBu YW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAyOg0KICAgICAgICAgQWxwaGEtMyBjb2RlIC0gZWRp dGlvbiAxIiwgQXVndXN0IDE5ODguDQoNCiAgIFszXSAgIElTTyBUQzQ2L1dHMywgIklTTyAxNTky NDoyMDAzIChFL0YpIC0gQ29kZXMgZm9yIHRoZQ0KICAgICAgICAgcmVwcmVzZW50YXRpb24gb2Yg bmFtZXMgb2Ygc2NyaXB0cyIsIEphbnVhcnkgMjAwNC4NCg0KICAgWzRdICAgSW50ZXJuYXRpb25h bCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIkNvZGVzIGZvciB0aGUNCiAgICAg ICAgIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcywgM3JkIGVkaXRpb24iLA0K ICAgICAgICAgSVNPIFN0YW5kYXJkIDMxNjYsIEF1Z3VzdCAxOTg4Lg0KDQogICBbNV0gICBTdGF0 aXN0aWNhbCBEaXZpc2lvbiwgVW5pdGVkIE5hdGlvbnMsICJTdGFuZGFyZCBDb3VudHJ5IG9yIEFy ZWENCiAgICAgICAgIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UiLCBVTiBTdGFuZGFyZCBDb3Vu dHJ5IG9yIEFyZWEgQ29kZXMNCiAgICAgICAgIGZvciBTdGF0aXN0aWNhbCBVc2UsIFJldmlzaW9u IDQgKFVuaXRlZCBOYXRpb25zIHB1YmxpY2F0aW9uLA0KICAgICAgICAgU2FsZXMgTm8uIDk4LlhW SUkuOSwgSnVuZSAxOTk5Lg0KDQogICBbNl0gICBJU08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1p dHRlZSwgIklTTyA2MzkgSm9pbnQgQWR2aXNvcnkNCiAgICAgICAgIENvbW1pdHRlZTogIFdvcmtp bmcgcHJpbmNpcGxlcyBmb3IgSVNPIDYzOSBtYWludGVuYW5jZSIsIE1hcmNoDQogICAgICAgICAy MDAwLA0KICAgICAgICAgPGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvaXNv NjM5amFjX24zci5odG1sPi4NCg0KICAgWzddICAgSGFyZGNhc3RsZS1LaWxsZSwgUy4sICJNYXBw aW5nIGJldHdlZW4gWC40MDAoMTk4OCkgLyBJU08gMTAwMjENCiAgICAgICAgIGFuZCBSRkMgODIy IiwgUkZDIDEzMjcsIE1heSAxOTkyLg0KDQogICBbOF0gICBCb3JlbnN0ZWluLCBOLiBhbmQgTi4g RnJlZWQsICJNSU1FIChNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbA0KICAgICAgICAgRXh0ZW5z aW9ucykgUGFydCBPbmU6IE1lY2hhbmlzbXMgZm9yIFNwZWNpZnlpbmcgYW5kIERlc2NyaWJpbmcN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUg ICAgICAgICAgICAgIFtQYWdlIDM2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoNCg0KICAgICAgICAg dGhlIEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNzYWdlIEJvZGllcyIsIFJGQyAxNTIxLCBTZXB0ZW1i ZXINCiAgICAgICAgIDE5OTMuDQoNCiAgIFs5XSAgIEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3Ig dGhlIElkZW50aWZpY2F0aW9uIG9mIExhbmd1YWdlcyIsDQogICAgICAgICBSRkMgMTc2NiwgTWFy Y2ggMTk5NS4NCg0KICAgWzEwXSAgSG92ZXksIFIuIGFuZCBTLiBCcmFkbmVyLCAiVGhlIE9yZ2Fu aXphdGlvbnMgSW52b2x2ZWQgaW4gdGhlDQogICAgICAgICBJRVRGIFN0YW5kYXJkcyBQcm9jZXNz IiwgQkNQIDExLCBSRkMgMjAyOCwgT2N0b2JlciAxOTk2Lg0KDQogICBbMTFdICBCcmFkbmVyLCBT LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQNCiAg ICAgICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFsxMl0g IEZyZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1ZSBhbmQgRW5jb2Rl ZCBXb3JkDQogICAgICAgICBFeHRlbnNpb25zOiBDaGFyYWN0ZXIgU2V0cywgTGFuZ3VhZ2VzLCBh bmQgQ29udGludWF0aW9ucyIsDQogICAgICAgICBSRkMgMjIzMSwgTm92ZW1iZXIgMTk5Ny4NCg0K ICAgWzEzXSAgQ3JvY2tlciwgRC4sIEVkLiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYg Zm9yIFN5bnRheA0KICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgMjIzNCwgTm92 ZW1iZXIgMTk5Ny4NCg0KICAgWzE0XSAgQmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4gYW5k IEwuIE1hc2ludGVyLCAiVW5pZm9ybQ0KICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllcnMgKFVS SSk6IEdlbmVyaWMgU3ludGF4IiwgUkZDIDIzOTYsIEF1Z3VzdA0KICAgICAgICAgMTk5OC4NCg0K ICAgWzE1XSAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdy aXRpbmcgYW4gSUFOQQ0KICAgICAgICAgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwg QkNQIDI2LCBSRkMgMjQzNCwgT2N0b2Jlcg0KICAgICAgICAgMTk5OC4NCg0KICAgWzE2XSAgRmll bGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRlciwg TC4sDQogICAgICAgICBMZWFjaCwgUC4gYW5kIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0IFRy YW5zZmVyIFByb3RvY29sIC0tDQogICAgICAgICBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5 OTkuDQoNCiAgIFsxN10gIENhcnBlbnRlciwgQi4sIEJha2VyLCBGLiBhbmQgTS4gUm9iZXJ0cywg Ik1lbW9yYW5kdW0gb2YNCiAgICAgICAgIFVuZGVyc3RhbmRpbmcgQ29uY2VybmluZyB0aGUgVGVj aG5pY2FsIFdvcmsgb2YgdGhlIEludGVybmV0DQogICAgICAgICBBc3NpZ25lZCBOdW1iZXJzIEF1 dGhvcml0eSIsIFJGQyAyODYwLCBKdW5lIDIwMDAuDQoNCiAgIFsxOF0gIEFsdmVzdHJhbmQsIEgu LCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mIExhbmd1YWdlcyIsDQogICAgICAgICBC Q1AgNDcsIFJGQyAzMDY2LCBKYW51YXJ5IDIwMDEuDQoNCiAgIFsxOV0gIFllcmdlYXUsIEYuLCAi VVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTyAxMDY0NiIsDQogICAgICAgICBT VEQgNjMsIFJGQyAzNjI5LCBOb3ZlbWJlciAyMDAzLg0KDQogICBbMjBdICBLbHluZSwgRy4gYW5k IEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0Og0KICAgICAgICAgVGlt ZXN0YW1wcyIsIFJGQyAzMzM5LCBKdWx5IDIwMDIuDQoNCiAgIFsyMV0gIDxodHRwOi8vd3d3Lmll dGYub3JnL3JmYy9yZmMyMDI2LnR4dD4NCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTEsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDM3XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDA1DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEFkZGlzb24gUGhp bGxpcHMgKGVkaXRvcikNCiAgIFF1ZXN0IFNvZnR3YXJlDQoNCiAgIEVtYWlsOiBhZGRpc29uLnBo aWxsaXBzQHF1ZXN0LmNvbQ0KDQoNCiAgIE1hcmsgRGF2aXMgKGVkaXRvcikNCiAgIElCTQ0KDQog ICBFbWFpbDogbWFyay5kYXZpc0B1cy5pYm0uY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAg ICBbUGFnZSAzOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3Mg ICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCkFwcGVuZGl4IEEuICBBY2tub3ds ZWRnZW1lbnRzDQoNCiAgIEFueSBsaXN0IG9mIGNvbnRyaWJ1dG9ycyBpcyBib3VuZCB0byBiZSBp bmNvbXBsZXRlOyBwbGVhc2UgcmVnYXJkIHRoZQ0KICAgZm9sbG93aW5nIGFzIG9ubHkgYSBzZWxl Y3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxlIHdobyBoYXZlDQogICBjb250cmlidXRlZCB0 byBtYWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0b2RheS4NCg0KICAgVGhlIGNvbnRyaWJ1 dG9ycyB0byBSRkMgMzA2NiBhbmQgUkZDIDE3NjYsIHRoZSBwcmVjdXJzb3JzIG9mIHRoaXMNCiAg IGRvY3VtZW50LCBtYWRlIGVub3Jtb3VzIGNvbnRyaWJ1dGlvbnMgZGlyZWN0bHkgb3IgaW5kaXJl Y3RseSB0byB0aGlzDQogICBkb2N1bWVudCBhbmQgYXJlIGdlbmVyYWxseSByZXNwb25zaWJsZSBm b3IgdGhlIHN1Y2Nlc3Mgb2YgbGFuZ3VhZ2UNCiAgIHRhZ3MuDQoNCiAgIFRoZSBmb2xsb3dpbmcg cGVvcGxlIChpbiBhbHBoYWJldGljYWwgb3JkZXIpIGNvbnRyaWJ1dGVkIHRvIHRoaXMNCiAgIGRv Y3VtZW50IG9yIHRvIFJGQ3MgMTc2NiBhbmQgMzA2NjoNCg0KICAgR2xlbm4gQWRhbXMsIEhhcmFs ZCBUdmVpdCBBbHZlc3RyYW5kLCBUaW0gQmVybmVycy1MZWUsIE1hcmMgQmxhbmNoZXQsDQogICBO YXRoYW5pZWwgQm9yZW5zdGVpbiwgRXJpYyBCcnVubmVyLCBTZWFuIE0uICBCdXJrZSwgSmVyZW15 IENhcnJvbGwsDQogICBKb2huIENsZXdzLCBKaW0gQ29ua2xpbiwgUGV0ZXIgQ29uc3RhYmxlLCBK b2huIENvd2FuLCBNYXJrIENyaXNwaW4sDQogICBEYXZlIENyb2NrZXIsIE1hcnRpbiBEdWVyc3Qs IEZyYW5rIEVsbGVybWFuLCBNaWNoYWVsIEV2ZXJzb24sIERvdWcNCiAgIEV3ZWxsLCBOZWQgRnJl ZWQsIFRpbSBHb29kd2luLCBEaXJrLVdpbGxlbSB2YW4gR3VsaWssIE1hcmlvbiBHdW5uLA0KICAg Sm9lbCBIYWxwcmVuLCBFbGxpb3R0ZSBSdXN0eSBIYXJvbGQsIFBhdWwgSG9mZm1hbiwgUmljaGFy ZCBJc2hpZGEsDQogICBPbGxlIEphcm5lZm9ycywgS2VudCBLYXJsc3NvbiwgSm9obiBLbGVuc2lu LCBBbGFpbiBMYUJvbnRlLCBFcmljDQogICBNYWRlciwgS2VpdGggTW9vcmUsIENocmlzIE5ld21h biwgTWFzYXRha2EgT2h0YSwgR2VvcmdlIFJob3RlbiwNCiAgIE1hcmt1cyBTY2hlcmVyLCBLZWxk IEpvcm4gU2ltb25zZW4sIFRoaWVycnkgU291cmJpZXIsIE90dG8gU3RvbHosIFRleA0KICAgVGV4 aW4sIEFuZHJlYSBWaW5lLCBSaHlzIFdlYXRoZXJsZXksIE1pc2hhIFdvbGYsIEZyYW5jb2lzIFll cmdlYXUgYW5kDQogICBtYW55LCBtYW55IG90aGVycy4NCg0KICAgVmVyeSBzcGVjaWFsIHRoYW5r cyBtdXN0IGdvIHRvIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCB3aG8NCiAgIG9yaWdpbmF0ZWQg UkZDcyAxNzY2IGFuZCAzMDY2LCBhbmQgd2l0aG91dCB3aG9tIHRoaXMgZG9jdW1lbnQgd291bGQN CiAgIG5vdCBoYXZlIGJlZW4gcG9zc2libGUuICBTcGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRvIE1p Y2hhZWwgRXZlcnNvbiwNCiAgIHdobyBoYXMgc2VydmVkIGFzIGxhbmd1YWdlIHRhZyByZXZpZXdl ciBmb3IgYWxtb3N0IHRoZSBjb21wbGV0ZQ0KICAgcGVyaW9kIHNpbmNlIHRoZSBwdWJsaWNhdGlv biBvZiBSRkMgMTc2Ni4gIFNwZWNpYWwgdGhhbmtzIHRvIERvdWcNCiAgIEV3ZWxsLCBmb3IgaGlz IHByb2R1Y3Rpb24gb2YgdGhlIGZpcnN0IGNvbXBsZXRlIHN1YnRhZyByZWdpc3RyeSwgYW5kDQog ICBoaXMgd29yayBpbiBwcm9kdWNpbmcgYSB0ZXN0IHBhcnNlciBmb3IgdmVyaWZ5aW5nIGxhbmd1 YWdlIHRhZ3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDExLCAyMDA1ICAgICAgICAgICAgICBbUGFn ZSAzOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgbGFuZ3RhZ3MgICAgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCkFwcGVuZGl4IEIuICBFeGFtcGxlcyBvZiBM YW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkNCg0KICAgU2ltcGxlIGxhbmd1YWdlIHN1YnRhZzoN CiAgICAgIGRlIChHZXJtYW4pDQogICAgICBmciAoRnJlbmNoKQ0KICAgICAgamEgKEphcGFuZXNl KQ0KICAgICAgaS1lbm9jaGlhbiAoZXhhbXBsZSBvZiBhIGdyYW5kZmF0aGVyZWQgdGFnKQ0KDQog ICBMYW5ndWFnZSBzdWJ0YWcgcGx1cyBTY3JpcHQgc3VidGFnOg0KICAgICAgemgtSGFudCAoVHJh ZGl0aW9uYWwgQ2hpbmVzZSkNCiAgICAgIGVuLUxhdG4gKEVuZ2xpc2ggd3JpdHRlbiBpbiBMYXRp biBzY3JpcHQpDQogICAgICBzci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4gd2l0aCBDeXJpbGxpYyBz Y3JpcHQpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb246DQogICAgICB6aC1IYW5zLUNOIChT aW1wbGlmaWVkIENoaW5lc2UgZm9yIHRoZSBQUkMpDQogICAgICBzci1MYXRuLUNTIChTZXJiaWFu LCBMYXRpbiBzY3JpcHQsIFNlcmJpYSBhbmQgTW9udGVuZWdybykNCg0KICAgTGFuZ3VhZ2UtU2Ny aXB0LVJlZ2lvbi1WYXJpYW50Og0KICAgICAgZW4tTGF0bi1VUy1ib29udCAoQm9vbnRsaW5nIGRp YWxlY3Qgb2YgRW5nbGlzaCkNCiAgICAgIGRlLUxhdG4tQ0gtMTk5NiAoR2VybWFuIHdyaXR0ZW4g aW4gTGF0aW4gc2NyaXB0IGZvciBTd2l0emVybGFuZA0KICAgICAgdXNpbmcgdGhlIG9ydGhvZ3Jh cGh5IG9mIDE5OTYpDQoNCiAgIExhbmd1YWdlLVJlZ2lvbjoNCiAgICAgIGRlLURFIChHZXJtYW4g Zm9yIEdlcm1hbnkpDQogICAgICB6aC1TRyAoQ2hpbmVzZSBmb3IgU2luZ2Fwb3JlKQ0KICAgICAg Y3MtMjAwIChDemVjaCBmb3IgQ3plY2hvc2xvdmFraWEpDQogICAgICBzci1DUyAoU2VyYmlhbiBm b3IgU2VyYmlhIGFuZCBNb250ZW5lZ3JvKQ0KICAgICAgZXMtNDE5IChTcGFuaXNoIGZvciBMYXRp biBBbWVyaWNhIGFuZCBDYXJpYmJlYW4gcmVnaW9uIHVzaW5nIHRoZQ0KICAgICAgVU4gcmVnaW9u IGNvZGUpDQoNCiAgIE90aGVyIE1peHR1cmVzOg0KICAgICAgZW4tYm9vbnQgKEJvb250bGluZyBk aWFsZWN0IG9mIEVuZ2xpc2gpDQoNCiAgIHByaXZhdGUtdXNlIG1lY2hhbmlzbToNCiAgICAgIGRl LUNILXgtcGhvbmViaw0KICAgICAgYXotQXJhYi14LUFaRS1kZXJiZW5kDQoNCiAgIEV4dGVuZGVk IGxhbmd1YWdlIHN1YnRhZ3MgKGV4YW1wbGVzIE9OTFk6IGV4dGVuZGVkIGxhbmd1YWdlcyBtdXN0 IGJlDQogICBkZWZpbmVkIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50KToN CiAgICAgIHpoLW1pbg0KICAgICAgemgtbWluLW5hbi1IYW50LUNODQoNCiAgIFByaXZhdGUtdXNl IHN1YnRhZ3M6DQogICAgICB4LXdoYXRldmVyIChwcml2YXRlIHVzZSB1c2luZyB0aGUgc2luZ2xl dG9uICd4JykNCiAgICAgIHFhYS1RYWFhLVFNLXgtc291dGhlcm4gKGFsbCBwcml2YXRlIHRhZ3Mp DQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEx LCAyMDA1ICAgICAgICAgICAgICBbUGFnZSA0MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgbGFuZ3RhZ3MgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwNQ0KDQoNCiAg ICAgIGRlLVFhYWEgKEdlcm1hbiwgd2l0aCBhIHByaXZhdGUgc2NyaXB0KQ0KICAgICAgZGUtTGF0 bi1RTSAoR2VybWFuLCBMYXRpbi1zY3JpcHQsIHByaXZhdGUgcmVnaW9uKQ0KICAgICAgZGUtUWFh YS1ERSAoR2VybWFuLCBwcml2YXRlIHNjcmlwdCwgZm9yIEdlcm1hbnkpDQoNCiAgIFRhZ3MgdGhh dCB1c2UgZXh0ZW5zaW9ucyAoZXhhbXBsZXMgT05MWTogZXh0ZW5zaW9ucyBtdXN0IGJlIGRlZmlu ZWQNCiAgIGJ5IHJldmlzaW9uIG9yIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50IG9yIGJ5IFJGQyk6 DQogICAgICBlbi1VUy11LWlzbGFtQ2FsDQogICAgICB6aC1DTi1hLW15RXh0LXgtcHJpdmF0ZQ0K ICAgICAgZW4tYS1teUV4dC1iLWFub3RoZXINCg0KICAgU29tZSBJbnZhbGlkIFRhZ3M6DQogICAg ICBkZS00MTktREUgKHR3byByZWdpb24gdGFncykNCiAgICAgIGEtREUgKHVzZSBvZiBhIHNpbmds ZSBjaGFyYWN0ZXIgc3VidGFnIGluIHByaW1hcnkgcG9zaXRpb247IG5vdGUNCiAgICAgIHRoYXQg dGhlcmUgYXJlIGEgZmV3IGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdpdGggImktIiB0 aGF0DQogICAgICBhcmUgdmFsaWQpDQogICAgICBhci1hLWFhYS1iLWJiYi1hLWNjYyAodHdvIGV4 dGVuc2lvbnMgd2l0aCBzYW1lIHNpbmdsZSBsZXR0ZXINCiAgICAgIHByZWZpeCkNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAg ICAgICAgICAgW1BhZ2UgNDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxh bmd0YWdzICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQpBcHBlbmRpeCBDLiAg Q29udmVyc2lvbiBvZiB0aGUgUkZDIDMwNjYgTGFuZ3VhZ2UgVGFnIFJlZ2lzdHJ5DQoNCiAgIFVw b24gcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIEJDUCwgdGhlIGV4aXN0aW5nIElB TkENCiAgIGxhbmd1YWdlIHRhZyByZWdpc3RyeSBtdXN0IGJlIGNvbnZlcnRlZCBpbnRvIHRoZSBu ZXcgc3VidGFnIHJlZ2lzdHJ5Lg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHByb2Nlc3Mg Zm9yIHBlcmZvcm1pbmcgdGhpcyBjb252ZXJzaW9uLg0KDQogICBUaGUgaW1wYWN0IG9uIHRoZSBJ QU5BIG1haW50YWluZXJzIG9mIHRoZSByZWdpc3RyeSBvZiB0aGlzIGNvbnZlcnNpb24NCiAgIHdp bGwgYmUgYSBzbWFsbCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldyBlbnRyaWVzLiAg VGhlDQogICBpbml0aWFsIHNldCBvZiByZWNvcmRzIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElB TkEsIHNpbmNlIHRoZSB3b3JrDQogICB0byBjcmVhdGUgaXQgd2lsbCBiZSBwZXJmb3JtZWQgZXh0 ZXJuYWxseS4NCg0KICAgV2hlbiB0aGlzIGRvY3VtZW50IGlzIHB1Ymxpc2hlZCwgYW4gZW1haWwg d2lsbCBiZSBzZW50IGJ5IHRoZQ0KICAgY2hhaXIocykgb2YgdGhlIExUUlUgd29ya2luZyBncm91 cCB0byB0aGUgTFRSVSBhbmQgaWV0Zi1sYW5ndWFnZXMNCiAgIG1haWwgbGlzdHMgYWR2aXNpbmcg b2YgdGhlIGltcGVuZGluZyBjb252ZXJzaW9uIG9mIHRoZSByZWdpc3RyeS4gIEluDQogICB0aGF0 IG5vdGljZSwgdGhlIGNoYWlyKHMpIHdpbGwgcHJvdmlkZSBhIFVSTCB3aG9zZSByZWZlcnJlZCBj b250ZW50DQogICBpcyB0aGUgcHJvcG9zZWQgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkg Zm9sbG93aW5nIGNvbnZlcnNpb24uDQogICBUaGVyZSB3aWxsIGJlIGEgTGFzdCBDYWxsIHBlcmlv ZCBvZiBub3QgbGVzcyB0aGFuIGZvdXIgd2Vla3MgZm9yDQogICBjb21tZW50cyBhbmQgY29ycmVj dGlvbnMgdG8gYmUgZGlzY3Vzc2VkIG9uIHRoZQ0KICAgaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmcg bWFpbCBsaXN0LiAgQ2hhbmdlcyBhcyBhIHJlc3VsdCBvZiBjb21tZW50cw0KICAgd2lsbCBub3Qg cmVzdGFydCB0aGUgTGFzdCBDYWxsIHBlcmlvZC4gIEF0IHRoZSBlbmQgb2YgdGhlIHBlcmlvZCwg dGhlDQogICBjaGFpcihzKSB3aWxsIGZvcndhcmQgdGhlIFVSTCB0byBJQU5BLCB3aGljaCB3aWxs IHBvc3QgdGhlIG5ldw0KICAgcmVnaXN0cnkgb24tbGluZS4NCg0KICAgVGFncyB0aGF0IGFyZSBj dXJyZW50bHkgZGVwcmVjYXRlZCB3aWxsIGJlIG1haW50YWluZWQgYXMNCiAgIGdyYW5kZmF0aGVy ZWQgZW50cmllcy4gIFRoZSByZWNvcmQgZm9yIHRoZSBncmFuZGZhdGhlcmVkIGVudHJ5IHdpbGwN CiAgIGNvbnRhaW4gYSBub3RlIGluZGljYXRpbmcgdGhhdCB0aGUgZW50cnkgaXMgJ2RlcHJlY2F0 ZWQnIGFuZCByZWFzb24NCiAgIGZvciB0aGUgZGVwcmVjYXRpb24uICBGb3IgZXhhbXBsZSwgdGhl IHRhZyAiYXJ0LWxvamJhbiIgaXMgZGVwcmVjYXRlZA0KICAgYW5kIHdpbGwgYmUgcGxhY2VkIGlu IHRoZSBncmFuZGZhdGhlcmVkIHNlY3Rpb24uDQoNCiAgIFRhZ3MgdGhhdCBhcmUgbm90IGRlcHJl Y2F0ZWQgdGhhdCBjb25zaXN0IGVudGlyZWx5IG9mIHN1YnRhZ3MgdGhhdA0KICAgYXJlIHZhbGlk IHVuZGVyIHRoaXMgZG9jdW1lbnQgYW5kIHdoaWNoIGhhdmUgdGhlIGNvcnJlY3QgZm9ybSBhbmQN CiAgIGZvcm1hdCBmb3IgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgYXJlIHN1cGVyc2Vk ZWQgYnkgdGhpcw0KICAgZG9jdW1lbnQuICBTdWNoIHRhZ3MgYXJlIHBsYWNlZCBpbiB0aGUgJ3Jl ZHVuZGFudCcgc2VjdGlvbiBvZiB0aGUNCiAgIHJlZ2lzdHJ5LiAgRm9yIGV4YW1wbGUsIHpoLUhh bnQgaXMgbm93IGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KICAgVGFncyB0aGF0IGNvbnRh aW4gc3VidGFncyB3aGljaCBhcmUgY29uc2lzdGVudCB3aXRoIHJlZ2lzdHJhdGlvbg0KICAgdW5k ZXIgdGhlIGd1aWRlbGluZXMgaW4gdGhpcyBkb2N1bWVudCB3aWxsIGhhdmUgYSBuZXcgc3VidGFn DQogICByZWdpc3RyYXRpb24gY3JlYXRlZCBmb3IgZWFjaCBlbGlnaWJsZSBzdWJ0YWcuICBJZiBh bGwgb2YgdGhlIHN1YnRhZ3MNCiAgIGluIHRoZSBvcmlnaW5hbCB0YWcgYXJlIGZ1bGx5IGRlZmlu ZWQgYnkgdGhlIHJlc3VsdGluZyByZWdpc3RyYXRpb25zDQogICBvciBieSB0aGlzIGRvY3VtZW50 LCB0aGVuIHRoZSBvcmlnaW5hbCB0YWcgaXMgc3VwZXJzZWRlZCBieSB0aGlzDQogICBkb2N1bWVu dC4gIFN1Y2ggdGFncyBhcmUgcGxhY2VkIGluIHRoZSAncmVkdW5kYW50JyBzZWN0aW9uIG9mIHRo ZQ0KICAgcmVnaXN0cnkuICBGb3IgZXhhbXBsZSwgZW4tYm9vbnQgd2lsbCByZXN1bHQgaW4gYSBu ZXcgc3VidGFnICJib29udCINCiAgIGFuZCB0aGUgUkZDIDMwNjYgcmVnaXN0ZXJlZCB0YWcgJ2Vu LWJvb250JyBwbGFjZWQgaW4gdGhlIHJlZHVuZGFudA0KICAgc2VjdGlvbiBvZiB0aGUgcmVnaXN0 cnkuDQoNCiAgIFRhZ3MgdGhhdCBjb250YWluIG9uZSBvciBtb3JlIHN1YnRhZ3MgdGhhdCBkbyBu b3QgbWF0Y2ggdGhlIHZhbGlkDQogICByZWdpc3RyYXRpb24gcGF0dGVybiBhbmQgd2hpY2ggYXJl IG5vdCBvdGhlcndpc2UgZGVmaW5lZCBieSB0aGlzDQogICBkb2N1bWVudCBhcmUgbWFya2VkIGFz ICdncmFuZGZhdGhlcmVkJyBieSB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNDJd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIGxhbmd0YWdzICAgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQogICBUaGVyZSB3aWxsIGJlIGEgcmVhc29uYWJsZSBw ZXJpb2QgaW4gd2hpY2ggdGhlIGNvbW11bml0eSBtYXkgY29tbWVudA0KICAgb24gdGhlIHByb3Bv c2VkIGxpc3QgZW50cmllcywgd2hpY2ggU0hBTEwgYmUgbm8gbGVzcyB0aGFuIGZvdXIgd2Vla3MN CiAgIGluIGxlbmd0aC4gIEF0IHRoZSBjb21wbGV0aW9uIG9mIHRoaXMgcGVyaW9kLCB0aGUgY2hh aXIocykgd2lsbA0KICAgbm90aWZ5IGlhbmFAaWFuYS5vcmcgYW5kIHRoZSBsdHJ1IGFuZCBpZXRm LWxhbmd1YWdlcyBtYWlsIGxpc3RzIHRoYXQNCiAgIHRoZSB0YXNrIGlzIGNvbXBsZXRlIGFuZCBm b3J3YXJkIHRoZSBuZWNlc3NhcnkgbWF0ZXJpYWxzIHRvIElBTkEgZm9yDQogICBwdWJsaWNhdGlv bi4NCg0KICAgUmVnaXN0cmF0aW9ucyB0aGF0IGFyZSBpbiBwcm9jZXNzIHVuZGVyIHRoZSBydWxl cyBkZWZpbmVkIGluIFJGQyAzMDY2DQogICBNQVkgYmUgY29tcGxldGVkIHVuZGVyIHRoZSBmb3Jt ZXIgcnVsZXMsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZQ0KICAgbGFuZ3VhZ2UgdGFnIHJldmll d2VyLiAgQW55IG5ldyByZWdpc3RyYXRpb25zIHN1Ym1pdHRlZCBhZnRlciB0aGUNCiAgIHJlcXVl c3QgZm9yIGNvbnZlcnNpb24gb2YgdGhlIHJlZ2lzdHJ5IE1VU1QgYmUgcmVqZWN0ZWQuDQoNCiAg IEFsbCBleGlzdGluZyBSRkMgMzA2NiBsYW5ndWFnZSB0YWcgcmVnaXN0cmF0aW9ucyB3aWxsIGJl IG1haW50YWluZWQNCiAgIGluIHBlcnBldHVpdHkuDQoNCiAgIFVzZXJzIG9mIHRhZ3MgdGhhdCBh cmUgZ3JhbmRmYXRoZXJlZCBzaG91bGQgY29uc2lkZXIgcmVnaXN0ZXJpbmcNCiAgIGFwcHJvcHJp YXRlIHN1YnRhZ3MgaW4gdGhlIElBTkEgc3VidGFnIHJlZ2lzdHJ5IChidXQgYXJlIG5vdCByZXF1 aXJlZA0KICAgdG8pLg0KDQogICBXaGVyZSB0d28gc3VidGFncyBoYXZlIHRoZSBzYW1lIG1lYW5p bmcsIHRoZSBwcmlvcml0eSBvZiB3aGljaCB0bw0KICAgbWFrZSBjYW5vbmljYWwgU0hBTEwgYmUg dGhlIGZvbGxvd2luZzoNCiAgIG8gIEFzIG9mIHRoZSBkYXRlIG9mIGFjY2VwdGFuY2Ugb2YgdGhp cyBkb2N1bWVudCBhcyBhIEJDUCwgaWYgYSBjb2RlDQogICAgICBleGlzdHMgaW4gdGhlIGFzc29j aWF0ZWQgSVNPIHN0YW5kYXJkIGFuZCBpdCBpcyBub3QgZGVwcmVjYXRlZCBvcg0KICAgICAgd2l0 aGRyYXduIGFzIG9mIHRoYXQgZGF0ZSwgdGhlbiBpdCBoYXMgcHJpb3JpdHkuDQogICBvICBPdGhl cndpc2UsIHRoZSBlYXJsaWVyLXJlZ2lzdGVyZWQgdGFnIGluIHRoZSBhc3NvY2lhdGVkIElTTw0K ICAgICAgc3RhbmRhcmQgaGFzIHByaW9yaXR5Lg0KDQogICBVTiBudW1lcmljIGNvZGVzIGFzc2ln bmVkIHRvICdtYWNyby1nZW9ncmFwaGljYWwgKGNvbnRpbmVudGFsKScgb3INCiAgIHN1Yi1yZWdp b25zIG5vdCBhc3NvY2lhdGVkIHdpdGggYW4gYXNzaWduZWQgSVNPIDMxNjYgYWxwaGEtMiBjb2Rl IGFyZQ0KICAgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhbmQgYXJlIHZhbGlkIGZvciB1 c2UgaW4gbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIGNvZGVzIE1VU1QgYmUgYWRkZWQgdG8gdGhl IGluaXRpYWwgdmVyc2lvbiBvZiB0aGUgcmVnaXN0cnkuDQogICBUaGUgVU4gbnVtZXJpYyBjb2Rl cyBmb3IgJ2Vjb25vbWljIGdyb3VwaW5ncycgb3IgJ290aGVyIGdyb3VwaW5ncycsDQogICBhbmQg dGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRoZSBVTiBkb2N1bWVudCBN VVNUIE5PVA0KICAgYmUgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5Lg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MTEsIDIwMDUgICAgICAgICAgICAgIFtQYWdlIDQzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICBsYW5ndGFncyAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDA1DQoNCg0K SW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBw b3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxs ZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFp bWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRl Y2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5v dCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFk ZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIElu Zm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGlu IFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0K ICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0 IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUs IG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFs IGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFy eSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRp b24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBh dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55 IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHly aWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRh cnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVp cmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBp bmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlz Y2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0K ICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQg VEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJS QU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVE IFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFO VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UuDQoNCg0KQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRl cm5ldCBTb2NpZXR5ICgyMDA1KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhl IHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBh bmQNCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFs bCB0aGVpciByaWdodHMuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhl IFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50 ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAxMSwgMjAwNSAgICAgICAgICAgICAgW1BhZ2UgNDRdDQoMDQo= ------_=_NextPart_001_01C5273F.8C81A070 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C5273F.8C81A070-- From ltru-bounces@ietf.org Sat Mar 12 15:37:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06051; Sat, 12 Mar 2005 15:37:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DADPn-0006x6-BW; Sat, 12 Mar 2005 15:40:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADLZ-0005g3-BA; Sat, 12 Mar 2005 15:36:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADLY-0005fd-82 for ltru@megatron.ietf.org; Sat, 12 Mar 2005 15:36:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05951 for ; Sat, 12 Mar 2005 15:36:25 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DADOo-0006vc-AT for ltru@ietf.org; Sat, 12 Mar 2005 15:39:51 -0500 Received: from h-68-164-242-230.snvacaid.dynamic.covad.net ([68.164.242.230] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DADLU-0000YJ-00 for ltru@ietf.org; Sat, 12 Mar 2005 12:36:24 -0800 Message-ID: <000d01c52743$356300e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <007301c52738$bae2ba40$030aa8c0@DEWELL> Subject: Re: [Ltru] Update to proposed registry Date: Sat, 12 Mar 2005 12:36:26 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, March 12, 2005 11:21 AM > Subject: [Ltru] Update to proposed registry > > Addison and Mark's new draft contains an important change: grandfathered > tags are allowed to have a canonical value. This means grandfathered > tags can be formally deprecated, not just marked with a comment. This > is a change we've talked about for some time. The wording is still a > bit inconsistent, but I expect that will be cleared up soon. > > Accordingly, I've updated the proposed draft registry available at: > > http://users.adelphia.net/~dewell/lstreg.html > http://users.adelphia.net/~dewell/lstreg.txt > > to add canonical values to all the grandfathered tags that were > previously commented as "deprecated." This update also removes the > variant subtag 'lojban' and changes the status of "art-lojban" from > redundant to grandfathered (with a canonical value of "jbo"). > > There is also a change history at > http://users.adelphia.net/~dewell/lstreg-history.html. > > All comments within the scope of the charter are welcome. (co-chair hat OFF) Would it make sense to make this into a working group i-d? When (re-)populating a registry, it seems like it would be nice to be able to give IANA something that had been under WG change control, without having to incorporate it all in the registry document. On the other hand, the format of the entries would be hard to reconcile with the constraints on i-ds. Many of the lines exceed 72 characters. In any case, if the updated registry would contain information that cannot be derived algorithmically from the current registry contents, we *somehow* would have to provide that information to IANA, whether in the registry document itself or in a new companion document. Ideas? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 12 16:03:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07403; Sat, 12 Mar 2005 16:03:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DADpH-0007bQ-GI; Sat, 12 Mar 2005 16:07:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADl1-0000N7-PP; Sat, 12 Mar 2005 16:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADl0-0000N2-9o for ltru@megatron.ietf.org; Sat, 12 Mar 2005 16:02:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07356 for ; Sat, 12 Mar 2005 16:02:44 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DADoH-0007Yo-Ro for ltru@ietf.org; Sat, 12 Mar 2005 16:06:10 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 12 Mar 2005 13:02:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Update to proposed registry Date: Sat, 12 Mar 2005 13:02:31 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A924C04@irvmbxw01.quest.com> Thread-Topic: [Ltru] Update to proposed registry Thread-Index: AcUnQ04pSUPqKkkoRuaCrmm7Srvt3QAA1R2w From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 Mar 2005 21:02:32.0522 (UTC) FILETIME=[CF128AA0:01C52746] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable See Appendix C in the registry I-D. IMHO, there is no reason that the prototype registry has itself to be an = internet draft. Merely that there be a process for creating and = approving it.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: Saturday, March 12, 2005 12:36 PM > To: LTRU Working Group > Subject: Re: [Ltru] Update to proposed registry >=20 > Hi - >=20 > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Saturday, March 12, 2005 11:21 AM > > Subject: [Ltru] Update to proposed registry > > >=20 > > Addison and Mark's new draft contains an important change: = grandfathered > > tags are allowed to have a canonical value. This means = grandfathered > > tags can be formally deprecated, not just marked with a comment. = This > > is a change we've talked about for some time. The wording is still = a > > bit inconsistent, but I expect that will be cleared up soon. > > > > Accordingly, I've updated the proposed draft registry available at: > > > > http://users.adelphia.net/~dewell/lstreg.html > > http://users.adelphia.net/~dewell/lstreg.txt > > > > to add canonical values to all the grandfathered tags that were > > previously commented as "deprecated." This update also removes the > > variant subtag 'lojban' and changes the status of "art-lojban" from > > redundant to grandfathered (with a canonical value of "jbo"). > > > > There is also a change history at > > http://users.adelphia.net/~dewell/lstreg-history.html. > > > > All comments within the scope of the charter are welcome. >=20 > (co-chair hat OFF) >=20 > Would it make sense to make this into a working group i-d? > When (re-)populating a registry, it seems like it would be nice > to be able to give IANA something that had been under WG change > control, without having to incorporate it all in the registry = document. > On the other hand, the format of the entries would be hard to > reconcile with the constraints on i-ds. Many of the lines exceed > 72 characters. In any case, if the updated registry would contain > information that cannot be derived algorithmically from the current > registry contents, we *somehow* would have to provide that information > to IANA, whether in the registry document itself or in a new companion > document. Ideas? >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 12 16:20:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08435; Sat, 12 Mar 2005 16:20:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAE5j-0007xy-CS; Sat, 12 Mar 2005 16:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADzz-0001zP-7R; Sat, 12 Mar 2005 16:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DADzy-0001zK-Ha for ltru@megatron.ietf.org; Sat, 12 Mar 2005 16:18:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08320 for ; Sat, 12 Mar 2005 16:18:12 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAE3G-0007vk-Bm for ltru@ietf.org; Sat, 12 Mar 2005 16:21:38 -0500 Received: from h-68-164-242-230.snvacaid.dynamic.covad.net ([68.164.242.230] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DADzw-0001ux-00 for ltru@ietf.org; Sat, 12 Mar 2005 13:18:12 -0800 Message-ID: <00bd01c52749$0c131440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0A924C04@irvmbxw01.quest.com> Subject: Re: [Ltru] Update to proposed registry Date: Sat, 12 Mar 2005 13:18:10 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi - (co-chair hat off) > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Saturday, March 12, 2005 1:02 PM > Subject: RE: [Ltru] Update to proposed registry > > See Appendix C in the registry I-D. > > IMHO, there is no reason that the prototype registry has itself to be an internet draft. True, it's just that the procedures for change control and approval of i-ds are already in place. The material in appendix C of registry-00, as you point out, would provide another way of accomplishing the same thing. > Merely that there be a process for creating and approving it. I think it would make sense to move this material into the IANA considerations section as a separate subsection, with a title something like "Initialization of the Registry". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 12 16:33:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09275; Sat, 12 Mar 2005 16:33:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAEIE-0008HW-GM; Sat, 12 Mar 2005 16:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAEER-0003S7-Tn; Sat, 12 Mar 2005 16:33:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAEEQ-0003Rr-Nx for ltru@megatron.ietf.org; Sat, 12 Mar 2005 16:33:11 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09235 for ; Sat, 12 Mar 2005 16:33:07 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAEDW-0000wg-RV for ltru@lists.ietf.org; Sat, 12 Mar 2005 22:32:14 +0100 Received: from du-001-218.access.de.clara.net ([212.82.227.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Mar 2005 22:32:14 +0100 Received: from nobody by du-001-218.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Mar 2005 22:32:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 12 Mar 2005 22:28:42 +0100 Organization: Lines: 38 Message-ID: <42335F0A.54C@xyzzy.claranet.de> References: <007301c52738$bae2ba40$030aa8c0@DEWELL> <000d01c52743$356300e0$7f1afea9@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-218.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: [http://users.adelphia.net/~dewell/lstreg.txt] > Would it make sense to make this into a working group i-d? Yes, please. Same procedure as with RfC 3864 and draft-klyne-hdrreg-mail-05. Unfortunately IANA used this nice document listing all header fields to be defined in [RFC-klyne-hdrreg-mail-05], which is not exactly what RfC 3864 wanted. But for new header fields defined after RfC 3864 it works, e.g. Solicitation [RFC3865]. > it would be nice to be able to give IANA something that had > been under WG change control I tried to convince IANA that i-klingon should be marked as "deprecated, use tlh", but so far that had no effect. Maybe using the generic registry update Web form was a bad idea (?) > the format of the entries would be hard to reconcile with > the constraints on i-ds. Many of the lines exceed > 72 characters. Maybe something like this is possible with xml2rfc: Column 1 goes to the scetion title, it would be redundant in the I-D lines. One section "region", one "language", etc. Columns 2 and 4 (subtag and date) always exist, that could be the first line of each entry. Column 5 (canonical value) also fits into the first line. Column 3 and 6 could go into the second line for each entry. Some style of list in xml2rfc could probably handle this. That strategy would work for the worst case (longest line) grandfathered | zh-min-nan | etc. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 15:23:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08097; Sun, 13 Mar 2005 15:23:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAZgF-0005rn-RB; Sun, 13 Mar 2005 15:27:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAZbn-0007hF-VQ; Sun, 13 Mar 2005 15:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAZbm-0007hA-Mi for ltru@megatron.ietf.org; Sun, 13 Mar 2005 15:22:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08040 for ; Sun, 13 Mar 2005 15:22:40 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAZfF-0005nH-II for ltru@ietf.org; Sun, 13 Mar 2005 15:26:18 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 13 Mar 2005 12:22:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Update to proposed registry Date: Sun, 13 Mar 2005 12:22:30 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Update to proposed registry Thread-Index: AcUnSz6pyHeWkfaPQEeLzTENxg/m5wAPczuA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 13 Mar 2005 20:22:31.0202 (UTC) FILETIME=[622FF020:01C5280A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable I think that what Frank is suggesting below is documenting the *content* = of the registry, as distinct from the registry itself. Based on our experience to date, my suggestions would be: 1. Appoint Doug as the official editor of the draft registry (assuming = he is willing to continue). 2. NOT make the draft registry into a version controlled document until = the IESG approves the registry draft. Changes in the registry draft have = an effect on the format and contents of the registry itself. Save doing = version control on the document until its own approval process starts. 3. DO figure out how to do it under the auspices of the IETF and RFC = 2616 (if applicable) or in line with what others have done (if not). 4. DO discuss the rules for appropriate content, etc. To the extent = possible, these should be embodied in the registry draft, of which the = prototype registry should be (and currently *is*) a reflection. Think of = the prototype registry as an expression of those rules useful in = debating the finer grained rules. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: Saturday, March 12, 2005 1:29 PM > To: ltru@ietf.org > Subject: [Ltru] Re: Update to proposed registry >=20 > Randy Presuhn wrote: >=20 > [http://users.adelphia.net/~dewell/lstreg.txt] > > Would it make sense to make this into a working group i-d? >=20 > Yes, please. > Same procedure as with RfC 3864 and draft-klyne-hdrreg-mail-05. >=20 > Unfortunately IANA used this nice document listing all header > fields to be defined in [RFC-klyne-hdrreg-mail-05], which is > not exactly what RfC 3864 wanted. But for new header fields > defined after RfC 3864 it works, e.g. Solicitation [RFC3865]. >=20 > > it would be nice to be able to give IANA something that had > > been under WG change control >=20 > I tried to convince IANA that i-klingon should be marked as > "deprecated, use tlh", but so far that had no effect. Maybe > using the generic registry update Web form was a bad idea (?) >=20 > > the format of the entries would be hard to reconcile with > > the constraints on i-ds. Many of the lines exceed > > 72 characters. >=20 > Maybe something like this is possible with xml2rfc: >=20 > Column 1 goes to the scetion title, it would be redundant in > the I-D lines. One section "region", one "language", etc. >=20 > Columns 2 and 4 (subtag and date) always exist, that could be > the first line of each entry. Column 5 (canonical value) also > fits into the first line. Column 3 and 6 could go into the > second line for each entry. Some style of list in xml2rfc > could probably handle this. That strategy would work for the > worst case (longest line) grandfathered | zh-min-nan | etc. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 17:38:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16490; Sun, 13 Mar 2005 17:38:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAbmq-00023d-Kh; Sun, 13 Mar 2005 17:42:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAbix-0004XD-Ei; Sun, 13 Mar 2005 17:38:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAbiv-0004X8-Hv for ltru@megatron.ietf.org; Sun, 13 Mar 2005 17:38:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16480 for ; Sun, 13 Mar 2005 17:38:11 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAbmP-000207-OL for ltru@ietf.org; Sun, 13 Mar 2005 17:41:51 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 3E7F84EFB1; Sun, 13 Mar 2005 17:38:06 -0500 (EST) Message-Id: <6.0.0.20.2.20050314071105.081253f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 14 Mar 2005 07:33:04 +0900 To: "Addison Phillips" , "Frank Ellermann" , , "Doug Ewell" From: Martin Duerst Subject: RE: [Ltru] Re: Update to proposed registry In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hello Addison, others, At 05:22 05/03/14, Addison Phillips wrote: >I think that what Frank is suggesting below is documenting the *content* of >the registry, as distinct from the registry itself. > >Based on our experience to date, my suggestions would be: > >1. Appoint Doug as the official editor of the draft registry (assuming he >is willing to continue). With my chairs hat on, but only asking, not appointing: Doug, would you be willing to edit the draft registry for the LTRU WG? Would you volunteer to turn that into an internet-draft if that's what we decide needs to be done? >2. NOT make the draft registry into a version controlled document until the >IESG approves the registry draft. Changes in the registry draft have an >effect on the format and contents of the registry itself. Save doing >version control on the document until its own approval process starts. With my chairs hat off: Are you suggesting that we publish the draft registry as an internet draft (which we might call draft-ietf-ltru-initial or draft-ietf-ltru-populate), but we only publish the -00.txt version when draft-ietf-ltru-registry has been approved? In general, developping things in sync seems a better idea. I.e. if we would do it as an internet draft, the ideal would be that draft-ietf-ltru-initial would be published just a day or two after each publication of draft-ietf-ltru-registry. >3. DO figure out how to do it under the auspices of the IETF and RFC 2616 >(if applicable) or in line with what others have done (if not). With my chairs hat on: I don't think there is any question about the fact that this should be done under the auspices of the IETF. But we have to find out what that means, and how it can be done best. Chairs hat off again. >4. DO discuss the rules for appropriate content, etc. To the extent >possible, these should be embodied in the registry draft, of which the >prototype registry should be (and currently *is*) a reflection. Think of >the prototype registry as an expression of those rules useful in debating >the finer grained rules. >> -----Original Message----- >> From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On >> Behalf Of Frank Ellermann >> Randy Presuhn wrote: >> >> [http://users.adelphia.net/~dewell/lstreg.txt] >> > Would it make sense to make this into a working group i-d? >> >> Yes, please. >> Same procedure as with RfC 3864 and draft-klyne-hdrreg-mail-05. >> >> Unfortunately IANA used this nice document listing all header >> fields to be defined in [RFC-klyne-hdrreg-mail-05], which is >> not exactly what RfC 3864 wanted. But for new header fields >> defined after RfC 3864 it works, e.g. Solicitation [RFC3865]. >> >> > it would be nice to be able to give IANA something that had >> > been under WG change control I agree. For those not too familliar with IANA, it is also important to say that IANA prefers very clear rules that allow them to work in a purely secretarial function, without having to make any judgement decisions on matter they may not understand anyway. >> I tried to convince IANA that i-klingon should be marked as >> "deprecated, use tlh", but so far that had no effect. Maybe >> using the generic registry update Web form was a bad idea (?) >> >> > the format of the entries would be hard to reconcile with >> > the constraints on i-ds. Many of the lines exceed >> > 72 characters. >> >> Maybe something like this is possible with xml2rfc: >> >> Column 1 goes to the scetion title, it would be redundant in >> the I-D lines. One section "region", one "language", etc. >> >> Columns 2 and 4 (subtag and date) always exist, that could be >> the first line of each entry. Column 5 (canonical value) also >> fits into the first line. Column 3 and 6 could go into the >> second line for each entry. Some style of list in xml2rfc >> could probably handle this. That strategy would work for the >> worst case (longest line) grandfathered | zh-min-nan | etc. Would that mean that we would change the registry format, or would that I-D come with detailled instructions of how to reconstruct the current registry format from the I-D, or would this mean that we change the format? Also, I have heard that this has been considered, but would a rather different approach to a registry format (e.g. using XML) make it easier to put the initial registry data into an I-D and back? Can we move to an XML format without making things too complicated? Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 17:53:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17209; Sun, 13 Mar 2005 17:53:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAc1U-0002V8-0Z; Sun, 13 Mar 2005 17:57:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAbww-0005p0-M1; Sun, 13 Mar 2005 17:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAbwv-0005ov-Si for ltru@megatron.ietf.org; Sun, 13 Mar 2005 17:52:42 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17178 for ; Sun, 13 Mar 2005 17:52:39 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050313225210.DHXQ7277.mta10.adelphia.net@DEWELL> for ; Sun, 13 Mar 2005 17:52:10 -0500 Message-ID: <000801c5281f$45054e40$030aa8c0@DEWELL> From: "Doug Ewell" To: References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> Date: Sun, 13 Mar 2005 14:52:00 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Would it make sense to make this into a working group i-d? > When (re-)populating a registry, it seems like it would be nice > to be able to give IANA something that had been under WG change > control, without having to incorporate it all in the registry > document. I agree that it should be under some sort of change control. My change-history page is intended only as a starting point toward something more official. I don't think I agree that it should be an I-D, since it is not intended to become an RFC. > On the other hand, the format of the entries would be hard to > reconcile with the constraints on i-ds. Many of the lines exceed > 72 characters. The longest line is 140 characters (plus CR/LF), thanks to that ridiculously long description for "zh-min-nan". The proposed draft registry (PDR) is consistent with the layout defined in Section 3.1, which certainly makes it inconsistent with formats that insist on 72 characters. > In any case, if the updated registry would contain > information that cannot be derived algorithmically from the current > registry contents, we *somehow* would have to provide that information > to IANA, whether in the registry document itself or in a new companion > document. Ideas? We do. At least 98% of the PDR can be derived algorithmically from the core ISO standards, their history pages, and the current registry -- you would need all of these -- but there might be some surprises that need explanation. Perhaps it should be a new Appendix D to draft-ietf-ltru-registry, rather than a new companion document. Later: > I think it would make sense to move this material into the IANA > considerations section as a separate subsection, with a title > something like "Initialization of the Registry". Something like that. Frank Ellermann wrote: > I tried to convince IANA that i-klingon should be marked as > "deprecated, use tlh", but so far that had no effect. Maybe > using the generic registry update Web form was a bad idea (?) The PDR has the following entries: language | tlh | Klingon; tlhIngan-Hol | 2004-07-06 | | grandfathered | i-klingon | Klingon | 1999-05-26 | tlh | # deprecated 2004-02-24 The grandfathered tag "i-klingon" has a canonical value of "tlh", which does what you want. > Maybe something like this is possible with xml2rfc: > > Column 1 goes to the scetion title, it would be redundant in > the I-D lines. One section "region", one "language", etc. > > Columns 2 and 4 (subtag and date) always exist, that could be > the first line of each entry. Column 5 (canonical value) also > fits into the first line. Column 3 and 6 could go into the > second line for each entry. Some style of list in xml2rfc > could probably handle this. That strategy would work for the > worst case (longest line) grandfathered | zh-min-nan | etc. If we are going to shoehorn the registry into an RFC-compatible format, we will need to revise Section 3.1 substantially. The primary intent of the format was to be machine-readable, rather than laid out attractively for humans (cf. the current registry). I'm in favor of WG accountability and control over the registry, but against trying to turn it into an RFC. An RFC can't be changed once it's published, which is exactly what we don't want to happen with the registry. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 18:12:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19827; Sun, 13 Mar 2005 18:12:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAcJP-0003GA-Fj; Sun, 13 Mar 2005 18:15:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAcEs-0007d0-JY; Sun, 13 Mar 2005 18:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAcEp-0007cp-N5 for ltru@megatron.ietf.org; Sun, 13 Mar 2005 18:11:12 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19732 for ; Sun, 13 Mar 2005 18:11:08 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050313231040.DZAU7277.mta10.adelphia.net@DEWELL>; Sun, 13 Mar 2005 18:10:40 -0500 Message-ID: <000b01c52821$db1efc80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.com> <6.0.0.20.2.20050314071105.081253f0@localhost> Subject: Re: [Ltru] Re: Update to proposed registry Date: Sun, 13 Mar 2005 15:10:30 -0800 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 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Martin Duerst wrote: >> Based on our experience to date, my suggestions would be: >> >> 1. Appoint Doug as the official editor of the draft registry >> (assuming he is willing to continue). > > With my chairs hat on, but only asking, not appointing: > Doug, would you be willing to edit the draft registry for the LTRU WG? Certainly. > Would you volunteer to turn that into an internet-draft if that's what > we decide needs to be done? If that's what you decide. But if that involves changing the format of the registry to make it fit into 72-character lines, we need to discuss that first. One of the existing descriptions is 94 characters long *just by itself*. >> 2. NOT make the draft registry into a version controlled document >> until the IESG approves the registry draft. Changes in the registry >> draft have an effect on the format and contents of the registry >> itself. Save doing version control on the document until its own >> approval process starts. > > With my chairs hat off: > > Are you suggesting that we publish the draft registry as an internet > draft (which we might call draft-ietf-ltru-initial or draft-ietf-ltru- > populate), but we only publish the -00.txt version when draft-ietf- > ltru-registry has been approved? > > In general, developping things in sync seems a better idea. I.e. if > we would do it as an internet draft, the ideal would be that > draft-ietf-ltru-initial would be published just a day or two after > each publication of draft-ietf-ltru-registry. I agree with Addison. Appendix C says that the "real" proposed registry is created (converted) only *after* the draft is approved. However, certain items within the current proposed registry have generated as much controversy as the draft itself, so we need to continue developing it in parallel with the draft. But that may not mean it needs to be under change control yet. The registry does have its own Last Call period. > I agree. For those not too familliar with IANA, it is also important > to say that IANA prefers very clear rules that allow them to work > in a purely secretarial function, without having to make any > judgement decisions on matter they may not understand anyway. Can't fault them for that. :-) >>> Maybe something like this is possible with xml2rfc: >>> ... > > Would that mean that we would change the registry format, or > would that I-D come with detailled instructions of how to reconstruct > the current registry format from the I-D, or would this mean that > we change the format? We need to decide this first, before suggesting particular tools. > Also, I have heard that this has been considered, but would > a rather different approach to a registry format (e.g. using > XML) make it easier to put the initial registry data into an > I-D and back? Can we move to an XML format without making > things too complicated? I could certainly convert it to XML with no problem. Whether that is the format we want is another question, and needs to be discussed. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 19:08:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23335; Sun, 13 Mar 2005 19:08:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAdCF-00050K-0j; Sun, 13 Mar 2005 19:12:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAd7z-0004KI-LU; Sun, 13 Mar 2005 19:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAd7x-0004KD-W3 for ltru@megatron.ietf.org; Sun, 13 Mar 2005 19:08:10 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23285 for ; Sun, 13 Mar 2005 19:08:06 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAd6u-0006r1-Ke for ltru@lists.ietf.org; Mon, 14 Mar 2005 01:07:04 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 01:07:04 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 01:07:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Mar 2005 01:06:48 +0100 Organization: Lines: 25 Message-ID: <4234D598.895@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.com> <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.c om> <6.0.0.20.2.20050314071105.081253f0@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: 212.82.251.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Martin Duerst wrote: > Would that mean that we would change the registry format Not necessarily. With your hat on you could decree that Doug is an ISO or W3C liaison, and maybe then it's possible to use a more flexible format than "I-D" for his registry. > would that I-D come with detailled instructions of how to > reconstruct the current registry format from the I-D As you said IANA is probably not interested to read the RfC only to create its own "xml2registry" script. Another idea: Just use the registry as is accepting the horrible I-D line wraps in the plain text version, xml2rfc can also create HTML, and that should be readable. Actually I'm more interested to have some format, whatever it is, then pretend that 3066bis existed 1990 or earlier, prove that some resulting regional tags would be plain nonsense today, and then really _think_ about this part in the draft. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 19:18:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23737; Sun, 13 Mar 2005 19:18:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAdLt-0005HB-On; Sun, 13 Mar 2005 19:22:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAdHt-0005CU-0B; Sun, 13 Mar 2005 19:18:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAdHq-0005CH-Ek for ltru@megatron.ietf.org; Sun, 13 Mar 2005 19:18:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23716 for ; Sun, 13 Mar 2005 19:18:17 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAdLK-0005Gh-Js for ltru@ietf.org; Sun, 13 Mar 2005 19:21:58 -0500 Received: from lns-p19-19-idf-82-65-139-89.adsl.proxad.net ([82.65.139.89] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DAdHj-00070l-EP; Sun, 13 Mar 2005 16:18:16 -0800 Message-Id: <6.1.2.0.2.20050314000816.03fd0530@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 14 Mar 2005 01:17:17 +0100 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Working Group submission: LTRU Registry Draft 00 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c On 21:10 12/03/2005, Addison Phillips said: >Dear Editor, >Please find attached in text format draft-00 of "draft-ietf-ltru-registry". >I understand that this will be processed after IETF-62. Thank you for this document. I have asked guidance to several concerned parties to present a comment synthesis (I give time for responses - or for no-response freeing me). I also asked guidance to some WG-IDN members and other ccTLDs which could be of help towards a ccTLD BP IRT concerning the Unicode updates impact on IDNs. For example a notion which can simplify the IDN support issue, but possibly introduce more complexity at the end of the day for the language tags in general (I do not know), is loosing the relations of IDN Tables - and tables tags - with languages to be in phase with real users demand and ccTLD political trends. As you know, priority today in the IDN area is the homographs/phishing issue. So I do not think I can come with real comment on this draft before end of the week. I suggest that we stick to the charter for the time being (obviously we can propose more) and to the consistency with other RFCs (in particular to IANA ICANN IETF MoU). I would also suggest that we make sure Doug Barton is on this list? His guidance would be useful. The same for Harald as the RFC 3066 author (however he said he will be on vacation until May). The move of the Drafts to an IETF WG was a first good normalization move. The second one should be the support of the ietf-languages@iana.org list by the IANA (host, archives, subscription page, etc.). best regards. jfc ===================================================== For your convenience: Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 20:00:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26139; Sun, 13 Mar 2005 20:00:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAe0H-0006Ty-Ri; Sun, 13 Mar 2005 20:04:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAdwY-0000Tj-QF; Sun, 13 Mar 2005 20:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAdwX-0000Tb-PF for ltru@megatron.ietf.org; Sun, 13 Mar 2005 20:00:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26127 for ; Sun, 13 Mar 2005 20:00:20 -0500 (EST) Received: from lakermmtao07.cox.net ([68.230.240.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAdzz-0006Te-85 for ltru@ietf.org; Sun, 13 Mar 2005 20:04:02 -0500 Received: from A31P ([68.100.55.187]) by lakermmtao07.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050314010003.BZEK19214.lakermmtao07.cox.net@A31P>; Sun, 13 Mar 2005 20:00:03 -0500 From: "Scott Hollenbeck" To: "'Doug Ewell'" , Subject: RE: [Ltru] Re: Update to proposed registry Date: Sun, 13 Mar 2005 19:57:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcUoH4T5LOVGBl70RJacTlTa+8cbVwAECgOQ In-Reply-To: <000801c5281f$45054e40$030aa8c0@DEWELL> Message-Id: <20050314010003.BZEK19214.lakermmtao07.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit > I'm in favor of WG accountability and control over the > registry, but against trying to turn it into an RFC. An RFC > can't be changed once it's published, which is exactly what > we don't want to happen with the registry. Don't confuse the contents of a registry with the contents of an RFC. An I-D/RFC can be used to tell IANA how to create a registry, how the entries are formatted, and how new entries are approved. It can also be used to populate initial values. The contents of the registry itself can change over time, though, and the initial RFC doesn't have to change to make that happen. The IETF likes to use RFCs or other stable standards specifications to populate IANA-maintained registries for tracking and community review purposes. RFCs can be obsoleted if need be. The thing to consider is just how often the contents of the registry will need to be changed. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 20:13:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27600; Sun, 13 Mar 2005 20:13:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAeCJ-0006ya-9P; Sun, 13 Mar 2005 20:16:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAe8a-000260-7s; Sun, 13 Mar 2005 20:12:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAe8Y-00025u-PL for ltru@megatron.ietf.org; Sun, 13 Mar 2005 20:12:51 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27520 for ; Sun, 13 Mar 2005 20:12:46 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAe7W-0005LP-5P for ltru@lists.ietf.org; Mon, 14 Mar 2005 02:11:46 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 02:11:46 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 02:11:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Mar 2005 02:10:14 +0100 Organization: Lines: 63 Message-ID: <4234E475.7046@xyzzy.claranet.de> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> 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.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > i-klingon | Klingon | 1999-05-26 | tlh | # deprecated 2004-02-24 Yes, you have it, but IANA still has the old entry. This could be a hen and egg issue. I've got a confirmation for the update request, maybe they'll fix it after the IETF meeting, I'll ask them again in about two weeks. It's "obvious" (after somebody told me where to find "tlh"). You still have "i-default" without canonical "und", and I still don't see the difference between "i-default" and "und". Both are dummies. If they are different I'd like some explanations in the draft. So far I only understand "avoid UND like hell" (2.3 clause 4), but "i-default" is not much better, or is it ? > If we are going to shoehorn the registry into an > RFC-compatible format It's only an I-D limitation, the later registry itself can be in the form proposed in the draft. Published by IANA in any form they like. You can see the somewhat dubious results for the "header registry", compare it with the complete input in draft-klyne-hdrreg-mail-05 I really wonder what happens when the IETF expires this draft, all the good work lost unless somebody offers a public copy ? > The primary intent of the format was to be machine-readable, > rather than laid out attractively for humans Yes, that's fine, if IANA gets the idea. The existing charset registry could be a model for a more IANA-friendly format, also working in a separate I-D or in 3066bis IANA considerations: For your purposes you would probably split what you have in six files: languages, scripts, regions, variants, grandfathered, redundant. Each part has its own source(s), e.g. ISO 639 for the languages. Each entry could consist of up to five lines, terminated by an empty line: Name: in Description: Indonesian Date: 2004-07-06 Canonical: id Comment: # deprecated 1989 Or something like this format all in one file, then you'd say: Language: in Description: Indonesian Date: 2004-07-06 Canonical: id Comment: # deprecated 1989 Even if that's a bad idea you could apparently delete all "# " in the column for comments, or is this a feature ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 20:20:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28208; Sun, 13 Mar 2005 20:20:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAeJ4-0007Cp-Cr; Sun, 13 Mar 2005 20:23:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAeES-0002bc-S7; Sun, 13 Mar 2005 20:18:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAeEQ-0002bV-Vt for ltru@megatron.ietf.org; Sun, 13 Mar 2005 20:18:55 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28126 for ; Sun, 13 Mar 2005 20:18:51 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050314011823.LGXE5402.mta11.adelphia.net@DEWELL> for ; Sun, 13 Mar 2005 20:18:23 -0500 Message-ID: <002701c52833$a99cdd00$030aa8c0@DEWELL> From: "Doug Ewell" To: References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> Date: Sun, 13 Mar 2005 17:17:59 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Actually I'm more interested to have some format, whatever it > is, then pretend that 3066bis existed 1990 or earlier, prove > that some resulting regional tags would be plain nonsense > today, and then really _think_ about this part in the draft. This was something Frank brought up a while back on ietf-languages. He's concerned about the fact that the draft admits all ISO 3166 codes ever approved since the inception of that standard (1974), even those that have since been withdrawn. He's especially concerned that region subtags such as BQ and NT would be permanently allocated in the registry to obscure, no-longer-existent entities, so that if ISO 3166/MA ever reassigns these codes to other entities, those entities will be stuck with less-mnemonic UN M.49 numeric codes. IMHO, we should discuss the basic principle of admitting all codes, instead of quibbling over the merits of individual codes like BQ and NT. So here is my restatement of Frank's proposal, together with a fair and unbiased (I hope) set of pro and con arguments: PROPOSAL: Remove all ISO 3166 codes withdrawn before a certain date. Possibilities include 1988-08-15 (publication of ISO 3166 3/e) and 1995-03-01 (publication of RFC 1766). PRO: These codes weren't valid in RFC 1766 or 3066, so we should not have to retroactively allow them now. They could cause confusion for users reading the registry. If ISO 3166/MA does take leave of their sense and reassign more codes, this limits the damage somewhat. CON: Just because an ISO code was withdrawn on a certain date doesn't mean everyone immediately stopped using it. Look at the iw/he and ji/yi examples, where users were *encouraged* to keep generating the old codes. Doing this for 3166 but not 639 might attract criticism over inconsistency. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 20:34:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29287; Sun, 13 Mar 2005 20:34:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAeWw-0007iB-6Z; Sun, 13 Mar 2005 20:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAeSQ-0003tu-DU; Sun, 13 Mar 2005 20:33:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAeSP-0003tp-Gi for ltru@megatron.ietf.org; Sun, 13 Mar 2005 20:33:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29219 for ; Sun, 13 Mar 2005 20:33:19 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAeVu-0007gU-EW for ltru@ietf.org; Sun, 13 Mar 2005 20:36:59 -0500 Received: from h-64-105-136-31.snvacaid.dynamic.covad.net ([64.105.136.31] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DAeSL-0007e2-00 for ltru@ietf.org; Sun, 13 Mar 2005 17:33:17 -0800 Message-ID: <003501c52835$da71dc80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050314010003.BZEK19214.lakermmtao07.cox.net@A31P> Subject: Re: [Ltru] Re: Update to proposed registry Date: Sun, 13 Mar 2005 17:33:41 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi - (co-chair hat off) > From: "Scott Hollenbeck" > To: "'Doug Ewell'" ; > Sent: Sunday, March 13, 2005 4:57 PM > Subject: RE: [Ltru] Re: Update to proposed registry ... > Don't confuse the contents of a registry with the contents of an RFC. An > I-D/RFC can be used to tell IANA how to create a registry, how the entries > are formatted, and how new entries are approved. It can also be used to > populate initial values. The contents of the registry itself can change over > time, though, and the initial RFC doesn't have to change to make that > happen. > > The IETF likes to use RFCs or other stable standards specifications to > populate IANA-maintained registries for tracking and community review > purposes. RFCs can be obsoleted if need be. The thing to consider is just > how often the contents of the registry will need to be changed. ... Also, just putting something into an i-d does not necessarily put it on the path to publication as an RFC. Though I like some aspects of the abstract idea of having the initial contents of the registry in an internet-draft (rather than a web page somewhere) because it fits in with the way IANA likes to work, I worry when discussion turns to changing the format of registry entries simply in order to accommodate the constraints on posting the information in the form of an internet-draft, unless there would be other, substantial benefits from those format changes. In any case, I think that using i-ds or RFCs as the *update* mechanism after the registry has been initialized would be far too heavy-weight. I think we have several alternatives available for initializing the registry: 1) pointer to external file/web site (current proposal in -registry-00.txt 2) reference to WG internet-draft handed to IANA 3) reference to WG RFC containing initial contents 4) embed initialization data into appendix of registry document Did I miss some? My biggest concern about 2-4 is that the quirks of i-d posting and rfc publication formats would require us to spend time on aspects of registry entries that we might otherwise not have to spend. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 20:51:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00465; Sun, 13 Mar 2005 20:51:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAenk-0008J2-Jk; Sun, 13 Mar 2005 20:55:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAejx-0005bM-AX; Sun, 13 Mar 2005 20:51:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAejw-0005bH-LL for ltru@megatron.ietf.org; Sun, 13 Mar 2005 20:51:28 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00461 for ; Sun, 13 Mar 2005 20:51:26 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050314015057.KNIV7277.mta10.adelphia.net@DEWELL>; Sun, 13 Mar 2005 20:50:57 -0500 Message-ID: <002a01c52838$35419fe0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050314010003.BZEK19214.lakermmtao07.cox.net@A31P> Subject: Re: [Ltru] Re: Update to proposed registry Date: Sun, 13 Mar 2005 17:50:30 -0800 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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: > Don't confuse the contents of a registry with the contents of an RFC. > An I-D/RFC can be used to tell IANA how to create a registry, how the > entries are formatted, and how new entries are approved. It can also > be used to populate initial values. The contents of the registry > itself can change over time, though, and the initial RFC doesn't have > to change to make that happen. The current draft does all of these except the last (populating the initial values). Appendix C proposes that the WG chair will present a proposed registry for Last Call, and describes how it is put together (more or less), but doesn't specify how it is managed before then. The draft *could* be revised to include the entire proposed registry. I'm not saying it *should*, and in fact I thought I remembered someone arguing months ago on ietf-languages that an RFC was no place for a code list. (That may have been just their opinion, of course.) > The IETF likes to use RFCs or other stable standards specifications to > populate IANA-maintained registries for tracking and community review > purposes. RFCs can be obsoleted if need be. The thing to consider is > just how often the contents of the registry will need to be changed. The registry will need to be updated: (a) to register a new subtag to reflect a new ISO 639, 3166, or 15924 code; (b) to register a new variant (or extlang) subtag; (c) to reflect the approval of an extension RFC (is this true?); (d) to change a description in a way compatible with Section 3.2; (e) to add new values to the "recommended prefix" field; (f) to reclassify a grandfathered tag as redundant, per Section 3.2; (g) to change any comment. My first attempt at the registry was on 2004-07-06. Since then, there have been 22 revisions, but most were reflections of the evolving nature of the draft. By my count, there have been 9 changes that would have taken place if RFC 3066bis were live and stable. This extrapolates to about one change per month. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 21:21:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02143; Sun, 13 Mar 2005 21:21:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAfGg-0000ld-Tc; Sun, 13 Mar 2005 21:25:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfCc-0007pe-BK; Sun, 13 Mar 2005 21:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfCb-0007pZ-Ck for ltru@megatron.ietf.org; Sun, 13 Mar 2005 21:21:05 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02076 for ; Sun, 13 Mar 2005 21:21:02 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAfBU-0001SC-V7 for ltru@lists.ietf.org; Mon, 14 Mar 2005 03:19:56 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 03:19:56 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 03:19:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Mar 2005 03:10:39 +0100 Organization: Lines: 38 Message-ID: <4234F29F.1E3A@xyzzy.claranet.de> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> 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.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > a fair and unbiased (I hope) set of pro and con arguments: Yes, within the constraints of the draft. It's a problem in the design for some cases: 1 - Region known as XX splits into XX and YY, one part inherits the CC. Old XX tags could be nonsense under the new XX, example sl-YU 2 - Regions known as AA and BB join to a new AA, the union inherits the CC of one of its former parts. The registry still supports old BB tags, but there's no way to identify old AA tags. Example: dsb-DD vs. fy-DE. 3 - Same case, the registry wouldn't identify AA as canonical value for BB, beause it has not the same UN number. Example: YD (720) plus YE (886) are now YE (887). 4 - Sometimes regions have an UN number and no CC, but one or more ccTLDs. Examples: 830 (GG), 830 (JE), 833 (IM). Almost all "old" problems could be avoided by a cut-off date, but the same design would soon cause similar "new" problems. One radical solution could be to admit that some things simply cannot work "forever", and ISO 3166 CCs belong to this class, It's like old calendar dates and times. Maybe the concept of "regions" for the TZ database is already better than ISO 3166. Or the UN numbers are the solution, and ISO 3166 CCs and IANA ccTLDs simply mean whatever they mean "now", allowing old CCs in their old meaning temporarily (with a canonical UN number), until they get a new meaning. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 21:31:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02883; Sun, 13 Mar 2005 21:31:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAfQ0-00017R-RY; Sun, 13 Mar 2005 21:34:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfLA-0000Ab-NX; Sun, 13 Mar 2005 21:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfL9-0000AW-4v for ltru@megatron.ietf.org; Sun, 13 Mar 2005 21:29:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02784 for ; Sun, 13 Mar 2005 21:29:53 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAfOf-00015l-Bd for ltru@ietf.org; Sun, 13 Mar 2005 21:33:34 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2E2Tdi4005391; Sun, 13 Mar 2005 21:29:40 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 13 Mar 2005 21:29:42 -0500 Date: Sun, 13 Mar 2005 21:29:42 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Update to proposed registry Message-ID: <20050314022942.GJ2941@skunk.reutershealth.com> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> <4234E475.7046@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4234E475.7046@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Frank Ellermann scripsit: > You still have "i-default" without canonical "und", and I still > don't see the difference between "i-default" and "und". Both > are dummies. If they are different I'd like some explanations > in the draft. i-default means "the language readable to the most people", typically English with the hard bits left out. und means "language has not yet been determined", and should be used only when a language MUST be specified and no information is available. -- 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 http://www.reutershealth.com sure you are in hell, however, then you must be jcowan@reutershealth.com on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 21:33:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02996; Sun, 13 Mar 2005 21:33:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAfRo-00019b-1M; Sun, 13 Mar 2005 21:36:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfND-0000I0-Dl; Sun, 13 Mar 2005 21:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfNB-0000Hk-Sl for ltru@megatron.ietf.org; Sun, 13 Mar 2005 21:32:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02934 for ; Sun, 13 Mar 2005 21:32:00 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAfQi-000180-9n for ltru@ietf.org; Sun, 13 Mar 2005 21:35:41 -0500 Received: from lns-p19-19-idf-82-65-139-89.adsl.proxad.net ([82.65.139.89] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DAfN5-0002Hm-K6; Sun, 13 Mar 2005 18:31:59 -0800 Message-Id: <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 14 Mar 2005 02:57:06 +0100 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) In-Reply-To: <002701c52833$a99cdd00$030aa8c0@DEWELL> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On 02:17 14/03/2005, Doug Ewell said: >Frank Ellermann wrote: > > Actually I'm more interested to have some format, whatever it > > is, then pretend that 3066bis existed 1990 or earlier, prove > > that some resulting regional tags would be plain nonsense > > today, and then really _think_ about this part in the draft. > >This was something Frank brought up a while back on ietf-languages. >He's concerned about the fact that the draft admits all ISO 3166 codes >ever approved since the inception of that standard (1974), even those >that have since been withdrawn. IMHO There is a problem here of who does what. The IANA most known table, to the point to be referred worldwide as "the IANA table" is the ccTLD table which documents the ICANN understanding of ISO 3166. Also, as I understand the MoU between IANA, IESG and ICANN this table is in the ICANN area of decision (and is quite influenced by GAC). Obviously ICANN is not going to wipe off or to create a country at whim. But there may be differences and delays. Let for example consider the EU case. Recently someone discussed the existence of European Greek vs. Greece and Cyprus Greeks. ICANN will give the possibility to document it: is that in line with your proposition. Pacific and Indian countries have asked similar extensions. What is the situation you want for PS? At the end of the day we will most probably get the same situation. But the WG-ltru is not the one in control or a second, linguistic, IANA version of ISO 3166 is to be created? Another point to consider. An IETF WG is charter oriented. When the Charter is completed, it is closed. My understanding is that the IESG has approved this WG for two tasks and a short duration. It can obviously be renewed. But I think we should not assumed it to be permanent - at least at this stage and without a proper guidance from the IESG. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 22:09:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05734; Sun, 13 Mar 2005 22:09:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAg1G-0002K3-6P; Sun, 13 Mar 2005 22:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfxR-0003Oi-6N; Sun, 13 Mar 2005 22:09:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfxO-0003Od-Tw for ltru@megatron.ietf.org; Sun, 13 Mar 2005 22:09:27 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05699 for ; Sun, 13 Mar 2005 22:09:24 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAfwP-0005Cc-Pf for ltru@lists.ietf.org; Mon, 14 Mar 2005 04:08:25 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 04:08:25 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 04:08:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Mar 2005 04:07:42 +0100 Organization: Lines: 15 Message-ID: <4234FFFE.3545@xyzzy.claranet.de> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> <4234E475.7046@xyzzy.claranet.de> <20050314022942.GJ2941@skunk.reutershealth.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.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit John Cowan wrote: > i-default means "the language readable to the most people", > typically English Yes, but if I use English in an implementation, for whatever reason, then why not say "en" in an enforced language tag ? In cases where "en" makes no sense I could still use "und". In other words, why not add this beast to chapter 2.3 (4) in the next draft ? The registry could reflect this with a comment "NOT RECOMMENDED" for "und", or "NOT RECOMMENDED, consider 'en' or 'und'" for "i-default". If somebody still insists on "i-default" he got at least a fair warning. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 22:12:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06413; Sun, 13 Mar 2005 22:12:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAg43-0002S9-Jp; Sun, 13 Mar 2005 22:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfza-0003h5-Ju; Sun, 13 Mar 2005 22:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAfzX-0003gO-Iq for ltru@megatron.ietf.org; Sun, 13 Mar 2005 22:11:40 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06291 for ; Sun, 13 Mar 2005 22:11:37 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050314031108.PAQO12278.mta9.adelphia.net@DEWELL>; Sun, 13 Mar 2005 22:11:08 -0500 Message-ID: <006201c52843$6b79ee40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) Date: Sun, 13 Mar 2005 19:10:47 -0800 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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > The IANA most known table, to the point to be referred worldwide as > "the IANA table" is the ccTLD table which documents the ICANN > understanding of ISO 3166. Also, as I understand the MoU between IANA, > IESG and ICANN this table is in the ICANN area of decision (and is > quite influenced by GAC). Obviously ICANN is not going to wipe off or > to create a country at whim. But there may be differences and delays. > Let for example consider the EU case. Recently someone discussed the > existence of European Greek vs. Greece and Cyprus Greeks. ICANN will > give the possibility to document it: is that in line with your > proposition. Pacific and Indian countries have asked similar > extensions. What is the situation you want for PS? I don't really care what ICANN does. If the ccTLD table "documents the ICANN understanding of ISO 3166," their understanding obviously leaves something to be desired. They have ccTLDs corresponding to the non-ISO 3166 codes AC, GG, IM, and JE, and they think the code for United Kingdom is UK instead of GB. ICANN doesn't need to "give [anyone] the possibility" to document the various flavors of Greek. You can write "el" or "el-GR" or "el-CY" or whatever, right now, according to RFC 3066 or even RFC 1766. I don't know what PS has to do with the rest of your paragraph, but ISO 3166 has assigned the code PS for "Palestinian Territory, Occupied" and that is what is relevant here. > At the end of the day we will most probably get the same situation. > But the WG-ltru is not the one in control or a second, linguistic, > IANA version of ISO 3166 is to be created? I have no idea what is being asked here. > Another point to consider. An IETF WG is charter oriented. When the > Charter is completed, it is closed. My understanding is that the IESG > has approved this WG for two tasks and a short duration. It can > obviously be renewed. But I think we should not assumed it to be > permanent - at least at this stage and without a proper guidance from > the IESG. I don't think anyone imagines this WG to be permanent. Both the charter and the current draft explain that the review function for new subtags will lie with the ietf-languages list and with the Language Subtag Reviewer. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 13 22:59:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09348; Sun, 13 Mar 2005 22:59:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAgnS-0003xE-A5; Sun, 13 Mar 2005 23:03:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAgjB-0007GU-3Y; Sun, 13 Mar 2005 22:58:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAgj7-0007GO-NB for ltru@megatron.ietf.org; Sun, 13 Mar 2005 22:58:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09217 for ; Sun, 13 Mar 2005 22:58:43 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAgme-0003vQ-TB for ltru@ietf.org; Sun, 13 Mar 2005 23:02:26 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2E3wZt5005833; Sun, 13 Mar 2005 22:58:35 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 13 Mar 2005 22:58:35 -0500 Date: Sun, 13 Mar 2005 22:58:34 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Update to proposed registry Message-ID: <20050314035834.GK2941@skunk.reutershealth.com> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> <4234E475.7046@xyzzy.claranet.de> <20050314022942.GJ2941@skunk.reutershealth.com> <4234FFFE.3545@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4234FFFE.3545@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Frank Ellermann scripsit: > Yes, but if I use English in an implementation, for whatever > reason, then why not say "en" in an enforced language tag ? RFC 2277 says in Section 4.5, Default Language: When human-readable text must be presented in a context where the sender has no knowledge of the recipient's language preferences (such as login failures or E-mailed warnings, or prior to language negotiation), text SHOULD be presented in Default Language. Default Language is assigned the tag "i-default" according to the procedures of RFC 1766. It is not a specific language, but rather identifies the condition where the language preferences of the user cannot be established. Messages in Default Language MUST be understandable by an English- speaking person, since English is the language which, worldwide, the greatest number of people will be able to get adequate help in interpreting when working with computers. Note that negotiating English is NOT the same as Default Language; Default Language is an emergency measure in otherwise unmanageable situations. In many cases, using only English text is reasonable; in some cases, the English text may be augumented by text in other languages. > In cases where "en" makes no sense I could still use "und". "Und" is consistent, e.g., with the text being in Comanche when the tagger doesn't know that. Neither "en" nor "i-default" is consistent with that. -- The Unicode Standard does not encode John Cowan idiosyncratic, personal, novel, or private http://www.ccil.org/~cowan use characters, nor does it encode logos http://www.reutershealth.com or graphics. jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 00:31:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19133; Mon, 14 Mar 2005 00:31:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAiEa-0007Mr-J8; Mon, 14 Mar 2005 00:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiAu-0007a3-98; Mon, 14 Mar 2005 00:31:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiAr-0007Zq-LM for ltru@megatron.ietf.org; Mon, 14 Mar 2005 00:31:30 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19129 for ; Mon, 14 Mar 2005 00:31:26 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAi9k-0006Rj-Cp for ltru@lists.ietf.org; Mon, 14 Mar 2005 06:30:20 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 06:30:20 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 06:30:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Mar 2005 06:29:02 +0100 Organization: Lines: 29 Message-ID: <4235211E.575F@xyzzy.claranet.de> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> <4234E475.7046@xyzzy.claranet.de> <20050314022942.GJ2941@skunk.reutershealth.com> <4234FFFE.3545@xyzzy.claranet.de> <20050314035834.GK2941@skunk.reutershealth.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.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit John Cowan wrote: [BCP 18] >| In many cases, using only English text is reasonable; in >| some cases, the English text may be augumented by text in >| other languages. [i-default vs. und] > "Und" is consistent, e.g., with the text being in Comanche > when the tagger doesn't know that. Neither "en" nor > "i-default" is consistent with that. Okay, maybe I've got it finally: "und" stands for "I have no clue, it could be Greek". For "i-default" I'd know what it is, it's something that makes sense at least for an "en"-audience. But it's not really "en", otherwise I could say so in the tag. And it's less than "mul", because it would always include "en" where "mul" could be anything. Maybe it's only an error number / sound / icon, or some words making sense in more than only English (stop / verboten / ...). Is that the idea ? A pointer to BCP 18 in the comment column for i-default could help. Or IANA should keep the existing i-files with the grandfathered details. IANA should also keep the details for all future registered variants, if they don't fit in the comments column of the future registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 00:49:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20650; Mon, 14 Mar 2005 00:49:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAiWD-00081a-9q; Mon, 14 Mar 2005 00:53:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiSO-0000Sv-Kb; Mon, 14 Mar 2005 00:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiSL-0000Sh-1r for ltru@megatron.ietf.org; Mon, 14 Mar 2005 00:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20626 for ; Mon, 14 Mar 2005 00:49:29 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAiVs-000817-IL for ltru@ietf.org; Mon, 14 Mar 2005 00:53:13 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 9A93E4EF9A; Mon, 14 Mar 2005 00:49:27 -0500 (EST) Message-Id: <6.0.0.20.2.20050314095058.0807f9d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 14 Mar 2005 10:15:51 +0900 To: "JFC (Jefsey) Morfin" , "Addison Phillips" From: Martin Duerst Subject: Re: [Ltru] Working Group submission: LTRU Registry Draft 00 In-Reply-To: <6.1.2.0.2.20050314000816.03fd0530@mail.jefsey.com> References: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.com> <6.1.2.0.2.20050314000816.03fd0530@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.7 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hello Jefsey, At 09:17 05/03/14, JFC (Jefsey) Morfin wrote: >I have asked guidance to several concerned parties to present a comment synthesis (I give time for responses - or for no-response freeing me). I also asked guidance to some WG-IDN members and other ccTLDs which could be of help towards a ccTLD BP IRT concerning the Unicode updates impact on IDNs. Please note that the IETF, and this WG, is an organization consisting of individuals. Any comment is welcome, but it is best if concerned individuals send these comments directly to our mailing list (and if they are concerned, of course the best thing to do is to become a member of the WG, which is open to any interested individual), rather than somebody trying to consolidate comments from various people. >So I do not think I can come with real comment on this draft before end of the week. The draft has not yet even officially been published, and I'm sure we'll give at least a week for the first rounds of comments. >I suggest that we stick to the charter for the time being That should go without saying. >(obviously we can propose more) and to the consistency with other RFCs (in particular to IANA ICANN IETF MoU). That would be http://www.ietf.org/rfc/rfc2860.txt, I guess. I'm unclear how this is relevant to the specific work items of the WG, except in a very general sense. >I would also suggest that we make sure Doug Barton is on this list? His guidance would be useful. If Doug had to be on every list that discussed some IANA-related issues, he'd probably not get any sleep. There are well-established ways for contacts between WGs and IANA, and we will use them when necessary. >The same for Harald as the RFC 3066 author (however he said he will be on vacation until May). I'm very sure Harald knows about this WG, and will subscribe to the mailing list if he wants to. >The move of the Drafts to an IETF WG was a first good normalization move. The second one should be the support of the ietf-languages@iana.org list by the IANA (host, archives, subscription page, etc.). Traditionally, all IETF-related mailing lists have been hosted by volunteers. The hosting of the ietf-languages@iana.org list is a support issue that should not concern this WG. What we need in our documents is the address of this mailing list, and this is already a IANA address, so we should be fine independently of where the list is actually hosted. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 00:53:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21054; Mon, 14 Mar 2005 00:53:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAiZw-000888-4Z; Mon, 14 Mar 2005 00:57:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiUv-0000yZ-US; Mon, 14 Mar 2005 00:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiUq-0000yR-QR for ltru@megatron.ietf.org; Mon, 14 Mar 2005 00:52:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20875 for ; Mon, 14 Mar 2005 00:52:05 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAiYP-00085H-VD for ltru@ietf.org; Mon, 14 Mar 2005 00:55:50 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2E5pxgO006394; Mon, 14 Mar 2005 00:51:59 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 14 Mar 2005 00:52:04 -0500 Date: Mon, 14 Mar 2005 00:52:04 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Update to proposed registry Message-ID: <20050314055204.GN2941@skunk.reutershealth.com> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> <4234E475.7046@xyzzy.claranet.de> <20050314022942.GJ2941@skunk.reutershealth.com> <4234FFFE.3545@xyzzy.claranet.de> <20050314035834.GK2941@skunk.reutershealth.com> <4235211E.575F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4235211E.575F@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Frank Ellermann scripsit: > Okay, maybe I've got it finally: "und" stands for "I have no > clue, it could be Greek". Yes, and the only reason to use it is when you MUST tag. If tagging is optional, then omitting a tag is better than using "und". > For "i-default" I'd know what it is, > it's something that makes sense at least for an "en"-audience. > > But it's not really "en", otherwise I could say so in the tag. > And it's less than "mul", because it would always include "en" > where "mul" could be anything. Correct. > Maybe it's only an error number / sound / icon, or some words > making sense in more than only English (stop / verboten / ...). Indeed. I note that STOP appears on many road signs even in non-anglophone countries, e.g. > Is that the idea ? A pointer to BCP 18 in the comment column > for i-default could help. Or IANA should keep the existing > i-files with the grandfathered details. IANA should also keep > the details for all future registered variants, if they don't > fit in the comments column of the future registry. Bye, Frank A good idea. -- How they ever reached any conclusion at all jcowan@reutershealth.com> is starkly unknowable to the human mind. http://www.reutershealth.com --"Backstage Lensman", Randall Garrett http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 00:57:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21340; Mon, 14 Mar 2005 00:57:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAidJ-0008II-8N; Mon, 14 Mar 2005 01:00:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiXu-0001NU-1T; Mon, 14 Mar 2005 00:55:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAiXs-0001NP-6e for ltru@megatron.ietf.org; Mon, 14 Mar 2005 00:55:16 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21222 for ; Mon, 14 Mar 2005 00:55:12 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050314055444.UIOT5402.mta11.adelphia.net@DEWELL>; Mon, 14 Mar 2005 00:54:44 -0500 Message-ID: <006f01c5285a$467704e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> Date: Sun, 13 Mar 2005 21:54:09 -0800 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 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> a fair and unbiased (I hope) set of pro and con arguments: > > Yes, within the constraints of the draft. It's a problem in > the design for some cases: > > 1 - Region known as XX splits into XX and YY, one part inherits > the CC. Old XX tags could be nonsense under the new XX, > example sl-YU > > 2 - Regions known as AA and BB join to a new AA, the union > inherits the CC of one of its former parts. The registry > still supports old BB tags, but there's no way to identify > old AA tags. Example: dsb-DD vs. fy-DE. > > 3 - Same case, the registry wouldn't identify AA as canonical > value for BB, beause it has not the same UN number. > Example: YD (720) plus YE (886) are now YE (887). Frank, I know you have additional problems with the use of ISO 3166-1 country codes in language tags. I did summarize each of them for the authors, each with its own set of pro and con arguments, and I can present those to the group if desired. I'd like to focus on one issue at a time here, and at the moment we were talking about setting a cutoff date to restrict the use of withdrawn country codes as region subtags. I'd also like to draw attention to the charter, which refers specifically to the goal of updating RFC 3066 within the general framework of RFC 3066. It does not provide for this group to overturn the basic principles of RFCs 1766 and 3066, which include the use of ISO 3166-1 country codes to narrow the scope of a language. Everyone agrees that there are drawbacks to using these codes, but they are entrenched in current usage, and they have mnemonic value (as you pointed out in your other arguments). It is not our mission to render untold numbers of existing language tags obsolete. There are several other issues that various people have had regarding language tags, which are also not within the scope of this group or its charter. I suspect these will come out before long. > 4 - Sometimes regions have an UN number and no CC, but one or > more ccTLDs. Examples: 830 (GG), 830 (JE), 833 (IM). Again, let me reiterate: ISO 3166-1 country codes used to qualify language tags are *not* the same as ccTLDs. They do not fulfill the same purpose. They should not be confused for one another. > Or the UN numbers are the solution, and ISO 3166 CCs and IANA > ccTLDs simply mean whatever they mean "now", allowing old CCs > in their old meaning temporarily (with a canonical UN number), > until they get a new meaning. Earlier, you stated that the old FQ should not be reserved in the language subtag registry, because if ISO 3166/MA ever reassigns FQ to a new country, its residents "will hate the obscure UN number and you." Now you say the numbers are better than the alpha-2 codes? Please, let's stick to the work at hand, which is to update and enhance RFC 3066, not to replace it with a new mechanism altogether. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 03:00:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23672; Mon, 14 Mar 2005 03:00:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAkYX-0004Sc-FH; Mon, 14 Mar 2005 03:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAkUJ-00011B-Fx; Mon, 14 Mar 2005 02:59:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAkUF-000113-Us for ltru@megatron.ietf.org; Mon, 14 Mar 2005 02:59:40 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23605 for ; Mon, 14 Mar 2005 02:59:38 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050314075908.PQIU4618.mta13.adelphia.net@DEWELL>; Mon, 14 Mar 2005 02:59:08 -0500 Message-ID: <00b901c5286b$afbc6ba0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> Date: Sun, 13 Mar 2005 23:59:01 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Update to proposed registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > I think we have several alternatives available for initializing the > registry: > 1) pointer to external file/web site (current proposal in > -registry-00.txt > 2) reference to WG internet-draft handed to IANA > 3) reference to WG RFC containing initial contents > 4) embed initialization data into appendix of registry document > > Did I miss some? My biggest concern about 2-4 is that the quirks > of i-d posting and rfc publication formats would require us to spend > time on aspects of registry entries that we might otherwise not > have to spend. I suppose I should clarify that I'm willing to bend and twist the proposed registry into pretty much any shape the WG desires. XML, comma-quote, Excel, Frank's tabular format, whatever. My main concern is the one Randy sort of alluded to, that we might get bogged down in the details of formatting when we have bigger issues to tackle. I should also point out that the format of the registry has been discussed before, on ietf-languages. The draft originally specified that the records were to be semicolon-delimited, but this posed a problem with ISO 639 descriptions which contained semicolons, such as "Catalan; Valencian". Although the descriptions are not normative, we didn't feel it was a great idea to modify or truncate them simply to fit the file format, and enclosing such names in quotes would have been heavier-weight than simply changing the file format to bar-delimited to avoid the problem. IIRC, we did briefly discuss XML, but I don't recall the details of that discussion. I guess the only reasonable plain-text format I would really object to is tab-delimited. Although some Unix developers are really fond of this format, it doesn't seem to hold up well in certain Internet and mail environments where tabs get expanded to spaces. This might be a major problem since the registry will be available online, and probably will be mirrored unofficially on numerous sites. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 03:13:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24955; Mon, 14 Mar 2005 03:13:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAklQ-0004wa-NM; Mon, 14 Mar 2005 03:17:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAkh0-0002Vd-Sn; Mon, 14 Mar 2005 03:12:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAkgx-0002RS-SW for ltru@megatron.ietf.org; Mon, 14 Mar 2005 03:12:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24880 for ; Mon, 14 Mar 2005 03:12:46 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAkkX-0004vf-C6 for ltru@ietf.org; Mon, 14 Mar 2005 03:16:30 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 082944EF9A; Mon, 14 Mar 2005 03:12:41 -0500 (EST) Message-Id: <6.0.0.20.2.20050314150239.08e90ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 14 Mar 2005 15:06:17 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Update to proposed registry In-Reply-To: <4234D598.895@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.com> <634978A7DF025A40BFEF33EB191E13BC0A924C35@irvmbxw01.quest.com> <6.0.0.20.2.20050314071105.081253f0@localhost> <4234D598.895@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit At 09:06 05/03/14, Frank Ellermann wrote: >Martin Duerst wrote: > >> Would that mean that we would change the registry format > >Not necessarily. With your hat on you could decree that >Doug is an ISO or W3C liaison, [with several hats on] A liaison always needs two sides. I have some hats on the W3C side, but I don't think I'd want to use them for that. While W3C is an important customer of IETF language tags, the IETF is in charge, and it would feel really weird to have something like "IETF approves new spec for language tag registry; initial registry data provided by W3C". Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 03:13:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24986; Mon, 14 Mar 2005 03:13:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAklf-0004wv-CS; Mon, 14 Mar 2005 03:17:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAkgt-0002RJ-Jl; Mon, 14 Mar 2005 03:12:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAkgs-0002RD-4D for ltru@megatron.ietf.org; Mon, 14 Mar 2005 03:12:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24875 for ; Mon, 14 Mar 2005 03:12:40 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAkkR-0004vY-Jx for ltru@ietf.org; Mon, 14 Mar 2005 03:16:24 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 22B244EF9A; Mon, 14 Mar 2005 03:12:38 -0500 (EST) Message-Id: <6.0.0.20.2.20050314145112.08dde470@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 14 Mar 2005 14:57:44 +0900 To: "Doug Ewell" , From: Martin Duerst Subject: Re: [Ltru] Re: Update to proposed registry In-Reply-To: <000801c5281f$45054e40$030aa8c0@DEWELL> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit At 07:52 05/03/14, Doug Ewell wrote: >Randy Presuhn wrote: >> In any case, if the updated registry would contain >> information that cannot be derived algorithmically from the current >> registry contents, we *somehow* would have to provide that information >> to IANA, whether in the registry document itself or in a new companion >> document. Ideas? > >We do. At least 98% of the PDR can be derived algorithmically from the >core ISO standards, their history pages, and the current registry -- you >would need all of these -- but there might be some surprises that need >explanation. Perhaps it should be a new Appendix D to >draft-ietf-ltru-registry, rather than a new companion document. If we are already at 98%, how much more effort would it be to reach 100%? If it is reasonably easy to reach 100%, I think we should try to reach it. This would change the initial registry from "a separate document approved by the WG and handed over by the chairs to IANA (or whatever other process details we choose)" to essentially be approved by the IESG based on IETF consensus. We could still actually hand over the actual document to the IANA, but anybody could veryfy that it's just an embodiment of what the registry draft/rfc says. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 03:39:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27315; Mon, 14 Mar 2005 03:39:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAlA1-00060c-OQ; Mon, 14 Mar 2005 03:42:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAl5Y-0005TN-KC; Mon, 14 Mar 2005 03:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAl5X-0005TI-17 for ltru@megatron.ietf.org; Mon, 14 Mar 2005 03:38:11 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27277 for ; Mon, 14 Mar 2005 03:38:08 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DAl4T-0003cY-E9 for ltru@lists.ietf.org; Mon, 14 Mar 2005 09:37:05 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 09:37:05 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2005 09:37:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 14 Mar 2005 09:33:23 +0100 Organization: Lines: 75 Message-ID: <42354C53.D98@xyzzy.claranet.de> References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> <006f01c5285a$467704e0$030aa8c0@DEWELL> 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.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I'd like to focus on one issue at a time here, and at the > moment we were talking about setting a cutoff date to > restrict the use of withdrawn country codes as region > subtags. Okay, we can discuss it in this order, but we can also discuss it simultaneously. The cutoff date could solve most immediate problems, but not the general problem. So if we'd decide that there is a general problem _and_ fix it somehow, then we would not need to discuss a cutoff date. > I'd also like to draw attention to the charter, which refers > specifically to the goal of updating RFC 3066 within the > general framework of RFC 3066. It apparently allows to keep the 1766 / 3066 idea as is, which is by definition backwards compatible, and to use UN M 49 codes for persistent tags. I could use en-GB for something that is at least valid for one day plus five years - the old ISO 3166 grace period, but you said that they plan to extend this to 50 years, and of course GB won't cease to exist tomorrow. I could also use en-826 when en-GB isn't stable enough for my purposes. If it's against the charter of this WG to discuss this idea, then I'm really lost and probably wasting our time. > It is not our mission to render untold numbers of existing > language tags obsolete. Sure, but existing 3066 and future 3066bis tags could coexist. If en-833 is allowed (actual draft) and doesn't cause havoc for existing 3066 implementations, then the same would be true for en-826. And en-GB could stay what it always was, no absolutely guaranteed persistence, but good enough as long as GB is a country code plus 5 or plus 50 years, whatever ISO decides. Plus the time until they really decide to recycle it for some new GB. Most probably the meaning of "en" is so far from today's "en" if and when that happens, that the stability of GB in an old en-GB is the least problem with this tag. > Again, let me reiterate: ISO 3166-1 country codes used to > qualify language tags are *not* the same as ccTLDs. They do > not fulfill the same purpose. Yes, they are not exactly the same, but the differences are limited to a few odd cases. And we're talking about a future IANA registry here, they already have a registry for ccTLDs based on ISO 3166. I trust that IANA gets it right no matter what ISO 3166 does. And I'm convinced that normal Internet users will try to use their ccTLD in language tags no matter what RfC 3066bis says. Why not sanction this expected behaviour instead of trying to forbid it ? > Now you say the numbers are better than the alpha-2 codes? It's an idea to support stable tags with numbers and less than perfect ccTLD tags in the same draft simultaneously. With full backwards compatibility for all tags valid when RfC 1766 was published, but without guaranteed stability. For guaranteed stability 3066bis could offer the UN M 49 numbers as a feature. This could solve all remaining problems I had with draft 10. No ??-FQ or ???-FQ tags exist today, and when FQ is introduced it would be what the users expect it to be in a language tag of their century. Or their millennium in the case of a future FQ. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 08:38:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29910; Mon, 14 Mar 2005 08:38:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAppw-0001x8-Qp; Mon, 14 Mar 2005 08:42:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAplV-0004iy-Vi; Mon, 14 Mar 2005 08:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAplU-0004ik-B0 for ltru@megatron.ietf.org; Mon, 14 Mar 2005 08:37:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29729 for ; Mon, 14 Mar 2005 08:37:46 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApp6-0001nf-FP for ltru@ietf.org; Mon, 14 Mar 2005 08:41:33 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2EDbS4m009805; Mon, 14 Mar 2005 08:37:28 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 14 Mar 2005 08:37:40 -0500 Date: Mon, 14 Mar 2005 08:37:40 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Update to proposed registry Message-ID: <20050314133740.GA20009@skunk.reutershealth.com> References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> <00b901c5286b$afbc6ba0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b901c5286b$afbc6ba0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Doug Ewell scripsit: > I suppose I should clarify that I'm willing to bend and twist the > proposed registry into pretty much any shape the WG desires. XML, > comma-quote, Excel, Frank's tabular format, whatever. "Record-jar" format as described at http://www.catb.org/~esr/writings/taoup/html/ch05s02.html#id2906931 might be a good choice. Essentially, it uses RFC 2822 style headers (with foldable whitespace) for each entry in the registry, and a line containing "%" (more robust than a blank line) to separate entries. It allows fairly arbitrary data in a tall and narrow layout. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like jcowan@reutershealth.com ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 08:47:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01024; Mon, 14 Mar 2005 08:47:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApyf-0002NT-7u; Mon, 14 Mar 2005 08:51:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApuy-0007eE-QV; Mon, 14 Mar 2005 08:47:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DApuu-0007e3-4q for ltru@megatron.ietf.org; Mon, 14 Mar 2005 08:47:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01015 for ; Mon, 14 Mar 2005 08:47:30 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DApyX-0002Ko-Gb for ltru@ietf.org; Mon, 14 Mar 2005 08:51:17 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2EDlMdD009882; Mon, 14 Mar 2005 08:47:22 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 14 Mar 2005 08:47:34 -0500 Date: Mon, 14 Mar 2005 08:47:34 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: "Obsolete" region subtags Message-ID: <20050314134734.GB20009@skunk.reutershealth.com> References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> <006f01c5285a$467704e0$030aa8c0@DEWELL> <42354C53.D98@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42354C53.D98@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Frank Ellermann scripsit: > It apparently allows to keep the 1766 / 3066 idea as is, which > is by definition backwards compatible, and to use UN M 49 codes > for persistent tags. I could use en-GB for something that is > at least valid for one day plus five years - the old ISO 3166 > grace period, but you said that they plan to extend this to 50 > years, and of course GB won't cease to exist tomorrow. > > I could also use en-826 when en-GB isn't stable enough for my > purposes. We don't want to allow both en-GB and en-826 at the same time. That would be very bad for interoperability. Indeed, the latter would never become valid, even if the ISO 3166 MA were to reassign "GB". > If en-833 is allowed (actual draft) and doesn't cause havoc for > existing 3066 implementations, then the same would be true for > en-826. Syntactically speaking, yes. Semantically, it would be a disaster. The reason en-833 is not a problem is that it refers to a variety variety of English that is geographically restricted in a way that does not correspond to any ISO 3166 code. > Yes, they are not exactly the same, but the differences are > limited to a few odd cases. And we're talking about a future > IANA registry here, they already have a registry for ccTLDs > based on ISO 3166. I trust that IANA gets it right no matter > what ISO 3166 does. Historically IANA has slavishly followed the whims of the ISO 3166 MA. > And I'm convinced that normal Internet users will try to use > their ccTLD in language tags no matter what RfC 3066bis says. > Why not sanction this expected behaviour instead of trying to > forbid it ? Because it's wrong and not backward compatible. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 10:04:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09584; Mon, 14 Mar 2005 10:04:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArAw-0005wT-M4; Mon, 14 Mar 2005 10:08:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAr5E-0007qq-Ja; Mon, 14 Mar 2005 10:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAr5D-0007qf-3Y for ltru@megatron.ietf.org; Mon, 14 Mar 2005 10:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09341 for ; Mon, 14 Mar 2005 10:02:12 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAr8q-0005rs-RW for ltru@ietf.org; Mon, 14 Mar 2005 10:06:01 -0500 Received: from lns-p19-19-idf-82-65-139-89.adsl.proxad.net ([82.65.139.89] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DAr55-0001Wt-Vm; Mon, 14 Mar 2005 07:02:08 -0800 Message-Id: <6.1.2.0.2.20050314113456.03fbf070@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 14 Mar 2005 16:02:00 +0100 To: John Cowan , Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Update to proposed registry In-Reply-To: <20050314035834.GK2941@skunk.reutershealth.com> References: <20050313170246.JSBJ2135.mta4.adelphia.net@megatron.ietf.org> <000801c5281f$45054e40$030aa8c0@DEWELL> <4234E475.7046@xyzzy.claranet.de> <20050314022942.GJ2941@skunk.reutershealth.com> <4234FFFE.3545@xyzzy.claranet.de> <20050314035834.GK2941@skunk.reutershealth.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b I note this quoted RFC 2277 paragraph is inconsistent on the "English" issue. At 04:58 14/03/2005, John Cowan wrote: > Messages in Default Language MUST be understandable by an English- > speaking person, This is consistent with current international and industry practice which is the use of Basic English that obviously every English person will understand. > since English is the language which, worldwide, the > greatest number of people will be able to get adequate help in > interpreting when working with computers. This is uncorrect. My Franglish shows it. The language the greatest number of persons working with computers will be able to interpret is Basic English. As far as I remember from long ago Boeing Basic English uses 800 terms and Airbus 400. Oxford or Harvard English will be of no use to programers or users. A common example is "depress the A key" is perfect ununderstable English to a user. "Hit the A key" is. I note that (at least a decade ago) DoD RFPs required text documentations to match grade tests. A kid of a given grade was to be able to understand the text: a program made available by various US Agencies and private firms permited to run the test. There should be a way to describe these different English langagues. > Note that negotiating English is NOT the same as Default Language; > Default Language is an emergency measure in otherwise unmanageable > situations. > > In many cases, using only English text is reasonable; in some cases, > the English text may be augumented by text in other languages. I suggest that an RFC considers the definition of a IANA Basic English and of an international code consistency. For example, I note that "xn" (the header of ACE labels produced by punycode) is the standard European code for "danger" and a promotion for XN Inc. the leading insurrance company for expatriated persons. It is also commonly understood as "Christians" and in some readings as "xenophobe", different understandings which are not appropriate with the signaling of an international transcoding of a local language. Such an RFC could also address the issue of the language Icons in an ISO 7000 consistent way. jfc ===================================================== For your convenience: Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 10:05:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09780; Mon, 14 Mar 2005 10:05:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArBo-0005yz-2D; Mon, 14 Mar 2005 10:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAr5E-0007qu-O4; Mon, 14 Mar 2005 10:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAr5D-0007qk-Md for ltru@megatron.ietf.org; Mon, 14 Mar 2005 10:02:15 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09344 for ; Mon, 14 Mar 2005 10:02:13 -0500 (EST) Received: from lns-p19-19-idf-82-65-139-89.adsl.proxad.net ([82.65.139.89] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DAr57-0001Wt-7W; Mon, 14 Mar 2005 07:02:14 -0800 Message-Id: <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 14 Mar 2005 12:59:12 +0100 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) In-Reply-To: <006201c52843$6b79ee40$030aa8c0@DEWELL> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede At 04:10 14/03/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: >I don't really care what ICANN does. Such a lack of care is not appropriate to the current debate. IANA is to conform to the requirements of this WG only pursuing to the terms of the ICANN, IETF, IANA MoU (RFC 2860). For a given period of time, ICANN and IANA present the IANA as an ICANN function, so ICANN is actually implied twice. This WG Charter does not include a rewrite of this MoU so we have to care about what ICANN does, if only to make sure there is no problem. I call your attention on the part 4 of this MoU and on the possibility of ICANN to be confronted to a conflicting position paper or for its BoD to take a position on this issue. The last thing this WG should want is to face a latter change in the understanding of one of the three used tables. I note that my position is exactly described in your "And I'm convinced that normal Internet users will try to use their ccTLD in language tags no matter what RfC 3066bis says. Why not sanction this expected behavior instead of trying to forbid it ?". >If the ccTLD table "documents the ICANN understanding of ISO 3166," their >understanding obviously leaves something to be desired. They have ccTLDs >corresponding to the non-ISO 3166 codes AC, GG, IM, and JE, and they think >the code for United Kingdom is UK instead of GB. As you may know, ICANN is advised by the GAC which gathers the documented entities (States). If you notice a discrepancy with ISO 3166 which is also sponsored by the same States, I suggest you bring the problem where it really belongs: to the UN General Assembly. This is precisely because a certain number of problems of same level have been identified that 192 chiefs of States and States delegations have unanimously voted that a report on these issues be presented to the General Secretary. This process is currently underway through the WGIG and everyone can contribute. I think this concern is of real importance and justifies a report. I planed to prepare it through a workshop I organize on this issue in June (during the EUGENI meeting where most of the concerned organizations and committees representatives will be present) after a preparation process which I started at the Paris ISO meeting in August. - I have no problem to invite you (or any other one from the ltru list) among my guest speakers (one slot on the 3 or 4 planned slots). - we can certainly send an earlier letter to Mr. Khummer and to the WGIG to call their attention on the issue. > > But the WG-ltru is not the one in control or a second, linguistic, > > IANA version of ISO 3166 is to be created? > >I have no idea what is being asked here. Exactly what you say: "the differences are limited to a few odd cases. And we're talking about a future IANA registry here, they already have a registry for ccTLDs based on ISO 3166. I trust that IANA gets it right no matter what ISO 3166 does". This WG can propose a second IANA reading of the ISO 3166. - one by ICANN as part of its reserved name/numbering area - one by no-one yet defined to be maintained for the W3C languages needs But we have to be aware that would probably open the way to other lists better satisfying other needs. This conflicts with the RFC 1958 suggestion to strive for one single commonly used solution when possible. > > Another point to consider. An IETF WG is charter oriented. When the > > Charter is completed, it is closed. My understanding is that the IESG > > has approved this WG for two tasks and a short duration. It can > > obviously be renewed. But I think we should not assumed it to be > > permanent - at least at this stage and without a proper guidance from > > the IESG. > >I don't think anyone imagines this WG to be permanent. Glad you agree. >Both the charter and the crrent draft explain that the review function for >new subtags will lie with the ietf-languages list and with the Language >Subtag Reviewer. The ietf-languages@iana.org is chartered to review language tags, not to review the IANA understanding of ISO tables. This is why I asked for a permanent WG-Tags, tagging is not a need limited to languages and just now. But better to start with something. jfc ===================================================== For your convenience: Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 11:58:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22639; Mon, 14 Mar 2005 11:58:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAsxX-0002R8-HV; Mon, 14 Mar 2005 12:02:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsr0-0001Kv-Bp; Mon, 14 Mar 2005 11:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAsqy-0001Km-Rt for ltru@megatron.ietf.org; Mon, 14 Mar 2005 11:55:40 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22362 for ; Mon, 14 Mar 2005 11:55:37 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050314165506.OEPW12278.mta9.adelphia.net@DEWELL>; Mon, 14 Mar 2005 11:55:06 -0500 Message-ID: <0e1901c528b6$822be1c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) Date: Mon, 14 Mar 2005 08:54:36 -0800 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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> I don't really care what ICANN does. > > Such a lack of care is not appropriate to the current debate. I don't care what ICANN does with respect to its interpretation of ISO 3166 country codes as ccTLDs. They have interpreted them in their own way (adding a few codes and changing one), and that is fine for them. UN/ECE has interpreted them in their own way for use in UN/LOCODE (semi-standardizing the private-use code ZX for offshore installations), and that is fine for them. Country codes in language tags are not ccTLDs. The parties responsible for ccTLD administration do not influence the use of country codes in language tags. > IANA is to conform to the requirements of this WG only pursuing to the > terms of the ICANN, IETF, IANA MoU (RFC 2860). For a given period of > time, ICANN and IANA present the IANA as an ICANN function, so ICANN > is actually implied twice. This WG Charter does not include a rewrite > of this MoU so we have to care about what ICANN does, if only to make > sure there is no problem. > > I call your attention on the part 4 of this MoU and on the possibility > of ICANN to be confronted to a conflicting position paper or for its > BoD to take a position on this issue. The last thing this WG should > want is to face a latter change in the understanding of one of the > three used tables. Section 4.1 of RFC 2860 says that it is absolutely within the scope of IANA to maintain a registry of language tags, or subtags, as long as there is an RFC calling for them to do so. Did you have another point? > I note that my position is exactly described in your "And I'm > convinced that normal Internet users will try to use their ccTLD in > language tags no matter what RfC 3066bis says. Why not sanction this > expected behavior instead of trying to forbid it ?". I didn't write that, and I don't agree with it. Frank Ellermann wrote it. (The German-style lowercase f in "RfC" is a good clue.) >> If the ccTLD table "documents the ICANN understanding of ISO 3166," >> their understanding obviously leaves something to be desired. They >> have ccTLDs corresponding to the non-ISO 3166 codes AC, GG, IM, and >> JE, and they think the code for United Kingdom is UK instead of GB. > > As you may know, ICANN is advised by the GAC which gathers the > documented entities (States). If you notice a discrepancy with ISO > 3166 which is also sponsored by the same States, I suggest you bring > the problem where it really belongs: to the UN General Assembly. This > is precisely because a certain number of problems of same level have > been identified that 192 chiefs of States and States delegations have > unanimously voted that a report on these issues be presented to the > General Secretary. This process is currently underway through the WGIG > and everyone can contribute. That's nice, but I really don't care how ICANN or IANA chooses to use ISO 3166 for the purpose of allocating ccTLDs. It has no bearing on language tags. >>> But the WG-ltru is not the one in control or a second, linguistic, >>> IANA version of ISO 3166 is to be created? >> >> I have no idea what is being asked here. > > Exactly what you say: "the differences are limited to a few odd cases. > And we're talking about a future IANA registry here, they already have > a registry for ccTLDs based on ISO 3166. I trust that IANA gets it > right no matter what ISO 3166 does". That doesn't sound like me either. Did I write that? > This WG can propose a second IANA reading of the ISO 3166. > - one by ICANN as part of its reserved name/numbering area > - one by no-one yet defined to be maintained for the W3C languages > needs > > But we have to be aware that would probably open the way to other > lists better satisfying other needs. This conflicts with the RFC 1958 > suggestion to strive for one single commonly used solution when > possible. RFC 1958 does not say that one solution has to fit all conceivable problems. There is a long, established history of using ISO 3166 codes (a) for ccTLDs, (b) in language tags, (c) in locale identifiers, and (d) in other standards and protocols as well. None of these usages trumps any other. > The ietf-languages@iana.org is chartered to review language tags, not > to review the IANA understanding of ISO tables. This is why I asked > for a permanent WG-Tags, tagging is not a need limited to languages > and just now. But better to start with something. Two types of subtag requests will be considered by ietf-languages and approved by the Language Subtag Reviewer: - those invented by an individual or group - those based on updates to ISO 639, 3166, or 15924 In the latter case, nobody is asking ietf-languages to "review the IANA understanding of ISO tables." The ISO updates will be added *almost* automatically to the registry. The only exceptions, described carefully in the draft, are when ISO codes conflict with something already in the registry. No philosophical judgments are required. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 12:29:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26001; Mon, 14 Mar 2005 12:29:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAtRo-0003te-8x; Mon, 14 Mar 2005 12:33:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAtNZ-0007md-Gp; Mon, 14 Mar 2005 12:29:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAtNY-0007mY-2o for ltru@megatron.ietf.org; Mon, 14 Mar 2005 12:29:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25946 for ; Mon, 14 Mar 2005 12:29:16 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAtRA-0003p1-SQ for ltru@ietf.org; Mon, 14 Mar 2005 12:33:07 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Mar 2005 09:28:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Update to proposed registry Date: Mon, 14 Mar 2005 09:28:58 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A924F53@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Update to proposed registry Thread-Index: AcUoHW++66TasznKSw67ek4TrtEtYwAnFthQ From: "Addison Phillips" To: "Martin Duerst" , "Frank Ellermann" , , "Doug Ewell" X-OriginalArrivalTime: 14 Mar 2005 17:28:59.0407 (UTC) FILETIME=[4EAFD9F0:01C528BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Elision as necessary in a response to Martin below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Martin Duerst [mailto:duerst@w3.org] > Sent: Sunday, March 13, 2005 2:33 PM >=20 > >2. NOT make the draft registry into a version controlled document = until > the > >IESG approves the registry draft. Changes in the registry draft have = an > >effect on the format and contents of the registry itself. Save doing > >version control on the document until its own approval process = starts. >=20 > With my chairs hat off: >=20 > Are you suggesting that we publish the draft registry as an internet > draft (which we might call draft-ietf-ltru-initial or draft-ietf-ltru- > populate), > but we only publish the -00.txt version when draft-ietf-ltru-registry > has been approved? [Addison Phillips]=20 No. My understanding of Randy's message was that he wanted the registry = to be versioned and hosted by the IETF. I'm explicitly suggesting that = we not place the registry under version control until the document that = controls the format (the registry I-D) is finalized. Maintaining a = shadow registry in the meantime is a good idea: the details that we work = out in debating its content should be recorded and memorialized in the = registry draft (which contains the rules for populating the registry, = after all). IOW, don't rely on the registry to memorialize why it = contains what it contains.=20 >=20 > In general, developping things in sync seems a better idea. I.e. if > we would do it as an internet draft, the ideal would be that > draft-ietf-ltru-initial would be published just a day or two after > each publication of draft-ietf-ltru-registry. [Addison Phillips]=20 Yes, exactly so. And that would be "draft-initial-00". >=20 > >3. DO figure out how to do it under the auspices of the IETF and RFC > 2616 > >(if applicable) or in line with what others have done (if not). >=20 > With my chairs hat on: >=20 > I don't think there is any question about the fact that this should > be done under the auspices of the IETF. But we have to find out what > that means, and how it can be done best. [Addison Phillips]=20 The "if not" was meant to apply to RFC 2616, not the IETF. I agree that = this is an all-IETF effort. The question is whether the draft registry = is an I-D or just a document. Personally, I think torturing the thing to = be an I-D is a waste of time. The registry draft defines the registry = just fine. It should be possible to point to every entry in the initial = registry and say why it is there (from text in the registry I-D). If = subsequent to the registry I-D's adoption, there is objection to = something that was defined by the rules in the registry I-D and we = change it.... that suggests changing the new RFC. Which is messy. >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 14:48:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12328; Mon, 14 Mar 2005 14:48:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAvbk-0001hF-QI; Mon, 14 Mar 2005 14:52:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAvXB-0005VD-Tj; Mon, 14 Mar 2005 14:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAvXA-0005V1-EQ for ltru@megatron.ietf.org; Mon, 14 Mar 2005 14:47:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12271 for ; Mon, 14 Mar 2005 14:47:22 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAvap-0001bq-RT for ltru@ietf.org; Mon, 14 Mar 2005 14:51:13 -0500 Received: from h-64-105-34-21.snvacaid.dynamic.covad.net ([64.105.34.21] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DAvX4-0006GG-00 for ltru@ietf.org; Mon, 14 Mar 2005 11:47:18 -0800 Message-ID: <00f401c528ce$afc626a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> <006f01c5285a$467704e0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: "Obsolete" region subtags Date: Mon, 14 Mar 2005 11:47:42 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - (co-chair hat ON) > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "Frank Ellermann" > Sent: Sunday, March 13, 2005 9:54 PM > Subject: [Ltru] Re: "Obsolete" region subtags ... > Frank, I know you have additional problems with the use of ISO 3166-1 > country codes in language tags. I did summarize each of them for the > authors, each with its own set of pro and con arguments, and I can > present those to the group if desired. ... Let's keep technical discussions (within the scope of our charter) on the WG mailing list. In particular, since Addison Phillips and Mark Davis are serving as *editors* of the registry i-d, they now take their direction from the WG, even as we recognize their contribution as authors of the material that went into that -00 version, and as contributors to the technical discussion. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 15:24:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17266; Mon, 14 Mar 2005 15:24:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwAW-0003Cs-PZ; Mon, 14 Mar 2005 15:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAw63-0001AH-IV; Mon, 14 Mar 2005 15:23:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAw62-00019i-4n for ltru@megatron.ietf.org; Mon, 14 Mar 2005 15:23:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17020 for ; Mon, 14 Mar 2005 15:23:24 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAw9i-0003AU-OA for ltru@ietf.org; Mon, 14 Mar 2005 15:27:15 -0500 Received: from h-64-105-34-21.snvacaid.dynamic.covad.net ([64.105.34.21] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DAw5z-0004qC-00 for ltru@ietf.org; Mon, 14 Mar 2005 12:23:23 -0800 Message-ID: <010301c528d3$ba36ef20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org><002701c52833$a99cdd00$030aa8c0@DEWELL><6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com><006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) Date: Mon, 14 Mar 2005 12:23:47 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi - > From: "JFC (Jefsey) Morfin" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Monday, March 14, 2005 3:59 AM > Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) ... > IANA is to conform to the requirements of this WG only pursuing to the > terms of the ICANN, IETF, IANA MoU (RFC 2860). For a given period of time, > ICANN and IANA present the IANA as an ICANN function, so ICANN is actually > implied twice. This WG Charter does not include a rewrite of this MoU so we > have to care about what ICANN does, if only to make sure there is no problem. > > I call your attention on the part 4 of this MoU and on the possibility of > ICANN to be confronted to a conflicting position paper or for its BoD to > take a position on this issue. The last thing this WG should want is to > face a latter change in the understanding of one of the three used tables. ... I really don't see how this is relevant to this WG. The material cited applies to the discovery of technical conflicts in the instructions given IANA for the operation of a given registry. As long as we provide a non-contradictory spec for the one registry we are chartered to describe, the cited procedures will not be invoked. The fact that parts of some tags may have bit patterns which might also appear in some other registries is merely a coincidence, as far as IANA would be concerned, and causes no conflict that would require invocation of RFC 2860. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 18:34:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06755; Mon, 14 Mar 2005 18:34:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAz8Z-0003rv-Sn; Mon, 14 Mar 2005 18:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAz3n-0004Hj-RU; Mon, 14 Mar 2005 18:33:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAz3l-0004C8-Ml for ltru@megatron.ietf.org; Mon, 14 Mar 2005 18:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06396 for ; Mon, 14 Mar 2005 18:33:14 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAz7T-0003kP-RE for ltru@ietf.org; Mon, 14 Mar 2005 18:37:08 -0500 Received: from lns-p19-8-idf-82-249-14-208.adsl.proxad.net ([82.249.14.208] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DAz3i-0003Bu-4Z; Mon, 14 Mar 2005 15:33:15 -0800 Message-Id: <6.1.2.0.2.20050314130922.0317a8e0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 14 Mar 2005 13:39:41 +0100 To: Martin Duerst From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Working Group submission: LTRU Registry Draft 00 In-Reply-To: <6.0.0.20.2.20050314095058.0807f9d0@localhost> References: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.com> <6.1.2.0.2.20050314000816.03fd0530@mail.jefsey.com> <6.0.0.20.2.20050314095058.0807f9d0@localhost> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.6 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc At 02:15 14/03/2005, Martin Duerst wrote: >Hello Jefsey, > >At 09:17 05/03/14, JFC (Jefsey) Morfin wrote: > > >I have asked guidance to several concerned parties to present a comment > synthesis (I give time for responses - or for no-response freeing me). I > also asked guidance to some WG-IDN members and other ccTLDs which could > be of help towards a ccTLD BP IRT concerning the Unicode updates impact > on IDNs. > >Please note that the IETF, and this WG, is an organization consisting >of individuals. Any comment is welcome, but it is best if concerned >individuals send these comments directly to our mailing list (and if >they are concerned, of course the best thing to do is to become >a member of the WG, which is open to any interested individual), >rather than somebody trying to consolidate comments from various people. Full agreement. But it is not my decision if my members, other organization or SG chairs, governement representatives, etc. want or do not want to participate to this WG. You will note that the signature I adopted is an incitation to do so. But this recognition/exposure process should be a common work and attitude. But there are different objections such as: - I am their rep for that. They do not necessarily want to bear the ad hominem I must support. - they do not know IETF and the workload is too heavy. Most say "no to", "yes to". They are not interested in details. - the language divide - some cultural visions (economical, political, societal...) would be disruptive in this process and are not advisable. - many think ISO, ITU, MINC, ETSI, etc. are better suited for the task. The IAB documented (RFC 3869) its lack of interest in multilingualism. The IESG Charter is perceived as not adequate. W3C is not an open body. IETF has ne feed back from market. etc. etc. These are real world oppositions we have to live with. At the end of the day they will make the decision through usage. If it is against the IETF proposed solution, IETF will only have introduced confusion. For many the IETF trust factor is very low after IDNA. > >So I do not think I can come with real comment on this draft before end > of the week. > >The draft has not yet even officially been published, and I'm sure >we'll give at least a week for the first rounds of comments. > > >I suggest that we stick to the charter for the time being > >That should go without saying. > > >(obviously we can propose more) and to the consistency with other RFCs > (in particular to IANA ICANN IETF MoU). > >That would be http://www.ietf.org/rfc/rfc2860.txt, I guess. >I'm unclear how this is relevant to the specific work items of >the WG, except in a very general sense. I responded Doug on this issue. > >I would also suggest that we make sure Doug Barton is on this list? His > guidance would be useful. > >If Doug had to be on every list that discussed some IANA-related issues, >he'd probably not get any sleep. There are well-established ways for >contacts between WGs and IANA, and we will use them when necessary. This may represent a serious waste of time and effort if all the concerned parties are not aware at the earliest of the problems their own procedure and obligations may represent for each others. The lingual issue is central to the whole Internet deployement and intergovernance and subject to many controversies while IETF/IESG/IAB is not much at ease with it. The last thing we want is that we establish a practice which will be further contradicted. Again, one IDNA is enough. > >The same for Harald as the RFC 3066 author (however he said he will be > on vacation until May). > >I'm very sure Harald knows about this WG, and will subscribe to the >mailing list if he wants to. > > >The move of the Drafts to an IETF WG was a first good normalization > move. The second one should be the support of the ietf-languages@iana.org > list by the IANA (host, archives, subscription page, etc.). > >Traditionally, all IETF-related mailing lists have been hosted by >volunteers. The hosting of the ietf-languages@iana.org list is a >support issue that should not concern this WG. What we need >in our documents is the address of this mailing list, and this is >already a IANA address, so we should be fine independently of where >the list is actually hosted. No. RFC 2860 says differently. However I may be wrong: can you give me the http://iana.org/xxxx page to subscribe to the ietf-languages@iana.org list and to get its archives? As you know, according the IETF, the Internet is the adherence to the Internet documents and procedures produced by the Internet standard process. Such an adherence depend on the support brought by the concerned parties to their writing. Again IDNA, RFC 3869, RFC 3066 bis Last Calls, ietf-languages debates are not really motivating, at least we must show a good and documented interface demonstrating a clear commitment (look at the difference between the ICANN IDNA page and the IANA related pages). The intelligent bootstrap and C-activity concepts which root the RFC process do not scale well (http://bootstrap.org). I know: there are 20 years this year I face their limitations. :-) All the best. jfc ===================================================== For your convenience: Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 20:03:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14855; Mon, 14 Mar 2005 20:03:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB0Wr-0007zU-Kd; Mon, 14 Mar 2005 20:07:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB0RU-0004l7-0l; Mon, 14 Mar 2005 20:01:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB0RT-0004kq-8t for ltru@megatron.ietf.org; Mon, 14 Mar 2005 20:01:51 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14692 for ; Mon, 14 Mar 2005 20:01:47 -0500 (EST) Received: from lns-p19-8-idf-82-249-14-208.adsl.proxad.net ([82.249.14.208] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DB0RR-0006LU-8B; Mon, 14 Mar 2005 17:01:49 -0800 Message-Id: <6.1.2.0.2.20050314224257.0399eeb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 15 Mar 2005 02:01:40 +0100 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] "Obsolete" region subtags (was: Re: Update to proposed registry) In-Reply-To: <010301c528d3$ba36ef20$7f1afea9@oemcomputer> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <010301c528d3$ba36ef20$7f1afea9@oemcomputer> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On 21:23 14/03/2005, Randy Presuhn said: >I really don't see how this is relevant to this WG. The material cited >applies >to the discovery of technical conflicts in the instructions given IANA for the >operation of a given registry. As long as we provide a non-contradictory spec >for the one registry we are chartered to describe, the cited procedures >will not be invoked. The fact that parts of some tags may have bit patterns >which might also appear in some other registries is merely a coincidence, >as far >as IANA would be concerned, and causes no conflict that would require >invocation of RFC 2860. Dear Randy, I would not like to harp again and again on the same issue (I fully responded already to Martin) wich is the difference between a work among a few people and RFCs and the real world which is a little larger and more complex and where no one really knows RFCs (so many of them). I fully understand the interest of some coordination between Unicode, W3C, etc. and the political interest to use the simple and central Internet standard process for that. But please think of this: what is the use for the CLDR project to build a coordinated set of cross references, and to be blocked at some later stage by the blunt political "no" I fear. I am into this for 27 years. Your effort could be very beneficial if caried well or very detrimental otherwise: I have not made my mind yet about it. I am not opposed to your quick march, but the risk of mission creep and the political oppositions are important and I do not feel you really considered them all. An RFC is not a standard. A poor RFC as a BCP 047 replacement could kill everything. So, for the time being, please let us stick to the charter. The charter does not say that this WG is to define countries independently from ICANN, that is from GAC, that is from their own State. Let stick to KISS. This process is on the language identification and internationalization layers. You may not share my layered analysis of the Multilingual Internet, but these layers do exist and if you venture into Country and Language definition you will be blocked sometime. IMHO all this needs adherence. I do not see it yet. Let build it together. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 20:12:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15767; Mon, 14 Mar 2005 20:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB0fQ-0008MC-AR; Mon, 14 Mar 2005 20:16:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB0b0-0006PP-Eq; Mon, 14 Mar 2005 20:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB0az-0006PD-1z for ltru@megatron.ietf.org; Mon, 14 Mar 2005 20:11:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15626 for ; Mon, 14 Mar 2005 20:11:35 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB0ef-0008Kq-8P for ltru@ietf.org; Mon, 14 Mar 2005 20:15:30 -0500 Received: from Lugh (unknown [83.70.164.159]) by postie2.hosting365.ie (Postfix) with ESMTP id 452171F3B9BD4 for ; Tue, 15 Mar 2005 01:11:34 +0000 (GMT) From: "Jon Hanna" To: "'LTRU Working Group'" Subject: RE: [Ltru] "Obsolete" region subtags (was: Re: Update toproposed registry) Date: Tue, 15 Mar 2005 01:11:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.1.2.0.2.20050314224257.0399eeb0@mail.jefsey.com> Thread-Index: AcUo+tA11N2rtTpTRtGWTBt4vXfi0wAAQpOg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050315011134.452171F3B9BD4@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit > I would not like to harp again and again on the same issue Great so. Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 21:59:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25075; Mon, 14 Mar 2005 21:59:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2Km-0004UL-IB; Mon, 14 Mar 2005 22:03:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2GE-0007Vd-UC; Mon, 14 Mar 2005 21:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2GC-0007Uj-TK for ltru@megatron.ietf.org; Mon, 14 Mar 2005 21:58:21 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24970 for ; Mon, 14 Mar 2005 21:58:18 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DB2Eo-0003Y6-EZ for ltru@lists.ietf.org; Tue, 15 Mar 2005 03:56:54 +0100 Received: from 62.80.58.24 ([62.80.58.24]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2005 03:56:54 +0100 Received: from nobody by 62.80.58.24 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2005 03:56:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 15 Mar 2005 03:56:27 +0100 Organization: Lines: 27 Message-ID: <42364EDB.197@xyzzy.claranet.de> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.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: 62.80.58.24 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > At 04:10 14/03/2005, Doug Ewell wrote: [...] > I note that my position is exactly described in your > "And I'm convinced [...] That wasn't Doug, it was me in another article, and Doug only answered it in another article, please don't confuse this. > I suggest you bring the problem where it really belongs: to > the UN General Assembly. Now wait a moment, I know that UK is no country code and only a ccTLD, just like everybody else here on this list. We don't need the UN for this "problem". We can only decide to use IANA as source (indirectly almost the same as ISO 3166), or we use ISO 3166 directly. For "we" read: the future tag reviewer. "We" could also mix these strategies, accept all ccTLDs (= be liberal in what you accept), but generate only the official CCs. There's no best way to do it, supporting UK is horrible, but not supporting IM is also a pain. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 14 23:07:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01967; Mon, 14 Mar 2005 23:07:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB3PO-0007fa-FN; Mon, 14 Mar 2005 23:11:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB3L2-0000GT-GU; Mon, 14 Mar 2005 23:07:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB3L1-0000GO-92 for ltru@megatron.ietf.org; Mon, 14 Mar 2005 23:07:23 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01925 for ; Mon, 14 Mar 2005 23:07:19 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DB3Jq-0000pi-21 for ltru@lists.ietf.org; Tue, 15 Mar 2005 05:06:10 +0100 Received: from 62.80.58.24 ([62.80.58.24]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2005 05:06:10 +0100 Received: from nobody by 62.80.58.24 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2005 05:06:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 15 Mar 2005 05:03:34 +0100 Organization: Lines: 68 Message-ID: <42365E96.3095@xyzzy.claranet.de> References: <20050314031049.BIYJ2124.mta7.adelphia.net@megatron.ietf.org> <006f01c5285a$467704e0$030aa8c0@DEWELL> <42354C53.D98@xyzzy.claranet.de> <20050314134734.GB20009@skunk.reutershealth.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: 62.80.58.24 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit John Cowan wrote: > We don't want to allow both en-GB and en-826 at the same > time. That would be very bad for interoperability. There's no problem with interoperability, if all CCs have a canonical and stable UN number as long as the CC exists. The draft already has many deprecated entries with pointers to new and stable canonical entries. For the big CS mess the registry would have been: region | CS | ... | 200 region | YU | ... | 890 Snapshot after the split of CS: region | CS | ... | 200 | deprecated region | CZ | ... | 203 region | SK | ... | 703 region | YU | ... | 890 region | 200 | ... | | deprecated, use 203 or 703 Snapshot after the split of YU: region | BA | ... | 070 region | CS | ... | 200 | deprecated region | CZ | ... | 203 region | HR | ... | 191 region | MK | ... | 807 region | SI | ... | 705 region | SK | ... | 703 region | YU | ... | 891 | note change from 890 region | 200 | ... | | deprecated, use 203 or 703 region | 890 | ... | | deprecated, use 070, 191, 705, 807, 891 Snapshot after the premature recycling of CS: region | BA | ... | 070 region | CS | ... | 891 region | CZ | ... | 203 region | HR | ... | 191 region | MK | ... | 807 region | SI | ... | 705 region | SK | ... | 703 region | YU | ... | 891 | deprecated region | 200 | ... | | deprecated, use 203 or 703 region | 890 | ... | | deprecated, use 070, 191, 705, 807, 891 As you see the canonical UN number never changes, even if it's deprecated. And the CC is only an alias of a canonical value, always reflecting the official ISO 3166 meaning, where it exists. Kept as deprecated alias like e.g. CS until ISO 3166 assigned a new official value. All the tag reviewer has to do, is to figure out the UN number. [GB] > the latter would never become valid, even if the ISO 3166 MA > were to reassign "GB". You're talking about the draft as it is, but I claim that it's broken, and propose a fix. With this fix GB could be assigned to a new region when necessary (after a long transition period like at least 50 years). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 02:46:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11094; Tue, 15 Mar 2005 02:46:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB6p3-0008Ho-Qz; Tue, 15 Mar 2005 02:50:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB6l8-0006nx-KO; Tue, 15 Mar 2005 02:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB6l5-0006ns-BZ for ltru@megatron.ietf.org; Tue, 15 Mar 2005 02:46:31 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11086 for ; Tue, 15 Mar 2005 02:46:24 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050315074554.SIMV4618.mta13.adelphia.net@DEWELL> for ; Tue, 15 Mar 2005 02:45:54 -0500 Message-ID: <0ec501c52932$e8194140$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050315025845.FMQV2124.mta7.adelphia.net@megatron.ietf.org> Date: Mon, 14 Mar 2005 23:45:05 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Against the backdrop of threats of obstruction, let us proceed. Randy Presuhn wrote: > Let's keep technical discussions (within the scope of our charter) on > the WG mailing list. In particular, since Addison Phillips and Mark > Davis are serving as *editors* of the registry i-d, they now take > their direction from the WG, even as we recognize their contribution > as authors of the material that went into that -00 version, and as > contributors to the technical discussion. Randy is correct, and I will make sure to follow this. The exchange I was talking about was actually before the WG got underway. What I had planned to do at this point was to forward my paraphrases of Frank Ellermann's proposals to the group: * allow non-ISO-3166 ccTLDs, such as AC, GG, JE, and UK * remove UN numeric code 200 for Czechoslovakia * make the canonical/alias relationship for region subtags adhere strictly to ISO 3166-3 And we should still discuss these. However, it appears that Frank has a completely different suggestion now: begin a transition away from alpha-2 region subtags like GB, and toward numeric region subtags like 826. I'd personally like to go on the record as opposing this one. The alpha-2 codes, for all their imperfections, are firmly entrenched in existing data and in the minds of users. They have much more mnemonic value than the numeric codes (quick, no peeking: what's the UN code for your country?). 98% of the time, they do match the country's ccTLD, for those who find that important. Frank wrote: > The draft already has many deprecated entries with pointers > to new and stable canonical entries. Not that many. I count eight. Having duplicate codes is actually something you want to do as little as possible; for one thing, it makes tag matching more difficult. In cases where a code is changed and you may have data with either code, there's little choice but to support both and map one to the other. But I don't think you want to do that for every country on Earth. John is right; it really would cause interoperability problems. In particular, I wouldn't worry much about GB going away or being reused any time soon (perhaps a different example would be more convincing). Having said that, one of Frank's earlier proposals -- make the canonical/alias relationship for region subtags adhere strictly to ISO 3166-3 -- would actually add a few canonical/alias pairs to the registry. I've come to think this is actually a good idea, since it removes one potential source of arbitrariness (real or perceived). Speaking of which, does anyone have an official copy of ISO 3166-3 that can be used to double-check the "deprecated" and "changed" region subtags in the registry? I got my information from an unofficial source. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 04:43:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22309; Tue, 15 Mar 2005 04:43:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB8e1-0004ws-Im; Tue, 15 Mar 2005 04:47:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB8Yr-00039h-7t; Tue, 15 Mar 2005 04:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB8Yp-00039D-UN for ltru@megatron.ietf.org; Tue, 15 Mar 2005 04:42:00 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22263 for ; Tue, 15 Mar 2005 04:41:56 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DB8Xa-0005o6-NM for ltru@lists.ietf.org; Tue, 15 Mar 2005 10:40:42 +0100 Received: from 212.82.251.109 ([212.82.251.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2005 10:40:42 +0100 Received: from nobody by 212.82.251.109 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2005 10:40:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 15 Mar 2005 10:39:49 +0100 Organization: Lines: 44 Message-ID: <4236AD65.5BF1@xyzzy.claranet.de> References: <20050315025845.FMQV2124.mta7.adelphia.net@megatron.ietf.org> <0ec501c52932$e8194140$030aa8c0@DEWELL> 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.109 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > The exchange I was talking about was actually before the WG > got underway. We could still find it, it's in the archive of the languages list - not what you wrote to the editors as summary, but the examples where draft 10 had some surprising effects for the start dates "begin of ISO 3166" and "begin of UN numbers". >> The draft already has many deprecated entries with pointers >> to new and stable canonical entries. > Not that many. I count eight I counted some more, but less than twenty. And about the same number of deprecated entries without new canonical value like sh or DD. You've probably not counted the 7 new grandfathered pointers. > Having duplicate codes is actually something you want to do > as little as possible Yes, but it happened in the last twenty years, and the draft wants to be persistent for centuries. Maybe this big CS mess was not only a bug, but also a feature, it demonstrated in fast forward motion that we're abusing ISO 3166-1, if we use it for "frozen" stable tags. > I wouldn't worry much about GB going away or being reused > any time soon (perhaps a different example would be more > convincing). Real examples in our earlier discussion were CS, GE, and SK. Public ISO 3166-3 sources: I found nothing better than the URL you have, FOTW (flags of the world) lists the same codes reported by a FOTW user (see end of page). The future tag reviewer could use corresponding newsletters. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 11:53:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18383; Tue, 15 Mar 2005 11:41:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBF2p-0000J0-Nt; Tue, 15 Mar 2005 11:37:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBDmF-0004Oy-Do; Tue, 15 Mar 2005 10:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBDmD-0004OX-Hl for ltru@megatron.ietf.org; Tue, 15 Mar 2005 10:16:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26909 for ; Tue, 15 Mar 2005 10:16:07 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBDq3-0003jY-MZ for ltru@ietf.org; Tue, 15 Mar 2005 10:20:08 -0500 Received: from lns-p19-8-idf-82-249-14-208.adsl.proxad.net ([82.249.14.208] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DBDm9-0007yK-4D; Tue, 15 Mar 2005 07:16:05 -0800 Message-Id: <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 15 Mar 2005 12:28:36 +0100 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <42364EDB.197@xyzzy.claranet.de> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.7 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 At 03:56 15/03/2005, Frank Ellermann wrote: >JFC (Jefsey) Morfin wrote: > > At 04:10 14/03/2005, Doug Ewell wrote: >[...] > > I note that my position is exactly described in your > > "And I'm convinced >[...] >That wasn't Doug, it was me in another article, and Doug only >answered it in another article, please don't confuse this. Dear Frank, Apologies. The point was well made anyway. > > I suggest you bring the problem where it really belongs: to > > the UN General Assembly. > >Now wait a moment, I know that UK is no country code and only >a ccTLD, just like everybody else here on this list. This is not fully exact, and this is the point. >We don't need the UN for this "problem". We can only decide to use IANA >as source (indirectly almost the same as ISO 3166), or we use ISO 3166 >directly. For "we" read: the future tag reviewer. I am afraid you can, but you will be blocked if this is not what the British Government wants (they are the one who accepted UK, GG, JJ, IM.. through ICANN, and GB through ISO). You cannot _decide_ to use the IANA or ISO source. You can propose an RFC, but again the one who will decide (as for any RFC) is the market, and this market in this case starts with the Governments who made their point load and clear (WSIS) and who may say it at GAC level. What I try to make understood is that the document this WG will produce will be counterproductive if it is not supported by the entities in charge (Governments) and their usual delegates (GAC, national NICs, Culture Ministries, Academic and Computer people), their common bodies (ISO, ITU, UNESCO, WSIS) and their national users. Worst, if it is opposed. >"We" could also mix these strategies, accept all ccTLDs (= be >liberal in what you accept), but generate only the official >CCs. There's no best way to do it, supporting UK is horrible, >but not supporting IM is also a pain. We should stop talking about ccTLDs. They blur the picture. We are talking of country codes and of local Internet communities, of people. These people have a Government to represent them. We do not represent them. We are simply to serve them the way they want. If we do not do that we will lose them and we will lose our credibility as a global system, what means we could close the shop. To help us understand how we stand. When referring to a network issue we often think of hierarchies. This is the root (:-) of most of our misunderstandings. Network, and the real world you propose something to (such as this Draft), are not hierarchical (centralized) and ruled by RFCs.They are not even decentralized (meshed top like in the DNS, with local hierarchy) with some opinion leaders to convice. Real life networking is granular and distributed. DNS is just a default hierarchical vision of the universal namespace. As are the CLDR proposed locales. As soon as you accept this, you see you can support whatever people want, without any big problem (may be some challenges :-), and everyone will support you. But I accept it may change a few things, not my fault: see Paul Bahan. jfc > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 12:26:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24707; Tue, 15 Mar 2005 12:18:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFXB-0000Cw-Hx; Tue, 15 Mar 2005 12:08:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFHB-00078u-K9; Tue, 15 Mar 2005 11:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFHA-00078i-Bw for ltru@megatron.ietf.org; Tue, 15 Mar 2005 11:52:12 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19805 for ; Tue, 15 Mar 2005 11:52:04 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050315165135.JMYY4618.mta13.adelphia.net@DEWELL> for ; Tue, 15 Mar 2005 11:51:35 -0500 Message-ID: <0ee501c5297f$2fd068a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Subject: [Ltru] Re: "Obsolete" region subtags Date: Tue, 15 Mar 2005 08:51:07 -0800 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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> The exchange I was talking about was actually before the WG >> got underway. > > We could still find it, it's in the archive of the languages > list - not what you wrote to the editors as summary, but the > examples where draft 10 had some surprising effects for the > start dates "begin of ISO 3166" and "begin of UN numbers". I don't see any wording in draft-phillips-langtags-10 that differs in this regard from draft-09. Which section number or appendix are you looking at? >>> The draft already has many deprecated entries with pointers >>> to new and stable canonical entries. > > > Not that many. I count eight > > I counted some more, but less than twenty. And about the same > number of deprecated entries without new canonical value like > sh or DD. I can list the ones I found, but I think we agree the number is small compared to 800+ generative subtags. > You've probably not counted the 7 new grandfathered pointers. I'm not worried about the grandfathered tags, since their number will never increase once the draft is approved. >> Having duplicate codes is actually something you want to do >> as little as possible > > Yes, but it happened in the last twenty years, and the draft > wants to be persistent for centuries. Maybe this big CS mess > was not only a bug, but also a feature, it demonstrated in fast > forward motion that we're abusing ISO 3166-1, if we use it for > "frozen" stable tags. I am certain that we are not going to deprecate or phase out the use of alpha-2 country codes in language tags. I think continuing to pursue this particular cause will be a waste of effort. >> I wouldn't worry much about GB going away or being reused >> any time soon (perhaps a different example would be more >> convincing). > > Real examples in our earlier discussion were CS, GE, and SK. Czechoslovakia, Gilbert and Ellice Islands, and Sikkim. If the United Kingdom of Great Britain and Northern Ireland breaks up or changes its name appreciably, such that ISO 3166/MA changes its alpha-2 code AND subsequently decides to reuse the code GB for some other entity, any time within our lifetimes, I promise I will travel to your home and personally offer my apology for my shortsightedness. I'm not trying to be rude, but I just don't see that particular reuse ever happening. > Public ISO 3166-3 sources: I found nothing better than the > URL you have, FOTW (flags of the world) lists the same codes > reported by a FOTW > user (see end of page). I didn't know that very interesting site had an ISO 3166-3 page. But in any case, I already have a good *unofficial* source. What I am looking for is the real thing. > The future tag reviewer could use corresponding newsletters. I'm sure the future *subtag* reviewer will have as many puppies like me, yapping at his feet with ISO change notices, as he can stand. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 12:36:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26767; Tue, 15 Mar 2005 12:35:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFm6-0003w6-HX; Tue, 15 Mar 2005 12:24:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFhR-00031f-NR; Tue, 15 Mar 2005 12:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFfZ-0002B3-4Q for ltru@megatron.ietf.org; Tue, 15 Mar 2005 12:17:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23587 for ; Tue, 15 Mar 2005 12:17:14 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFh6-0002Wl-UV for ltru@ietf.org; Tue, 15 Mar 2005 12:19:01 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 09:14:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: "Obsolete" region subtags Date: Tue, 15 Mar 2005 09:14:45 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: "Obsolete" region subtags Thread-Index: AcUpFLMNc/aHq91MRTWn0VNqnfwZGwAZPOGw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 15 Mar 2005 17:14:45.0868 (UTC) FILETIME=[7C59E2C0:01C52982] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable We chose the UN M.49 numbers as the backup for ISO 3166 codes precisely = because they are stable. Allowing multiple subtags to mean the same thing, as Frank suggests = below, would be a problem. Many language tag processors that I know of = are implemented based solely on the values of the tags themselves, with = no external knowledge baked into them. The existence of a registry might = change that to some degree, but you'll still have many of what the draft = calls "well-formed" processors for which "GB" is just a token. To take the step you suggest, while an improvement in clarity and = stability, would require additional "smarts" in tag processors in order = to do simple matching of tags.=20 I think that the draft as it sits embodies most of your suggestion = anyway. The relationship between ISO 3166 codes and UN M.49 codes is = spelled out in Section 3.2. One of the side effects of the text in that = section is that it demonstrates the UN M.49 code's cardinality in = deciding what to do. Your example of the CS/YU registry entries below is very clear and = perhaps the UN M.49 codes should be notes in the registry to assist with = clarity in the future. I note, however, that it is an example of changes = before the adoption of the draft. If these changes were to take place = under the draft (tomorrow instead of a few years ago), then the results = would be very different: > region | BA | ... | > region | CS | Czechoslovakia |=20 > region | CZ | ... |=20 > region | HR | ... |=20 > region | MK | ... |=20 > region | SI | ... |=20 > region | SK | ... |=20 > region | YU | ... | deprecated, use 891 > region | 891 | Serbia and Montenegro |=20 In other words, if ISO 3166 doesn't stick to 50-year reservations of = withdrawn codes, we will see sporadic creation of numeric UN M.49 codes. = Countries will probably take notice of this and try to avoid obtaining = problematic codes when they change their names. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: Monday, March 14, 2005 8:04 PM > To: ltru@ietf.org > Subject: [Ltru] Re: "Obsolete" region subtags >=20 > John Cowan wrote: >=20 > > We don't want to allow both en-GB and en-826 at the same > > time. That would be very bad for interoperability. >=20 > There's no problem with interoperability, if all CCs have a > canonical and stable UN number as long as the CC exists. >=20 > The draft already has many deprecated entries with pointers > to new and stable canonical entries. >=20 > For the big CS mess the registry would have been: >=20 > region | CS | ... | 200 > region | YU | ... | 890 >=20 > Snapshot after the split of CS: >=20 > region | CS | ... | 200 | deprecated > region | CZ | ... | 203 > region | SK | ... | 703 > region | YU | ... | 890 > region | 200 | ... | | deprecated, use 203 or 703 >=20 > Snapshot after the split of YU: >=20 > region | BA | ... | 070 > region | CS | ... | 200 | deprecated > region | CZ | ... | 203 > region | HR | ... | 191 > region | MK | ... | 807 > region | SI | ... | 705 > region | SK | ... | 703 > region | YU | ... | 891 | note change from 890 > region | 200 | ... | | deprecated, use 203 or 703 > region | 890 | ... | | deprecated, use 070, 191, 705, 807, 891 >=20 > Snapshot after the premature recycling of CS: >=20 > region | BA | ... | 070 > region | CS | ... | 891 > region | CZ | ... | 203 > region | HR | ... | 191 > region | MK | ... | 807 > region | SI | ... | 705 > region | SK | ... | 703 > region | YU | ... | 891 | deprecated > region | 200 | ... | | deprecated, use 203 or 703 > region | 890 | ... | | deprecated, use 070, 191, 705, 807, 891 >=20 > As you see the canonical UN number never changes, even if it's > deprecated. And the CC is only an alias of a canonical value, > always reflecting the official ISO 3166 meaning, where it > exists. Kept as deprecated alias like e.g. CS until ISO 3166 > assigned a new official value. >=20 > All the tag reviewer has to do, is to figure out the UN number. >=20 > [GB] > > the latter would never become valid, even if the ISO 3166 MA > > were to reassign "GB". >=20 > You're talking about the draft as it is, but I claim that it's > broken, and propose a fix. With this fix GB could be assigned > to a new region when necessary (after a long transition period > like at least 50 years). > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 15:42:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16951; Tue, 15 Mar 2005 15:42:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIvm-00067H-UD; Tue, 15 Mar 2005 15:46:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBIql-0001Se-Ed; Tue, 15 Mar 2005 15:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBI4C-0008OD-I6 for ltru@megatron.ietf.org; Tue, 15 Mar 2005 14:51:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10418 for ; Tue, 15 Mar 2005 14:44:22 -0500 (EST) Received: from ns.cnri.reston.va.us ([132.151.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHmb-0000B7-Iv for ltru@ietf.org; Tue, 15 Mar 2005 14:32:52 -0500 Received: from cnri-7-100.cnri.reston.va.us ([132.151.7.100] helo=dinara.foretec.com) by ns.cnri.reston.va.us with esmtp (Exim 4.20) id 1DBHif-0003Z2-Up; Tue, 15 Mar 2005 14:28:45 -0500 Message-Id: <6.1.0.6.2.20050315143149.0202bec0@odin.ietf.org> X-Sender: dinaras@odin.ietf.org X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 15 Mar 2005 14:32:27 -0500 To: "Addison Phillips" From: Dinara Suleymanova In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.2 (++) X-Scan-Signature: 075ec310e0beff494c4cbd1f2f410b79 X-Mailman-Approved-At: Tue, 15 Mar 2005 15:41:10 -0500 Cc: LTRU Working Group Subject: [Ltru] Re: Working Group submission: LTRU Registry Draft 00 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.2 (++) X-Scan-Signature: dabfe2103f3a601f203a0eb2d513c834 This has to be approved by the wg chairs. At 03:10 PM 3/12/2005, Addison Phillips wrote: >Dear Editor, > >Please find attached in text format draft-00 of "draft-ietf-ltru-registry". > >I understand that this will be processed after IETF-62. > >Best Regards, > >Addison (for the editors) > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Chair, W3C Internationalization Core Working Group >http://www.w3.org/International > >Internationalization is not a feature. >It is an architecture. > > > > >Network Working Group A. Phillips, Ed. >Internet-Draft Quest Software >Expires: September 11, 2005 M. Davis, Ed. > IBM > March 10, 2005 > > > Tags for Identifying Languages > draft-ietf-ltru-registry-00 > >Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. > > 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 September 11, 2005. > >Copyright Notice > > Copyright (C) The Internet Society (2005). > >Abstract > > This document describes the structure, content, construction, and > semantics of language tags for use in cases where it is desirable to > indicate the language used in an information object. It also > describes how to register values for use in language tags and the > creation of user defined extensions for private interchange. This > > > >Phillips & Davis Expires September 11, 2005 [Page 1] > >Internet-Draft langtags March 2005 > > > document obsoletes RFC 3066 (which replaced RFC 1766). > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . 4 > 2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.1.1 Length Considerations . . . . . . . . . . . . . . . . 5 > 2.2 Language Subtag Sources and Interpretation . . . . . . . . 6 > 2.2.1 Primary Language Subtag . . . . . . . . . . . . . . . 7 > 2.2.2 Extended Language Subtags . . . . . . . . . . . . . . 9 > 2.2.3 Script Subtag . . . . . . . . . . . . . . . . . . . . 9 > 2.2.4 Region Subtag . . . . . . . . . . . . . . . . . . . . 10 > 2.2.5 Variant Subtags . . . . . . . . . . . . . . . . . . . 11 > 2.2.6 Extension Subtags . . . . . . . . . . . . . . . . . . 11 > 2.2.7 Private Use Subtags . . . . . . . . . . . . . . . . . 12 > 2.2.8 Pre-Existing RFC 3066 Registrations . . . . . . . . . 13 > 2.2.9 Possibilities for Registration . . . . . . . . . . . . 13 > 2.2.10 Classes of Conformance . . . . . . . . . . . . . . . 14 > 2.3 Choice of Language Tag . . . . . . . . . . . . . . . . . . 15 > 2.4 Meaning of the Language Tag . . . . . . . . . . . . . . . 16 > 2.4.1 Canonicalization of Language Tags . . . . . . . . . . 17 > 2.5 Considerations for Private Use Subtags . . . . . . . . . . 18 > 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 > 3.1 Format of the IANA Language Subtag Registry . . . . . . . 20 > 3.2 Stability of IANA Registry Entries . . . . . . . . . . . . 24 > 3.3 Registration Procedure for Subtags . . . . . . . . . . . . 27 > 3.4 Extensions and Extensions Namespace . . . . . . . . . . . 30 > 4. Security Considerations . . . . . . . . . . . . . . . . . . 32 > 5. Character Set Considerations . . . . . . . . . . . . . . . . 33 > 6. Changes from RFC 3066 . . . . . . . . . . . . . . . . . . . 34 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 > A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 > B. Examples of Language Tags (Informative) . . . . . . . . . . 40 > C. Conversion of the RFC 3066 Language Tag Registry . . . . . . 42 > Intellectual Property and Copyright Statements . . . . . . . 44 > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 2] > >Internet-Draft langtags March 2005 > > >1. Introduction > > Human beings on our planet have, past and present, used a number of > languages. There are many reasons why one would want to identify the > language used when presenting or requesting information. > > Information about a user's language preferences commonly needs to be > identified so that appropriate processing can be applied. For > example, the user's language preferences in a browser can be used to > select web pages appropriately. A choice of language preference can > also be used to select among tools (such as dictionaries) to assist > in the processing or understanding of content in different languages. > > In addition, knowledge about the particular language used by some > piece of information content may be useful or even required by some > types of information processing; for example spell-checking, > computer-synthesized speech, Braille transcription, or high-quality > print renderings. > > One means of indicating the language used is by labeling the > information content with a language identifier. These identifiers > can also be used to specify user preferences when selecting > information content, or for labeling additional attributes of content > and associated resources. > > These identifiers can also be used to indicate additional attributes > of content that are closely related to the language. In particular, > it is often necessary to indicate specific information about the > dialect, writing system, or orthography used in a document or > resource, as these attributes may be important for the user to obtain > information in a form that they can understand, or important in > selecting appropriate processing resources for the given content. > > This document specifies an identifier mechanism and a registration > function for values to be used with that identifier mechanism. It > also defines a mechanism for private use values and future extension. > > This document replaces RFC 3066, which replaced RFC 1766. For a list > of changes in this document, see Section 6. > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC 2119] [11]. > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 3] > >Internet-Draft langtags March 2005 > > >2. The Language Tag > >2.1 Syntax > > The language tag is composed of one or more parts: A primary language > subtag and a (possibly empty) series of subsequent subtags. Subtags > are distinguished by their length, position in the subtag sequence, > and content, so that each type of subtag can be recognized solely by > these features. This makes it possible to construct a parser that > can extract and assign some semantic information to the subtags, even > if specific subtag values are not recognized. Thus a parser need not > have an up-to-date copy of the registered subtag values to perform > most searching and matching operations. > > The syntax of this tag in ABNF [RFC 2234] [13] is: > > Language-Tag = (lang > *("-" extlang) > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) > / privateuse ; private-use tag > / grandfathered ; grandfathered registrations > > lang = 2*3ALPHA ; shortest ISO 639 code > / registered-lang > extlang = 3ALPHA ; reserved for future use > script = 4ALPHA ; ISO 15924 code > region = 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN country number > variant = ALPHA (4*7alphanum) ; registered variants > / DIGIT (3*7alphanum) > extension = singleton 1*("-" (2*8alphanum)) ; extension subtag(s) > privateuse = ("x"/"X") 1*("-" (1*8alphanum)) ; private use subtag(s) > singleton = ("a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z") > ; Single letters: x/X is reserved for private use > registered-lang = 4*8ALPHA ; registered language subtag > grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered > registration > ; Note: i is the only singleton > that starts > ; a grandfathered tag > alphanum = (ALPHA / DIGIT) ; letters and numbers > > Figure 1: Language Tag ABNF > > The character "-" is HYPHEN-MINUS (ABNF: %x2D). Note that there is a > subtlety in the ABNF for 'variant': variants may consist of sequences > > > >Phillips & Davis Expires September 11, 2005 [Page 4] > >Internet-Draft langtags March 2005 > > > of up to eight characters. > > Whitespace is not permitted in a language tag. For examples of > language tags, see Appendix B. > > Note that although [RFC 2234] [13] refers to octets, the language > tags described in this document are sequences of characters from the > US-ASCII repertoire. Language tags may be used in documents and > applications that use other encodings, so long as these encompass the > US-ASCII repertoire. An example of this would be an XML document > that uses the Unicode UTF-16LE encoding. > > The tags and their subtags, including private-use and extensions, are > to be treated as case insensitive: there exist conventions for the > capitalization of some of the subtags, but these should not be taken > to carry meaning. > > For example: > o [ISO 639] [1] recommends that language codes be written in lower > case ('mn' Mongolian). > o [ISO 3166] [4] recommends that country codes be capitalized ('MN' > Mongolia). > o [ISO 15924] [3] recommends that script codes use lower case with > the initial letter capitalized ('Cyrl' Cyrillic). > However, in the tags defined by this document, the uppercase US-ASCII > letters in the range 'A' (ABNF: %x41) through 'Z' (ABNF: %x5A) are > considered equivalent and mapped directly to their US-ASCII lowercase > equivalents in the range 'a' (ABNF: %x61) through 'z' (ABNF: %x7A). > Thus the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or > "mN-cYrL-Mn" (or any other combination) and each of these variations > conveys the same meaning: Mongolian written in the Cyrillic script as > used in Mongolia. > > For informative examples of language tags, see Appendix B at the end > of this document. > >2.1.1 Length Considerations > > Although neither the ABNF nor other guidelines in this document > provide a fixed upper limit on the number of size of subtags in a > Language Tag and it is possible to envision quite long and complex > subtag sequences, in practice these are rare because additional > granularity in tags seldom adds useful distinguishing information and > because longer, more granular tags interefere with the meaning, > understanding, and processing of language tags. > > In particular, variant subtags SHOULD be used only with their > recommended prefix. This limits most tags to a sequence of four > > > >Phillips & Davis Expires September 11, 2005 [Page 5] > >Internet-Draft langtags March 2005 > > > subtags (excluding any extensions or private use sequences). See > Section 2.3 for more information on selecting the most appropriate > Language Tag. > > A conformant implementation need not support the storage of language > tags which exceed a specified length. For an example, see [RFC 2231] > [12]. Any such a limitation MUST be clearly documented, and such > documentation SHOULD include the disposition of any longer tags (for > example, whether an error value is generated or the language tag is > truncated). If truncation is permitted it SHOULD NOT permit a subtag > to be divided. > >2.2 Language Subtag Sources and Interpretation > > The namespace of language tags and their subtags is administered by > the Internet Assigned Numbers Authority (IANA) [17] according to the > rules in Section 3 of this document. The registry maintained by IANA > is the source for valid subtags: other standards referenced in this > section provide the source material for that registry. > > Terminology in this section: > > o Tag or tags refers to a complete language tag, such as > "fr-Latn-CA". Examples of tags in this document are enclosed in > double-quotes ("en-US"). > o Subtag refers to a specific section of a tag, separated by hyphen, > such as the subtag 'Latn' in "fr-Latn-CA". Examples of subtags in > this document are enclosed in single quotes ('Latn'). > o Code or codes refers to tags defined in external standards (and > which are used as subtags in this document). For example, 'Latn' > is an [ISO 15924] [3] script code which was used to define the > 'Latn' script subtag for use in a language tag. Examples of codes > in this document are enclosed in single quotes ('en', 'Latn'). > > The definitions in this section apply to the various subtags within > the language tags defined by this document, excepting those > "grandfathered" tags defined in Section 2.2.8. > > Language tags are designed so that each subtag has unique length and > content restrictions. These make identification of the subtag's type > possible, even if the content of the subtag itself is unrecognized. > This allows tags to be parsed and processed without reference to the > latest version of the underlying standards or the IANA registry and > makes the associated exception handling when parsing tags simpler. > > Subtags in the IANA registry that do not come from an underlying > standard can only appear in specific positions in a tag. > Specifically, they can only occur as primary language subtags or as > > > >Phillips & Davis Expires September 11, 2005 [Page 6] > >Internet-Draft langtags March 2005 > > > variant subtags. > > Note that sequences of private-use and extension subtags MUST occur > at the end of the sequence of subtags and MUST NOT be interspersed > with subtags defined elsewhere in this document. > > Single letter and digit subtags are reserved for current or future > use. These include the following current uses: > > o The single letter subtag 'x' is reserved to introduce a sequence > of private-use subtags. The interpretation of any private-use > subtags is defined solely by private agreement and is not defined > by the rules in this section or in any standard or registry > defined in this document. > o All other single letter subtags are reserved to introduce > standardized extension subtag sequences as described in > Section 3.4. > > The single letter subtag 'i' is used by some grandfathered tags, such > as "i-enochian", where it always appears in the first position and > cannot be confused with an extension. > >2.2.1 Primary Language Subtag > > The primary subtag is the first subtag in a language tag and cannot > be empty. Except as noted, the primary subtag is the language > subtag. The following rules apply to the assignment and > interpretation of the primary subtag: > > o All 2-character language subtags were defined in the IANA registry > according to the assignments found in the standard ISO 639 Part 1, > "ISO 639-1:2002, Codes for the representation of names of > languages -- Part 1: Alpha-2 code" [ISO 639-1] [1], or using > assignments subsequently made by the ISO 639 Part 1 maintenance > agency or governing standardization bodies. > o All 3-character language subtags were defined in the IANA registry > according to the assignments found in ISO 639 Part 2, "ISO > 639-2:1998 - Codes for the representation of names of languages -- > Part 2: Alpha-3 code - edition 1" [ISO 639-2] [2], or assignments > subsequently made by the ISO 639 Part 2 maintenance agency or > governing standardization bodies. > o The subtags in the range 'qaa' through 'qtz' are reserved for > private use in language tags. These subtags correspond to codes > reserved by ISO 639-2 for private use. These codes MAY be used > for non-registered primary-language subtags (instead of using > private-use subtags following 'x-'). Please refer to Section 2.5 > for more information on private use subtags. > > > > >Phillips & Davis Expires September 11, 2005 [Page 7] > >Internet-Draft langtags March 2005 > > > o All language subtags of 4 to 8 characters in length in the IANA > registry were defined via the registration process in Section 3.3 > and MAY be used to form the primary language subtag. At the time > this document was created, there were no examples of this kind of > subtag and future registrations of this type will be discouraged: > primary languages are STRONGLY RECOMMENDED for registration with > ISO 639 and subtags rejected by ISO 639 will be closely > scrutinized before they are registered with IANA. > o The single character subtag 'x' as the primary subtag indicates > that the language tag consists solely of subtags whose meaning is > defined by private agreement. For example, in the tag "x-fr-CH", > the subtags 'fr' and 'CH' should not be taken to represent the > French language or the country of Switzerland (or any other value > in the IANA registry) unless there is a private agreement in place > to do so. See Section 2.5. > o Other values MUST NOT be assigned to the primary subtag except by > revision or update of this document. > > Note: For languages that have both an ISO 639-1 2-character code and > an ISO 639-2 3-character code, only the ISO 639-1 2-character code is > defined in the IANA registry. > > Note: For languages that have no ISO 639-1 2-character code and for > which the ISO 639-2/T (Terminology) code and the ISO 639-2/B > (Bibliographic) codes differ, only the Terminology code is defined in > the IANA registry. At the time this document was created, all > languages that had both kinds of 3-character code were also assigned > a 2-character code; it is not expected that future assignments of > this nature will occur. > > Note: To avoid problems with versioning and subtag choice as > experienced during the transition between RFC 1766 and RFC 3066, as > well as the canonical nature of subtags defined by this document, the > ISO 639 Registration Authority Joint Advisory Committee (ISO > 639/RA-JAC) has included the following statement in [6]: > > "A language code already in ISO 639-2 at the point of freezing ISO > 639-1 shall not later be added to ISO 639-1. This is to ensure > consistency in usage over time, since users are directed in Internet > applications to employ the alpha-3 code when an alpha-2 code for that > language is not available." > > In order to avoid instability of the canonical form of tags, if a > 2-character code is added to ISO 639-1 for a language for which a > 3-character code was already included in ISO 639-2, the 2-character > code will not be added as a subtag in the registry. See Section 3.2. > > For example, if some content were tagged with 'haw' (Hawaiian), which > > > >Phillips & Davis Expires September 11, 2005 [Page 8] > >Internet-Draft langtags March 2005 > > > currently has no 2-character code, the tag would not be invalidated > if ISO 639-1 were to assign a 2-character code to the Hawaiian > language at a later date. > > For example, one of the grandfathered IANA registrations is > "i-enochian". The subtag 'enochian' could be registered in the IANA > registry as a primary language subtag (assuming that ISO 639 does not > register this language first), making tags such as "enochian-AQ" and > "enochian-Latn" valid. > >2.2.2 Extended Language Subtags > > The following rules apply to the extended language subtags: > > o Three letter subtags immediately following the primary subtag are > reserved for future standardization, anticipating work that is > currently under way on ISO 639. > o Extended language subtags MUST follow the primary subtag and > precede any other subtags. > o There MAY be any additional number of extended language subtags. > o Extended language subtags will not be registered except by > revision of this document. > o Extended language subtags MUST NOT be used to form language tags > except by revision of this document. > > Example: In a future revision or update of this document, the tag > "zh-gan" (registered under RFC 3066) might become a valid > non-grandfathered tag in which the subtag 'gan' might represent the > Chinese dialect 'Gan'. > >2.2.3 Script Subtag > > The following rules apply to the script subtags: > > o All 4-character subtags were defined according to ISO 15924 > [3]--"Codes for the representation of the names of scripts": > alpha-4 script codes, or subsequently assigned by the ISO 15924 > maintenance agency or governing standardization bodies, denoting > the script or writing system used in conjunction with this > language. > o Script subtags MUST immediately follow the primary language subtag > and all extended language subtags and MUST occur before any other > type of subtag described below. > o The subtags 'Qaaa' through 'Qabx' are reserved for private use in > language tags. These subtags correspond to codes reserved by ISO > 15924 for private use. These codes MAY be used for non-registered > script values. Please refer to Section 2.5 for more information > on private-use subtags. > > > >Phillips & Davis Expires September 11, 2005 [Page 9] > >Internet-Draft langtags March 2005 > > > o Script subtags cannot be registered using the process in > Section 3.3 of this document. Variant subtags may be considered > for registration for that purpose. > > Example: "de-Latn" represents German written using the Latin script. > >2.2.4 Region Subtag > > The following rules apply to the region subtags: > > o The region subtag defines language variations used in a specific > region, geographic, or political area. Region subtags MUST follow > any language, extended language, or script subtags and MUST > precede all other subtags. > o All 2-character subtags following the primary subtag were defined > in the IANA registry according to the assignments found in ISO > 3166 [4]--"Codes for the representation of names of countries and > their subdivisions - Part 1: Country codes"--alpha-2 country codes > or assignments subsequently made by the ISO 3166 maintenance > agency or governing standardization bodies. > o All 3-character codes consisting of digit (numeric) characters > were defined in the IANA registry according to the assignments > found in UN Standard Country or Area Codes for Statistical Use > [5] or assignments subsequently made by the governing standards > body. Note that not all of the UN M.49 codes are defined in the > IANA registry: > * UN numeric codes assigned to 'macro-geographical (continental)' > or sub-regions not associated with an assigned ISO 3166 alpha-2 > code _are_ defined. > * UN numeric codes for 'economic groupings' or 'other groupings' > are _not_ defined in the IANA registry and MUST NOT be used to > form language tags. > * Countries with ambiguous ISO 3166 alpha-2 codes as defined in > Section 3.2 are defined in the registry and are canonical for > the given country or region defined. > * The alphanumeric codes in Appendix X of the UN document are > _not_ defined and MUST NOT be used to form language tags. (At > the time this document was created these values match the ISO > 3166 alpha-2 codes.) > o There may be at most one region subtag in a language tag. > o The subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are reserved for > private use in language tags. These subtags correspond to codes > reserved by ISO 3166 for private use. These codes MAY be used for > private use region subtags (instead of using a private-use subtag > sequence). Please refer to Section 2.5 for more information on > private use subtags. > > "de-Latn-CH" represents German ('de') written using the Latin script > > > >Phillips & Davis Expires September 11, 2005 [Page 10] > >Internet-Draft langtags March 2005 > > > ('Latn') as used in Switzerland ('CH'). > > "sr-Latn-CS" represents Serbian ('sr') written using Latin script > ('Latn') as used in Serbia and Montenegro ('CS'). > > "es-419" represents Spanish ('es') as used in the UN-defined Latin > America and Caribbean region ('419'). > >2.2.5 Variant Subtags > > The following rules apply to the variant subtags: > > o Variant subtags, as a collection in the IANA registry, are not > associated with any external standard. Variant subtags and their > meanings are defined by the registration process defined in > Section 3.3. > o Variant subtags MUST follow all of the other defined subtags, but > precede any extension or private-use subtag sequences. > o More than one variant MAY be used to form the language tag. > o Variant subtags MUST be registered with IANA according to the > rules in Section 3.3 of this document before being used to form > language tags. In order to distinguish variants from other types > of subtags, registrations must meet the following length and > content restrictions: > * Variant subtags that begin with a letter (a-z, A-Z) MUST be at > least five characters long. > * Variant subtags that begin with a digit (0-9) MUST be at least > four characters long. > * The maximum length of a variant subtag is eight characters > long. > > "en-boont" represents the Boontling dialect of English. > > "de-CH-1996" represents German as used in Switzerland and as written > using the spelling reform beginning in the year 1996 C.E. > >2.2.6 Extension Subtags > > The following rules apply to extensions: > > o Extension subtags are separated from the other subtags defined in > this document by a single-letter subtag ("singleton"). The > singleton MUST be one allocated to a registration authority via > the mechanism described in Section 3.4 and cannot be the letter > 'x', which is reserved for private-use subtag sequences. > o Note: Private-use subtag sequences starting with the singleton > subtag 'x' are described below. > > > > >Phillips & Davis Expires September 11, 2005 [Page 11] > >Internet-Draft langtags March 2005 > > > o An extension MUST follow at least a primary language subtag. That > is, a language tag cannot begin with an extension. Extensions > extend language tags, they do not override or replace them. For > example, "a-value" is not a well-formed language tag, while > "de-a-value" is. > o Each singleton subtag MUST appear at most one time in each tag > (other than as a private-use subtag). That is, singleton subtags > MUST NOT be repeated. For example, the tag "en-a-bbb-a-ccc" is > invalid because the subtag 'a' appears twice. > o Extension subtags MUST meet all of the requirements for the > content and format of subtags defined in this document. > o Extension subtags MUST meet whatever requirements are set by the > document that defines their singleton prefix and whatever > requirements are provided by the maintaining authority. > o Each extension subtag MUST be from two to eight characters long > and consist solely of letters or digits, with each subtag > separated by a single '-'. > o Each singleton MUST be followed by at least one extension subtag. > For example, the tag "tlh-a-b-foo" is invalid because the first > singleton 'a' is followed immediately by another singleton 'b'. > o Extension subtags MUST follow all language, extended language, > script, region and variant subtags in a tag. > o All subtags following the singleton and before another singleton > are part of the extension. Example: In the tag "fr-a-Latn", the > subtag 'Latn' does not represent the script subtag 'Latn' defined > in the IANA Language Subtag Registry. Its meaning is defined by > the extension 'a'. > o In the event that more than one extension appears in a single tag, > the tag SHOULD be canonicalized as described in Section 2.4.1. > > For example, if the prefix singleton 'r' and the shown subtags were > defined, then the following tag would be a valid example: > "en-Latn-GB-boont-r-extended-sequence-x-private" > >2.2.7 Private Use Subtags > > The following rules apply to private-use subtags: > > o Private-use subtags are separated from the other subtags defined > in this document by the reserved single-character subtag 'x'. > o Private-use subtags MUST follow all language, extended language, > script, region, variant, and extension subtags in the tag. > Another way of saying this is that all subtags following the > singleton 'x' MUST be considered private use. Example: The subtag > 'US' in the tag "en-x-US" is a private use subtag. > o Unlike Extensions, a tag MAY consist entirely of private-use > subtags. > > > > >Phillips & Davis Expires September 11, 2005 [Page 12] > >Internet-Draft langtags March 2005 > > > o No source is defined for private use subtags. Use of private use > subtags is by private agreement and SHOULD NOT be considered part > of this document. > > For example: Users who wished to utilize SIL Ethnologue for > identification might agree to exchange tags such as > "az-Arab-x-AZE-derbend". This example contains two private-use > subtags. The first is 'AZE' and the second is 'derbend'. > >2.2.8 Pre-Existing RFC 3066 Registrations > > Existing IANA-registered language tags from RFC 1766 and/or RFC 3066 > that are not defined by additions to this document maintain their > validity. IANA will maintain these tags in the registry under either > the "grandfathered" or "redundant" type. For more information see > Appendix C. > > It is important to note that all language tags formed under the > guidelines in this document were either legal, well-formed tags or > were valid for potential registration under RFC 3066. > >2.2.9 Possibilities for Registration > > Possibilities for registration of subtags include: > > o Primary language subtags for languages not listed in ISO 639 that > are not variants of any listed or registered language, can be > registered. At the time this document was created there were no > examples of this form of subtag. Before attempting to register a > language subtag, there MUST be an attempt to register the language > with ISO 639. No language subtags will be registered for codes > that exist in ISO 639-1 or ISO 639-2, which are under > consideration by the ISO 639 maintenance or registration > authorities, or which have never been attempted for registration > with those authorities. If ISO 639 has previously rejected a > language for registration, it is reasonable to assume that there > MUST be additional very compelling evidence of need before it will > be registered in the IANA registry (to the extent that it is very > unlikely that any subtags will be registered of this type). > o Dialect or other divisions or variations within a language, its > orthography, writing system, regional variation, or historical > usage may be registered as variant subtags. An example is the > 'scouse' subtag (the Scouse dialect of English). > > This document leaves the decision on what subtags are appropriate or > not to the registration process described in Section 3.3. > > ISO 639 defines a maintenance agency for additions to and changes in > > > >Phillips & Davis Expires September 11, 2005 [Page 13] > >Internet-Draft langtags March 2005 > > > the list of languages in ISO 639. This agency is: > > International Information Centre for Terminology (Infoterm) > Aichholzgasse 6/12, AT-1120 > Wien, Austria > Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 > > ISO 639-2 defines a maintenance agency for additions to and changes > in the list of languages in ISO 639-2. This agency is: > > Library of Congress > Network Development and MARC Standards Office > Washington, D.C. 20540 USA > Phone: +1 202 707 6237 Fax: +1 202 707 0115 > URL: http://www.loc.gov/standards/iso639 > > The maintenance agency for ISO 3166 (country codes) is: > > ISO 3166 Maintenance Agency > c/o International Organization for Standardization > Case postale 56 > CH-1211 Geneva 20 Switzerland > Phone: +41 22 749 72 33 Fax: +41 22 749 73 49 > URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html > > The registration authority for ISO 15924 (script codes) is: > > Unicode Consortium Box 391476 > Mountain View, CA 94039-1476, USA > URL: http://www.unicode.org/iso15924 > > The Statistics Division of the United Nations Secretariat maintains > the Standard Country or Area Codes for Statistical Use and can be > reached at: > > Statistical Services Branch > Statistics Division > United Nations, Room DC2-1620 > New York, NY 10017, USA > > Fax: +1-212-963-0623 > E-mail: statistics@un.org > URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm > >2.2.10 Classes of Conformance > > Implementations may wish to express their level of conformance with > the rules and practices described in this document. There are > > > >Phillips & Davis Expires September 11, 2005 [Page 14] > >Internet-Draft langtags March 2005 > > > generally two classes of conforming implementations: "well-formed" > processors and "validating" processors. Claims of conformance SHOULD > explicitly reference one of these definitions. > > 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. > > Well-formed processors are strongly encouraged to implement the > canonicalization rules contained in Section 2.4.1. > > An implementation that claims to be validating MUST: > o 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.4 > are supported, including version, revision, and date. > o For any such extensions supported, check that all subtags used in > that extension are valid. > o If the processor generates tags, it MUST do so in canonical form, > including any supported extensions, as defined in Section 2.4.1. > >2.3 Choice of Language Tag > > One may occasionally be faced with several possible tags for the same > body of text. > > Interoperability is best served when all users use the same language > tag in order to represent the same language. If an application has > requirements that make the rules here inapplicable, then that > application risks damaging interoperability. It is STRONGLY > RECOMMENDED that users not define their own rules for language tag > choice. > > Standards, protocols and applications that reference this document > normatively but apply different rules to the ones given in this > section MUST specify how the procedure varies from the one given > here. > > > > >Phillips & Davis Expires September 11, 2005 [Page 15] > >Internet-Draft langtags March 2005 > > > 1. Use as precise a tag as possible, but no more specific than is > justified. For example, 'de' might suffice for tagging an email > written in German, while "de-CH-1996" is probably unnecessarily > precise for such a task. > 2. Avoid using subtags that are not important for distinguishing > content in an application. For example, including the script > subtag in "en-Latn-US" is generally unnecessary, since nearly all > English texts are written in the Latin script and it is generally > not important to filter out those few that are not. > 3. Use the canonical subtag from the IANA registry in preference to > any of its aliases. For example, you should use 'he' for Hebrew > in preference to 'iw'. > 4. You SHOULD NOT use the 'UND' (Undetermined) language subtag to > label content, even if the language is unknown. Omitting the tag > is preferred. Some protocols may force you to give a value for > the language tag and the 'UND' subtag may be useful when matching > language tags in certain situations. > 5. You SHOULD NOT use the 'MUL' (Multiple) subtag if the protocol > allows you to use multiple languages, as is the case for the > Content-Language header in HTTP. > 6. You SHOULD NOT use the same variant subtag more than once within > a language tag. For example, you should not use > "en-US-boont-boont". > > To ensure consistent backward compatibility, this document contains > several provisions to account for potential instability in the > standards used to define the subtags that make up language tags. > These provisions mean that no language tag created under the rules in > this document will become obsolete. In addition, tags that are in > canonical form will always be in canonical form. > >2.4 Meaning of the Language Tag > > The language tag always defines a language as spoken (or written, > signed or otherwise signaled) by human beings for communication of > information to other human beings. Computer languages such as > programming languages are explicitly excluded. > > If a language tag B contains language tag A as a prefix, then B is > typically "narrower" or "more specific" than A. For example, > "zh-Hant-TW" is more specific than "zh-Hant". > > This relationship is not guaranteed in all cases: specifically, > languages that begin with the same sequence of subtags are NOT > guaranteed to be mutually intelligible, although they may be. For > example, the tag "az" shares a prefix with both "az-Latn" > (Azerbaijani written using the Latin script) and "az-Cyrl" > (Azerbaijani written using the Cyrillic script). A person fluent in > > > >Phillips & Davis Expires September 11, 2005 [Page 16] > >Internet-Draft langtags March 2005 > > > one script may not be able to read the other, even though the text > might be identical. Content tagged as "az" most probably is written > in just one script and thus might not be intelligible to a reader > familiar with the other script. > > The relationship between the tag and the information it relates to is > defined by the standard describing the context in which it appears. > Accordingly, this section can only give possible examples of its > usage. > o For a single information object, the associated language tags > might be interpreted as the set of languages that is required for > a complete comprehension of the complete object. Example: Plain > text documents. > o For an aggregation of information objects, the associated language > tags could be taken as the set of languages used inside components > of that aggregation. Examples: Document stores and libraries. > o For information objects whose purpose is to provide alternatives, > the associated language tags could be regarded as a hint that the > content is provided in several languages, and that one has to > inspect each of the alternatives in order to find its language or > languages. In this case, the presence of multiple tags might not > mean that one needs to be multi-lingual to get complete > understanding of the document. Example: MIME > multipart/alternative. > o In markup languages, such as HTML and XML, language information > can be added to each part of the document identified by the markup > structure (including the whole document itself). For example, one > could write C'est la vie. inside a > Norwegian document; the Norwegian-speaking user could then access > a French-Norwegian dictionary to find out what the marked section > meant. If the user were listening to that document through a > speech synthesis interface, this formation could be used to signal > the synthesizer to appropriately apply French text-to-speech > pronunciation rules to that span of text, instead of misapplying > the Norwegian rules. > >2.4.1 Canonicalization of Language Tags > > Since a particular language tag may be used in many processes, > language tags SHOULD always be created or generated in a canonical > form. > > A language tag is in canonical form when: > 1. The tag is well-formed according the rules in Section 2.1 and > Section 2.2. > 2. None of the subtags in the language tag has a canonical_value > mapping in the IANA registry (see Section 3.1). Subtags with a > canonical_value mapping MUST be replaced with their mapping in > > > >Phillips & Davis Expires September 11, 2005 [Page 17] > >Internet-Draft langtags March 2005 > > > order to canonicalize the tag. > 3. If more than one extension subtag sequence exists, the extension > sequences are ordered into case-insensitive ASCII order by > singleton subtag. > > Example: The language tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical > form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not in > canonical form. > > Example: The language tag "en-NH" (English as used in the New > Hebrides) is not canonical because the 'NH' subtag has a canonical > mapping to 'VU' (Vanuatu). > > Note: Canonicalization of language tags does not imply anything about > the use of upper or lowercase letter in subtags as described in > Section 2.1. All comparisons MUST be performed in a case-insensitive > manner. > > Note: the value "--" in the canonical_value field of the registry > indicates a tag or subtag that has been deprecated and for which no > replacement or canonical equivalent has been assigned. Validating > processors SHOULD NOT generate tags that include these values. > > An extension MUST define any relationships that may exist between the > various subtags in the extension and thus MAY define an alternate > canonicalization scheme for the extension's subtags. Extensions MAY > define how the order of the extension's subtags are interpreted. For > example, an extension could define that its subtags are in canonical > order when the subtags are placed into ASCII order: that is, > "en-a-aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". Another extension > might define that the order of the subtags influences their semantic > meaning (so that "en-b-ccc-bbb-aaa" has a different value from > "en-b-aaa-bbb-ccc"). However, extension specifications SHOULD be > designed so that they are tolerant of the typical processes described > in Section 3.4. > >2.5 Considerations for Private Use Subtags > > Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and great > caution should be used in employing them in content or protocols > intended for general use. Private-use subtags are simply useless for > information exchange without prior arrangement. > > The value and semantic meaning of private-use tags and of the subtags > used within such a language tag are not defined by this document. > > The use of subtags defined in the IANA registry as having a specific > > > >Phillips & Davis Expires September 11, 2005 [Page 18] > >Internet-Draft langtags March 2005 > > > private use meaning convey more information that a purely private use > tag prefixed by the singleton subtag 'x'. For applications this > additional information may be useful. > > For example, the region subtags 'AA', 'ZZ' and in the ranges > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) may > be used to form a language tag. A tag such as "zh-Hans-XQ" conveys a > great deal of public, interchangeable information about the language > material (that it is Chinese in the simplified Chinese script and is > suitable for some geographic region 'XQ'). While the precise > geographic region is not known outside of private agreement, the tag > conveys far more information than an opaque tag such as "x-someLang", > which contains no information about the language subtag or script > subtag outside of the private agreement. > > However, in some cases content tagged with private use subtags may > interact with other systems in a different and possibly unsuitable > manner compared to tags that use opaque, privately defined subtags, > so the choice of the best approach may depend on the particular > domain in question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 19] > >Internet-Draft langtags March 2005 > > >3. IANA Considerations > > This section deals with the processes and requirements necessary to > maintain the registry of subtags and extensions for use in language > tags as defined by this document and in accordance with the > requirements of RFC 2434 [15]. > > The language subtag registry will be maintained so that, except for > extension subtags, it is possible to validate all of the subtags that > appear in a language tag under the provisions of this document or its > revisions or successors. In addition, the meaning of the various > subtags will be unambiguous and stable over time. (The meaning of > private-use subtags, of course, is not defined by the IANA registry.) > > The registry defined under this document contains a comprehensive > list of all of the subtags valid in language tags. This allows > implementers a straightforward and reliable way to validate language > tags. > >3.1 Format of the IANA Language Subtag Registry > > The IANA Language Subtag Registry will consist of a text file that is > machine readable in the format described in this section, plus copies > of the registration forms approved by the Language Subtag Reviewer in > accordance with the process described in Section 3.3. With the > exception of the registration forms for grandfathered and redundant > tags, no registration records will be maintained for the initial set > of subtags. > > Each record in the subtag registry will consist of a series of fields > separated by the symbol "|" (%x7D) and terminated by a newline. Text > appearing after the symbol "#" (%x23) contains comments. Whitespace > surrounding fields in the file is ignored. If a field contains more > than one value, the values are separated by semicolons (%x3B). > > There is a single date record at the start of the file which > indicates the most recent modification date of the file. It has two > fields: the type field is "date", and the second field is the > modification date, in the "full-date" format specified in RFC 3339 > [20]. For example: 2004-06-28 represents June 28, 2004 in the > Gregorian calendar: > date | 2004-06-28 > > The fields in each subtag record, in order, are: > type| subtag| description| date| canonical_value| > recommended_prefix # comments > > > > > >Phillips & Davis Expires September 11, 2005 [Page 20] > >Internet-Draft langtags March 2005 > > > o The character "vertical line" ("|", %x7D) delimits each of the > fields. > o Empty fields (and their separators) at the end of the record may > be omitted. > o Leading or trailing whitespace in each field is not part of the > content. > o When the type is "grandfathered" or "redundant", then the subtag > field is actually a whole tag. > o The "recommended_prefix" field is empty, except where the type is > "variant" > o The "comments" field is optional and appears only at the end of a > record, following a "number sign" ("#", %x23). > o The sequence '..' denotes a range of values. Such a range > represents all subtags of the same length that are alphabetically > within that range, including the values explicitly mentioned. For > example 'a..c' denotes the values 'a', 'b', and 'c'. > > The field 'type' MUST consist of one of the following strings: > "language", "extlang", "script", "region", "variant", > "grandfathered", and "redundant" and denotes the type of subtag (or > tag, in the case of "grandfathered" and "redundant"). > > The field 'subtag' contains the subtag being defined. > > The field 'description' contains a description of the subtag > transcribed into ASCII. > > Note: Descriptions in registry entries that correspond to ISO 639, > ISO 15924, ISO 3166 or UN M.49 codes are intended only to indicate > the meaning of that identifier as defined in the source standard at > the time it was added to the registry. The description does not > replace the content of the source standard itself. The descriptions > are not intended to be the English localized names for the subtags > and localization or translation of language tag and subtag > descriptions is out of scope of this document. > > The field 'date' contains the date the record was added to the > registry in the "full-date" format specified in RFC 3339 [20]. For > example: 2004-06-28 represents June 28, 2004, in the Gregorian > calendar. > > The field 'canonical value' represents a canonical mapping of this > record to a subtag record of the same 'type', except for records of > type "grandfathered" and "redundant". This field SHALL NOT be > modified (except for records of type "grandfathered"): therefore a > subtag whose record contains no canonical mapping when the record is > created is a canonical form and will remain so. The 'canonical > value' field in records of type "grandfathered" and "redundant" > > > >Phillips & Davis Expires September 11, 2005 [Page 21] > >Internet-Draft langtags March 2005 > > > contain whole language tags that are STRONGLY RECOMMENDED for use in > place of the record's value. In many cases the mappings were created > by deprecation of the tags during the period before this document was > adopted. For example, the tag "no-nyn" was deprecated in favor of > the ISO 639-1 defined language code 'nn'. > > The value "--" in the 'canonical value' field means that the tag or > subtag has been deprecated and that no replacement value has been > assigned. For example, the "region" code 'BQ' (British Antarctic > Territory) was withdrawn by ISO 3166 in 1979. Although valid in > language tags, it is deprecated and validating processors SHOULD NOT > generate this subtag. > > The field 'recommended prefix' is for use with registered variants > and contains a semicolon separated list of language-ranges considered > most appropriate for use with this subtag. Additional values can be > added to this field for variants only via additional registration. > Other modification of this field (such as removing or changing > values) is not permitted. > > The field 'comments' may contain additional information about the > subtag, as deemed appropriate for understanding the registry and > implementing language tags using the various subtags. These values > can be changed via the registration process and no guarantee of > stability is provided. > > > # IANA Language Subtag Registry > # This registry lists all valid subtags for language tags > # created under RFC XXXX. > date| 2004-08-07 > > # language codes: ISO 639 and registered codes > > # ISO 639-1 (alpha-2) codes > language| aa| Afar| 2004-07-06| | > language| ab| Abkhazian| 2004-07-06| | > language| ae| Avestan| 2004-07-06| | > language| he| hebrew| 2004-06-28| | > language| iw| hebrew| 2004-06-28| he | #note mapping > language| qaa..qtz| PRIVATE USE| 2004-07-06| | > language| raj| Rajasthani| 2004-07-06| | > language| seuss| Hypothetical Language| 2005-04-01 | |# registered > language > > # script codes: ISO 15924 > > script| Arab| Arabic| 2004-07-06| | > script| Armn| Armenian| 2004-07-06| | > > > >Phillips & Davis Expires September 11, 2005 [Page 22] > >Internet-Draft langtags March 2005 > > > script| Bali| Balinese| 2004-07-06| | > # region codes: ISO 3166 and UN codes > > # ISO 3166-1 alpha-2 codes > > region| AA| PRIVATE USE| 2004-08-01| | > region| AD| Andorra| 2004-07-06| | > region| AE| United Arab Emirates| 2004-07-06| | > region| AF| Afghanistan| 2004-07-06| | > region| BQ| British Antarctic Territory | 2004-07-06 | -- | # > deprecated 1979 > region| CS| Serbia and Montenegro| 2003-07-23| | > region| YU| Yugoslavia| 2004-06-28| | > > # United Nations M.49 numeric codes > region| 001| World| 2004-07-06| | > region| 002| Africa| 2004-07-06| | > region| 003| North America| 2004-07-06| | > region| 005| South America| 2004-07-06| | > region| 200| Czechoslovakia| 2004-07-06| | #formerly used code CS > > ## registered variants > > variant| boont| Boontling| 2003-02-14| | en > variant| gaulish| Gaulish| 2001-05-25| | cel > variant| guoyu| Mandarin or Standard Chinese| 1999-12-18| | zh > > # grandfathered from RFC 3066 > > grandfathered| en-GB-oed| English, Oxford English Dictionary spelling| > 2003-07-09| | > grandfathered| i-ami| Amis| 1999-05-25| | > grandfathered| i-bnn| Bunun| 1999-05-25| | > grandfathered| art-lojban| Lojban| 2001-11-11|jbo | # deprecated in > favor of 'jbo' > > # redundant > # The following codes were registered as complete tags, but can now be > # composed of registered subtags and do not require registration. > > redundant| az-Arab| Azerbaijani in Arabic script| 2003-05-30| | # use > language az + script Arab > redundant| az-Cyrl| Azerbaijani in Cyrillic script| 2003-05-30| | # > use language az + script Cyrl > redundant| en-boont| Boontling| 2003-02-14| | # use language en + > variant boont > > Figure 2: Example of the Registry Format > > Maintenance of the registry requires that as new codes are assigned > by ISO 639, ISO 15924, and ISO 3166, the Language Subtag Reviewer > will evaluate each assignment, determine whether it conflicts with > existing registry entries, and submit the information to IANA for > inclusion in the registry. > > > >Phillips & Davis Expires September 11, 2005 [Page 23] > >Internet-Draft langtags March 2005 > > > Note: The redundant and grandfathered entries together are the > complete list of tags registered under RFC 3066 [18]. The redundant > tags are those that can now be formed using the subtags defined in > Section 2.2. The grandfathered entries are those that can never be > legal under those same provisions. The items in both lists are > permanent and stable, although grandfathered items may be deprecated > over time. Refer to Appendix C for more information. > > RFC 3066 tags that were deprecated prior to the adoption of this > document are part of the list of grandfathered tags and their > component subtags were not included as registered variants (although > they remain eligible for registration). For example, the tag > "art-lojban" was deprecated in favor of the language subtag 'jbo'. > > The Language Subtag Reviewer MUST ensure that new subtags meet the > requirements in Section 2.3 or submit an appropriate alternate subtag > as described in that section. She or he will use the following form > to submit this information: > > LANGUAGE SUBTAG REGISTRATION FORM (NEW RECORD) > Record Text: > Type: > Subtag: > Description: > Date: > Canonical Mapping: > Recommended Prefix: > Comments: > > Figure 3 > > The field 'record text' contains the exact record that IANA is to > insert into the Language Subtag Registry. The contents of the > remaining fields must exactly match those in this field. > > Whenever an entry is created or modified in the registry, the 'date' > record at the start of the registry is updated to reflect the most > recent modification date in the RFC 3339 [20] "full-date" format. > >3.2 Stability of IANA Registry Entries > > The stability of entries and their meaning in the registry is > critical to the long term stability of language tags. The rules in > this section guarantee that a specific language tag's meaning is > stable over time and will not change and that the choice of language > tag for specific content is also stable over time. > > These rules specifically deal with how changes to codes (including > > > >Phillips & Davis Expires September 11, 2005 [Page 24] > >Internet-Draft langtags March 2005 > > > withdrawal and deprecation of codes) maintained by ISO 639, ISO > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language > Subtag Registry. Assignments to the IANA Language Subtag Registry > MUST follow the following stability rules: > o Values in the fields 'type', 'subtag', 'date' and 'canonical > value' MUST NOT be changed and are guaranteed to be stable over > time. > o Values in the 'description' field MUST NOT be changed in a way > that would invalidate previously-existing tags. They may be > broadened somewhat in scope, changed to add information, or > adapted to the most common modern usage. For example, countries > occasionally change their official names: an historical example of > this would be "Upper Volta" changing to "Burkina Faso". > o Values in the field 'recommended prefix' MAY be added via the > registration process. > o Values in the field 'recommended prefix' MAY be modified, so long > as the modifications broaden the set of recommended prefixes. > That is, a recommended prefix MAY be replaced by one of its own > prefixes. For example, the prefix "en-US" could be replaced by > "en", but not by the ranges "en-Latn", "fr", or "en-US-boont". > o Values in the field 'recommended prefix' MUST NOT be removed. > o The field 'comments' MAY be added, changed, modified, or removed > via the registration process or any of the processes or > considerations described in this section. > o Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not > conflict with existing subtags of the associated type and whose > meaning is not the same as an existing subtag of the same type are > entered into the IANA registry as new records and their value is > canonical for the meaning assigned to them. > o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are > withdrawn by their respective maintenance or registration > authority remain valid in language tags. The registration process > MAY be used to add a note indicating the withdrawal of the code by > the respective standard. > o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that do not > conflict with existing subtags of the associated type but which > represent the same meaning as an existing subtag of that type are > entered into the IANA registry as new records. The field > 'canonical value' for that record MUST contain the existing subtag > of the same meaning > Example If ISO 3166 were to assign the code 'IM' to represent the > value "Isle of Man" (represented in the IANA registry by the UN > M.49 code '833'), '833' remains the canonical subtag and 'IM' > would be assigned '833' as a canonical value. This prevents > tags that are in canonical form from becoming non-canonical. > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 25] > >Internet-Draft langtags March 2005 > > > Example If the tag 'enochian' were registered as a primary > language subtag and ISO 639 subsequently assigned an alpha-3 > code to the same language, the new ISO 639 code would be > entered into the IANA registry as a subtag with a canonical > mapping to 'enochian'. The new ISO code can be used, but it is > not canonical. > o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict > with existing subtags of the associated type MUST NOT be entered > into the registry. The following additional considerations apply: > * For ISO 639 codes, if the newly assigned code's meaning is not > represented by a subtag in the IANA registry, the Language > Subtag Reviewer, as described in Section 3.3, shall prepare a > proposal for entering in the IANA registry as soon as practical > a registered language subtag as an alternate value for the new > code. The form of the registered language subtag will be at > the discretion of the Language Subtag Reviewer and must conform > to other restrictions on language subtags in this document. > * For all subtags whose meaning is derived from an external > standard (i.e. ISO 639, ISO 15924, ISO 3166, or UN M.49), if a > new meaning is assigned to an existing code and the new meaning > broadens the meaning of that code, then the meaning for the > associated subtag MAY be changed to match. The meaning of a > subtag MUST NOT be narrowed, however, as this can result in an > unknown proportion of the existing uses of a subtag becoming > invalid. Note: ISO 639 MA/RA has adopted a similar stability > policy. > * For ISO 15924 codes, if the newly assigned code's meaning is > not represented by a subtag in the IANA registry, the Language > Subtag Reviewer, as described in Section 3.3, shall prepare a > proposal for entering in the IANA registry as soon as practical > a registered variant subtag as an alternate value for the new > code. The form of the registered variant subtag will be at the > discretion of the Language Subtag Reviewer and must conform to > other restrictions on variant subtags in this document. > * For ISO 3166 codes, if the newly assigned code's meaning is > associated with the same UN M.49 code as another 'region' > subtag, then the existing region subtag remains as the > canonical entry for that region and no new entry is created. A > note MAY be added to the existing region subtag indicating the > relationship to the new ISO 3166 code. > * For ISO 3166 codes, if the newly assigned code's meaning is > associated with a UN M.49 code that is not represented by an > existing region subtag, then then the Language Subtag Reviewer, > as described in Section 3.3, shall prepare a proposal for > entering the appropriate numeric UN country code as an entry in > the IANA registry. > * For ISO 3166 codes, if there is no associated UN numeric code, > then the Language Subtag Reviewer SHALL petition the UN to > > > >Phillips & Davis Expires September 11, 2005 [Page 26] > >Internet-Draft langtags March 2005 > > > create one. If there is no response from the UN within ninety > days of the request being sent, the Language Subtag Reviewer > shall prepare a proposal for entering in the IANA registry as > soon as practical a registered variant subtag as an alternate > value for the new code. The form of the registered variant > subtag will be at the discretion of the Language Subtag > Reviewer and must conform to other restrictions on variant > subtags in this document. This situation is very unlikely to > ever occur. > o 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 grandfathered tag > MUST be marked as redundant. Note that this will not affect > language tags that match the grandfathered tag, since these tags > will now match valid generative subtag sequences. For example, if > 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). > > Language tags formed under RFC 3066 that use the region subtag 'CS' > were ambiguous, since tags produced before 2003 used that code for > the (now dissolved) country Czechoslovakia. ISO 3166 assigned this > code to the country Serbia and Montenegro in 2003 and this draft > makes that the canonical value for this subtag. To form a language > tag for the region Czechoslovakia, the UN M.49 code '200' is included > in the registry. As a practical matter, applications that encounter > the RFC 3066 tag "cs-CS" or "sk-CS" MAY wish to convert that to > "cs-200" or "sk-200" (or use one of the successor region subtags, > such as 'CZ' or 'SK'), since that is the most likely interpretation. > >3.3 Registration Procedure for Subtags > > The procedure given here MUST be used by anyone who wants to use a > subtag not currently in the IANA Language Subtag Registry. > > Only primary language and variant subtags will be considered for > independent registration. (Subtags required for stability and > subtags required to keep the registry synchronized with ISO 639, ISO > 15924, ISO 3166, and UN M.49 within the limits defined by this > document are the only exceptions to this. See Section 3.2.) > > This procedure MAY also be used to register or alter the information > for the "description", "note", or "recommended prefix" fields in a > subtag's record as described in Figure 2. Changes to all other > fields in the IANA registry are NOT permitted. > > If registering a new language subtag, the process starts by filling > > > >Phillips & Davis Expires September 11, 2005 [Page 27] > >Internet-Draft langtags March 2005 > > > out the registration form reproduced below. Note that each response > is not limited in size and should take the room necessary to > adequately describe the registration. > > LANGUAGE SUBTAG REGISTRATION FORM > 1. Name of requester: > 2. E-mail address of requester: > 3. Subtag to be registered: > 4. Type of Registration: > [ ] language > [ ] variant > 5. Description of subtag (in English or transcribed into ASCII): > 6. Intended meaning of the subtag: > 7. Recommended prefix(es) of subtag (for variants): > 8. Native name of the language or variation (transcribed into ASCII): > 9. Reference to published description of the language (book or article): > 10. Any other relevant information: > > Figure 4 > > The subtag registration form MUST be sent to > for a two week review period before it can > be submitted to IANA. (This is an open list. Requests to be added > should be sent to .) > > Variant subtags are generally registered for use with a particular > range of language tags. For example, the subtag 'boont' is intended > for use with language tags that start with the primary language > subtag "en", since Boontling is a dialect of English. Thus the > subtag 'boont' could be included in tags such as "en-Latn-boont" or > "en-US-boont". This information is stored in the "recommended > prefix" field in the registry and MUST be provided in the > registration form. > > Any subtag MAY be incorporated into a variety of language tags, > according to the rules of Section 2.1, including tags that do not > match any of the recommended prefixes of the registered subtag. > (Note that this is probably a poor choice.) This makes validation > simpler and thus more uniform across implementations, and does not > require the registration of a separate subtag for the same purpose > and meaning but a different recommended prefix. > > The recommended prefixes for a given registered subtag will be > maintained in the IANA registry as a guide to usage. If it is > necessary to add an additional prefix to that list for an existing > language tag, that can be done by filing an additional registration > form. In that form, the "Any other relevant information:" field > should indicate that it is the addition of an additional recommended > > > >Phillips & Davis Expires September 11, 2005 [Page 28] > >Internet-Draft langtags March 2005 > > > prefix. > > Requests to add a recommended prefix to a subtag that imply a > different semantic meaning will probably be rejected. For example, a > request to add the prefix "de" to the subtag 'nedis' so that the tag > "de-nedis" represented some German dialect would be rejected. The > 'nedis' subtag represents a particular Slovenian dialect and the > additional registration would change the semantic meaning assigned to > the subtag. A separate subtag should be proposed instead. > > The Language Subtag Reviewer is responsible for responding to > requests for the registration of subtags through the registration > process and is appointed by the IESG. > > When the two week period has passed the Language Subtag Reviewer > either forwards the request to iana@iana.org, or rejects it because > of significant objections raised on the list or due to problems with > constraints in this document (which should be explicitly cited). The > reviewer may also extend the review period in two week increments to > permit further discussion. The reviewer must indicate on the list > whether the registration has been accepted, rejected, or extended > following each two week period. > > Note that the reviewer can raise objections on the list if he or she > so desires. The important thing is that the objection must be made > publicly. > > The applicant is free to modify a rejected application with > additional information and submit it again; this restarts the two > week comment period. > > Decisions made by the reviewer may be appealed to the IESG [RFC 2028] > [10] under the same rules as other IETF decisions [RFC 2026] [21]. > > All approved registration forms are available online in the directory > http://www.iana.org/numbers.html under "languages". > > Updates of registrations follow the same procedure as registrations. > The subtag reviewer decides whether to allow a new registrant to > update a registration made by someone else; normally objections by > the original registrant would carry extra weight in such a decision. > > Registrations are permanent and stable. Once registered, subtags > will not be removed from the registry and will remain the canonical > method of referring to a specific language or variant. This > provision does not apply to grandfathered tags, which may become > deprecated due to registration of subtags. For example, the tag > "i-navajo" is deprecated in favor of the ISO 639-1 based subtag 'nv'. > > > >Phillips & Davis Expires September 11, 2005 [Page 29] > >Internet-Draft langtags March 2005 > > > Note: The purpose of the "published description" in the registration > form is intended as an aid to people trying to verify whether a > language is registered or what language or language variation a > particular subtag refers to. In most cases, reference to an > authoritative grammar or dictionary of that language will be useful; > in cases where no such work exists, other well known works describing > that language or in that language may be appropriate. The subtag > reviewer decides what constitutes "good enough" reference material. > This requirement is not intended to exclude particular languages or > dialects due to the size of the speaker population or lack of a > standardized orthography. Minority languages will be considered > equally on their own merits. > >3.4 Extensions and Extensions Namespace > > Extension subtags are those introduced by single-letter subtags other > than 'x-'. They are reserved for the generation of identifiers which > contain a language component, and are compatible with applications > that process language tags according to this specification. For > example, they might be used to define locale identifiers, which are > generally based on language. > > The structure and form of extensions are defined by this document so > that implementations can be created that are forward compatible with > applications that may be created using single-letter subtags in the > future. In addition, defining a mechanism for maintaining > single-letter subtags will lend to the stability of this document by > reducing the likely need for future revisions or updates. > > IANA will maintain a registry of allocated single-letter subtags. > This registry contains the following information: letter identifier; > name; purpose; RFC defining the subtag namespace and its use; and the > name, URL, and email address of the maintaining authority. > > Allocation of a single-letter subtag shall take the form of an RFC > defining the name, purpose, processes, and procedures for maintaining > the subtags. The maintaining or registering authority, including > name, contact email, discussion list email, and URL location of the > registry must be indicated clearly in the RFC. The RFC MUST specify > each of the following: > o The specification MUST reference the specific version or revision > of this document that govern its creation and MUST reference this > section of this document. > o The specification and all subtags defined by the specification > MUST follow the ABNF and other rules for the formation of tags and > subtags as defined in this document. In particular it MUST > specify that case is not significant. > > > > >Phillips & Davis Expires September 11, 2005 [Page 30] > >Internet-Draft langtags March 2005 > > > o The specification MUST specify a canonical representation. > o The specification of valid subtags MUST be available over the > Internet and at no cost. > o The specification MUST be in the public domain or available via a > royalty-free license acceptable to the IETF and specified in the > RFC. > o The specification MUST be versioned and each version of the > specification MUST be numbered, dated, and stable. > o The specification MUST be stable. That is, extension subtags, > once defined by a specification, MUST NOT be retracted or change > in meaning in any substantial way. > o IANA MUST be informed of changes to the contact information and > URL for the specification. > > The determination of whether an Internet-Draft meets the above > conditions and the decision to grant or withhold such authority rests > solely with the IESG, and is subject to the normal review and appeals > process associated with the RFC process. > > Extension authors are strongly cautioned that many (including most > well-formed) processors will be unaware of any special relationships > or meaning inherent in the order of extension subtags. Extension > authors SHOULD avoid subtag relationships or canonicalization > mechanisms that interfere with matching or with length restrictions > that may exist in common protocols where the extension is used. In > particular, applications may truncate the subtags in doing matching > or in fitting into limited lengths, so it is RECOMMENDED that the > most significant information be in the most significant (left-most) > subtags, and that the specification gracefully handle truncated > subtags. > > When a language tag is to be used in a specific, known, protocol, it > is RECOMMENDED that that the language tag not contain extensions not > supported by that protocol. In addition, it should be noted that > some protocols may impose upper limits on the length of the strings > used to store or transport the language tag. > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 31] > >Internet-Draft langtags March 2005 > > >4. Security Considerations > > The only security issue that has been raised with language tags since > the publication of RFC 1766, which stated that "Security issues are > believed to be irrelevant to this memo", is a concern with language > identifiers used in content negotiation - that they may be used to > infer the nationality of the sender, and thus identify potential > targets for surveillance. > > This is a special case of the general problem that anything you send > is visible to the receiving party. It is useful to be aware that > such concerns can exist in some cases. > > The evaluation of the exact magnitude of the threat, and any possible > countermeasures, is left to each application protocol. > > Although the specification of valid subtags for an extension MUST be > available over the Internet, implementations SHOULD NOT mechanically > depend on it being always accessible, to prevent denial-of-service > attacks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 32] > >Internet-Draft langtags March 2005 > > >5. Character Set Considerations > > The syntax in this document requires that language tags use only the > characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most > character sets, so presentation of language tags should not have any > character set issues. > > Rendering of characters based on the content of a language tag is not > addressed in this memo. Historically, some languages have relied on > the use of specific character sets or other information in order to > infer how a specific character should be rendered (notably this > applies to language and culture specific variations of Han ideographs > as used in Japanese, Chinese, and Korean). When language tags are > applied to spans of text, rendering engines may use that information > in deciding which font to use in the absence of other information, > particularly where languages with distinct writing traditions use the > same characters. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 33] > >Internet-Draft langtags March 2005 > > >6. Changes from RFC 3066 > > The main goals for this revision of language tags were the following: > > *Compatibility.* All valid RFC 3066 language tags (including those > in the IANA registry) remain valid in this specification. Thus > there is complete backward compatibility of this specification with > existing content. In addition, this document defines language tags > in such as way as to ensure future compatibility, and processors > based solely on the RFC 3066 ABNF (such as those described in XML > Schema version 1.0) will be able to process tags described by this > document. > > *Stability.* Because of the changes in underlying ISO standards, a > valid RFC 3066 language tag may become invalid (or have its meaning > change) at a later date. With so much of the world's computing > infrastructure dependent on language tags, this is simply > unacceptable: it invalidates content that may have an extensive > shelf-life. In this specification, once a language tag is valid, it > remains valid forever. Previously, there was no way to determine > when two tags were equivalent. This specification provides a stable > mechanism for doing so, through the use of canonical forms. These > are also stable, so that implementations can depend on the use of > canonical forms to assess equivalency. > > *Validity.* The structure of language tags defined by this document > makes it possible to determine if a particular tag is well-formed > without regard for the actual content or "meaning" of the tag as a > whole. This is important because the registry and underlying > standards change over time. In addition, it must be possible to > determine if a tag is valid (or not) for a given point in time in > order to provide reproducible, testable results. This process must > not be error-prone; otherwise even intelligent people will generate > implementations that give different results. This specification > provides for that by having a single data file, with specific > versioning information, so that the validity of language tags at any > point in time can be precisely determined (instead of interpolating > values from many separate sources). > > *Extensibility.* It is important to be able to differentiate between > written forms of language -- for many implementations this is more > important than distinguishing between spoken variants of a language. > Languages are written in a wide variety of different scripts, so this > document provides for the generative use of ISO 15924 script codes. > Like the generative use of ISO language and country codes in RFC > 3066, this allows combinations to be produced without resorting to > the registration process. The addition of UN codes provides for the > generation of language tags with regional scope, which is also > > > >Phillips & Davis Expires September 11, 2005 [Page 34] > >Internet-Draft langtags March 2005 > > > required for information technology. > > The recast of the registry from containing whole language tags to > subtags is a key part of this. An important feature of RFC 3066 was > that it allowed generative use of subtags. This allows people to > meaningfully use generated tags, without the delays in registering > whole tags, and the burden on the registry of having to supply all of > the combinations that people may find useful. > > Because of the widespread use of language tags, it is potentially > disruptive to have periodic revisions of the core specification, > despite demonstrated need. The extension mechanism provides for a > way for independent RFCs to define extensions to language tags. > These extensions have a very constrained, well-defined structure to > prevent extensions from interfering with implementations of language > tags defined in this document. The document also anticipates > features of ISO 639-3 with the addition of the extlang subtags. The > use and definition of private use tags has also been modified, to > allow people to move as much information as possible out of private > use tags, and into the regular structure. The goal is to > dramatically reduce the need to produce a revision of this document > in the future. > > The specific changes in this document to meet these goals are: > o Defines the ABNF and rules for subtags so that the category of all > subtags can be determined without reference to the registry. > o Adds the concept of well-formed vs. validating processors, > defining the rules by which an implementation can claim to be one > or the other. > o Changes the IANA language tag registry to a language subtag > registry that provides a complete list of valid subtags in the > IANA registry. This allows for robust implementation and ease of > maintenance. The language subtag registry becomes the canonical > source for forming language tags. > o Provides a process that guarantees stability of language tags, by > handling reuse of values by ISO 639, ISO 15924, and ISO 3166 in > the event that they register a previously used value for a new > purpose. > o Allows ISO 15924 script code subtags and allows them to be used > generatively. Adds the concept of a variant subtag and allows > variants to be used generatively. Adds the ability to use a class > of UN tags as regions. > o Defines the private-use tags in ISO 639, ISO 15924, and ISO 3166 > as the mechanism for creating private-use language, script, and > region subtags respectively. > o Adds a well-defined extension mechanism. > o Defines an extended language subtag, possibly for use with certain > anticipated features of ISO 639-3. > > > >Phillips & Davis Expires September 11, 2005 [Page 35] > >Internet-Draft langtags March 2005 > > > Ed Note: The following items are provided for the convenience of > reviewers and will be removed from the final document. > > Changes between draft-phillips-langtags-10 and this version are: > o Expunged the terminology "language range", since that section goes > with matching (A.Phillips, M.Davis) > o Added text describing the handling of existing RFC 3066 registry > entries that were deprecated prior to the adoption of this > document. These tags are now grandfathered. (A.Phillips, > D.Ewell) > o Modified the conversion rules for the registry (Appendix C) to > refer to the chairs, the LTRU mail list and so forth (A.Phillips) > o Added text to allow tags and subtags to be deprecated using the > canonical value "--". This is applied to codes withdrawn by ISO > 639 MA and ISO 3166 MA, for example. (F.Ellerman, D.Ewell) > >7. References > > [1] International Organization for Standardization, "ISO > 639-1:2002, Codes for the representation of names of languages > -- Part 1: Alpha-2 code", ISO Standard 639, 2002. > > [2] International Organization for Standardization, "ISO 639-2:1998 > - Codes for the representation of names of languages -- Part 2: > Alpha-3 code - edition 1", August 1988. > > [3] ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the > representation of names of scripts", January 2004. > > [4] International Organization for Standardization, "Codes for the > representation of names of countries, 3rd edition", > ISO Standard 3166, August 1988. > > [5] Statistical Division, United Nations, "Standard Country or Area > Codes for Statistical Use", UN Standard Country or Area Codes > for Statistical Use, Revision 4 (United Nations publication, > Sales No. 98.XVII.9, June 1999. > > [6] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory > Committee: Working principles for ISO 639 maintenance", March > 2000, > . > > [7] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 > and RFC 822", RFC 1327, May 1992. > > [8] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail > Extensions) Part One: Mechanisms for Specifying and Describing > > > >Phillips & Davis Expires September 11, 2005 [Page 36] > >Internet-Draft langtags March 2005 > > > the Format of Internet Message Bodies", RFC 1521, September > 1993. > > [9] Alvestrand, H., "Tags for the Identification of Languages", > RFC 1766, March 1995. > > [10] Hovey, R. and S. Bradner, "The Organizations Involved in the > IETF Standards Process", BCP 11, RFC 2028, October 1996. > > [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [12] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word > Extensions: Character Sets, Languages, and Continuations", > RFC 2231, November 1997. > > [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997. > > [14] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform > Resource Identifiers (URI): Generic Syntax", RFC 2396, August > 1998. > > [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA > Considerations Section in RFCs", BCP 26, RFC 2434, October > 1998. > > [16] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., > Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- > HTTP/1.1", RFC 2616, June 1999. > > [17] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of > Understanding Concerning the Technical Work of the Internet > Assigned Numbers Authority", RFC 2860, June 2000. > > [18] Alvestrand, H., "Tags for the Identification of Languages", > BCP 47, RFC 3066, January 2001. > > [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", > STD 63, RFC 3629, November 2003. > > [20] Klyne, G. and C. Newman, "Date and Time on the Internet: > Timestamps", RFC 3339, July 2002. > > [21] > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 37] > >Internet-Draft langtags March 2005 > > >Authors' Addresses > > Addison Phillips (editor) > Quest Software > > Email: addison.phillips@quest.com > > > Mark Davis (editor) > IBM > > Email: mark.davis@us.ibm.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 38] > >Internet-Draft langtags March 2005 > > >Appendix A. Acknowledgements > > Any list of contributors is bound to be incomplete; please regard the > following as only a selection from the group of people who have > contributed to make this document what it is today. > > The contributors to RFC 3066 and RFC 1766, the precursors of this > document, made enormous contributions directly or indirectly to this > document and are generally responsible for the success of language > tags. > > The following people (in alphabetical order) contributed to this > document or to RFCs 1766 and 3066: > > Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet, > Nathaniel Borenstein, Eric Brunner, Sean M. Burke, Jeremy Carroll, > John Clews, Jim Conklin, Peter Constable, John Cowan, Mark Crispin, > Dave Crocker, Martin Duerst, Frank Ellerman, Michael Everson, Doug > Ewell, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, > Joel Halpren, Elliotte Rusty Harold, Paul Hoffman, Richard Ishida, > Olle Jarnefors, Kent Karlsson, John Klensin, Alain LaBonte, Eric > Mader, Keith Moore, Chris Newman, Masataka Ohta, George Rhoten, > Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto Stolz, Tex > Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois Yergeau and > many, many others. > > Very special thanks must go to Harald Tveit Alvestrand, who > originated RFCs 1766 and 3066, and without whom this document would > not have been possible. Special thanks must go to Michael Everson, > who has served as language tag reviewer for almost the complete > period since the publication of RFC 1766. Special thanks to Doug > Ewell, for his production of the first complete subtag registry, and > his work in producing a test parser for verifying language tags. > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 39] > >Internet-Draft langtags March 2005 > > >Appendix B. Examples of Language Tags (Informative) > > Simple language subtag: > de (German) > fr (French) > ja (Japanese) > i-enochian (example of a grandfathered tag) > > Language subtag plus Script subtag: > zh-Hant (Traditional Chinese) > en-Latn (English written in Latin script) > sr-Cyrl (Serbian written with Cyrillic script) > > Language-Script-Region: > zh-Hans-CN (Simplified Chinese for the PRC) > sr-Latn-CS (Serbian, Latin script, Serbia and Montenegro) > > Language-Script-Region-Variant: > en-Latn-US-boont (Boontling dialect of English) > de-Latn-CH-1996 (German written in Latin script for Switzerland > using the orthography of 1996) > > Language-Region: > de-DE (German for Germany) > zh-SG (Chinese for Singapore) > cs-200 (Czech for Czechoslovakia) > sr-CS (Serbian for Serbia and Montenegro) > es-419 (Spanish for Latin America and Caribbean region using the > UN region code) > > Other Mixtures: > en-boont (Boontling dialect of English) > > private-use mechanism: > de-CH-x-phonebk > az-Arab-x-AZE-derbend > > Extended language subtags (examples ONLY: extended languages must be > defined by revision or update to this document): > zh-min > zh-min-nan-Hant-CN > > Private-use subtags: > x-whatever (private use using the singleton 'x') > qaa-Qaaa-QM-x-southern (all private tags) > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 40] > >Internet-Draft langtags March 2005 > > > de-Qaaa (German, with a private script) > de-Latn-QM (German, Latin-script, private region) > de-Qaaa-DE (German, private script, for Germany) > > Tags that use extensions (examples ONLY: extensions must be defined > by revision or update to this document or by RFC): > en-US-u-islamCal > zh-CN-a-myExt-x-private > en-a-myExt-b-another > > Some Invalid Tags: > de-419-DE (two region tags) > a-DE (use of a single character subtag in primary position; note > that there are a few grandfathered tags that start with "i-" that > are valid) > ar-a-aaa-b-bbb-a-ccc (two extensions with same single letter > prefix) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 41] > >Internet-Draft langtags March 2005 > > >Appendix C. Conversion of the RFC 3066 Language Tag Registry > > Upon publication of this document as a BCP, the existing IANA > language tag registry must be converted into the new subtag registry. > This section defines the process for performing this conversion. > > The impact on the IANA maintainers of the registry of this conversion > will be a small increase in the frequency of new entries. The > initial set of records represents no impact on IANA, since the work > to create it will be performed externally. > > When this document is published, an email will be sent by the > chair(s) of the LTRU working group to the LTRU and ietf-languages > mail lists advising of the impending conversion of the registry. In > that notice, the chair(s) will provide a URL whose referred content > is the proposed IANA Language Subtag Registry following conversion. > There will be a Last Call period of not less than four weeks for > comments and corrections to be discussed on the > ietf-languages@iana.org mail list. Changes as a result of comments > will not restart the Last Call period. At the end of the period, the > chair(s) will forward the URL to IANA, which will post the new > registry on-line. > > Tags that are currently deprecated will be maintained as > grandfathered entries. The record for the grandfathered entry will > contain a note indicating that the entry is 'deprecated' and reason > for the deprecation. For example, the tag "art-lojban" is deprecated > and will be placed in the grandfathered section. > > Tags that are not deprecated that consist entirely of subtags that > are valid under this document and which have the correct form and > format for tags defined by this document are superseded by this > document. Such tags are placed in the 'redundant' section of the > registry. For example, zh-Hant is now defined by this document. > > Tags that contain subtags which are consistent with registration > under the guidelines in this document will have a new subtag > registration created for each eligible subtag. If all of the subtags > in the original tag are fully defined by the resulting registrations > or by this document, then the original tag is superseded by this > document. Such tags are placed in the 'redundant' section of the > registry. For example, en-boont will result in a new subtag "boont" > and the RFC 3066 registered tag 'en-boont' placed in the redundant > section of the registry. > > Tags that contain one or more subtags that do not match the valid > registration pattern and which are not otherwise defined by this > document are marked as 'grandfathered' by this document. > > > >Phillips & Davis Expires September 11, 2005 [Page 42] > >Internet-Draft langtags March 2005 > > > There will be a reasonable period in which the community may comment > on the proposed list entries, which SHALL be no less than four weeks > in length. At the completion of this period, the chair(s) will > notify iana@iana.org and the ltru and ietf-languages mail lists that > the task is complete and forward the necessary materials to IANA for > publication. > > Registrations that are in process under the rules defined in RFC 3066 > MAY be completed under the former rules, at the discretion of the > language tag reviewer. Any new registrations submitted after the > request for conversion of the registry MUST be rejected. > > All existing RFC 3066 language tag registrations will be maintained > in perpetuity. > > Users of tags that are grandfathered should consider registering > appropriate subtags in the IANA subtag registry (but are not required > to). > > Where two subtags have the same meaning, the priority of which to > make canonical SHALL be the following: > o As of the date of acceptance of this document as a BCP, if a code > exists in the associated ISO standard and it is not deprecated or > withdrawn as of that date, then it has priority. > o Otherwise, the earlier-registered tag in the associated ISO > standard has priority. > > UN numeric codes assigned to 'macro-geographical (continental)' or > sub-regions not associated with an assigned ISO 3166 alpha-2 code are > defined in the IANA registry and are valid for use in language tags. > These codes MUST be added to the initial version of the registry. > The UN numeric codes for 'economic groupings' or 'other groupings', > and the alphanumeric codes in Appendix X of the UN document MUST NOT > be added to the registry. > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 43] > >Internet-Draft langtags March 2005 > > >Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > >Disclaimer of Validity > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > >Copyright Statement > > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > >Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > >Phillips & Davis Expires September 11, 2005 [Page 44] _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 15:49:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17812; Tue, 15 Mar 2005 15:49:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJ2L-0006eS-EQ; Tue, 15 Mar 2005 15:53:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBIx4-0003jC-Q3; Tue, 15 Mar 2005 15:47:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBIx3-0003fo-AS for ltru@megatron.ietf.org; Tue, 15 Mar 2005 15:47:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17563 for ; Tue, 15 Mar 2005 15:47:37 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJ0t-0006Z7-VN for ltru@ietf.org; Tue, 15 Mar 2005 15:51:41 -0500 Received: from lns-p19-19-idf-82-254-246-100.adsl.proxad.net ([82.254.246.100] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DBIwu-00046U-8s; Tue, 15 Mar 2005 12:47:32 -0800 Message-Id: <6.1.2.0.2.20050315203041.036b5090@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 15 Mar 2005 21:47:22 +0100 To: "Addison Phillips" , "Frank Ellermann" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b At 18:14 15/03/2005, Addison Phillips wrote: >Allowing multiple subtags to mean the same thing, as Frank suggests below, >would be a problem. Many language tag processors that I know of are >implemented based solely on the values of the tags themselves, with no >external knowledge baked into them. The existence of a registry might >change that to some degree, but you'll still have many of what the draft >calls "well-formed" processors for which "GB" is just a token. I question myself on this. The DNS is 22 years old, the mail older. I understand that one wants to be careful at not changing them too much - yet the market will change them if it solved the spam. IDNs are one year and a half old and several consider that one can still change or even kill them. As far as I understand, you refer to applications resulting from RFC 3066, and may be from its predecessor? So they are 3 to 7 years old? They most probably are browsers/aplications which have anyway to be updated to support IDNs (applications needing to check languages are likely to also use IDNs)? We are going to have a lot of changes in the DNS in the coming month to support the local TLDs which are to be a must. The support of the Tables will probably be required at users level, for 3+LD consistency checks,etc. (even if not planned yet). Many other applications would probably want then to use functions using country codes if they were available. Microsoft always said they wanted to watch the market reaction before implementing the IDN support in the OS. This WG could consider user located functions to get and integrate the IANA cc table and updates . It could then use them. Would it not be better to start anew while there is still a "small" base (RFC 3066 is still here for them) rather than to continue for ever with an old system? BTW I personally think the IDN Tables and other TLD infos (such as the lingual aliases of the TLDs) are part of the Locale, jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 15:52:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18432; Tue, 15 Mar 2005 15:52:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJ5L-0006tD-GV; Tue, 15 Mar 2005 15:56:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJ0S-0005X8-5g; Tue, 15 Mar 2005 15:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJ0Q-0005X3-Ob for ltru@megatron.ietf.org; Tue, 15 Mar 2005 15:51:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18075 for ; Tue, 15 Mar 2005 15:51:08 -0500 (EST) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJ4G-0006qT-LU; Tue, 15 Mar 2005 15:55:12 -0500 Received: from h-68-165-5-84.snvacaid.dynamic.covad.net ([68.165.5.84] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DBJ0G-0006nL-00; Tue, 15 Mar 2005 12:51:01 -0800 Message-ID: <001d01c529a0$c1f08a00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Dinara Suleymanova" References: <634978A7DF025A40BFEF33EB191E13BC0A924C02@irvmbxw01.quest.com> <6.1.0.6.2.20050315143149.0202bec0@odin.ietf.org> Subject: Re: [Ltru] Re: Working Group submission: LTRU Registry Draft 00 Date: Tue, 15 Mar 2005 12:51:07 -0800 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-Spam-Score: 2.3 (++) X-Scan-Signature: d13c2ca5541a74ff83822b4b3ddbdd0b Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.3 (++) X-Scan-Signature: dae399da00b3daa34cc88bf89ead3cc4 Hi - Approved. Our previous approval request was sent to internet-drafts@ietf.org on March 10. (Copy included below) Randy Presuhn, ltru co-chair. ================================================ Status: U Return-Path: Received: from maynard.mail.mindspring.net ([207.69.200.243]) by strange.mail.mindspring.net (EarthLink SMTP Server) with ESMTP id 1d9zC46oV3Nl3oW0 for ; Thu, 10 Mar 2005 21:10:52 -0500 (EST) Received: from [192.168.167.40] (helo=wamui02.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D9Zc1-0003Rd-00; Thu, 10 Mar 2005 21:10:49 -0500 Message-ID: <26503169.1110507049502.JavaMail.root@wamui02.slb.atl.earthlink.net> Date: Thu, 10 Mar 2005 20:10:49 -0600 (GMT-06:00) From: Randy Presuhn Reply-To: Randy Presuhn To: internet-drafts@ietf.org Subject: permission to post ltru wg -00- drafts Cc: duerst@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-ELNK-AV: 0 Hi - This note is to let you know that Martin Duerst and I, co-chairs of the ltru working group, expect Mark Davis and Addison Phillips to be submitting two working group internet drafts in the next few days. The draft names will be draft-ietf-ltru-registry-00.txt draft-ietf-ltru-matching-00.txt You have our advance permission to post these documents. Randy Presuhn ltru WG co-chair ================================================= > From: "Dinara Suleymanova" > To: "Addison Phillips" > Cc: "LTRU Working Group" > Sent: Tuesday, March 15, 2005 11:32 AM > Subject: [Ltru] Re: Working Group submission: LTRU Registry Draft 00 > > This has to be approved by the wg chairs. > > At 03:10 PM 3/12/2005, Addison Phillips wrote: > >Dear Editor, > > > >Please find attached in text format draft-00 of "draft-ietf-ltru-registry". > > > >I understand that this will be processed after IETF-62. > > > >Best Regards, > > > >Addison (for the editors) > > > >Addison P. Phillips > >Globalization Architect, Quest Software > >http://www.quest.com > > > >Chair, W3C Internationalization Core Working Group > >http://www.w3.org/International > > > >Internationalization is not a feature. > >It is an architecture. > > > > > > > > > >Network Working Group A. Phillips, Ed. > >Internet-Draft Quest Software > >Expires: September 11, 2005 M. Davis, Ed. > > IBM > > March 10, 2005 > > > > > > Tags for Identifying Languages > > draft-ietf-ltru-registry-00 > > > >Status of this Memo > > > > This document is an Internet-Draft and is subject to all provisions > > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > > author represents that any applicable patent or other IPR claims of > > which he or she is aware have been or will be disclosed, and any of > > which he or she become aware will be disclosed, in accordance with > > RFC 3668. > > > > 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 September 11, 2005. > > > >Copyright Notice > > > > Copyright (C) The Internet Society (2005). > > > >Abstract > > > > This document describes the structure, content, construction, and > > semantics of language tags for use in cases where it is desirable to > > indicate the language used in an information object. It also > > describes how to register values for use in language tags and the > > creation of user defined extensions for private interchange. This > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 1] > > > >Internet-Draft langtags March 2005 > > > > > > document obsoletes RFC 3066 (which replaced RFC 1766). > > > >Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. The Language Tag . . . . . . . . . . . . . . . . . . . . . . 4 > > 2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2.1.1 Length Considerations . . . . . . . . . . . . . . . . 5 > > 2.2 Language Subtag Sources and Interpretation . . . . . . . . 6 > > 2.2.1 Primary Language Subtag . . . . . . . . . . . . . . . 7 > > 2.2.2 Extended Language Subtags . . . . . . . . . . . . . . 9 > > 2.2.3 Script Subtag . . . . . . . . . . . . . . . . . . . . 9 > > 2.2.4 Region Subtag . . . . . . . . . . . . . . . . . . . . 10 > > 2.2.5 Variant Subtags . . . . . . . . . . . . . . . . . . . 11 > > 2.2.6 Extension Subtags . . . . . . . . . . . . . . . . . . 11 > > 2.2.7 Private Use Subtags . . . . . . . . . . . . . . . . . 12 > > 2.2.8 Pre-Existing RFC 3066 Registrations . . . . . . . . . 13 > > 2.2.9 Possibilities for Registration . . . . . . . . . . . . 13 > > 2.2.10 Classes of Conformance . . . . . . . . . . . . . . . 14 > > 2.3 Choice of Language Tag . . . . . . . . . . . . . . . . . . 15 > > 2.4 Meaning of the Language Tag . . . . . . . . . . . . . . . 16 > > 2.4.1 Canonicalization of Language Tags . . . . . . . . . . 17 > > 2.5 Considerations for Private Use Subtags . . . . . . . . . . 18 > > 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 > > 3.1 Format of the IANA Language Subtag Registry . . . . . . . 20 > > 3.2 Stability of IANA Registry Entries . . . . . . . . . . . . 24 > > 3.3 Registration Procedure for Subtags . . . . . . . . . . . . 27 > > 3.4 Extensions and Extensions Namespace . . . . . . . . . . . 30 > > 4. Security Considerations . . . . . . . . . . . . . . . . . . 32 > > 5. Character Set Considerations . . . . . . . . . . . . . . . . 33 > > 6. Changes from RFC 3066 . . . . . . . . . . . . . . . . . . . 34 > > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 > > A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 > > B. Examples of Language Tags (Informative) . . . . . . . . . . 40 > > C. Conversion of the RFC 3066 Language Tag Registry . . . . . . 42 > > Intellectual Property and Copyright Statements . . . . . . . 44 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 2] > > > >Internet-Draft langtags March 2005 > > > > > >1. Introduction > > > > Human beings on our planet have, past and present, used a number of > > languages. There are many reasons why one would want to identify the > > language used when presenting or requesting information. > > > > Information about a user's language preferences commonly needs to be > > identified so that appropriate processing can be applied. For > > example, the user's language preferences in a browser can be used to > > select web pages appropriately. A choice of language preference can > > also be used to select among tools (such as dictionaries) to assist > > in the processing or understanding of content in different languages. > > > > In addition, knowledge about the particular language used by some > > piece of information content may be useful or even required by some > > types of information processing; for example spell-checking, > > computer-synthesized speech, Braille transcription, or high-quality > > print renderings. > > > > One means of indicating the language used is by labeling the > > information content with a language identifier. These identifiers > > can also be used to specify user preferences when selecting > > information content, or for labeling additional attributes of content > > and associated resources. > > > > These identifiers can also be used to indicate additional attributes > > of content that are closely related to the language. In particular, > > it is often necessary to indicate specific information about the > > dialect, writing system, or orthography used in a document or > > resource, as these attributes may be important for the user to obtain > > information in a form that they can understand, or important in > > selecting appropriate processing resources for the given content. > > > > This document specifies an identifier mechanism and a registration > > function for values to be used with that identifier mechanism. It > > also defines a mechanism for private use values and future extension. > > > > This document replaces RFC 3066, which replaced RFC 1766. For a list > > of changes in this document, see Section 6. > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC 2119] [11]. > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 3] > > > >Internet-Draft langtags March 2005 > > > > > >2. The Language Tag > > > >2.1 Syntax > > > > The language tag is composed of one or more parts: A primary language > > subtag and a (possibly empty) series of subsequent subtags. Subtags > > are distinguished by their length, position in the subtag sequence, > > and content, so that each type of subtag can be recognized solely by > > these features. This makes it possible to construct a parser that > > can extract and assign some semantic information to the subtags, even > > if specific subtag values are not recognized. Thus a parser need not > > have an up-to-date copy of the registered subtag values to perform > > most searching and matching operations. > > > > The syntax of this tag in ABNF [RFC 2234] [13] is: > > > > Language-Tag = (lang > > *("-" extlang) > > ["-" script] > > ["-" region] > > *("-" variant) > > *("-" extension) > > ["-" privateuse]) > > / privateuse ; private-use tag > > / grandfathered ; grandfathered registrations > > > > lang = 2*3ALPHA ; shortest ISO 639 code > > / registered-lang > > extlang = 3ALPHA ; reserved for future use > > script = 4ALPHA ; ISO 15924 code > > region = 2ALPHA ; ISO 3166 code > > / 3DIGIT ; UN country number > > variant = ALPHA (4*7alphanum) ; registered variants > > / DIGIT (3*7alphanum) > > extension = singleton 1*("-" (2*8alphanum)) ; extension subtag(s) > > privateuse = ("x"/"X") 1*("-" (1*8alphanum)) ; private use subtag(s) > > singleton = ("a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z") > > ; Single letters: x/X is reserved for private use > > registered-lang = 4*8ALPHA ; registered language subtag > > grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered > > registration > > ; Note: i is the only singleton > > that starts > > ; a grandfathered tag > > alphanum = (ALPHA / DIGIT) ; letters and numbers > > > > Figure 1: Language Tag ABNF > > > > The character "-" is HYPHEN-MINUS (ABNF: %x2D). Note that there is a > > subtlety in the ABNF for 'variant': variants may consist of sequences > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 4] > > > >Internet-Draft langtags March 2005 > > > > > > of up to eight characters. > > > > Whitespace is not permitted in a language tag. For examples of > > language tags, see Appendix B. > > > > Note that although [RFC 2234] [13] refers to octets, the language > > tags described in this document are sequences of characters from the > > US-ASCII repertoire. Language tags may be used in documents and > > applications that use other encodings, so long as these encompass the > > US-ASCII repertoire. An example of this would be an XML document > > that uses the Unicode UTF-16LE encoding. > > > > The tags and their subtags, including private-use and extensions, are > > to be treated as case insensitive: there exist conventions for the > > capitalization of some of the subtags, but these should not be taken > > to carry meaning. > > > > For example: > > o [ISO 639] [1] recommends that language codes be written in lower > > case ('mn' Mongolian). > > o [ISO 3166] [4] recommends that country codes be capitalized ('MN' > > Mongolia). > > o [ISO 15924] [3] recommends that script codes use lower case with > > the initial letter capitalized ('Cyrl' Cyrillic). > > However, in the tags defined by this document, the uppercase US-ASCII > > letters in the range 'A' (ABNF: %x41) through 'Z' (ABNF: %x5A) are > > considered equivalent and mapped directly to their US-ASCII lowercase > > equivalents in the range 'a' (ABNF: %x61) through 'z' (ABNF: %x7A). > > Thus the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or > > "mN-cYrL-Mn" (or any other combination) and each of these variations > > conveys the same meaning: Mongolian written in the Cyrillic script as > > used in Mongolia. > > > > For informative examples of language tags, see Appendix B at the end > > of this document. > > > >2.1.1 Length Considerations > > > > Although neither the ABNF nor other guidelines in this document > > provide a fixed upper limit on the number of size of subtags in a > > Language Tag and it is possible to envision quite long and complex > > subtag sequences, in practice these are rare because additional > > granularity in tags seldom adds useful distinguishing information and > > because longer, more granular tags interefere with the meaning, > > understanding, and processing of language tags. > > > > In particular, variant subtags SHOULD be used only with their > > recommended prefix. This limits most tags to a sequence of four > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 5] > > > >Internet-Draft langtags March 2005 > > > > > > subtags (excluding any extensions or private use sequences). See > > Section 2.3 for more information on selecting the most appropriate > > Language Tag. > > > > A conformant implementation need not support the storage of language > > tags which exceed a specified length. For an example, see [RFC 2231] > > [12]. Any such a limitation MUST be clearly documented, and such > > documentation SHOULD include the disposition of any longer tags (for > > example, whether an error value is generated or the language tag is > > truncated). If truncation is permitted it SHOULD NOT permit a subtag > > to be divided. > > > >2.2 Language Subtag Sources and Interpretation > > > > The namespace of language tags and their subtags is administered by > > the Internet Assigned Numbers Authority (IANA) [17] according to the > > rules in Section 3 of this document. The registry maintained by IANA > > is the source for valid subtags: other standards referenced in this > > section provide the source material for that registry. > > > > Terminology in this section: > > > > o Tag or tags refers to a complete language tag, such as > > "fr-Latn-CA". Examples of tags in this document are enclosed in > > double-quotes ("en-US"). > > o Subtag refers to a specific section of a tag, separated by hyphen, > > such as the subtag 'Latn' in "fr-Latn-CA". Examples of subtags in > > this document are enclosed in single quotes ('Latn'). > > o Code or codes refers to tags defined in external standards (and > > which are used as subtags in this document). For example, 'Latn' > > is an [ISO 15924] [3] script code which was used to define the > > 'Latn' script subtag for use in a language tag. Examples of codes > > in this document are enclosed in single quotes ('en', 'Latn'). > > > > The definitions in this section apply to the various subtags within > > the language tags defined by this document, excepting those > > "grandfathered" tags defined in Section 2.2.8. > > > > Language tags are designed so that each subtag has unique length and > > content restrictions. These make identification of the subtag's type > > possible, even if the content of the subtag itself is unrecognized. > > This allows tags to be parsed and processed without reference to the > > latest version of the underlying standards or the IANA registry and > > makes the associated exception handling when parsing tags simpler. > > > > Subtags in the IANA registry that do not come from an underlying > > standard can only appear in specific positions in a tag. > > Specifically, they can only occur as primary language subtags or as > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 6] > > > >Internet-Draft langtags March 2005 > > > > > > variant subtags. > > > > Note that sequences of private-use and extension subtags MUST occur > > at the end of the sequence of subtags and MUST NOT be interspersed > > with subtags defined elsewhere in this document. > > > > Single letter and digit subtags are reserved for current or future > > use. These include the following current uses: > > > > o The single letter subtag 'x' is reserved to introduce a sequence > > of private-use subtags. The interpretation of any private-use > > subtags is defined solely by private agreement and is not defined > > by the rules in this section or in any standard or registry > > defined in this document. > > o All other single letter subtags are reserved to introduce > > standardized extension subtag sequences as described in > > Section 3.4. > > > > The single letter subtag 'i' is used by some grandfathered tags, such > > as "i-enochian", where it always appears in the first position and > > cannot be confused with an extension. > > > >2.2.1 Primary Language Subtag > > > > The primary subtag is the first subtag in a language tag and cannot > > be empty. Except as noted, the primary subtag is the language > > subtag. The following rules apply to the assignment and > > interpretation of the primary subtag: > > > > o All 2-character language subtags were defined in the IANA registry > > according to the assignments found in the standard ISO 639 Part 1, > > "ISO 639-1:2002, Codes for the representation of names of > > languages -- Part 1: Alpha-2 code" [ISO 639-1] [1], or using > > assignments subsequently made by the ISO 639 Part 1 maintenance > > agency or governing standardization bodies. > > o All 3-character language subtags were defined in the IANA registry > > according to the assignments found in ISO 639 Part 2, "ISO > > 639-2:1998 - Codes for the representation of names of languages -- > > Part 2: Alpha-3 code - edition 1" [ISO 639-2] [2], or assignments > > subsequently made by the ISO 639 Part 2 maintenance agency or > > governing standardization bodies. > > o The subtags in the range 'qaa' through 'qtz' are reserved for > > private use in language tags. These subtags correspond to codes > > reserved by ISO 639-2 for private use. These codes MAY be used > > for non-registered primary-language subtags (instead of using > > private-use subtags following 'x-'). Please refer to Section 2.5 > > for more information on private use subtags. > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 7] > > > >Internet-Draft langtags March 2005 > > > > > > o All language subtags of 4 to 8 characters in length in the IANA > > registry were defined via the registration process in Section 3.3 > > and MAY be used to form the primary language subtag. At the time > > this document was created, there were no examples of this kind of > > subtag and future registrations of this type will be discouraged: > > primary languages are STRONGLY RECOMMENDED for registration with > > ISO 639 and subtags rejected by ISO 639 will be closely > > scrutinized before they are registered with IANA. > > o The single character subtag 'x' as the primary subtag indicates > > that the language tag consists solely of subtags whose meaning is > > defined by private agreement. For example, in the tag "x-fr-CH", > > the subtags 'fr' and 'CH' should not be taken to represent the > > French language or the country of Switzerland (or any other value > > in the IANA registry) unless there is a private agreement in place > > to do so. See Section 2.5. > > o Other values MUST NOT be assigned to the primary subtag except by > > revision or update of this document. > > > > Note: For languages that have both an ISO 639-1 2-character code and > > an ISO 639-2 3-character code, only the ISO 639-1 2-character code is > > defined in the IANA registry. > > > > Note: For languages that have no ISO 639-1 2-character code and for > > which the ISO 639-2/T (Terminology) code and the ISO 639-2/B > > (Bibliographic) codes differ, only the Terminology code is defined in > > the IANA registry. At the time this document was created, all > > languages that had both kinds of 3-character code were also assigned > > a 2-character code; it is not expected that future assignments of > > this nature will occur. > > > > Note: To avoid problems with versioning and subtag choice as > > experienced during the transition between RFC 1766 and RFC 3066, as > > well as the canonical nature of subtags defined by this document, the > > ISO 639 Registration Authority Joint Advisory Committee (ISO > > 639/RA-JAC) has included the following statement in [6]: > > > > "A language code already in ISO 639-2 at the point of freezing ISO > > 639-1 shall not later be added to ISO 639-1. This is to ensure > > consistency in usage over time, since users are directed in Internet > > applications to employ the alpha-3 code when an alpha-2 code for that > > language is not available." > > > > In order to avoid instability of the canonical form of tags, if a > > 2-character code is added to ISO 639-1 for a language for which a > > 3-character code was already included in ISO 639-2, the 2-character > > code will not be added as a subtag in the registry. See Section 3.2. > > > > For example, if some content were tagged with 'haw' (Hawaiian), which > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 8] > > > >Internet-Draft langtags March 2005 > > > > > > currently has no 2-character code, the tag would not be invalidated > > if ISO 639-1 were to assign a 2-character code to the Hawaiian > > language at a later date. > > > > For example, one of the grandfathered IANA registrations is > > "i-enochian". The subtag 'enochian' could be registered in the IANA > > registry as a primary language subtag (assuming that ISO 639 does not > > register this language first), making tags such as "enochian-AQ" and > > "enochian-Latn" valid. > > > >2.2.2 Extended Language Subtags > > > > The following rules apply to the extended language subtags: > > > > o Three letter subtags immediately following the primary subtag are > > reserved for future standardization, anticipating work that is > > currently under way on ISO 639. > > o Extended language subtags MUST follow the primary subtag and > > precede any other subtags. > > o There MAY be any additional number of extended language subtags. > > o Extended language subtags will not be registered except by > > revision of this document. > > o Extended language subtags MUST NOT be used to form language tags > > except by revision of this document. > > > > Example: In a future revision or update of this document, the tag > > "zh-gan" (registered under RFC 3066) might become a valid > > non-grandfathered tag in which the subtag 'gan' might represent the > > Chinese dialect 'Gan'. > > > >2.2.3 Script Subtag > > > > The following rules apply to the script subtags: > > > > o All 4-character subtags were defined according to ISO 15924 > > [3]--"Codes for the representation of the names of scripts": > > alpha-4 script codes, or subsequently assigned by the ISO 15924 > > maintenance agency or governing standardization bodies, denoting > > the script or writing system used in conjunction with this > > language. > > o Script subtags MUST immediately follow the primary language subtag > > and all extended language subtags and MUST occur before any other > > type of subtag described below. > > o The subtags 'Qaaa' through 'Qabx' are reserved for private use in > > language tags. These subtags correspond to codes reserved by ISO > > 15924 for private use. These codes MAY be used for non-registered > > script values. Please refer to Section 2.5 for more information > > on private-use subtags. > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 9] > > > >Internet-Draft langtags March 2005 > > > > > > o Script subtags cannot be registered using the process in > > Section 3.3 of this document. Variant subtags may be considered > > for registration for that purpose. > > > > Example: "de-Latn" represents German written using the Latin script. > > > >2.2.4 Region Subtag > > > > The following rules apply to the region subtags: > > > > o The region subtag defines language variations used in a specific > > region, geographic, or political area. Region subtags MUST follow > > any language, extended language, or script subtags and MUST > > precede all other subtags. > > o All 2-character subtags following the primary subtag were defined > > in the IANA registry according to the assignments found in ISO > > 3166 [4]--"Codes for the representation of names of countries and > > their subdivisions - Part 1: Country codes"--alpha-2 country codes > > or assignments subsequently made by the ISO 3166 maintenance > > agency or governing standardization bodies. > > o All 3-character codes consisting of digit (numeric) characters > > were defined in the IANA registry according to the assignments > > found in UN Standard Country or Area Codes for Statistical Use > > [5] or assignments subsequently made by the governing standards > > body. Note that not all of the UN M.49 codes are defined in the > > IANA registry: > > * UN numeric codes assigned to 'macro-geographical (continental)' > > or sub-regions not associated with an assigned ISO 3166 alpha-2 > > code _are_ defined. > > * UN numeric codes for 'economic groupings' or 'other groupings' > > are _not_ defined in the IANA registry and MUST NOT be used to > > form language tags. > > * Countries with ambiguous ISO 3166 alpha-2 codes as defined in > > Section 3.2 are defined in the registry and are canonical for > > the given country or region defined. > > * The alphanumeric codes in Appendix X of the UN document are > > _not_ defined and MUST NOT be used to form language tags. (At > > the time this document was created these values match the ISO > > 3166 alpha-2 codes.) > > o There may be at most one region subtag in a language tag. > > o The subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are reserved for > > private use in language tags. These subtags correspond to codes > > reserved by ISO 3166 for private use. These codes MAY be used for > > private use region subtags (instead of using a private-use subtag > > sequence). Please refer to Section 2.5 for more information on > > private use subtags. > > > > "de-Latn-CH" represents German ('de') written using the Latin script > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 10] > > > >Internet-Draft langtags March 2005 > > > > > > ('Latn') as used in Switzerland ('CH'). > > > > "sr-Latn-CS" represents Serbian ('sr') written using Latin script > > ('Latn') as used in Serbia and Montenegro ('CS'). > > > > "es-419" represents Spanish ('es') as used in the UN-defined Latin > > America and Caribbean region ('419'). > > > >2.2.5 Variant Subtags > > > > The following rules apply to the variant subtags: > > > > o Variant subtags, as a collection in the IANA registry, are not > > associated with any external standard. Variant subtags and their > > meanings are defined by the registration process defined in > > Section 3.3. > > o Variant subtags MUST follow all of the other defined subtags, but > > precede any extension or private-use subtag sequences. > > o More than one variant MAY be used to form the language tag. > > o Variant subtags MUST be registered with IANA according to the > > rules in Section 3.3 of this document before being used to form > > language tags. In order to distinguish variants from other types > > of subtags, registrations must meet the following length and > > content restrictions: > > * Variant subtags that begin with a letter (a-z, A-Z) MUST be at > > least five characters long. > > * Variant subtags that begin with a digit (0-9) MUST be at least > > four characters long. > > * The maximum length of a variant subtag is eight characters > > long. > > > > "en-boont" represents the Boontling dialect of English. > > > > "de-CH-1996" represents German as used in Switzerland and as written > > using the spelling reform beginning in the year 1996 C.E. > > > >2.2.6 Extension Subtags > > > > The following rules apply to extensions: > > > > o Extension subtags are separated from the other subtags defined in > > this document by a single-letter subtag ("singleton"). The > > singleton MUST be one allocated to a registration authority via > > the mechanism described in Section 3.4 and cannot be the letter > > 'x', which is reserved for private-use subtag sequences. > > o Note: Private-use subtag sequences starting with the singleton > > subtag 'x' are described below. > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 11] > > > >Internet-Draft langtags March 2005 > > > > > > o An extension MUST follow at least a primary language subtag. That > > is, a language tag cannot begin with an extension. Extensions > > extend language tags, they do not override or replace them. For > > example, "a-value" is not a well-formed language tag, while > > "de-a-value" is. > > o Each singleton subtag MUST appear at most one time in each tag > > (other than as a private-use subtag). That is, singleton subtags > > MUST NOT be repeated. For example, the tag "en-a-bbb-a-ccc" is > > invalid because the subtag 'a' appears twice. > > o Extension subtags MUST meet all of the requirements for the > > content and format of subtags defined in this document. > > o Extension subtags MUST meet whatever requirements are set by the > > document that defines their singleton prefix and whatever > > requirements are provided by the maintaining authority. > > o Each extension subtag MUST be from two to eight characters long > > and consist solely of letters or digits, with each subtag > > separated by a single '-'. > > o Each singleton MUST be followed by at least one extension subtag. > > For example, the tag "tlh-a-b-foo" is invalid because the first > > singleton 'a' is followed immediately by another singleton 'b'. > > o Extension subtags MUST follow all language, extended language, > > script, region and variant subtags in a tag. > > o All subtags following the singleton and before another singleton > > are part of the extension. Example: In the tag "fr-a-Latn", the > > subtag 'Latn' does not represent the script subtag 'Latn' defined > > in the IANA Language Subtag Registry. Its meaning is defined by > > the extension 'a'. > > o In the event that more than one extension appears in a single tag, > > the tag SHOULD be canonicalized as described in Section 2.4.1. > > > > For example, if the prefix singleton 'r' and the shown subtags were > > defined, then the following tag would be a valid example: > > "en-Latn-GB-boont-r-extended-sequence-x-private" > > > >2.2.7 Private Use Subtags > > > > The following rules apply to private-use subtags: > > > > o Private-use subtags are separated from the other subtags defined > > in this document by the reserved single-character subtag 'x'. > > o Private-use subtags MUST follow all language, extended language, > > script, region, variant, and extension subtags in the tag. > > Another way of saying this is that all subtags following the > > singleton 'x' MUST be considered private use. Example: The subtag > > 'US' in the tag "en-x-US" is a private use subtag. > > o Unlike Extensions, a tag MAY consist entirely of private-use > > subtags. > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 12] > > > >Internet-Draft langtags March 2005 > > > > > > o No source is defined for private use subtags. Use of private use > > subtags is by private agreement and SHOULD NOT be considered part > > of this document. > > > > For example: Users who wished to utilize SIL Ethnologue for > > identification might agree to exchange tags such as > > "az-Arab-x-AZE-derbend". This example contains two private-use > > subtags. The first is 'AZE' and the second is 'derbend'. > > > >2.2.8 Pre-Existing RFC 3066 Registrations > > > > Existing IANA-registered language tags from RFC 1766 and/or RFC 3066 > > that are not defined by additions to this document maintain their > > validity. IANA will maintain these tags in the registry under either > > the "grandfathered" or "redundant" type. For more information see > > Appendix C. > > > > It is important to note that all language tags formed under the > > guidelines in this document were either legal, well-formed tags or > > were valid for potential registration under RFC 3066. > > > >2.2.9 Possibilities for Registration > > > > Possibilities for registration of subtags include: > > > > o Primary language subtags for languages not listed in ISO 639 that > > are not variants of any listed or registered language, can be > > registered. At the time this document was created there were no > > examples of this form of subtag. Before attempting to register a > > language subtag, there MUST be an attempt to register the language > > with ISO 639. No language subtags will be registered for codes > > that exist in ISO 639-1 or ISO 639-2, which are under > > consideration by the ISO 639 maintenance or registration > > authorities, or which have never been attempted for registration > > with those authorities. If ISO 639 has previously rejected a > > language for registration, it is reasonable to assume that there > > MUST be additional very compelling evidence of need before it will > > be registered in the IANA registry (to the extent that it is very > > unlikely that any subtags will be registered of this type). > > o Dialect or other divisions or variations within a language, its > > orthography, writing system, regional variation, or historical > > usage may be registered as variant subtags. An example is the > > 'scouse' subtag (the Scouse dialect of English). > > > > This document leaves the decision on what subtags are appropriate or > > not to the registration process described in Section 3.3. > > > > ISO 639 defines a maintenance agency for additions to and changes in > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 13] > > > >Internet-Draft langtags March 2005 > > > > > > the list of languages in ISO 639. This agency is: > > > > International Information Centre for Terminology (Infoterm) > > Aichholzgasse 6/12, AT-1120 > > Wien, Austria > > Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 > > > > ISO 639-2 defines a maintenance agency for additions to and changes > > in the list of languages in ISO 639-2. This agency is: > > > > Library of Congress > > Network Development and MARC Standards Office > > Washington, D.C. 20540 USA > > Phone: +1 202 707 6237 Fax: +1 202 707 0115 > > URL: http://www.loc.gov/standards/iso639 > > > > The maintenance agency for ISO 3166 (country codes) is: > > > > ISO 3166 Maintenance Agency > > c/o International Organization for Standardization > > Case postale 56 > > CH-1211 Geneva 20 Switzerland > > Phone: +41 22 749 72 33 Fax: +41 22 749 73 49 > > URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html > > > > The registration authority for ISO 15924 (script codes) is: > > > > Unicode Consortium Box 391476 > > Mountain View, CA 94039-1476, USA > > URL: http://www.unicode.org/iso15924 > > > > The Statistics Division of the United Nations Secretariat maintains > > the Standard Country or Area Codes for Statistical Use and can be > > reached at: > > > > Statistical Services Branch > > Statistics Division > > United Nations, Room DC2-1620 > > New York, NY 10017, USA > > > > Fax: +1-212-963-0623 > > E-mail: statistics@un.org > > URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm > > > >2.2.10 Classes of Conformance > > > > Implementations may wish to express their level of conformance with > > the rules and practices described in this document. There are > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 14] > > > >Internet-Draft langtags March 2005 > > > > > > generally two classes of conforming implementations: "well-formed" > > processors and "validating" processors. Claims of conformance SHOULD > > explicitly reference one of these definitions. > > > > 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. > > > > Well-formed processors are strongly encouraged to implement the > > canonicalization rules contained in Section 2.4.1. > > > > An implementation that claims to be validating MUST: > > o 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.4 > > are supported, including version, revision, and date. > > o For any such extensions supported, check that all subtags used in > > that extension are valid. > > o If the processor generates tags, it MUST do so in canonical form, > > including any supported extensions, as defined in Section 2.4.1. > > > >2.3 Choice of Language Tag > > > > One may occasionally be faced with several possible tags for the same > > body of text. > > > > Interoperability is best served when all users use the same language > > tag in order to represent the same language. If an application has > > requirements that make the rules here inapplicable, then that > > application risks damaging interoperability. It is STRONGLY > > RECOMMENDED that users not define their own rules for language tag > > choice. > > > > Standards, protocols and applications that reference this document > > normatively but apply different rules to the ones given in this > > section MUST specify how the procedure varies from the one given > > here. > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 15] > > > >Internet-Draft langtags March 2005 > > > > > > 1. Use as precise a tag as possible, but no more specific than is > > justified. For example, 'de' might suffice for tagging an email > > written in German, while "de-CH-1996" is probably unnecessarily > > precise for such a task. > > 2. Avoid using subtags that are not important for distinguishing > > content in an application. For example, including the script > > subtag in "en-Latn-US" is generally unnecessary, since nearly all > > English texts are written in the Latin script and it is generally > > not important to filter out those few that are not. > > 3. Use the canonical subtag from the IANA registry in preference to > > any of its aliases. For example, you should use 'he' for Hebrew > > in preference to 'iw'. > > 4. You SHOULD NOT use the 'UND' (Undetermined) language subtag to > > label content, even if the language is unknown. Omitting the tag > > is preferred. Some protocols may force you to give a value for > > the language tag and the 'UND' subtag may be useful when matching > > language tags in certain situations. > > 5. You SHOULD NOT use the 'MUL' (Multiple) subtag if the protocol > > allows you to use multiple languages, as is the case for the > > Content-Language header in HTTP. > > 6. You SHOULD NOT use the same variant subtag more than once within > > a language tag. For example, you should not use > > "en-US-boont-boont". > > > > To ensure consistent backward compatibility, this document contains > > several provisions to account for potential instability in the > > standards used to define the subtags that make up language tags. > > These provisions mean that no language tag created under the rules in > > this document will become obsolete. In addition, tags that are in > > canonical form will always be in canonical form. > > > >2.4 Meaning of the Language Tag > > > > The language tag always defines a language as spoken (or written, > > signed or otherwise signaled) by human beings for communication of > > information to other human beings. Computer languages such as > > programming languages are explicitly excluded. > > > > If a language tag B contains language tag A as a prefix, then B is > > typically "narrower" or "more specific" than A. For example, > > "zh-Hant-TW" is more specific than "zh-Hant". > > > > This relationship is not guaranteed in all cases: specifically, > > languages that begin with the same sequence of subtags are NOT > > guaranteed to be mutually intelligible, although they may be. For > > example, the tag "az" shares a prefix with both "az-Latn" > > (Azerbaijani written using the Latin script) and "az-Cyrl" > > (Azerbaijani written using the Cyrillic script). A person fluent in > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 16] > > > >Internet-Draft langtags March 2005 > > > > > > one script may not be able to read the other, even though the text > > might be identical. Content tagged as "az" most probably is written > > in just one script and thus might not be intelligible to a reader > > familiar with the other script. > > > > The relationship between the tag and the information it relates to is > > defined by the standard describing the context in which it appears. > > Accordingly, this section can only give possible examples of its > > usage. > > o For a single information object, the associated language tags > > might be interpreted as the set of languages that is required for > > a complete comprehension of the complete object. Example: Plain > > text documents. > > o For an aggregation of information objects, the associated language > > tags could be taken as the set of languages used inside components > > of that aggregation. Examples: Document stores and libraries. > > o For information objects whose purpose is to provide alternatives, > > the associated language tags could be regarded as a hint that the > > content is provided in several languages, and that one has to > > inspect each of the alternatives in order to find its language or > > languages. In this case, the presence of multiple tags might not > > mean that one needs to be multi-lingual to get complete > > understanding of the document. Example: MIME > > multipart/alternative. > > o In markup languages, such as HTML and XML, language information > > can be added to each part of the document identified by the markup > > structure (including the whole document itself). For example, one > > could write C'est la vie. inside a > > Norwegian document; the Norwegian-speaking user could then access > > a French-Norwegian dictionary to find out what the marked section > > meant. If the user were listening to that document through a > > speech synthesis interface, this formation could be used to signal > > the synthesizer to appropriately apply French text-to-speech > > pronunciation rules to that span of text, instead of misapplying > > the Norwegian rules. > > > >2.4.1 Canonicalization of Language Tags > > > > Since a particular language tag may be used in many processes, > > language tags SHOULD always be created or generated in a canonical > > form. > > > > A language tag is in canonical form when: > > 1. The tag is well-formed according the rules in Section 2.1 and > > Section 2.2. > > 2. None of the subtags in the language tag has a canonical_value > > mapping in the IANA registry (see Section 3.1). Subtags with a > > canonical_value mapping MUST be replaced with their mapping in > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 17] > > > >Internet-Draft langtags March 2005 > > > > > > order to canonicalize the tag. > > 3. If more than one extension subtag sequence exists, the extension > > sequences are ordered into case-insensitive ASCII order by > > singleton subtag. > > > > Example: The language tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical > > form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not in > > canonical form. > > > > Example: The language tag "en-NH" (English as used in the New > > Hebrides) is not canonical because the 'NH' subtag has a canonical > > mapping to 'VU' (Vanuatu). > > > > Note: Canonicalization of language tags does not imply anything about > > the use of upper or lowercase letter in subtags as described in > > Section 2.1. All comparisons MUST be performed in a case-insensitive > > manner. > > > > Note: the value "--" in the canonical_value field of the registry > > indicates a tag or subtag that has been deprecated and for which no > > replacement or canonical equivalent has been assigned. Validating > > processors SHOULD NOT generate tags that include these values. > > > > An extension MUST define any relationships that may exist between the > > various subtags in the extension and thus MAY define an alternate > > canonicalization scheme for the extension's subtags. Extensions MAY > > define how the order of the extension's subtags are interpreted. For > > example, an extension could define that its subtags are in canonical > > order when the subtags are placed into ASCII order: that is, > > "en-a-aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". Another extension > > might define that the order of the subtags influences their semantic > > meaning (so that "en-b-ccc-bbb-aaa" has a different value from > > "en-b-aaa-bbb-ccc"). However, extension specifications SHOULD be > > designed so that they are tolerant of the typical processes described > > in Section 3.4. > > > >2.5 Considerations for Private Use Subtags > > > > Private-use subtags require private agreement between the parties > > that intend to use or exchange language tags that use them and great > > caution should be used in employing them in content or protocols > > intended for general use. Private-use subtags are simply useless for > > information exchange without prior arrangement. > > > > The value and semantic meaning of private-use tags and of the subtags > > used within such a language tag are not defined by this document. > > > > The use of subtags defined in the IANA registry as having a specific > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 18] > > > >Internet-Draft langtags March 2005 > > > > > > private use meaning convey more information that a purely private use > > tag prefixed by the singleton subtag 'x'. For applications this > > additional information may be useful. > > > > For example, the region subtags 'AA', 'ZZ' and in the ranges > > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) may > > be used to form a language tag. A tag such as "zh-Hans-XQ" conveys a > > great deal of public, interchangeable information about the language > > material (that it is Chinese in the simplified Chinese script and is > > suitable for some geographic region 'XQ'). While the precise > > geographic region is not known outside of private agreement, the tag > > conveys far more information than an opaque tag such as "x-someLang", > > which contains no information about the language subtag or script > > subtag outside of the private agreement. > > > > However, in some cases content tagged with private use subtags may > > interact with other systems in a different and possibly unsuitable > > manner compared to tags that use opaque, privately defined subtags, > > so the choice of the best approach may depend on the particular > > domain in question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 19] > > > >Internet-Draft langtags March 2005 > > > > > >3. IANA Considerations > > > > This section deals with the processes and requirements necessary to > > maintain the registry of subtags and extensions for use in language > > tags as defined by this document and in accordance with the > > requirements of RFC 2434 [15]. > > > > The language subtag registry will be maintained so that, except for > > extension subtags, it is possible to validate all of the subtags that > > appear in a language tag under the provisions of this document or its > > revisions or successors. In addition, the meaning of the various > > subtags will be unambiguous and stable over time. (The meaning of > > private-use subtags, of course, is not defined by the IANA registry.) > > > > The registry defined under this document contains a comprehensive > > list of all of the subtags valid in language tags. This allows > > implementers a straightforward and reliable way to validate language > > tags. > > > >3.1 Format of the IANA Language Subtag Registry > > > > The IANA Language Subtag Registry will consist of a text file that is > > machine readable in the format described in this section, plus copies > > of the registration forms approved by the Language Subtag Reviewer in > > accordance with the process described in Section 3.3. With the > > exception of the registration forms for grandfathered and redundant > > tags, no registration records will be maintained for the initial set > > of subtags. > > > > Each record in the subtag registry will consist of a series of fields > > separated by the symbol "|" (%x7D) and terminated by a newline. Text > > appearing after the symbol "#" (%x23) contains comments. Whitespace > > surrounding fields in the file is ignored. If a field contains more > > than one value, the values are separated by semicolons (%x3B). > > > > There is a single date record at the start of the file which > > indicates the most recent modification date of the file. It has two > > fields: the type field is "date", and the second field is the > > modification date, in the "full-date" format specified in RFC 3339 > > [20]. For example: 2004-06-28 represents June 28, 2004 in the > > Gregorian calendar: > > date | 2004-06-28 > > > > The fields in each subtag record, in order, are: > > type| subtag| description| date| canonical_value| > > recommended_prefix # comments > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 20] > > > >Internet-Draft langtags March 2005 > > > > > > o The character "vertical line" ("|", %x7D) delimits each of the > > fields. > > o Empty fields (and their separators) at the end of the record may > > be omitted. > > o Leading or trailing whitespace in each field is not part of the > > content. > > o When the type is "grandfathered" or "redundant", then the subtag > > field is actually a whole tag. > > o The "recommended_prefix" field is empty, except where the type is > > "variant" > > o The "comments" field is optional and appears only at the end of a > > record, following a "number sign" ("#", %x23). > > o The sequence '..' denotes a range of values. Such a range > > represents all subtags of the same length that are alphabetically > > within that range, including the values explicitly mentioned. For > > example 'a..c' denotes the values 'a', 'b', and 'c'. > > > > The field 'type' MUST consist of one of the following strings: > > "language", "extlang", "script", "region", "variant", > > "grandfathered", and "redundant" and denotes the type of subtag (or > > tag, in the case of "grandfathered" and "redundant"). > > > > The field 'subtag' contains the subtag being defined. > > > > The field 'description' contains a description of the subtag > > transcribed into ASCII. > > > > Note: Descriptions in registry entries that correspond to ISO 639, > > ISO 15924, ISO 3166 or UN M.49 codes are intended only to indicate > > the meaning of that identifier as defined in the source standard at > > the time it was added to the registry. The description does not > > replace the content of the source standard itself. The descriptions > > are not intended to be the English localized names for the subtags > > and localization or translation of language tag and subtag > > descriptions is out of scope of this document. > > > > The field 'date' contains the date the record was added to the > > registry in the "full-date" format specified in RFC 3339 [20]. For > > example: 2004-06-28 represents June 28, 2004, in the Gregorian > > calendar. > > > > The field 'canonical value' represents a canonical mapping of this > > record to a subtag record of the same 'type', except for records of > > type "grandfathered" and "redundant". This field SHALL NOT be > > modified (except for records of type "grandfathered"): therefore a > > subtag whose record contains no canonical mapping when the record is > > created is a canonical form and will remain so. The 'canonical > > value' field in records of type "grandfathered" and "redundant" > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 21] > > > >Internet-Draft langtags March 2005 > > > > > > contain whole language tags that are STRONGLY RECOMMENDED for use in > > place of the record's value. In many cases the mappings were created > > by deprecation of the tags during the period before this document was > > adopted. For example, the tag "no-nyn" was deprecated in favor of > > the ISO 639-1 defined language code 'nn'. > > > > The value "--" in the 'canonical value' field means that the tag or > > subtag has been deprecated and that no replacement value has been > > assigned. For example, the "region" code 'BQ' (British Antarctic > > Territory) was withdrawn by ISO 3166 in 1979. Although valid in > > language tags, it is deprecated and validating processors SHOULD NOT > > generate this subtag. > > > > The field 'recommended prefix' is for use with registered variants > > and contains a semicolon separated list of language-ranges considered > > most appropriate for use with this subtag. Additional values can be > > added to this field for variants only via additional registration. > > Other modification of this field (such as removing or changing > > values) is not permitted. > > > > The field 'comments' may contain additional information about the > > subtag, as deemed appropriate for understanding the registry and > > implementing language tags using the various subtags. These values > > can be changed via the registration process and no guarantee of > > stability is provided. > > > > > > # IANA Language Subtag Registry > > # This registry lists all valid subtags for language tags > > # created under RFC XXXX. > > date| 2004-08-07 > > > > # language codes: ISO 639 and registered codes > > > > # ISO 639-1 (alpha-2) codes > > language| aa| Afar| 2004-07-06| | > > language| ab| Abkhazian| 2004-07-06| | > > language| ae| Avestan| 2004-07-06| | > > language| he| hebrew| 2004-06-28| | > > language| iw| hebrew| 2004-06-28| he | #note mapping > > language| qaa..qtz| PRIVATE USE| 2004-07-06| | > > language| raj| Rajasthani| 2004-07-06| | > > language| seuss| Hypothetical Language| 2005-04-01 | |# registered > > language > > > > # script codes: ISO 15924 > > > > script| Arab| Arabic| 2004-07-06| | > > script| Armn| Armenian| 2004-07-06| | > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 22] > > > >Internet-Draft langtags March 2005 > > > > > > script| Bali| Balinese| 2004-07-06| | > > # region codes: ISO 3166 and UN codes > > > > # ISO 3166-1 alpha-2 codes > > > > region| AA| PRIVATE USE| 2004-08-01| | > > region| AD| Andorra| 2004-07-06| | > > region| AE| United Arab Emirates| 2004-07-06| | > > region| AF| Afghanistan| 2004-07-06| | > > region| BQ| British Antarctic Territory | 2004-07-06 | -- | # > > deprecated 1979 > > region| CS| Serbia and Montenegro| 2003-07-23| | > > region| YU| Yugoslavia| 2004-06-28| | > > > > # United Nations M.49 numeric codes > > region| 001| World| 2004-07-06| | > > region| 002| Africa| 2004-07-06| | > > region| 003| North America| 2004-07-06| | > > region| 005| South America| 2004-07-06| | > > region| 200| Czechoslovakia| 2004-07-06| | #formerly used code CS > > > > ## registered variants > > > > variant| boont| Boontling| 2003-02-14| | en > > variant| gaulish| Gaulish| 2001-05-25| | cel > > variant| guoyu| Mandarin or Standard Chinese| 1999-12-18| | zh > > > > # grandfathered from RFC 3066 > > > > grandfathered| en-GB-oed| English, Oxford English Dictionary spelling| > > 2003-07-09| | > > grandfathered| i-ami| Amis| 1999-05-25| | > > grandfathered| i-bnn| Bunun| 1999-05-25| | > > grandfathered| art-lojban| Lojban| 2001-11-11|jbo | # deprecated in > > favor of 'jbo' > > > > # redundant > > # The following codes were registered as complete tags, but can now be > > # composed of registered subtags and do not require registration. > > > > redundant| az-Arab| Azerbaijani in Arabic script| 2003-05-30| | # use > > language az + script Arab > > redundant| az-Cyrl| Azerbaijani in Cyrillic script| 2003-05-30| | # > > use language az + script Cyrl > > redundant| en-boont| Boontling| 2003-02-14| | # use language en + > > variant boont > > > > Figure 2: Example of the Registry Format > > > > Maintenance of the registry requires that as new codes are assigned > > by ISO 639, ISO 15924, and ISO 3166, the Language Subtag Reviewer > > will evaluate each assignment, determine whether it conflicts with > > existing registry entries, and submit the information to IANA for > > inclusion in the registry. > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 23] > > > >Internet-Draft langtags March 2005 > > > > > > Note: The redundant and grandfathered entries together are the > > complete list of tags registered under RFC 3066 [18]. The redundant > > tags are those that can now be formed using the subtags defined in > > Section 2.2. The grandfathered entries are those that can never be > > legal under those same provisions. The items in both lists are > > permanent and stable, although grandfathered items may be deprecated > > over time. Refer to Appendix C for more information. > > > > RFC 3066 tags that were deprecated prior to the adoption of this > > document are part of the list of grandfathered tags and their > > component subtags were not included as registered variants (although > > they remain eligible for registration). For example, the tag > > "art-lojban" was deprecated in favor of the language subtag 'jbo'. > > > > The Language Subtag Reviewer MUST ensure that new subtags meet the > > requirements in Section 2.3 or submit an appropriate alternate subtag > > as described in that section. She or he will use the following form > > to submit this information: > > > > LANGUAGE SUBTAG REGISTRATION FORM (NEW RECORD) > > Record Text: > > Type: > > Subtag: > > Description: > > Date: > > Canonical Mapping: > > Recommended Prefix: > > Comments: > > > > Figure 3 > > > > The field 'record text' contains the exact record that IANA is to > > insert into the Language Subtag Registry. The contents of the > > remaining fields must exactly match those in this field. > > > > Whenever an entry is created or modified in the registry, the 'date' > > record at the start of the registry is updated to reflect the most > > recent modification date in the RFC 3339 [20] "full-date" format. > > > >3.2 Stability of IANA Registry Entries > > > > The stability of entries and their meaning in the registry is > > critical to the long term stability of language tags. The rules in > > this section guarantee that a specific language tag's meaning is > > stable over time and will not change and that the choice of language > > tag for specific content is also stable over time. > > > > These rules specifically deal with how changes to codes (including > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 24] > > > >Internet-Draft langtags March 2005 > > > > > > withdrawal and deprecation of codes) maintained by ISO 639, ISO > > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language > > Subtag Registry. Assignments to the IANA Language Subtag Registry > > MUST follow the following stability rules: > > o Values in the fields 'type', 'subtag', 'date' and 'canonical > > value' MUST NOT be changed and are guaranteed to be stable over > > time. > > o Values in the 'description' field MUST NOT be changed in a way > > that would invalidate previously-existing tags. They may be > > broadened somewhat in scope, changed to add information, or > > adapted to the most common modern usage. For example, countries > > occasionally change their official names: an historical example of > > this would be "Upper Volta" changing to "Burkina Faso". > > o Values in the field 'recommended prefix' MAY be added via the > > registration process. > > o Values in the field 'recommended prefix' MAY be modified, so long > > as the modifications broaden the set of recommended prefixes. > > That is, a recommended prefix MAY be replaced by one of its own > > prefixes. For example, the prefix "en-US" could be replaced by > > "en", but not by the ranges "en-Latn", "fr", or "en-US-boont". > > o Values in the field 'recommended prefix' MUST NOT be removed. > > o The field 'comments' MAY be added, changed, modified, or removed > > via the registration process or any of the processes or > > considerations described in this section. > > o Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not > > conflict with existing subtags of the associated type and whose > > meaning is not the same as an existing subtag of the same type are > > entered into the IANA registry as new records and their value is > > canonical for the meaning assigned to them. > > o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are > > withdrawn by their respective maintenance or registration > > authority remain valid in language tags. The registration process > > MAY be used to add a note indicating the withdrawal of the code by > > the respective standard. > > o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that do not > > conflict with existing subtags of the associated type but which > > represent the same meaning as an existing subtag of that type are > > entered into the IANA registry as new records. The field > > 'canonical value' for that record MUST contain the existing subtag > > of the same meaning > > Example If ISO 3166 were to assign the code 'IM' to represent the > > value "Isle of Man" (represented in the IANA registry by the UN > > M.49 code '833'), '833' remains the canonical subtag and 'IM' > > would be assigned '833' as a canonical value. This prevents > > tags that are in canonical form from becoming non-canonical. > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 25] > > > >Internet-Draft langtags March 2005 > > > > > > Example If the tag 'enochian' were registered as a primary > > language subtag and ISO 639 subsequently assigned an alpha-3 > > code to the same language, the new ISO 639 code would be > > entered into the IANA registry as a subtag with a canonical > > mapping to 'enochian'. The new ISO code can be used, but it is > > not canonical. > > o Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict > > with existing subtags of the associated type MUST NOT be entered > > into the registry. The following additional considerations apply: > > * For ISO 639 codes, if the newly assigned code's meaning is not > > represented by a subtag in the IANA registry, the Language > > Subtag Reviewer, as described in Section 3.3, shall prepare a > > proposal for entering in the IANA registry as soon as practical > > a registered language subtag as an alternate value for the new > > code. The form of the registered language subtag will be at > > the discretion of the Language Subtag Reviewer and must conform > > to other restrictions on language subtags in this document. > > * For all subtags whose meaning is derived from an external > > standard (i.e. ISO 639, ISO 15924, ISO 3166, or UN M.49), if a > > new meaning is assigned to an existing code and the new meaning > > broadens the meaning of that code, then the meaning for the > > associated subtag MAY be changed to match. The meaning of a > > subtag MUST NOT be narrowed, however, as this can result in an > > unknown proportion of the existing uses of a subtag becoming > > invalid. Note: ISO 639 MA/RA has adopted a similar stability > > policy. > > * For ISO 15924 codes, if the newly assigned code's meaning is > > not represented by a subtag in the IANA registry, the Language > > Subtag Reviewer, as described in Section 3.3, shall prepare a > > proposal for entering in the IANA registry as soon as practical > > a registered variant subtag as an alternate value for the new > > code. The form of the registered variant subtag will be at the > > discretion of the Language Subtag Reviewer and must conform to > > other restrictions on variant subtags in this document. > > * For ISO 3166 codes, if the newly assigned code's meaning is > > associated with the same UN M.49 code as another 'region' > > subtag, then the existing region subtag remains as the > > canonical entry for that region and no new entry is created. A > > note MAY be added to the existing region subtag indicating the > > relationship to the new ISO 3166 code. > > * For ISO 3166 codes, if the newly assigned code's meaning is > > associated with a UN M.49 code that is not represented by an > > existing region subtag, then then the Language Subtag Reviewer, > > as described in Section 3.3, shall prepare a proposal for > > entering the appropriate numeric UN country code as an entry in > > the IANA registry. > > * For ISO 3166 codes, if there is no associated UN numeric code, > > then the Language Subtag Reviewer SHALL petition the UN to > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 26] > > > >Internet-Draft langtags March 2005 > > > > > > create one. If there is no response from the UN within ninety > > days of the request being sent, the Language Subtag Reviewer > > shall prepare a proposal for entering in the IANA registry as > > soon as practical a registered variant subtag as an alternate > > value for the new code. The form of the registered variant > > subtag will be at the discretion of the Language Subtag > > Reviewer and must conform to other restrictions on variant > > subtags in this document. This situation is very unlikely to > > ever occur. > > o 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 grandfathered tag > > MUST be marked as redundant. Note that this will not affect > > language tags that match the grandfathered tag, since these tags > > will now match valid generative subtag sequences. For example, if > > 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). > > > > Language tags formed under RFC 3066 that use the region subtag 'CS' > > were ambiguous, since tags produced before 2003 used that code for > > the (now dissolved) country Czechoslovakia. ISO 3166 assigned this > > code to the country Serbia and Montenegro in 2003 and this draft > > makes that the canonical value for this subtag. To form a language > > tag for the region Czechoslovakia, the UN M.49 code '200' is included > > in the registry. As a practical matter, applications that encounter > > the RFC 3066 tag "cs-CS" or "sk-CS" MAY wish to convert that to > > "cs-200" or "sk-200" (or use one of the successor region subtags, > > such as 'CZ' or 'SK'), since that is the most likely interpretation. > > > >3.3 Registration Procedure for Subtags > > > > The procedure given here MUST be used by anyone who wants to use a > > subtag not currently in the IANA Language Subtag Registry. > > > > Only primary language and variant subtags will be considered for > > independent registration. (Subtags required for stability and > > subtags required to keep the registry synchronized with ISO 639, ISO > > 15924, ISO 3166, and UN M.49 within the limits defined by this > > document are the only exceptions to this. See Section 3.2.) > > > > This procedure MAY also be used to register or alter the information > > for the "description", "note", or "recommended prefix" fields in a > > subtag's record as described in Figure 2. Changes to all other > > fields in the IANA registry are NOT permitted. > > > > If registering a new language subtag, the process starts by filling > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 27] > > > >Internet-Draft langtags March 2005 > > > > > > out the registration form reproduced below. Note that each response > > is not limited in size and should take the room necessary to > > adequately describe the registration. > > > > LANGUAGE SUBTAG REGISTRATION FORM > > 1. Name of requester: > > 2. E-mail address of requester: > > 3. Subtag to be registered: > > 4. Type of Registration: > > [ ] language > > [ ] variant > > 5. Description of subtag (in English or transcribed into ASCII): > > 6. Intended meaning of the subtag: > > 7. Recommended prefix(es) of subtag (for variants): > > 8. Native name of the language or variation (transcribed into ASCII): > > 9. Reference to published description of the language (book or article): > > 10. Any other relevant information: > > > > Figure 4 > > > > The subtag registration form MUST be sent to > > for a two week review period before it can > > be submitted to IANA. (This is an open list. Requests to be added > > should be sent to .) > > > > Variant subtags are generally registered for use with a particular > > range of language tags. For example, the subtag 'boont' is intended > > for use with language tags that start with the primary language > > subtag "en", since Boontling is a dialect of English. Thus the > > subtag 'boont' could be included in tags such as "en-Latn-boont" or > > "en-US-boont". This information is stored in the "recommended > > prefix" field in the registry and MUST be provided in the > > registration form. > > > > Any subtag MAY be incorporated into a variety of language tags, > > according to the rules of Section 2.1, including tags that do not > > match any of the recommended prefixes of the registered subtag. > > (Note that this is probably a poor choice.) This makes validation > > simpler and thus more uniform across implementations, and does not > > require the registration of a separate subtag for the same purpose > > and meaning but a different recommended prefix. > > > > The recommended prefixes for a given registered subtag will be > > maintained in the IANA registry as a guide to usage. If it is > > necessary to add an additional prefix to that list for an existing > > language tag, that can be done by filing an additional registration > > form. In that form, the "Any other relevant information:" field > > should indicate that it is the addition of an additional recommended > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 28] > > > >Internet-Draft langtags March 2005 > > > > > > prefix. > > > > Requests to add a recommended prefix to a subtag that imply a > > different semantic meaning will probably be rejected. For example, a > > request to add the prefix "de" to the subtag 'nedis' so that the tag > > "de-nedis" represented some German dialect would be rejected. The > > 'nedis' subtag represents a particular Slovenian dialect and the > > additional registration would change the semantic meaning assigned to > > the subtag. A separate subtag should be proposed instead. > > > > The Language Subtag Reviewer is responsible for responding to > > requests for the registration of subtags through the registration > > process and is appointed by the IESG. > > > > When the two week period has passed the Language Subtag Reviewer > > either forwards the request to iana@iana.org, or rejects it because > > of significant objections raised on the list or due to problems with > > constraints in this document (which should be explicitly cited). The > > reviewer may also extend the review period in two week increments to > > permit further discussion. The reviewer must indicate on the list > > whether the registration has been accepted, rejected, or extended > > following each two week period. > > > > Note that the reviewer can raise objections on the list if he or she > > so desires. The important thing is that the objection must be made > > publicly. > > > > The applicant is free to modify a rejected application with > > additional information and submit it again; this restarts the two > > week comment period. > > > > Decisions made by the reviewer may be appealed to the IESG [RFC 2028] > > [10] under the same rules as other IETF decisions [RFC 2026] [21]. > > > > All approved registration forms are available online in the directory > > http://www.iana.org/numbers.html under "languages". > > > > Updates of registrations follow the same procedure as registrations. > > The subtag reviewer decides whether to allow a new registrant to > > update a registration made by someone else; normally objections by > > the original registrant would carry extra weight in such a decision. > > > > Registrations are permanent and stable. Once registered, subtags > > will not be removed from the registry and will remain the canonical > > method of referring to a specific language or variant. This > > provision does not apply to grandfathered tags, which may become > > deprecated due to registration of subtags. For example, the tag > > "i-navajo" is deprecated in favor of the ISO 639-1 based subtag 'nv'. > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 29] > > > >Internet-Draft langtags March 2005 > > > > > > Note: The purpose of the "published description" in the registration > > form is intended as an aid to people trying to verify whether a > > language is registered or what language or language variation a > > particular subtag refers to. In most cases, reference to an > > authoritative grammar or dictionary of that language will be useful; > > in cases where no such work exists, other well known works describing > > that language or in that language may be appropriate. The subtag > > reviewer decides what constitutes "good enough" reference material. > > This requirement is not intended to exclude particular languages or > > dialects due to the size of the speaker population or lack of a > > standardized orthography. Minority languages will be considered > > equally on their own merits. > > > >3.4 Extensions and Extensions Namespace > > > > Extension subtags are those introduced by single-letter subtags other > > than 'x-'. They are reserved for the generation of identifiers which > > contain a language component, and are compatible with applications > > that process language tags according to this specification. For > > example, they might be used to define locale identifiers, which are > > generally based on language. > > > > The structure and form of extensions are defined by this document so > > that implementations can be created that are forward compatible with > > applications that may be created using single-letter subtags in the > > future. In addition, defining a mechanism for maintaining > > single-letter subtags will lend to the stability of this document by > > reducing the likely need for future revisions or updates. > > > > IANA will maintain a registry of allocated single-letter subtags. > > This registry contains the following information: letter identifier; > > name; purpose; RFC defining the subtag namespace and its use; and the > > name, URL, and email address of the maintaining authority. > > > > Allocation of a single-letter subtag shall take the form of an RFC > > defining the name, purpose, processes, and procedures for maintaining > > the subtags. The maintaining or registering authority, including > > name, contact email, discussion list email, and URL location of the > > registry must be indicated clearly in the RFC. The RFC MUST specify > > each of the following: > > o The specification MUST reference the specific version or revision > > of this document that govern its creation and MUST reference this > > section of this document. > > o The specification and all subtags defined by the specification > > MUST follow the ABNF and other rules for the formation of tags and > > subtags as defined in this document. In particular it MUST > > specify that case is not significant. > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 30] > > > >Internet-Draft langtags March 2005 > > > > > > o The specification MUST specify a canonical representation. > > o The specification of valid subtags MUST be available over the > > Internet and at no cost. > > o The specification MUST be in the public domain or available via a > > royalty-free license acceptable to the IETF and specified in the > > RFC. > > o The specification MUST be versioned and each version of the > > specification MUST be numbered, dated, and stable. > > o The specification MUST be stable. That is, extension subtags, > > once defined by a specification, MUST NOT be retracted or change > > in meaning in any substantial way. > > o IANA MUST be informed of changes to the contact information and > > URL for the specification. > > > > The determination of whether an Internet-Draft meets the above > > conditions and the decision to grant or withhold such authority rests > > solely with the IESG, and is subject to the normal review and appeals > > process associated with the RFC process. > > > > Extension authors are strongly cautioned that many (including most > > well-formed) processors will be unaware of any special relationships > > or meaning inherent in the order of extension subtags. Extension > > authors SHOULD avoid subtag relationships or canonicalization > > mechanisms that interfere with matching or with length restrictions > > that may exist in common protocols where the extension is used. In > > particular, applications may truncate the subtags in doing matching > > or in fitting into limited lengths, so it is RECOMMENDED that the > > most significant information be in the most significant (left-most) > > subtags, and that the specification gracefully handle truncated > > subtags. > > > > When a language tag is to be used in a specific, known, protocol, it > > is RECOMMENDED that that the language tag not contain extensions not > > supported by that protocol. In addition, it should be noted that > > some protocols may impose upper limits on the length of the strings > > used to store or transport the language tag. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 31] > > > >Internet-Draft langtags March 2005 > > > > > >4. Security Considerations > > > > The only security issue that has been raised with language tags since > > the publication of RFC 1766, which stated that "Security issues are > > believed to be irrelevant to this memo", is a concern with language > > identifiers used in content negotiation - that they may be used to > > infer the nationality of the sender, and thus identify potential > > targets for surveillance. > > > > This is a special case of the general problem that anything you send > > is visible to the receiving party. It is useful to be aware that > > such concerns can exist in some cases. > > > > The evaluation of the exact magnitude of the threat, and any possible > > countermeasures, is left to each application protocol. > > > > Although the specification of valid subtags for an extension MUST be > > available over the Internet, implementations SHOULD NOT mechanically > > depend on it being always accessible, to prevent denial-of-service > > attacks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 32] > > > >Internet-Draft langtags March 2005 > > > > > >5. Character Set Considerations > > > > The syntax in this document requires that language tags use only the > > characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most > > character sets, so presentation of language tags should not have any > > character set issues. > > > > Rendering of characters based on the content of a language tag is not > > addressed in this memo. Historically, some languages have relied on > > the use of specific character sets or other information in order to > > infer how a specific character should be rendered (notably this > > applies to language and culture specific variations of Han ideographs > > as used in Japanese, Chinese, and Korean). When language tags are > > applied to spans of text, rendering engines may use that information > > in deciding which font to use in the absence of other information, > > particularly where languages with distinct writing traditions use the > > same characters. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 33] > > > >Internet-Draft langtags March 2005 > > > > > >6. Changes from RFC 3066 > > > > The main goals for this revision of language tags were the following: > > > > *Compatibility.* All valid RFC 3066 language tags (including those > > in the IANA registry) remain valid in this specification. Thus > > there is complete backward compatibility of this specification with > > existing content. In addition, this document defines language tags > > in such as way as to ensure future compatibility, and processors > > based solely on the RFC 3066 ABNF (such as those described in XML > > Schema version 1.0) will be able to process tags described by this > > document. > > > > *Stability.* Because of the changes in underlying ISO standards, a > > valid RFC 3066 language tag may become invalid (or have its meaning > > change) at a later date. With so much of the world's computing > > infrastructure dependent on language tags, this is simply > > unacceptable: it invalidates content that may have an extensive > > shelf-life. In this specification, once a language tag is valid, it > > remains valid forever. Previously, there was no way to determine > > when two tags were equivalent. This specification provides a stable > > mechanism for doing so, through the use of canonical forms. These > > are also stable, so that implementations can depend on the use of > > canonical forms to assess equivalency. > > > > *Validity.* The structure of language tags defined by this document > > makes it possible to determine if a particular tag is well-formed > > without regard for the actual content or "meaning" of the tag as a > > whole. This is important because the registry and underlying > > standards change over time. In addition, it must be possible to > > determine if a tag is valid (or not) for a given point in time in > > order to provide reproducible, testable results. This process must > > not be error-prone; otherwise even intelligent people will generate > > implementations that give different results. This specification > > provides for that by having a single data file, with specific > > versioning information, so that the validity of language tags at any > > point in time can be precisely determined (instead of interpolating > > values from many separate sources). > > > > *Extensibility.* It is important to be able to differentiate between > > written forms of language -- for many implementations this is more > > important than distinguishing between spoken variants of a language. > > Languages are written in a wide variety of different scripts, so this > > document provides for the generative use of ISO 15924 script codes. > > Like the generative use of ISO language and country codes in RFC > > 3066, this allows combinations to be produced without resorting to > > the registration process. The addition of UN codes provides for the > > generation of language tags with regional scope, which is also > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 34] > > > >Internet-Draft langtags March 2005 > > > > > > required for information technology. > > > > The recast of the registry from containing whole language tags to > > subtags is a key part of this. An important feature of RFC 3066 was > > that it allowed generative use of subtags. This allows people to > > meaningfully use generated tags, without the delays in registering > > whole tags, and the burden on the registry of having to supply all of > > the combinations that people may find useful. > > > > Because of the widespread use of language tags, it is potentially > > disruptive to have periodic revisions of the core specification, > > despite demonstrated need. The extension mechanism provides for a > > way for independent RFCs to define extensions to language tags. > > These extensions have a very constrained, well-defined structure to > > prevent extensions from interfering with implementations of language > > tags defined in this document. The document also anticipates > > features of ISO 639-3 with the addition of the extlang subtags. The > > use and definition of private use tags has also been modified, to > > allow people to move as much information as possible out of private > > use tags, and into the regular structure. The goal is to > > dramatically reduce the need to produce a revision of this document > > in the future. > > > > The specific changes in this document to meet these goals are: > > o Defines the ABNF and rules for subtags so that the category of all > > subtags can be determined without reference to the registry. > > o Adds the concept of well-formed vs. validating processors, > > defining the rules by which an implementation can claim to be one > > or the other. > > o Changes the IANA language tag registry to a language subtag > > registry that provides a complete list of valid subtags in the > > IANA registry. This allows for robust implementation and ease of > > maintenance. The language subtag registry becomes the canonical > > source for forming language tags. > > o Provides a process that guarantees stability of language tags, by > > handling reuse of values by ISO 639, ISO 15924, and ISO 3166 in > > the event that they register a previously used value for a new > > purpose. > > o Allows ISO 15924 script code subtags and allows them to be used > > generatively. Adds the concept of a variant subtag and allows > > variants to be used generatively. Adds the ability to use a class > > of UN tags as regions. > > o Defines the private-use tags in ISO 639, ISO 15924, and ISO 3166 > > as the mechanism for creating private-use language, script, and > > region subtags respectively. > > o Adds a well-defined extension mechanism. > > o Defines an extended language subtag, possibly for use with certain > > anticipated features of ISO 639-3. > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 35] > > > >Internet-Draft langtags March 2005 > > > > > > Ed Note: The following items are provided for the convenience of > > reviewers and will be removed from the final document. > > > > Changes between draft-phillips-langtags-10 and this version are: > > o Expunged the terminology "language range", since that section goes > > with matching (A.Phillips, M.Davis) > > o Added text describing the handling of existing RFC 3066 registry > > entries that were deprecated prior to the adoption of this > > document. These tags are now grandfathered. (A.Phillips, > > D.Ewell) > > o Modified the conversion rules for the registry (Appendix C) to > > refer to the chairs, the LTRU mail list and so forth (A.Phillips) > > o Added text to allow tags and subtags to be deprecated using the > > canonical value "--". This is applied to codes withdrawn by ISO > > 639 MA and ISO 3166 MA, for example. (F.Ellerman, D.Ewell) > > > >7. References > > > > [1] International Organization for Standardization, "ISO > > 639-1:2002, Codes for the representation of names of languages > > -- Part 1: Alpha-2 code", ISO Standard 639, 2002. > > > > [2] International Organization for Standardization, "ISO 639-2:1998 > > - Codes for the representation of names of languages -- Part 2: > > Alpha-3 code - edition 1", August 1988. > > > > [3] ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the > > representation of names of scripts", January 2004. > > > > [4] International Organization for Standardization, "Codes for the > > representation of names of countries, 3rd edition", > > ISO Standard 3166, August 1988. > > > > [5] Statistical Division, United Nations, "Standard Country or Area > > Codes for Statistical Use", UN Standard Country or Area Codes > > for Statistical Use, Revision 4 (United Nations publication, > > Sales No. 98.XVII.9, June 1999. > > > > [6] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory > > Committee: Working principles for ISO 639 maintenance", March > > 2000, > > . > > > > [7] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 > > and RFC 822", RFC 1327, May 1992. > > > > [8] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail > > Extensions) Part One: Mechanisms for Specifying and Describing > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 36] > > > >Internet-Draft langtags March 2005 > > > > > > the Format of Internet Message Bodies", RFC 1521, September > > 1993. > > > > [9] Alvestrand, H., "Tags for the Identification of Languages", > > RFC 1766, March 1995. > > > > [10] Hovey, R. and S. Bradner, "The Organizations Involved in the > > IETF Standards Process", BCP 11, RFC 2028, October 1996. > > > > [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement > > Levels", BCP 14, RFC 2119, March 1997. > > > > [12] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word > > Extensions: Character Sets, Languages, and Continuations", > > RFC 2231, November 1997. > > > > [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax > > Specifications: ABNF", RFC 2234, November 1997. > > > > [14] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform > > Resource Identifiers (URI): Generic Syntax", RFC 2396, August > > 1998. > > > > [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA > > Considerations Section in RFCs", BCP 26, RFC 2434, October > > 1998. > > > > [16] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., > > Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- > > HTTP/1.1", RFC 2616, June 1999. > > > > [17] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of > > Understanding Concerning the Technical Work of the Internet > > Assigned Numbers Authority", RFC 2860, June 2000. > > > > [18] Alvestrand, H., "Tags for the Identification of Languages", > > BCP 47, RFC 3066, January 2001. > > > > [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", > > STD 63, RFC 3629, November 2003. > > > > [20] Klyne, G. and C. Newman, "Date and Time on the Internet: > > Timestamps", RFC 3339, July 2002. > > > > [21] > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 37] > > > >Internet-Draft langtags March 2005 > > > > > >Authors' Addresses > > > > Addison Phillips (editor) > > Quest Software > > > > Email: addison.phillips@quest.com > > > > > > Mark Davis (editor) > > IBM > > > > Email: mark.davis@us.ibm.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 38] > > > >Internet-Draft langtags March 2005 > > > > > >Appendix A. Acknowledgements > > > > Any list of contributors is bound to be incomplete; please regard the > > following as only a selection from the group of people who have > > contributed to make this document what it is today. > > > > The contributors to RFC 3066 and RFC 1766, the precursors of this > > document, made enormous contributions directly or indirectly to this > > document and are generally responsible for the success of language > > tags. > > > > The following people (in alphabetical order) contributed to this > > document or to RFCs 1766 and 3066: > > > > Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet, > > Nathaniel Borenstein, Eric Brunner, Sean M. Burke, Jeremy Carroll, > > John Clews, Jim Conklin, Peter Constable, John Cowan, Mark Crispin, > > Dave Crocker, Martin Duerst, Frank Ellerman, Michael Everson, Doug > > Ewell, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, > > Joel Halpren, Elliotte Rusty Harold, Paul Hoffman, Richard Ishida, > > Olle Jarnefors, Kent Karlsson, John Klensin, Alain LaBonte, Eric > > Mader, Keith Moore, Chris Newman, Masataka Ohta, George Rhoten, > > Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto Stolz, Tex > > Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois Yergeau and > > many, many others. > > > > Very special thanks must go to Harald Tveit Alvestrand, who > > originated RFCs 1766 and 3066, and without whom this document would > > not have been possible. Special thanks must go to Michael Everson, > > who has served as language tag reviewer for almost the complete > > period since the publication of RFC 1766. Special thanks to Doug > > Ewell, for his production of the first complete subtag registry, and > > his work in producing a test parser for verifying language tags. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 39] > > > >Internet-Draft langtags March 2005 > > > > > >Appendix B. Examples of Language Tags (Informative) > > > > Simple language subtag: > > de (German) > > fr (French) > > ja (Japanese) > > i-enochian (example of a grandfathered tag) > > > > Language subtag plus Script subtag: > > zh-Hant (Traditional Chinese) > > en-Latn (English written in Latin script) > > sr-Cyrl (Serbian written with Cyrillic script) > > > > Language-Script-Region: > > zh-Hans-CN (Simplified Chinese for the PRC) > > sr-Latn-CS (Serbian, Latin script, Serbia and Montenegro) > > > > Language-Script-Region-Variant: > > en-Latn-US-boont (Boontling dialect of English) > > de-Latn-CH-1996 (German written in Latin script for Switzerland > > using the orthography of 1996) > > > > Language-Region: > > de-DE (German for Germany) > > zh-SG (Chinese for Singapore) > > cs-200 (Czech for Czechoslovakia) > > sr-CS (Serbian for Serbia and Montenegro) > > es-419 (Spanish for Latin America and Caribbean region using the > > UN region code) > > > > Other Mixtures: > > en-boont (Boontling dialect of English) > > > > private-use mechanism: > > de-CH-x-phonebk > > az-Arab-x-AZE-derbend > > > > Extended language subtags (examples ONLY: extended languages must be > > defined by revision or update to this document): > > zh-min > > zh-min-nan-Hant-CN > > > > Private-use subtags: > > x-whatever (private use using the singleton 'x') > > qaa-Qaaa-QM-x-southern (all private tags) > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 40] > > > >Internet-Draft langtags March 2005 > > > > > > de-Qaaa (German, with a private script) > > de-Latn-QM (German, Latin-script, private region) > > de-Qaaa-DE (German, private script, for Germany) > > > > Tags that use extensions (examples ONLY: extensions must be defined > > by revision or update to this document or by RFC): > > en-US-u-islamCal > > zh-CN-a-myExt-x-private > > en-a-myExt-b-another > > > > Some Invalid Tags: > > de-419-DE (two region tags) > > a-DE (use of a single character subtag in primary position; note > > that there are a few grandfathered tags that start with "i-" that > > are valid) > > ar-a-aaa-b-bbb-a-ccc (two extensions with same single letter > > prefix) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 41] > > > >Internet-Draft langtags March 2005 > > > > > >Appendix C. Conversion of the RFC 3066 Language Tag Registry > > > > Upon publication of this document as a BCP, the existing IANA > > language tag registry must be converted into the new subtag registry. > > This section defines the process for performing this conversion. > > > > The impact on the IANA maintainers of the registry of this conversion > > will be a small increase in the frequency of new entries. The > > initial set of records represents no impact on IANA, since the work > > to create it will be performed externally. > > > > When this document is published, an email will be sent by the > > chair(s) of the LTRU working group to the LTRU and ietf-languages > > mail lists advising of the impending conversion of the registry. In > > that notice, the chair(s) will provide a URL whose referred content > > is the proposed IANA Language Subtag Registry following conversion. > > There will be a Last Call period of not less than four weeks for > > comments and corrections to be discussed on the > > ietf-languages@iana.org mail list. Changes as a result of comments > > will not restart the Last Call period. At the end of the period, the > > chair(s) will forward the URL to IANA, which will post the new > > registry on-line. > > > > Tags that are currently deprecated will be maintained as > > grandfathered entries. The record for the grandfathered entry will > > contain a note indicating that the entry is 'deprecated' and reason > > for the deprecation. For example, the tag "art-lojban" is deprecated > > and will be placed in the grandfathered section. > > > > Tags that are not deprecated that consist entirely of subtags that > > are valid under this document and which have the correct form and > > format for tags defined by this document are superseded by this > > document. Such tags are placed in the 'redundant' section of the > > registry. For example, zh-Hant is now defined by this document. > > > > Tags that contain subtags which are consistent with registration > > under the guidelines in this document will have a new subtag > > registration created for each eligible subtag. If all of the subtags > > in the original tag are fully defined by the resulting registrations > > or by this document, then the original tag is superseded by this > > document. Such tags are placed in the 'redundant' section of the > > registry. For example, en-boont will result in a new subtag "boont" > > and the RFC 3066 registered tag 'en-boont' placed in the redundant > > section of the registry. > > > > Tags that contain one or more subtags that do not match the valid > > registration pattern and which are not otherwise defined by this > > document are marked as 'grandfathered' by this document. > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 42] > > > >Internet-Draft langtags March 2005 > > > > > > There will be a reasonable period in which the community may comment > > on the proposed list entries, which SHALL be no less than four weeks > > in length. At the completion of this period, the chair(s) will > > notify iana@iana.org and the ltru and ietf-languages mail lists that > > the task is complete and forward the necessary materials to IANA for > > publication. > > > > Registrations that are in process under the rules defined in RFC 3066 > > MAY be completed under the former rules, at the discretion of the > > language tag reviewer. Any new registrations submitted after the > > request for conversion of the registry MUST be rejected. > > > > All existing RFC 3066 language tag registrations will be maintained > > in perpetuity. > > > > Users of tags that are grandfathered should consider registering > > appropriate subtags in the IANA subtag registry (but are not required > > to). > > > > Where two subtags have the same meaning, the priority of which to > > make canonical SHALL be the following: > > o As of the date of acceptance of this document as a BCP, if a code > > exists in the associated ISO standard and it is not deprecated or > > withdrawn as of that date, then it has priority. > > o Otherwise, the earlier-registered tag in the associated ISO > > standard has priority. > > > > UN numeric codes assigned to 'macro-geographical (continental)' or > > sub-regions not associated with an assigned ISO 3166 alpha-2 code are > > defined in the IANA registry and are valid for use in language tags. > > These codes MUST be added to the initial version of the registry. > > The UN numeric codes for 'economic groupings' or 'other groupings', > > and the alphanumeric codes in Appendix X of the UN document MUST NOT > > be added to the registry. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 43] > > > >Internet-Draft langtags March 2005 > > > > > >Intellectual Property Statement > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might be claimed to > > pertain to the implementation or use of the technology described in > > this document or the extent to which any license under such rights > > might or might not be available; nor does it represent that it has > > made any independent effort to identify any such rights. Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission for the use of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR repository at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > >Disclaimer of Validity > > > > This document and the information contained herein are provided on an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > >Copyright Statement > > > > Copyright (C) The Internet Society (2005). This document is subject > > to the rights, licenses and restrictions contained in BCP 78, and > > except as set forth therein, the authors retain all their rights. > > > > > >Acknowledgment > > > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > > > > > > > > > >Phillips & Davis Expires September 11, 2005 [Page 44] > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 15 16:15:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20302; Tue, 15 Mar 2005 16:15:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJSH-0008P8-MR; Tue, 15 Mar 2005 16:19:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJNu-00056h-0K; Tue, 15 Mar 2005 16:15:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJNs-00056b-MS for ltru@megatron.ietf.org; Tue, 15 Mar 2005 16:15:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20280 for ; Tue, 15 Mar 2005 16:15:18 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJRi-0008O8-EK for ltru@ietf.org; Tue, 15 Mar 2005 16:19:22 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 13:15:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: "Obsolete" region subtags Date: Tue, 15 Mar 2005 13:15:05 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A9F4BB0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: "Obsolete" region subtags Thread-Index: AcUpoEA2KLWMJ7UqSdGucj3m2aZhbAAAVEUg From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "Frank Ellermann" , X-OriginalArrivalTime: 15 Mar 2005 21:15:05.0838 (UTC) FILETIME=[0F52B0E0:01C529A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable I think you should quit comparing this to iDNS, although I note that = iDNS *is* explicitly designed to be compatible with the existing DNS = system. This explains many of the idiosyncrasies of its design. RFC 1766/3066 language tags have a considerable history and are = referenced by a considerable number of other standards. Your desire to = create an incompatible language tagging system for whatever reason is = based on the need for some software applications to be updated anyway? = That's a silly bit of logic. Forget applications for a moment. Think document formats. There is = considerable content that contains RFC 3066 language tags. The HTML, = XML, CSS, HTTP, SMTP, and many derivative standards use these tags = internally. Many web sites use them to select content--which means the = server component, not the user agent. Many databases and programming = languages use them. Content and data has a long shelf life. Breaking = compatibility is a serious step. We have devised a format that updates language tags in a compatible = manner to meet demonstrable needs. What application cannot be addressed = by this (compatible) design? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: 2005?3?15? 12:47 > To: Addison Phillips; Frank Ellermann; ltru@ietf.org > Subject: RE: [Ltru] Re: "Obsolete" region subtags >=20 > At 18:14 15/03/2005, Addison Phillips wrote: > >Allowing multiple subtags to mean the same thing, as Frank suggests = below, > >would be a problem. Many language tag processors that I know of are > >implemented based solely on the values of the tags themselves, with = no > >external knowledge baked into them. The existence of a registry might > >change that to some degree, but you'll still have many of what the = draft > >calls "well-formed" processors for which "GB" is just a token. >=20 > I question myself on this. The DNS is 22 years old, the mail older. I > understand that one wants to be careful at not changing them too much = - > yet > the market will change them if it solved the spam. IDNs are one year = and a > half old and several consider that one can still change or even kill = them. > As far as I understand, you refer to applications resulting from RFC = 3066, > and may be from its predecessor? So they are 3 to 7 years old? They = most > probably are browsers/aplications which have anyway to be updated to > support IDNs (applications needing to check languages are likely to = also > use IDNs)? >=20 > We are going to have a lot of changes in the DNS in the coming month = to > support the local TLDs which are to be a must. The support of the = Tables > will probably be required at users level, for 3+LD consistency = checks,etc. > (even if not planned yet). Many other applications would probably want > then to use functions using country codes if they were available. >=20 > Microsoft always said they wanted to watch the market reaction before > implementing the IDN support in the OS. This WG could consider user > located > functions to get and integrate the IANA cc table and updates . It = could > then use them. Would it not be better to start anew while there is = still a > "small" base (RFC 3066 is still here for them) rather than to continue = for > ever with an old system? >=20 > BTW I personally think the IDN Tables and other TLD infos (such as the > lingual aliases of the TLDs) are part of the Locale, > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 01:56:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06588; Wed, 16 Mar 2005 01:56:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBSVt-0006x7-Qg; Wed, 16 Mar 2005 02:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBSQI-0000h6-FE; Wed, 16 Mar 2005 01:54:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBSQG-0000h1-B2 for ltru@megatron.ietf.org; Wed, 16 Mar 2005 01:54:28 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06414 for ; Wed, 16 Mar 2005 01:54:26 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050316065356.WTQN4618.mta13.adelphia.net@DEWELL> for ; Wed, 16 Mar 2005 01:53:56 -0500 Message-ID: <0f3901c529f4$cd522940$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 15 Mar 2005 22:53:03 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Deprecated entries in the current registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Here are a few statistics on the current draft registry, for those who find this of interest. 479 language subtags 104 script subtags 301 region subtags 10 variant subtags 25 grandfathered tags 54 redundant tags for a total of 973 entries Language subtags with a canonical value: in, iw, ji, jw (4) Deprecated language subtags (canonical value is '--'): sh (1) Region subtags with a canonical value: BU, DY, HV, NH, RH, TP, YU, ZR (8) Deprecated region subtags (canonical value is '--'): BQ, CT, DD, FQ, FX, JT, MI, NQ, NT, PC, PU, PZ, SU, VD, WK, YD (16) Grandfathered tags with a canonical value: art-lojban, i-hak, i-klingon, i-lux, i-navajo, no-bok, no-nyn (7) 19 entries with a canonical value 17 deprecated entries with no replacement ("dash dash") Total of 36 deprecated and/or "alias" entries -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 07:19:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11762; Wed, 16 Mar 2005 07:19:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBXYf-00005V-HV; Wed, 16 Mar 2005 07:23:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBXTr-0001DO-7U; Wed, 16 Mar 2005 07:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBXTo-0001C2-UW for ltru@megatron.ietf.org; Wed, 16 Mar 2005 07:18:29 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11690 for ; Wed, 16 Mar 2005 07:18:25 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DBXSG-0007KE-7x for ltru@lists.ietf.org; Wed, 16 Mar 2005 13:16:52 +0100 Received: from c-134-89-135.hh.dial.de.ignite.net ([62.134.89.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Mar 2005 13:16:52 +0100 Received: from nobody by c-134-89-135.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Mar 2005 13:16:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 16 Mar 2005 13:10:52 +0100 Organization: Lines: 53 Message-ID: <4238224C.17C4@freenet.de> References: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.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: c-134-89-135.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: sss X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Addison Phillips wrote: > I think that the draft as it sits embodies most of your > suggestion anyway. For a "clean" start date like 1995 (RfC 1766) they'd be almost identical, maybe minus the five notorious ccTLDs. And they'd stay that way for at least 5 years + 1 day. Or at least 50 years if ISO 3166 adopts this transition period for old CCs. The earliest differences could then creep into the registry after 1995 +50 = 2045, if ISO 3166 is forced to recycle an old country code. With your startegy 3066bis would then stick to the old 1995 CC, my strategy would allow to follow ISO 3166. Both strategies are compatible with RfC 3066, arguably my idea is "more compatible", because it lets ISO 3166 do whatever it wants, like RfC 3066 does at the moment. >> region | BA | ... | >> region | CS | Czechoslovakia | >> region | CZ | ... | >> region | HR | ... | >> region | MK | ... | >> region | SI | ... | >> region | SK | ... | >> region | YU | ... | deprecated, use 891 >> region | 891 | Serbia and Montenegro | Yes, that's what you'd get for a 3066bis start date before the split of CS. Of course you won't pick this date, it would be incompatible with today's RfC 3066. IIRC Bruce found some Web pages with a lang= or xml:lang= using the new CS in a 3066 tag. > if ISO 3166 doesn't stick to 50-year reservations of > withdrawn codes, we will see sporadic creation of numeric > UN M.49 codes. The "we" in Internet community would see it for any transition period. 5 years or 50 years doesn't change the necessity to find a good mnemonic in ISO 3166-1. The "we" in you and me would probably manage to never see this strange effect, if you pick 1995 as start date, and if they don't invent immortality. > Countries will probably take notice of this and try to avoid > obtaining problematic codes when they change their names. New countries won't pick their names only to avoid a frozen CC in the 3066bis registry. If FQ makes sense for say Quebec they would go for it, and don't care about any FQ = Terre Adelaide. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 07:30:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12782; Wed, 16 Mar 2005 07:30:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBXjo-0000lc-Ux; Wed, 16 Mar 2005 07:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBXeG-0005RA-VE; Wed, 16 Mar 2005 07:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBXeD-0005LA-Td for ltru@megatron.ietf.org; Wed, 16 Mar 2005 07:29:15 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12625 for ; Wed, 16 Mar 2005 07:29:10 -0500 (EST) Received: from lns-p19-19-idf-82-254-246-100.adsl.proxad.net ([82.254.246.100] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DBXe9-0007HA-JF; Wed, 16 Mar 2005 04:29:10 -0800 Message-Id: <6.1.2.0.2.20050316113238.038d4260@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Mar 2005 12:24:51 +0100 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A9F4BB0@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A9F4BB0@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 On 22:15 15/03/2005, Addison Phillips said: >I think you should quit comparing this to iDNS, although I note that iDNS >*is* explicitly designed to be compatible with the existing DNS system. >This explains many of the idiosyncrasies of its design. Dear Addison, I think I am will not quit stop talking about the DNS for two good reasons. One is that I am a Registry Manager and represent the Registry Manager needs in here. Second is that naming is supported by just other standard and applications and has a considerable history referenced in a considerable number of other standards, laws, international resolutions related to international treaties. It also has another very important capacity: the capacity to say "no" to your propositions through its command of the IANA as an ICANN function. >RFC 1766/3066 language tags have a considerable history and are referenced >by a considerable number of other standards. Your desire to create an >incompatible language tagging system for whatever reason is based on the >need for some software applications to be updated anyway? That's a silly >bit of logic. I suggest that "silly" is an appropriate word in here. Up to now RFC 1766/3066 language tags _are_ compatible and I have no problem in living for ever with their present status. You introduce a perfectly reasonable need to extend and possibly modify their tagging. What I wand to discuss - and I think it very fair - is how these standard can be extended and possibly modified to suit your needs and if there is not a synergy in a common effort to best support my needs and yours. I do not see what would be "silly" in this. >Forget applications for a moment. Think document formats. There is >considerable content that contains RFC 3066 language tags. The HTML, XML, >CSS, HTTP, SMTP, and many derivative standards use these tags internally. I understand this. I understand that you are a W3C person, also considering Unicode concerns, in an IETF WG. But this should not make you forget that we also have the same need/problem in the non-web part of the internet. Let be clear. You may not want to share my analysis of the five issues involved in a "multilingual" internet (interidentification, internationalisation, multinationalization, multilingualization, vernacularization) and group/name them in a different way. I just repeat them so you may understand what I mean. In the network standardization process obviously W3C brings experience in interidentification (the language of a page as being different). Unicode obviously brings a huge/reference competence in internationalization. ccTLDs have a deep experience in or are by essence (as State bodies) multinationalization (what is discussed when referring to ISO 3166). We have in common a problem which is the IAB/IETF lack of interest/competence in multilingualization (what we globally approach through the tagging) as demonstrated in the IDNA inadequate solution and in the total lack of reference to it in the IAB RFC 3869. Now we have two possibilities. Either we join forces to reach a stable technical consensus everyone can build upon. Or we engage into a total fruitless war where States, i.e. ITU will eventually impose their dictat. And I suppose we both know what this dictat will be in the present situation, because they have been very clear in several consistent universal declarations. This will be in favor of multilingual domain names. The problem is that it will not satisfy you and it will certainly not satisfy me. >Many web sites use them to select content--which means the server >component, not the user agent. Many databases and programming languages >use them. Content and data has a long shelf life. Breaking compatibility >is a serious step. I know this for 30 years. This is why we have to be careful. There are nearly one million name servers around the world. There are hundred of millions of names replicated, aliased in them. Ignoring them in a standard which affects them in part will not be accepted. These names are used in billions pages, much more times than langtags. The question is not to know who is bigger. The question is how can we both serve them better and use the possible synergy to still spur more innovation there. >We have devised a format that updates language tags in a compatible manner >to meet demonstrable needs. What application cannot be addressed by this >(compatible) design? I said I had no time to review the draft before the end of the week. And the debate has not started on it. But what I can say from the current debate is there are four main aspects: 1. the format you quote 2. the maintenance of the format (what we discuss - management of the code lists) 3. the content management (organization and procedure) 4. the selection and registration of content (we are not concerned with the content, but are concerned with some guidelines). IRT point 1 (format) My reading is that up to now you have defined a format you checked as compatible with your needs. And rather than considering others' need as equally acceptable, you have more tried to keep or consider them out of the loop. I submit it is not the proper way. I agree that in the cases which are my own priorities my support background if very weak. I am personally interested in four areas: naming, OPES, user centric, CRC, multilingualism, scalability. Naming is ill technically supported by IETF documents and is now under grassroots effort with very large implications (tens of millions of users) that are totally unknown to IETF. OPES/MIDCOM are very important issues seriously documented or pushed by the IAB but obviously not mature. User centric is an evolution based on the core principles of networking (catenet) but long differed by technology limitations which comes back now. CRC are a generalized distributed (and therefore compatible) vision of what CLDR targets. I discussed multilingualism. Scalability is the core problem of IETF as we see it with the 11 years delay of IPv6, etc. Happily the new Chair is probably the best documenter of this issue. But probably not his priority. But these are necessary parts of the evolution of the response of the user demand. If you do not care about them, the demand will not care about your proposition. The longer it will take for them to realize it, the more confusion will have been introduced, the more time and money the correction will cost. The more time you will have wasted. And what will be poor is that most probably a lot of good work will have been lost. Consider X.400, consider EDI ... Sorry to have been long. I just do not know how to make understood what is so obvious to me and to most of those I know .... jfc ===================================================== For your convenience: Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 08:19:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17840; Wed, 16 Mar 2005 08:19:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBYUU-0003qN-A0; Wed, 16 Mar 2005 08:23:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBY7n-0002eJ-FH; Wed, 16 Mar 2005 07:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBY7l-0002eE-0D for ltru@megatron.ietf.org; Wed, 16 Mar 2005 07:59:45 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15637 for ; Wed, 16 Mar 2005 07:59:43 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DBY6M-0003di-JT for ltru@lists.ietf.org; Wed, 16 Mar 2005 13:58:19 +0100 Received: from c-134-89-135.hh.dial.de.ignite.net ([62.134.89.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Mar 2005 13:58:18 +0100 Received: from nobody by c-134-89-135.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Mar 2005 13:58:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 16 Mar 2005 13:52:47 +0100 Organization: Lines: 38 Message-ID: <42382C1F.762A@freenet.de> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.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: c-134-89-135.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: ss X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.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: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > you will be blocked if this is not what the British > Government wants (they are the one who accepted UK, GG, JJ, > IM..through ICANN, and GB through ISO). Don't forget AC. My best guess is that somebody talked faster than Jon Postel could think, and that's why we have AC and UK today. What has the British government to do with IM and the Channel Islands ? AFAIK they don't belong to the EU, they are no part of the UK, and they are no part of the British Empire like GI or SH (incl. AC, but far away from SH). Maybe I'm wrong, and the "Duchy of Normandy" story is only a fairy tale. > You cannot _decide_ to use the IANA or ISO source. This WG can decide that the language tag reviewer should create region codes as he sees fit. It would fail in the "last call", because nobody would volunteer as a tag reviewer in this case, unless he's suicidal. But in theory the WG could propose this. > this market in this case starts with the Governments Governments have _nothing_ to do with language tags, that's a feature and no bug. I'm not planning to discuss ku-TR with the government of TR, and I also refuse to discuss mnc-TW (?) with the government of CN. In many cases languages are _not_ recognized by the corresponding regional governments. > What I try to make understood is that the document this WG > will produce will be counterproductive if it is not supported > by the entities in charge (Governments) I'm strongly opposed to this position. Governments are among the last entities I'd trust, and only after a random generator failed. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 10:20:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00311; Wed, 16 Mar 2005 10:20:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBaNz-0002RX-Je; Wed, 16 Mar 2005 10:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBaJ7-0000Ta-5w; Wed, 16 Mar 2005 10:19:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBaJ5-0000TU-8y for ltru@megatron.ietf.org; Wed, 16 Mar 2005 10:19:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00166 for ; Wed, 16 Mar 2005 10:19:33 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBaN8-0002Jg-QV for ltru@ietf.org; Wed, 16 Mar 2005 10:23:47 -0500 Received: from lns-p19-19-idf-82-254-246-100.adsl.proxad.net ([82.254.246.100] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DBaJ2-0006Eo-44; Wed, 16 Mar 2005 07:19:32 -0800 Message-Id: <6.1.2.0.2.20050316144451.044824d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Mar 2005 16:19:22 +0100 To: nobody@xyzzy.claranet.de, ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <42382C1F.762A@freenet.de> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> <42382C1F.762A@freenet.de> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Dear Frank, I understand and respect your political positions. What I do not understand then is why do you want to use the IANA? As you may know, the IANA is an US Governement set of functions contracted to ICANN. http://www.icann.org/general/iana-contract-09feb00.htm http://www.icann.org/general/iana-contract-21mar01.htm http://www.icann.org/general/iana-contract-17mar03.htm At 13:52 16/03/2005, Frank Ellermann wrote: >I'm strongly opposed to this position. Governments are among >the last entities I'd trust, and only after a random generator >failed. More generaly you may want to consult: http://www.icann.org/general/agreements.htm to understand in which environment the IANA functions. The MoU with IETF stipulates that: "4.3. Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU. Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4. (For purposes of this MOU, the term "assignments" includes allocations.) In the event ICANN adopts a policy that prevents it from complying with the provisions of this Section 4 with respect to the assignments described in (a) - (c) above, ICANN will notify the IETF, which may then exercise its ability to cancel this MOU under Section 2 above. " What is discussed here is "in the event ICANN adopts a policy ....". I submit that what is relevant to IDNs does not fall under the terms of this agreement. I submit that what is true for ICANN adopting a policy .... is also true in the case IETF introduces discrepancies with ICANN policies (your abrupt wording concerning some of the ccTLDs is an obvious discrepancy). I submit that this wording can only confort the USG, ICANN, the GAC, UNESCO, ITU to consider that the name IANA area extends to language issues. A position I certainly support, extending it to Civil Society co-control. This is why I suggest that instead in saying "I do what I want", we try to coordinate, look for syngergy in the others' need we could address at the same time, to obtain a better entertwinned and therefore mutually protected situation. jfc Hosting a registry will cost you probably $ 250, all included. And as a premium, I would support anything you may want to do. ===================================================== For your convenience: Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 11:29:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06753; Wed, 16 Mar 2005 11:29:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBbSm-0006MN-DR; Wed, 16 Mar 2005 11:33:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBbNg-0006hK-E0; Wed, 16 Mar 2005 11:28:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBbNe-0006hF-92 for ltru@megatron.ietf.org; Wed, 16 Mar 2005 11:28:22 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06687 for ; Wed, 16 Mar 2005 11:28:19 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050316162750.MLKA4618.mta13.adelphia.net@DEWELL> for ; Wed, 16 Mar 2005 11:27:50 -0500 Message-ID: <0f5601c52a45$04b66720$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050316152116.TSWN5424.mta6.adelphia.net@megatron.ietf.org> Date: Wed, 16 Mar 2005 08:27:15 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> I think that the draft as it sits embodies most of your >> suggestion anyway. > > For a "clean" start date like 1995 (RfC 1766) they'd be almost > identical, maybe minus the five notorious ccTLDs. And they'd > stay that way for at least 5 years + 1 day. Or at least 50 > years if ISO 3166 adopts this transition period for old CCs. We have tried to be consistent in following ISO 3166 in the initial draft registry. AC, GG, IM, JE, and UK are *not* officially assigned ISO 3166 codes. They are ccTLDs, and they have been reserved by ISO 3166 for possible future assignment (except UK, which is reserved to *prevent* it from being assigned). It is possible that ISO 3166/MA will assign these codes at some point in the future with the meaning we currently expect. Or, it is possible that they will shift gears and assign them to some completely different entity. Remember that the alpha-3 code ROU was once reserved, because of its use for "Republic of Uruguay" in another context, and was subsequently assigned to Romania. "Reserved" is no guarantee of anything. > The earliest differences could then creep into the registry > after 1995 +50 = 2045, if ISO 3166 is forced to recycle an old > country code. With your startegy 3066bis would then stick to > the old 1995 CC, my strategy would allow to follow ISO 3166. The whole point of mapping ISO 3166 to region subtags in the registry, instead of using them directly, is that "following ISO 3166" faithfully can lead to instability when a code is changed, or worse, reused. That is what happened with CS. The draft removes this instability, at the expense of breaking with perfect adherence to ISO 3166 if necessary. Your strategy allows non-ISO 3166 ccTLDs, so that's not exactly "following ISO 3166" either. > Both strategies are compatible with RfC 3066, arguably my idea > is "more compatible", because it lets ISO 3166 do whatever it > wants, like RfC 3066 does at the moment. As stated above, letting ISO 3166 do whatever it wants is precisely a non-goal of the draft. > Yes, that's what you'd get for a 3066bis start date before the > split of CS. Of course you won't pick this date, it would be > incompatible with today's RfC 3066. IIRC Bruce found some Web > pages with a lang= or xml:lang= using the new CS in a 3066 tag. Yes, and the draft has been changed so that the magic cutoff date will be the date of publication of the draft. That ensures compatibility with RFC 3066 and should close this particular debate. >> if ISO 3166 doesn't stick to 50-year reservations of >> withdrawn codes, we will see sporadic creation of numeric >> UN M.49 codes. > > The "we" in Internet community would see it for any transition > period. 5 years or 50 years doesn't change the necessity to > find a good mnemonic in ISO 3166-1. The "we" in you and me > would probably manage to never see this strange effect, if you > pick 1995 as start date, and if they don't invent immortality. "Inventing immortality" is a phrase that is best avoided in this peaceful and cooperative environment. What the draft attempts to do is "enforce stability." >> Countries will probably take notice of this and try to avoid >> obtaining problematic codes when they change their names. > > New countries won't pick their names only to avoid a frozen CC > in the 3066bis registry. If FQ makes sense for say Quebec they > would go for it, and don't care about any FQ = Terre Adelaide. Language tags are not the only application that call for more stability that ISO 3166 has provided thus far. They received criticism from other groups as well for reusing CS. I imagine that in the future, the MA will take a closer look at avoiding the reuse of codes. Note that Addison did not say a country would choose its name to avoid a problematic code, only that they would not request the code itself. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 11:39:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07845; Wed, 16 Mar 2005 11:39:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBbcx-0006xF-4f; Wed, 16 Mar 2005 11:44:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBbXR-0000W7-TC; Wed, 16 Mar 2005 11:38:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBbXR-0000W2-6x for ltru@megatron.ietf.org; Wed, 16 Mar 2005 11:38:29 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07666 for ; Wed, 16 Mar 2005 11:38:24 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050316163755.MUUH4618.mta13.adelphia.net@DEWELL> for ; Wed, 16 Mar 2005 11:37:55 -0500 Message-ID: <0f5c01c52a46$6d85f4e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 16 Mar 2005 08:37:21 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit In the next few days I will be working on a full description of all the steps necessary to generate the initial draft registry, based on the underlying standards and describing any judgments that were made. This is not as trivial as it may seem, because of the need to consult lists of withdrawn codes from various sources, among other things. Also, I will submit some proposed changes to the registry that improve its consistency with regard to underlying standards. Some of these are based on some of Frank's earlier suggestions. More details later. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 14:38:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28330; Wed, 16 Mar 2005 14:38:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBePQ-0000t1-2Z; Wed, 16 Mar 2005 14:42:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeKP-0004j0-Oq; Wed, 16 Mar 2005 14:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeKO-0004iv-Ab for ltru@megatron.ietf.org; Wed, 16 Mar 2005 14:37:12 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28225 for ; Wed, 16 Mar 2005 14:37:09 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DBeBj-0004qO-9W for ltru@lists.ietf.org; Wed, 16 Mar 2005 20:28:15 +0100 Received: from c-134-89-135.hh.dial.de.ignite.net ([62.134.89.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Mar 2005 20:28:15 +0100 Received: from nobody by c-134-89-135.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Mar 2005 20:28:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 16 Mar 2005 20:13:41 +0100 Organization: Lines: 92 Message-ID: <42388565.FA5@xyzzy.claranet.de> References: <20050316152116.TSWN5424.mta6.adelphia.net@megatron.ietf.org> <0f5601c52a45$04b66720$030aa8c0@DEWELL> 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: c-134-89-135.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 3.5 (+++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > "following ISO 3166" faithfully can lead to instability when > a code is changed, or worse, reused. That is what happened > with CS. Yes, it was a stupid idea to follow ISO 3166-1 faithfully, they are forced to reuse old codes if countries want to have a code somehow reflecting the name of the coutry. We (or at least me) only didn't see how stupid this was until the new CS forced us to think. The draft tries a compromise, freeze all codes as they are now, allow new codes not conflicting with "frozen codes", otherwise use the UN number. I proposed another compromise, accept that some old codes must be reassigned sooner or later, and support UN numbers as "canonical" alternatives where stability is the most important issue. In a case like YT they were probably desperate to find a code for Mayotte, and they only didn't use MA, MO, MT, or MY because all these codes were already assigned. And for CS they looked into their table and found that SA, SB, SE, SM, and CM aren't free, but the old CS was "free" under their old rules. BTW, that's strange, I hated CS right from the moment when I first saw it, and now I'm defending them, because it's really not their fault if somebody else wants stability where it's almost impossible. The country codes aren't arbitrary combinations of 26 * 26 - 42 character pairs, they are generally abbreviations or acronyms. The draft kills ISO 3166-1 very slowly, one CC after the other as soon as it's reassigned, drifting away from ISO 3166-1 and forever listing some then prehistoric codes. Like the RH in the actual snapshot of a possible registry. > Your strategy allows non-ISO 3166 ccTLDs That's an independent detail, IANA as filter for the ISO 3166-1 input. This strategy would also work without the five ccTLDs. Addison's strategy also allows to use IANA ccTLDs as filtered ISO 3166-1 input, if the draft would say, so that has nothing to do with the procedure for future changes. As you said we'd be in trouble if ISO 3166-1 assigns these five codes to something else. ICANN would be also in trouble, what should they do, redelegate e.g. IM against the will of NIC.IM ? Let's forget my idea of using all ccTLDs for the moment. Maybe it's a bad idea. The best solution for all interested parties would be to assign AC, IM, GG, and JE officially, but I now see that a BCP about _language_ tags is not the place to start this. ISO 3166-1 should do it. Introducing UK as an alias for GB in a BCP about language tags is admittedly too odd to consider it, even if implementations tolerate it as a well-known user error. > the draft has been changed so that the magic cutoff date will > be the date of publication of the draft. At the moment you still have BQ, DD, RH, 200, etc. deprecated long before 2005, and blocking any future BQ, DD, or RH as CC. The deprecated 200 cannot block anything, so that's no problem. Are you sure that you want 172 "commonwealth of indepedent states" ? It's not exactly clear what it's meant to be, but all indepedent states have their own CC, and they all belonged to the former SU. 172 is apparently SU excl. Estonia, Latvia, and Lithuania. It's listed below the "selected economic and other groupings" as a subdivision of 778 on the UN page. > "Inventing immortality" is a phrase that is best avoided in > this peaceful and cooperative environment. Sorry. it was meant as a joke, with a new 50+ years transition period we're probably not more here when something odd happens with a future registry based on CCs 1995. They could reassign DY or VD after 2027, blocked in the registry based on 197?. > They received criticism from other groups as well for reusing > CS. Yes, among others I did. And I was wrong, at least partially. The IAB said something about 300 years IIRC. Try to invent a hypothetical 3166-IAB starting A.D. 1700, it's IMHO impossible. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 16:20:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18138; Wed, 16 Mar 2005 16:20:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBg02-0001NR-2d; Wed, 16 Mar 2005 16:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfN1-0005wM-97; Wed, 16 Mar 2005 15:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfMx-0005vu-87; Wed, 16 Mar 2005 15:43:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06310; Wed, 16 Mar 2005 15:43:53 -0500 (EST) Message-Id: <200503162043.PAA06310@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Mar 2005 15:43:53 -0500 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-00.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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-registry-00.txt Pages : 44 Date : 2005-3-16 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. This document obsoletes RFC 3066 (which replaced RFC 1766). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-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-registry-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-registry-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: <2005-3-16160955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16160955.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Wed Mar 16 18:09:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10566; Wed, 16 Mar 2005 18:09:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhhZ-0001mR-Fz; Wed, 16 Mar 2005 18:13:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhbi-0000Jd-Ot; Wed, 16 Mar 2005 18:07:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBhbg-0000JQ-U9 for ltru@megatron.ietf.org; Wed, 16 Mar 2005 18:07:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10273 for ; Wed, 16 Mar 2005 18:07:14 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhfn-0001hN-O0 for ltru@ietf.org; Wed, 16 Mar 2005 18:11:32 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id B82534F00C for ; Wed, 16 Mar 2005 18:07:09 -0500 (EST) Message-Id: <6.0.0.20.2.20050317075913.0a4b4c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Mar 2005 08:03:16 +0900 To: ltru@ietf.org From: Martin Duerst Subject: First draft published, please comment (was: Re: [Ltru] I-D ACTION:draft-ietf-ltru-registry-00.txt) In-Reply-To: <200503162043.PAA06310@ietf.org> References: <200503162043.PAA06310@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit With the publication of this Internet-Draft, we have reached our first milestone. Thanks to Addison and Mark for their work as editors. Now that we have a base document for discussion, we can start with the core of our work. Everybody, please read the published draft carefully and comment on it. For minor editorial stuff, please put a series of comments into one email. For more serious issues that you think may cause further discussion, please use separate mails per issue. Please carefully choose a subject, not just something like "draft comments". Regards, Martin. At 05:43 05/03/17, Internet-Drafts@ietf.org wrote: >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-registry-00.txt > Pages : 44 > Date : 2005-3-16 > >This document describes the structure, content, construction, and > semantics of language tags for use in cases where it is desirable to > indicate the language used in an information object. It also > describes how to register values for use in language tags and the > creation of user defined extensions for private interchange. This > document obsoletes RFC 3066 (which replaced RFC 1766). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 20:20:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22481; Wed, 16 Mar 2005 20:20:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBjkQ-0000Im-Lc; Wed, 16 Mar 2005 20:24:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBjeF-0004p7-H8; Wed, 16 Mar 2005 20:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBjeD-0004iu-MG for ltru@megatron.ietf.org; Wed, 16 Mar 2005 20:18:02 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22199 for ; Wed, 16 Mar 2005 20:17:56 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DBjck-0005yS-Ek for ltru@lists.ietf.org; Thu, 17 Mar 2005 02:16:31 +0100 Received: from 62.80.58.45 ([62.80.58.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Mar 2005 02:16:30 +0100 Received: from nobody by 62.80.58.45 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Mar 2005 02:16:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Mar 2005 02:14:06 +0100 Organization: Lines: 37 Message-ID: <4238D9DE.3D55@xyzzy.claranet.de> References: <200503162043.PAA06310@ietf.org> <6.0.0.20.2.20050317075913.0a4b4c40@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: 62.80.58.45 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] singleton (was: First draft published, please comment) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Martin Duerst wrote: > For minor editorial stuff, please put a series of comments > into one email. Minor fix, already posted as a comment for draft-10, but it did not make into the new draft: | One comment says that the singleton-ABNF is not yet finished: | | That's an 2234 oddity, if you say "x" or "X" then it's always | case insensitive, therefore you need %d120 or %d88 for a case | sensitive "x" vs. "X". A possible solution for draft-11: | privateuse = "x" 1*("-" (1*8alphanum)) ; private use subtag(s) | singleton = ALPHA ; Single letters: x/X is for private use Looking again at it that's still not correct, it should be: singleton = %x41-57 / %x59-6A / %x61-77 / %x79-7A ; ALPHA excl. "x" / "X" for private use doesn't care about these subtle details, but likes the new ugly "singleton" and the simplified "privateuse". RfC 2234 belongs to the future "normative references" in the next draft. RfC 1521 in the references is old, it's also apparently not used in the text as [8] or 1521. Maybe add [8] to the word MIME in 2.4, and replace RfC 1521 by 2045. That would go to the "informative references" in the next draft. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 20:35:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23940; Wed, 16 Mar 2005 20:35:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBjzh-0001E2-1Z; Wed, 16 Mar 2005 20:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBjv8-00022t-QS; Wed, 16 Mar 2005 20:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBjv6-00022o-SH for ltru@megatron.ietf.org; Wed, 16 Mar 2005 20:35:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23898 for ; Wed, 16 Mar 2005 20:35:26 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBjzF-0001DN-EF for ltru@ietf.org; Wed, 16 Mar 2005 20:39:45 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Mar 2005 17:35:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] singleton (was: First draft published, please comment) Date: Wed, 16 Mar 2005 17:35:12 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A9F5393@irvmbxw01.quest.com> Thread-Topic: [Ltru] singleton (was: First draft published, please comment) Thread-Index: AcUqj2+ndB5auaSTSx6MrErUTCXXXgAAOvKA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 17 Mar 2005 01:35:13.0014 (UTC) FILETIME=[90568160:01C52A91] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Fenner's parser doesn't like the new ABNF. I can make it ugly in the = manner suggested easily enough, though. It isn't very friendly, but I = don't think it matters. Perhaps: singleton =3D %x41-57 / %x59-6A / %x61-77 / %x79-7A ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z"=20 ; Single letters: x/X is reserved for private use With regard to the references, these have not been cleaned in awhile. = RFC 1521 is a dead reference. It was carried forward from RFC 3066... = but wasn't referenced in that RFC either, merely carried forward from = RFC 1766, Section 4.1. I can update the reference or we could just expunge it altogether. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: Wednesday, March 16, 2005 5:14 PM > To: ltru@ietf.org > Subject: [Ltru] singleton (was: First draft published, please comment) >=20 > Martin Duerst wrote: >=20 > > For minor editorial stuff, please put a series of comments > > into one email. >=20 > Minor fix, already posted as a comment for draft-10, but it did > not make into the new draft: >=20 > | One comment says that the singleton-ABNF is not yet finished: > | > = d=3D31580> >=20 > | That's an 2234 oddity, if you say "x" or "X" then it's always > | case insensitive, therefore you need %d120 or %d88 for a case > | sensitive "x" vs. "X". A possible solution for draft-11: >=20 > | privateuse =3D "x" 1*("-" (1*8alphanum)) ; private use subtag(s) > | singleton =3D ALPHA ; Single letters: x/X is for private use >=20 > Looking again at it that's still not correct, it should be: >=20 > singleton =3D %x41-57 / %x59-6A / %x61-77 / %x79-7A > ; ALPHA excl. "x" / "X" for private use >=20 > doesn't care about these > subtle details, but > likes the new ugly "singleton" and the simplified "privateuse". >=20 > RfC 2234 belongs to the future "normative references" in the > next draft. >=20 > RfC 1521 in the references is old, it's also apparently not > used in the text as [8] or 1521. Maybe add [8] to the word > MIME in 2.4, and replace RfC 1521 by 2045. That would go to > the "informative references" in the next draft. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 16 23:53:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10601; Wed, 16 Mar 2005 23:53:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBn4k-0001Vb-K9; Wed, 16 Mar 2005 23:57:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBmx1-0005re-Cm; Wed, 16 Mar 2005 23:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBmwx-0005rX-Rl for ltru@megatron.ietf.org; Wed, 16 Mar 2005 23:49:36 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09570 for ; Wed, 16 Mar 2005 23:49:29 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DBmvJ-0006f2-IZ for ltru@lists.ietf.org; Thu, 17 Mar 2005 05:47:53 +0100 Received: from du-042-057.access.de.clara.net ([213.221.65.57]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Mar 2005 05:47:53 +0100 Received: from nobody by du-042-057.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Mar 2005 05:47:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Mar 2005 05:42:06 +0100 Organization: Lines: 21 Message-ID: <42390A9E.9DA@xyzzy.claranet.de> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> <42382C1F.762A@freenet.de> <6.1.2.0.2.20050316144451.044824d0@mail.jefsey.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-057.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Registry homepage (was: "Obsolete" region subtags) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > why do you want to use the IANA? I'm not exactly sure why, but at the moment I trust that they try to work for some common good. I never had any problems with ICANN, quite the contrary, I like their WDPRS among other things. That's all off topic here, let's stick to the facts, at the moment IANA hosts all registries related to RfCs. In theory it might be possible to organize this in another way, with a registry at the W3C, an Unicode TR, or an ECMA standard. But why ? IANA will do what the language tag reviewer says, as long as he follows the rules in the future 3066bis. ICANN won't get (let alone follow) orders by an US government to unlist "haw", that's bad science fiction. And if ICANN is dissolved somebody else would volunteer as the new IANA. Not , that server is apparently down today, but maybe ORSN or OCLC or W3C or Unicode etc. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 00:18:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12892; Thu, 17 Mar 2005 00:18:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnTP-0002cq-RM; Thu, 17 Mar 2005 00:23:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnOU-0002dG-To; Thu, 17 Mar 2005 00:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnOJ-0002cs-6c for ltru@megatron.ietf.org; Thu, 17 Mar 2005 00:17:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12729 for ; Thu, 17 Mar 2005 00:17:47 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnSU-0002bF-0a for ltru@ietf.org; Thu, 17 Mar 2005 00:22:10 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id EB6D94EF92; Thu, 17 Mar 2005 00:17:47 -0500 (EST) Message-Id: <6.0.0.20.2.20050316180645.095bde50@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Mar 2005 14:17:31 +0900 To: "JFC (Jefsey) Morfin" , From: Martin Duerst Subject: RE: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <6.1.2.0.2.20050315203041.036b5090@mail.jefsey.com> References: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> <6.1.2.0.2.20050315203041.036b5090@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit [chairs hat mostly on] This WG is not about IDNS or TLDs or similar things. If you think that some insight may be gained from looking at parallels, talking about other technology than language tags may make sense, but we first would need some concrete proposal. Just arguing that we can change anything because browsers will have to change anyway doesn't help if we don't have a concrete proposal of how to change it. The best way for you to make a concrete proposal is to write it up and submit it as a (personal) internet-draft, which may or may not then be adopted by the WG. This is the traditional style of working in the IETF.The second best way is to send it to this list; this is okay in particular if the proposal is concise. If you have already made a concrete proposal, a pointer may be okay, although if it hasn't been made on this list, a copy would probably be better. But please make very sure that you have a concrete proposal, not only some general thoughts or oppinions. Many thanks in advance. Regards, Martin. At 05:47 05/03/16, JFC (Jefsey) Morfin wrote: >At 18:14 15/03/2005, Addison Phillips wrote: >>Allowing multiple subtags to mean the same thing, as Frank suggests below, would be a problem. Many language tag processors that I know of are implemented based solely on the values of the tags themselves, with no external knowledge baked into them. The existence of a registry might change that to some degree, but you'll still have many of what the draft calls "well-formed" processors for which "GB" is just a token. > >I question myself on this. The DNS is 22 years old, the mail older. I understand that one wants to be careful at not changing them too much - yet the market will change them if it solved the spam. IDNs are one year and a half old and several consider that one can still change or even kill them. As far as I understand, you refer to applications resulting from RFC 3066, and may be from its predecessor? So they are 3 to 7 years old? They most probably are browsers/aplications which have anyway to be updated to support IDNs (applications needing to check languages are likely to also use IDNs)? > >We are going to have a lot of changes in the DNS in the coming month to support the local TLDs which are to be a must. The support of the Tables will probably be required at users level, for 3+LD consistency checks,etc. (even if not planned yet). Many other applications would probably want then to use functions using country codes if they were available. > >Microsoft always said they wanted to watch the market reaction before implementing the IDN support in the OS. This WG could consider user located functions to get and integrate the IANA cc table and updates . It could then use them. Would it not be better to start anew while there is still a "small" base (RFC 3066 is still here for them) rather than to continue for ever with an old system? > >BTW I personally think the IDN Tables and other TLD infos (such as the lingual aliases of the TLDs) are part of the Locale, >jfc > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 00:20:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13056; Thu, 17 Mar 2005 00:20:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnUe-0002hU-IC; Thu, 17 Mar 2005 00:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnOV-0002dK-Dx; Thu, 17 Mar 2005 00:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnOK-0002d6-7f for ltru@megatron.ietf.org; Thu, 17 Mar 2005 00:17:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12746 for ; Thu, 17 Mar 2005 00:17:49 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnSV-0002bN-5k for ltru@ietf.org; Thu, 17 Mar 2005 00:22:11 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 3D8B04F100; Thu, 17 Mar 2005 00:17:49 -0500 (EST) Message-Id: <6.0.0.20.2.20050316181351.095c06b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 16 Mar 2005 18:27:01 +0900 To: "JFC (Jefsey) Morfin" , From: Martin Duerst Subject: RE: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <6.1.2.0.2.20050315203041.036b5090@mail.jefsey.com> References: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> <6.1.2.0.2.20050315203041.036b5090@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit [chairs hat off, mostly off topic] At 05:47 05/03/16, JFC (Jefsey) Morfin wrote: >I question myself on this. The DNS is 22 years old, the mail older. I understand that one wants to be careful at not changing them too much - yet the market will change them if it solved the spam. IDNs are one year and a half old and several consider that one can still change or even kill them. You are right that technology sometimes changes very quickly. But it is usually difficult to predict when that happens. >As far as I understand, you refer to applications resulting from RFC 3066, and may be from its predecessor? So they are 3 to 7 years old? They most probably are browsers/aplications which have anyway to be updated to support IDNs (applications needing to check languages are likely to also use IDNs)? Updating browsers for IDN is already happening. But this doesn't guarantee that the update for language tagging can be piggybacked. Browser makers tend to concentrate on the big issues. >We are going to have a lot of changes in the DNS in the coming month to support the local TLDs which are to be a must. I sincerely hope non-ASCII TLDs will happen. But I think they will first happen for ccTLDs. >The support of the Tables will probably be required at users level, for 3+LD consistency checks,etc. (even if not planned yet). I'd clearly disagree here. If any organization messes up their 3+LDs, that's their own fault. The client side doesn't have to bother. >Many other applications would probably want then to use functions using country codes if they were available. I don't really see that. Maybe examples could help. >Microsoft always said they wanted to watch the market reaction before implementing the IDN support in the OS. This WG could consider user located functions to get and integrate the IANA cc table and updates. It could then use them. What exactly are IANA cc tables? (pointers appreciated). How are they related to language tags? >Would it not be better to start anew while there is still a "small" base (RFC 3066 is still here for them) rather than to continue for ever with an old system? Only if the benefit of changing covers the costs of changing. As I don't really have an idea what the new system you are thinking of is looking like, I cant' really evaluate these benefits and costs. >BTW I personally think the IDN Tables and other TLD infos (such as the lingual aliases of the TLDs) are part of the Locale, I very strongly think that there should be no lingual aliases for TLDs. For many TLDs, I think there should be script equivalents, but that's a different thing on two counts. Also, I don't think that IDN tables should be part of a locale. A locale is essentially a collection of preferences for a group of users. IDN tables simply describe constraints on some particular kind of data (a domain name label in a certain domain). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 00:20:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13103; Thu, 17 Mar 2005 00:20:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnV3-0002i4-UQ; Thu, 17 Mar 2005 00:24:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnOd-0002df-PZ; Thu, 17 Mar 2005 00:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnOb-0002dY-0D for ltru@megatron.ietf.org; Thu, 17 Mar 2005 00:18:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12802 for ; Thu, 17 Mar 2005 00:18:05 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnSl-0002bn-4L for ltru@ietf.org; Thu, 17 Mar 2005 00:22:28 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 858B54EF92; Thu, 17 Mar 2005 00:18:04 -0500 (EST) Message-Id: <6.0.0.20.2.20050316180251.095e6d30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 16 Mar 2005 18:06:19 +0900 To: "Addison Phillips" , "Frank Ellermann" , From: Martin Duerst Subject: RE: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit At 02:14 05/03/16, Addison Phillips wrote: >We chose the UN M.49 numbers as the backup for ISO 3166 codes precisely >because they are stable. > >Allowing multiple subtags to mean the same thing, as Frank suggests below, >would be a problem. [chairs hat off] I fully agree. The fewer alternatives for the same thing, the better. We worked hard on RFC 3066 to make sure that only one of potentially three codes for the same language (2-letter code, 3-letter bibliographic code, 3-letter terminology code) was used, and that the solution was compatible with RFC 1766. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 00:40:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15037; Thu, 17 Mar 2005 00:40:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnoc-0003YK-GT; Thu, 17 Mar 2005 00:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnk2-0006RD-Qi; Thu, 17 Mar 2005 00:40:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnjt-0006Mw-WD for ltru@megatron.ietf.org; Thu, 17 Mar 2005 00:40:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15011 for ; Thu, 17 Mar 2005 00:40:06 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBno4-0003Xc-6k for ltru@ietf.org; Thu, 17 Mar 2005 00:44:29 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id F012C4EFDC; Thu, 17 Mar 2005 00:40:06 -0500 (EST) Message-Id: <6.0.0.20.2.20050317141918.08dcbbb0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Mar 2005 14:29:27 +0900 To: "JFC (Jefsey) Morfin" , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit At 20:28 05/03/15, JFC (Jefsey) Morfin wrote: >What I try to make understood is that the document this WG will produce will be counterproductive if it is not supported by the entities in charge (Governments) and their usual delegates (GAC, national NICs, Culture Ministries, Academic and Computer people), their common bodies (ISO, ITU, UNESCO, WSIS) and their national users. Worst, if it is opposed. RFC 1766 and RFC 3066 haven't had either much support or much opposition from governements and related organizations. My understanding is that this was because they did the job they were designed to do reasonably well. What makes you think that for the update we are currently working on, this will be different? My assumption is that if we produce something that does it's job reasonably well, people (individuals, governements, companies,...) will just use it. If there is anybody out there that does not trust us to do a reasonable job, the best thing for them is to join and help us do better. If somebody isn't joining, then the details that we work on are probably just not important enough to them, and they are ready to use whatever we produce, in the same way they have been fine with previous RFCs. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 00:41:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15114; Thu, 17 Mar 2005 00:41:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBnph-0003dS-2B; Thu, 17 Mar 2005 00:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnk3-0006RH-7r; Thu, 17 Mar 2005 00:40:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBnjw-0006N1-SB for ltru@megatron.ietf.org; Thu, 17 Mar 2005 00:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15017 for ; Thu, 17 Mar 2005 00:40:09 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBno8-0003Xh-0Y for ltru@ietf.org; Thu, 17 Mar 2005 00:44:32 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 245484EF92; Thu, 17 Mar 2005 00:40:08 -0500 (EST) Message-Id: <6.0.0.20.2.20050317143506.0a4b9ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Mar 2005 14:39:42 +0900 To: Frank Ellermann , ltru@ietf.org, "Doug Ewell" From: Martin Duerst Subject: Re: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <42388565.FA5@xyzzy.claranet.de> References: <20050316152116.TSWN5424.mta6.adelphia.net@megatron.ietf.org> <0f5601c52a45$04b66720$030aa8c0@DEWELL> <42388565.FA5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Hello Frank and Doug, The two of you are very at easy to discuss the particulars of some of these country codes. However, I fear that most people don't remember them as well as you do. Also, some people may be new to this WG and not have followed the discussion on the ietf-languages list. Would it be possible for the two of you (and others, of course) to provide a bit more of background information with your discussion? I'm not asking for lengthy discussions, just a little bit of additional info to help new people. Many thanks in advance, Martin. At 04:13 05/03/17, Frank Ellermann wrote: >Doug Ewell wrote: > >> "following ISO 3166" faithfully can lead to instability when >> a code is changed, or worse, reused. That is what happened >> with CS. > >Yes, it was a stupid idea to follow ISO 3166-1 faithfully, they >are forced to reuse old codes if countries want to have a code >somehow reflecting the name of the coutry. We (or at least me) >only didn't see how stupid this was until the new CS forced us >to think. > >The draft tries a compromise, freeze all codes as they are now, >allow new codes not conflicting with "frozen codes", otherwise >use the UN number. I proposed another compromise, accept that >some old codes must be reassigned sooner or later, and support >UN numbers as "canonical" alternatives where stability is the >most important issue. > >In a case like YT they were probably desperate to find a code >for Mayotte, and they only didn't use MA, MO, MT, or MY because >all these codes were already assigned. And for CS they looked >into their table and found that SA, SB, SE, SM, and CM aren't >free, but the old CS was "free" under their old rules. > >BTW, that's strange, I hated CS right from the moment when I >first saw it, and now I'm defending them, because it's really >not their fault if somebody else wants stability where it's >almost impossible. > >The country codes aren't arbitrary combinations of 26 * 26 - 42 >character pairs, they are generally abbreviations or acronyms. > >The draft kills ISO 3166-1 very slowly, one CC after the other >as soon as it's reassigned, drifting away from ISO 3166-1 and >forever listing some then prehistoric codes. Like the RH in >the actual snapshot of a possible registry. > >> Your strategy allows non-ISO 3166 ccTLDs > >That's an independent detail, IANA as filter for the ISO 3166-1 >input. This strategy would also work without the five ccTLDs. > >Addison's strategy also allows to use IANA ccTLDs as filtered >ISO 3166-1 input, if the draft would say, so that has nothing >to do with the procedure for future changes. > >As you said we'd be in trouble if ISO 3166-1 assigns these five >codes to something else. ICANN would be also in trouble, what >should they do, redelegate e.g. IM against the will of NIC.IM ? > >Let's forget my idea of using all ccTLDs for the moment. Maybe >it's a bad idea. The best solution for all interested parties >would be to assign AC, IM, GG, and JE officially, but I now see >that a BCP about _language_ tags is not the place to start this. > >ISO 3166-1 should do it. Introducing UK as an alias for GB in >a BCP about language tags is admittedly too odd to consider it, >even if implementations tolerate it as a well-known user error. > >> the draft has been changed so that the magic cutoff date will >> be the date of publication of the draft. > >At the moment you still have BQ, DD, RH, 200, etc. deprecated >long before 2005, and blocking any future BQ, DD, or RH as CC. > >The deprecated 200 cannot block anything, so that's no problem. > >Are you sure that you want 172 "commonwealth of indepedent >states" ? It's not exactly clear what it's meant to be, but >all indepedent states have their own CC, and they all belonged >to the former SU. 172 is apparently SU excl. Estonia, Latvia, >and Lithuania. It's listed below the "selected economic and >other groupings" as a subdivision of 778 on the UN page. > >> "Inventing immortality" is a phrase that is best avoided in >> this peaceful and cooperative environment. > >Sorry. it was meant as a joke, with a new 50+ years transition >period we're probably not more here when something odd happens >with a future registry based on CCs 1995. They could reassign >DY or VD after 2027, blocked in the registry based on 197?. > >> They received criticism from other groups as well for reusing >> CS. > >Yes, among others I did. And I was wrong, at least partially. >The IAB said something about 300 years IIRC. Try to invent a >hypothetical 3166-IAB starting A.D. 1700, it's IMHO impossible. > > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 02:55:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18910; Thu, 17 Mar 2005 02:55:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBpvJ-0000tz-U4; Thu, 17 Mar 2005 03:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBpqj-00015z-Vb; Thu, 17 Mar 2005 02:55:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBpqe-00013G-Oh for ltru@megatron.ietf.org; Thu, 17 Mar 2005 02:55:17 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18854 for ; Thu, 17 Mar 2005 02:55:13 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DBpow-0003wm-BA for ltru@lists.ietf.org; Thu, 17 Mar 2005 08:53:32 +0100 Received: from 212.82.251.148 ([212.82.251.148]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Mar 2005 08:53:30 +0100 Received: from nobody by 212.82.251.148 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Mar 2005 08:53:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 17 Mar 2005 08:48:59 +0100 Organization: Lines: 81 Message-ID: <4239366B.7D7C@xyzzy.claranet.de> References: <20050316152116.TSWN5424.mta6.adelphia.net@megatron.ietf.org> <0f5601c52a45$04b66720$030aa8c0@DEWELL> <42388565.FA5@xyzzy.claranet.de> <6.0.0.20.2.20050317143506.0a4b9ec0@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: 212.82.251.148 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: "Obsolete" region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Martin Duerst wrote: > Would it be possible for the two of you (and others, of > course) to provide a bit more of background information > with your discussion? The "last call" was draft 8. What we discussed on the languages list were drafts 9 and 10. The idea in these drafts was to define some rules how an existing registry would be updated. The start for this registry was the creation of ISO 3166-1 (about 1974) for country codes and the introduction of UN numbers (1982). I didn't know that these were the actual start dates until Doug told me so, and there was some confusion while I tried to find out what apparently arbitrary start date he picked. When that was clear what he had as registry was the result of applying the draft 9..10 rules on a registry started in 1974. This had some odd effects for country codes like CS, the old CZ+SK, but today the successor of the rest of YU. For compatibility with RfC 3066, which supports ISO 3166-1 CCs as they are at the day when 3066bis is published, the old CS won't do in an initial registry. Therefore we were looking for a better start day, the year of the publication of RfC 1766 (1995) would avoid most odd effects like old vs. new CS, deprecated RH, DD without a canonical DE despite of ISO 3166-3 "DDDE", and many more. That's not yet state of the art, the registry still has all these relics, where they don't conflict with RfC 3066, e.g. RH and DD. The CS issue is settled, that will be the new CS. It's not yet clear what to do with the deprecated 200 for the old CS. For a start date 1995 or later it wouldn't exist in the registry. With the rules of draft 9..10 it also wouldn't exist, these rules would keep the old CS and add 891 instead of the new CS. But that's incompatible with RfC 3066 tags today, where CS is the new CS. 200 is still unclear, it could be introduced as a special case. We observed some other peculiar effects with the rules in draft 9..10: In some cases country codes must be "exactly the same territory" as defined by UN numbers. Therefore DD can't get a canonical value DE, because 278 is not the same as 276, it's only a part of 276 (new DE). The registry would keep a (deprecated) DD without pointer to a better value. OTOH the old DE (with UN number 280) is implicitly replaced by the new DE (276), and there's no value at all in the registry for the old DE or 276. Same problem with VD / VN and YD / YE. The worst case YU also has this problem, the old YU (UN number 890) kept its country code YU (UN number 891), and then the code was changed to CS. The registry therefore has a deprecated YU corresponding to UN number 891. If there is a CC the number isn't listed under the actual rules, and so 891 is not in the registry. And 890 is also not in the registry, because the change from YU to CS was later, when the territory was 891. Old YU tags like sl-YU therefore lost their original region, and replacing them by sl-SI is not necessarily correct, maybe sl is also used in parts of HR (Croatia). sl = Slovenian, SI = Slovenia, YU = was Yugoslavia, listed as deprecated value for CS CS = Serbia and Montenegro My original idea to avoid all these historic problems was a start date like 1995. Apparently Doug now thinks that this was a good idea in certain cases. And I now think that it only hides a general design problem today, but it could be a similar mess in 100 years. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 06:29:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11993; Thu, 17 Mar 2005 06:29:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBtGh-00029I-Vh; Thu, 17 Mar 2005 06:34:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBtBd-0001Ia-4A; Thu, 17 Mar 2005 06:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBtBb-0001HQ-HA for ltru@megatron.ietf.org; Thu, 17 Mar 2005 06:29:07 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11862 for ; Thu, 17 Mar 2005 06:29:04 -0500 (EST) Received: from lns-p19-2-idf-82-251-145-54.adsl.proxad.net ([82.251.145.54] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DBtBX-0003mQ-4c; Thu, 17 Mar 2005 03:29:04 -0800 Message-Id: <6.1.2.0.2.20050317111343.0329c540@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 17 Mar 2005 12:29:00 +0100 To: Martin Duerst From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: "Obsolete" region subtags In-Reply-To: <6.0.0.20.2.20050317141918.08dcbbb0@localhost> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> <6.0.0.20.2.20050317141918.08dcbbb0@localhost> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 On 06:29 17/03/2005, Martin Duerst said: >At 20:28 05/03/15, JFC (Jefsey) Morfin wrote: > > >What I try to make understood is that the document this WG will produce > will be counterproductive if it is not supported by the entities in > charge (Governments) and their usual delegates (GAC, national NICs, > Culture Ministries, Academic and Computer people), their common bodies > (ISO, ITU, UNESCO, WSIS) and their national users. Worst, if it is opposed. Dear Martin, we probably disagree/agree on minor points IRT ccTLD, etc. But this is not a major issue. The market will decide. I did not sleep this night. It is noon and I am tired. I will however try to make you understand. Excuse me if this is not perfect. >RFC 1766 and RFC 3066 haven't had either much support or much >opposition from governements and related organizations. >My understanding is that this was because they did the job >they were designed to do reasonably well. Let drop all the RFC introduction confusion adding verbs to verbs. Their real job is to permit qualify language related issues and text as belonging to a language. The interest of the IDN Tables is that it is a (only?) application within the IANA. It target is to get a text in French and to describe it as fr-Latn-FR so everyone understand what it is. Great. The langtag is used to qualify/name the language of a text. >What makes you think that for the update we are currently working on, >this will be different? My assumption is that if we produce something >that does it's job reasonably well, people (individuals, governements, >companies,...) will just use it. If this was still the same, yes. This is why we were several to say no problem with the Draft should it be used in the same way as 3066. But actually the reason why RFC 3066 has no problem it is because it is not applied. - the ietf-languages list is an unknown list with no exposure and it did not registered much tags. The intent is to change that and to support every language with a registered tag. Associating in the IANA tables language names, countries, registrants and documentation for all of them. Look at the situation of the wikipedia on a certain number of languages and you will understand the change. This is why this list must get the proper exposure, to get acknowledged experts from every languages, familiar with the network technology and their national situation and policy. This way no one will be able to object the system is biased and a State sovereignty violation. - the RFC 3066 describes a lot of applications which are quoted the same in the draft. But these applications are not used. This changes with the new formalization and exposure. Quoted applications such as word processors, grammar checker, etc will be really considered. Big difference, they are no more read-only/qualify, they are write and produce. Let say there is a Greek text and I start editing it in French and I keep the Greek langtag. How will you be able to say I am wrong? I will say "this is Greek". To prove me wrong you need a reference to be run against my text, a syntax, a semantic, a grammar, a dictionary, etc. Short of that you may know that my text is not Greek, but you cannot do anything more. You need two additional descriptors to do that: an authoritative reference you can oppose me or force me to apply, and you need a style to say how you want me to apply it. There may be other descriptors needed, but Word uses only these 5 descriptors and my analysis says the same. You may say "I describe and I do not know where to document your additional descriptors from (may be style, but not reference, in most of the cases)". I say "you define and if you define with 3 descriptors this only it means you use defaults". The entire world will understand the defaults are the version of the langtag registrant. IBM, Microsoft, Apple. This is unthinkable. So there are two things to do here: 1. to reduce/keep the additonal registrations of subtags identical to the concerned ISO list. There should be no reference to a registrant, nor to additional elements. This should be reserved to the review process. The registration should be bilingual when ISO is bilingual (for the same two different sources of study). They should be concerted with the ISO reviewer who may have good reasons why not to have it. There should be several elected reviewers, otherwise the pressure will be to much. Look a the way Michael reacted to my friendly pressure. Others will be tough. 2. let define that the language tag uses 5 main descriptors which can be reduced to 1, 2, 3 or more when qualifying and having to be 5 when defining. Otherwise it would be analyse flaw. This would only lead States to block the issue at the IANA. States go slowly. They take time to understand and to decide. So, they may take one to three years. But they will definitely block what they will consider as a major violation of their cultural sovereignty. They are here to protect us, and they will carry their job. >If there is anybody out there that does not trust us to do a reasonable >job, the best thing for them is to join and help us do better. Thx! It happens that this is why I am here. And I keep reporting. It happens that the world is not at the order of the IESG and interested in sharing in the IETF. They have several way to help. This year through through the WSIS (I know IETF is not interested), then the GAC (I know IETF is interested in ICANN only when they obey the RFCs), then the ITU (I know IETF does not want to relate with them). This does not make things easy. You have to also understand, that in September the IAB has sent an RFC to the States asking their money to fund Internet R&D. This RFC does not allude to languages. So, States deduced that IETF is not interested. Then, some said this is not true, this RFC was only intended for the US Government. It was not necessarily a good move. >If somebody isn't joining, then the details that we work on are probably >just not important enough to them, and they are ready to use whatever >we produce, in the same way they have been fine with previous RFCs. Do you really believe this? All this Unicode people effort is of interest. The analysis should be completed, some warranties worked out and it should be sold to everyone concerned. Namely a few key Governments, International institutions, etc. And to be demonstrated, reported, documented. Support obtained from OS developers, national Linux communities. Otherwise it cannot fly. It can take-off. But it will not fly. You are touching culture at the core! Or present something no one can object and sell it around asking everyone "do you object to something?". Once you have 40 ccTLDs (local communities), 30 main governments supporting it, start a pilot process. Keep reporting. There is no big problem in getting through, if done the proper way with the proper logic. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 07:38:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19668; Thu, 17 Mar 2005 07:38:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBuKd-00050Q-4h; Thu, 17 Mar 2005 07:42:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBuFd-0005bz-SX; Thu, 17 Mar 2005 07:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBuFc-0005bu-Sh for ltru@megatron.ietf.org; Thu, 17 Mar 2005 07:37:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19591 for ; Thu, 17 Mar 2005 07:37:18 -0500 (EST) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBuJq-0004uw-2X for ltru@ietf.org; Thu, 17 Mar 2005 07:41:43 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 17 Mar 2005 07:37:05 -0500 id 0055C1B3.423979F1.00003300 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] singleton (was: First draft published, please comment) Date: Thu, 17 Mar 2005 07:37:54 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0749C889@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <4238D9DE.3D55@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Please do NOT use the ABNF parser found at . It has some known issues and it really needs to be replaced. The one found at is much better. Also, please note that RFC 2234 is being updated slightly as part of it's progression to Draft Standard: http://www.ietf.org/internet-drafts/draft-crocker-abnf-rfc2234bis-00.txt -Scott- > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Wednesday, March 16, 2005 8:14 PM > To: ltru@ietf.org > Subject: [Ltru] singleton (was: First draft published, please comment) > > > Martin Duerst wrote: > > > For minor editorial stuff, please put a series of comments > > into one email. > > Minor fix, already posted as a comment for draft-10, but it did > not make into the new draft: > > | One comment says that the singleton-ABNF is not yet finished: > | > | That's an 2234 oddity, if you say "x" or "X" then it's always | case insensitive, therefore you need %d120 or %d88 for a case | sensitive "x" vs. "X". A possible solution for draft-11: | privateuse = "x" 1*("-" (1*8alphanum)) ; private use subtag(s) | singleton = ALPHA ; Single letters: x/X is for private use Looking again at it that's still not correct, it should be: singleton = %x41-57 / %x59-6A / %x61-77 / %x79-7A ; ALPHA excl. "x" / "X" for private use doesn't care about these subtle details, but likes the new ugly "singleton" and the simplified "privateuse". RfC 2234 belongs to the future "normative references" in the next draft. RfC 1521 in the references is old, it's also apparently not used in the text as [8] or 1521. Maybe add [8] to the word MIME in 2.4, and replace RfC 1521 by 2045. That would go to the "informative references" in the next draft. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 09:25:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01806; Thu, 17 Mar 2005 09:25:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBw0B-0001bA-GQ; Thu, 17 Mar 2005 09:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvur-0002Mb-A4; Thu, 17 Mar 2005 09:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvuq-0002MW-6f for ltru@megatron.ietf.org; Thu, 17 Mar 2005 09:24:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01715 for ; Thu, 17 Mar 2005 09:23:57 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBvz5-0001Zo-Pe for ltru@ietf.org; Thu, 17 Mar 2005 09:28:24 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2HENn0i013857; Thu, 17 Mar 2005 09:23:50 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 17 Mar 2005 09:23:54 -0500 Date: Thu, 17 Mar 2005 09:23:54 -0500 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: "Obsolete" region subtags Message-ID: <20050317142353.GT3658@skunk.reutershealth.com> References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> <6.0.0.20.2.20050317141918.08dcbbb0@localhost> <6.1.2.0.2.20050317111343.0329c540@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050317111343.0329c540@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b JFC (Jefsey) Morfin scripsit: > It target is to get a text in French and to describe it as fr-Latn-FR so > everyone understand what it is. Great. > The langtag is used to qualify/name the language of a text. That is indeed the purpose of language tags. > If this was still the same, yes. This is why we were several to say no > problem with the Draft should it be used in the same way as 3066. But > actually the reason why RFC 3066 has no problem it is because it is not > applied. RFC 3066 is indeed applied, and in many places. Wherever you see an Accept-Language header in HTTP, or a lang attribute in HTML, or an xml:lang attribute in XML, RFC 3066 is being applied. > - the ietf-languages list is an unknown list with no exposure and it did > not registered much tags. The intent is to change that and to support > every language with a registered tag. Associating in the IANA tables > language names, countries, registrants and documentation for all of them. Most of this is just a clone of ISO 639 and ISO 3166. Under the new draft, it will be much less necessary to register new and unique subtags. > Look at the situation of the wikipedia on a certain number of languages > and you will understand the change. This is why this list must get the > proper exposure, to get acknowledged experts from every languages, > familiar with the network technology and their national situation and > policy. This way no one will be able to object the system is biased and a > State sovereignty violation. This concern is overblown. Languages are not the property of states. Nor is it plausible that experts in the world's 7000 languages are going to also be familiar with "network technology" (whatever that means exactly). It is more or less an accident that language tags are an IETF issue at all, as their connection to the Internet as such is rather weak. But here we are. > - the RFC 3066 describes a lot of applications which are quoted the same > in the draft. But these applications are not used. This changes with the > new formalization and exposure. Quoted applications such as word > processors, grammar checker, etc will be really considered. They are in use today. > Let say there is a Greek text and I start editing it in French and I keep > the Greek langtag. How will you be able to say I am wrong? I will say > "this is Greek". To prove me wrong you need a reference to be run against > my text, a syntax, a semantic, a grammar, a dictionary, etc. Short of > that you may know that my text is not Greek, but you cannot do anything > more. You need two additional descriptors to do that: an authoritative > reference you can oppose me or force me to apply, and you need a style to > say how you want me to apply it. This concern is also overblown. There is simply no dispute in general about what is Greek and what is French, any more than there is serious confusion between frogs and pond ripples (although a frog can be seen as a wave and a ripple as a particle from a quantum-mechanical viewpoint). > 1. to reduce/keep the additonal registrations of subtags identical to the > concerned ISO list. The ISO 639 list is known to inadequately identify the languages on it; Peter Constable and others have done heroic work in attempting to clarify this in order to create the current editor's draft of 639-3 (which will by intention provide a code for every language). > There should be no reference to a registrant, nor to > additional elements. This should be reserved to the review process. The > registration should be bilingual when ISO is bilingual (for the same two > different sources of study). The registrant is tracked for purely administrative reasons, not because he or she is considered to be individually authoritative. > 2. let define that the language tag uses 5 main descriptors which can be > reduced to 1, 2, 3 or more when qualifying and having to be 5 when > defining. This concern too is overblown. There are a very, very few cases where language identification is political: "This text is Croatian." "No, it is Serbian." For the overwhelming majority of languages, there is no dispute about identity. (There are often disputes over what is a language per se and what is a language variety, but that is not an essential concern for RFC 3066 any more than the analogous concern over states vs. territories is for ISO 3166.) -- John Cowan www.ccil.org/~cowan jcowan@reutershealth.com www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 17 12:57:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00300; Thu, 17 Mar 2005 12:57:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzJj-00013E-Ts; Thu, 17 Mar 2005 13:01:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzEz-000845-9K; Thu, 17 Mar 2005 12:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzEx-00080G-Sg for ltru@megatron.ietf.org; Thu, 17 Mar 2005 12:56:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00236 for ; Thu, 17 Mar 2005 12:56:56 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzJF-00011k-Ap for ltru@ietf.org; Thu, 17 Mar 2005 13:01:25 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Mar 2005 09:56:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] singleton (was: First draft published, please comment) Date: Thu, 17 Mar 2005 09:56:45 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9E686@irvmbxw01.quest.com> Thread-Topic: [Ltru] singleton (was: First draft published, please comment) Thread-Index: AcUqj2+ndB5auaSTSx6MrErUTCXXXgAAOvKAACJJrqA= From: "Addison Phillips" To: X-OriginalArrivalTime: 17 Mar 2005 17:56:46.0503 (UTC) FILETIME=[AF97C370:01C52B1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Chairs: I have created an editor's copy of draft-01 of the registry document. = Because RFC 2234 and the ABNF rules must apply to our document, I have = made the ABNF change noted in my message below (our existing ABNF is = somehow invalid?) I have not made the change regarding references. There needs to be = direction about what, if anything, to do with dead references. I am also prepared to follow your lead in incorporating appropriate = textual changes that you feel have achieved the necessary consensus on = the list. Changes in drafts I will continue to annotate in the "Changes" = section of the document (Section 6, currently) to make it easier to = track changes between versions. I will not incorporate any text until you tell me to do so. If you wish = me to create a mockup of changes or a checkpoint version for the = purposes of debate, I'm happy to do that. Please let me know what form = any such documents should take or any additional guidance you wish to = supply. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: Wednesday, March 16, 2005 5:35 PM > To: Frank Ellermann; ltru@ietf.org > Subject: RE: [Ltru] singleton (was: First draft published, please = comment) >=20 > Fenner's parser doesn't like the new ABNF. I can make it ugly in the > manner suggested easily enough, though. It isn't very friendly, but I > don't think it matters. Perhaps: >=20 > singleton =3D %x41-57 / %x59-6A / %x61-77 / %x79-7A > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" > ; Single letters: x/X is reserved for private use >=20 > With regard to the references, these have not been cleaned in awhile. = RFC > 1521 is a dead reference. It was carried forward from RFC 3066... but > wasn't referenced in that RFC either, merely carried forward from RFC = 1766, > Section 4.1. >=20 > I can update the reference or we could just expunge it altogether. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Frank Ellermann > > Sent: Wednesday, March 16, 2005 5:14 PM > > To: ltru@ietf.org > > Subject: [Ltru] singleton (was: First draft published, please = comment) > > > > Martin Duerst wrote: > > > > > For minor editorial stuff, please put a series of comments > > > into one email. > > > > Minor fix, already posted as a comment for draft-10, but it did > > not make into the new draft: > > > > | One comment says that the singleton-ABNF is not yet finished: > > | > > > = > d=3D31580> > > > > | That's an 2234 oddity, if you say "x" or "X" then it's always > > | case insensitive, therefore you need %d120 or %d88 for a case > > | sensitive "x" vs. "X". A possible solution for draft-11: > > > > | privateuse =3D "x" 1*("-" (1*8alphanum)) ; private use subtag(s) > > | singleton =3D ALPHA ; Single letters: x/X is for private use > > > > Looking again at it that's still not correct, it should be: > > > > singleton =3D %x41-57 / %x59-6A / %x61-77 / %x79-7A > > ; ALPHA excl. "x" / "X" for private use > > > > doesn't care about these > > subtle details, but > > likes the new ugly "singleton" and the simplified "privateuse". > > > > RfC 2234 belongs to the future "normative references" in the > > next draft. > > > > RfC 1521 in the references is old, it's also apparently not > > used in the text as [8] or 1521. Maybe add [8] to the word > > MIME in 2.4, and replace RfC 1521 by 2045. That would go to > > the "informative references" in the next draft. > > > > Bye, Frank > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 01:14:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05845; Fri, 18 Mar 2005 01:14:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCAoo-0001vS-DG; Fri, 18 Mar 2005 01:18:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCAje-0004i8-Gh; Fri, 18 Mar 2005 01:13:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCAjc-0004i0-Fz for ltru@megatron.ietf.org; Fri, 18 Mar 2005 01:13:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05801 for ; Fri, 18 Mar 2005 01:13:23 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCAnz-0001uJ-EA for ltru@ietf.org; Fri, 18 Mar 2005 01:17:56 -0500 Received: from h-68-166-189-252.snvacaid.dynamic.covad.net ([68.166.189.252] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCAjY-0006FX-00 for ltru@ietf.org; Thu, 17 Mar 2005 22:13:21 -0800 Message-ID: <004801c52b81$a7ac7540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org><002701c52833$a99cdd00$030aa8c0@DEWELL><6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com><006201c52843$6b79ee40$030aa8c0@DEWELL><6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com><42364EDB.197@xyzzy.claranet.de><6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com><42382C1F.762A@freenet.de><6.1.2.0.2.20050316144451.044824d0@mail.jefsey.com> <42390A9E.9DA@xyzzy.claranet.de> Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags) Date: Thu, 17 Mar 2005 22:13:50 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: "Frank Ellermann" > To: > Sent: Wednesday, March 16, 2005 8:42 PM > Subject: [Ltru] Registry homepage (was: "Obsolete" region subtags) > > JFC (Jefsey) Morfin wrote: > > > why do you want to use the IANA? > > I'm not exactly sure why, but at the moment I trust that they > try to work for some common good. I never had any problems > with ICANN, quite the contrary, I like their WDPRS among other > things. That's all off topic here, let's stick to the facts, > at the moment IANA hosts all registries related to RfCs. ... There's a simpler answer. Our charter says that this WG is to "describe the structure of the IANA registry." Alternatives are outside the scope of this working group. Please, let's focus this energy on the work we were chartered to do. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 01:36:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07464; Fri, 18 Mar 2005 01:36:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBAc-0002Nx-AO; Fri, 18 Mar 2005 01:41:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCB5m-0008IW-4E; Fri, 18 Mar 2005 01:36:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCB5k-0008IO-IS for ltru@megatron.ietf.org; Fri, 18 Mar 2005 01:36:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07383 for ; Fri, 18 Mar 2005 01:36:14 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBA8-0002NC-91 for ltru@ietf.org; Fri, 18 Mar 2005 01:40:48 -0500 Received: from h-68-166-189-252.snvacaid.dynamic.covad.net ([68.166.189.252] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCB5i-000429-00 for ltru@ietf.org; Thu, 17 Mar 2005 22:36:14 -0800 Message-ID: <005701c52b84$dab80e60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0AA9E686@irvmbxw01.quest.com> Subject: Re: [Ltru] singleton (was: First draft published, please comment) Date: Thu, 17 Mar 2005 22:36:45 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi - > From: "Addison Phillips" > To: > Sent: Thursday, March 17, 2005 9:56 AM > Subject: RE: [Ltru] singleton (was: First draft published, please comment) ... > I have not made the change regarding references. > There needs to be direction about what, if anything, > to do with dead references. (As contributor): delete dead references. (As WG co-chair): Removing dead references is a "pure" editorial task akin to fixing grammar or spelling. You've alerted the WG to the problem; if anyone feels strongly about it, it is incumbent on them to speak up. I recommend deleting the dead references. ... > I will not incorporate any text until you tell me to do so. > If you wish me to create a mockup of changes or a > checkpoint version for the purposes of debate, I'm happy to do that. The i-d itself normally serves that purpose. Integers are cheap, and, except during IETF meeting week, the secretariat gives fast service. > Please let me know what form any such documents should > take or any additional guidance you wish to supply. Several issues have been discussed during this first week of ltru. Martin and I will make a quick pass through the threads, and send out "consensus call" messages for the issues that have been brought up where we think there may be a rough consensus. That will give anyone with strong objections to those proposed resolutions the opportunity to present alternatives. After we've sent out those consensus calls: If anyone on this list thinks there's an issue that's reached consensus that we've overlooked, please post to the list. If we get it wrong, please post to the list. If we don't see objections in a day or two, the editors should go ahead with the changes. Randy Ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 01:40:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07680; Fri, 18 Mar 2005 01:40:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBEU-0002Sk-L9; Fri, 18 Mar 2005 01:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCB84-0008Uw-CU; Fri, 18 Mar 2005 01:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCB83-0008Uo-4J for ltru@megatron.ietf.org; Fri, 18 Mar 2005 01:38:39 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07580 for ; Fri, 18 Mar 2005 01:38:36 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DCB5A-0005zR-JP for ltru@lists.ietf.org; Fri, 18 Mar 2005 07:35:40 +0100 Received: from du-001-131.access.de.clara.net ([212.82.227.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Mar 2005 07:35:40 +0100 Received: from nobody by du-001-131.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Mar 2005 07:35:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 18 Mar 2005 07:33:39 +0100 Organization: Lines: 24 Message-ID: <423A7643.7D6B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0A9F5393@irvmbxw01.quest.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-131.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: singleton X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Addison Phillips wrote: > singleton = %x41-57 / %x59-6A / %x61-77 / %x79-7A > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" > ; Single letters: x/X is reserved for private use Yes, that's fine. AFAIK as editor you're free to edit whatever you think needs editing without intervention of Martin or Randy after the initial -00 version, unless it's a hot issue where a "rough consensus" isn't obvious. For the references simply delete what you don't need. If Bruce has something to say about RfC 2231 he will do it, I'll scream, and Randy or Martin would say that Bruce is right, as always. It's only me who needs the screaming when RfC 2231 is affected, language tags in a multi-line boundary don't make this worse as it already is, and it has almost nothing to do with your draft. What you IIRC really need are both "normative references" and "informative references", with e.g. RfC 2234 as "normative". Or as Scott said later RfC 2234bis, this should be ready soon, unless Bruce finds a problem in the 2234bis draft. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 02:10:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19638; Fri, 18 Mar 2005 02:10:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBh5-0003Ar-4Z; Fri, 18 Mar 2005 02:14:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCBc5-0005Jq-OO; Fri, 18 Mar 2005 02:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCBbf-0005C2-16 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 02:09:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18588 for ; Fri, 18 Mar 2005 02:09:13 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBg3-00039P-C4 for ltru@ietf.org; Fri, 18 Mar 2005 02:13:47 -0500 Received: from h-68-166-189-252.snvacaid.dynamic.covad.net ([68.166.189.252] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCBbc-00035T-00 for ltru@ietf.org; Thu, 17 Mar 2005 23:09:12 -0800 Message-ID: <007e01c52b89$76349a80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0A9F5393@irvmbxw01.quest.com> <423A7643.7D6B@xyzzy.claranet.de> Subject: Re: [Ltru] Re: singleton Date: Thu, 17 Mar 2005 23:09:43 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - > From: "Frank Ellermann" > To: > Sent: Thursday, March 17, 2005 10:33 PM > Subject: [Ltru] Re: singleton ... > Yes, that's fine. AFAIK as editor you're free to edit whatever > you think needs editing without intervention of Martin or Randy > after the initial -00 version, unless it's a hot issue where a > "rough consensus" isn't obvious. ... In general that is how most WGs operate. The co-chairs here are simply being extra-cautious in verifying rough consensus for the technical edits. We have quite a few participants who are not as well versed in the IETF way of doing things as one might like. As the WG matures in the coming weeks, we hope to start operating more like other WGs, and shift more of the work from the co-chairs to the editors. :-) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 02:31:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02585; Fri, 18 Mar 2005 02:31:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCC1y-0003aT-9w; Fri, 18 Mar 2005 02:36:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCBvO-0001dn-JK; Fri, 18 Mar 2005 02:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCBvG-0001d8-BU for ltru@megatron.ietf.org; Fri, 18 Mar 2005 02:29:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02395 for ; Fri, 18 Mar 2005 02:29:28 -0500 (EST) Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBzf-0003Xq-8R for ltru@ietf.org; Fri, 18 Mar 2005 02:34:03 -0500 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D91954F10A; Fri, 18 Mar 2005 02:29:27 -0500 (EST) Message-Id: <6.0.0.20.2.20050318153032.0b9a97e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Mar 2005 15:36:16 +0900 To: "Addison Phillips" , From: Martin Duerst Subject: RE: [Ltru] singleton (was: First draft published, please comment) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AA9E686@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AA9E686@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hello Addison, At 02:56 05/03/18, Addison Phillips wrote: >Chairs: Many thanks for checking with us. >I have created an editor's copy of draft-01 of the registry document. >Because RFC 2234 and the ABNF rules must apply to our document, I have made >the ABNF change noted in my message below (our existing ABNF is somehow invalid?) Good. >I have not made the change regarding references. There needs to be >direction about what, if anything, to do with dead references. I think this is one of these things where nobody cares enough. For such things, it's best if you just go ahead and do something, tell everybody on the list, and get back to it if it should turn out to be controversial. If you need input to start with, here is my personal preference: Update to RFC 2045 and reference it from after the word MIME. >I am also prepared to follow your lead in incorporating appropriate textual >changes that you feel have achieved the necessary consensus on the list. Great. Randy may come up with some proposal for how to manage issues. I hope we can soon reach an at least preliminary conclusion for how we want to address registry initialization. >Changes in drafts I will continue to annotate in the "Changes" section of >the document (Section 6, currently) to make it easier to track changes >between versions. Okay, very good. >I will not incorporate any text until you tell me to do so. If you wish me >to create a mockup of changes or a checkpoint version for the purposes of >debate, I'm happy to do that. Please let me know what form any such >documents should take or any additional guidance you wish to supply. I don't think we need an additional level. For some things, it will be okay for you to just create actual wording based on a conclusion we reach, and we all see that text in the next internet-draft. For other things, the best thing to do is to float the actual text here on the list. Thanks again for your work. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 07:10:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00733; Fri, 18 Mar 2005 07:10:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCGNR-0002JQ-Vr; Fri, 18 Mar 2005 07:14:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCGFi-0007sZ-21; Fri, 18 Mar 2005 07:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCGFh-0007s4-2f for ltru@megatron.ietf.org; Fri, 18 Mar 2005 07:06:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00109 for ; Fri, 18 Mar 2005 07:06:48 -0500 (EST) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCGAa-0001d7-AB for ltru@ietf.org; Fri, 18 Mar 2005 07:01:37 -0500 Received: from dul1shollenbl1 ([::ffff:68.100.55.187]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 18 Mar 2005 06:56:51 -0500 id 0055C1EE.423AC203.00005429 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:68.100.55.187; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:68.100.55.187; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: singleton Date: Fri, 18 Mar 2005 06:57:52 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0749C89D@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <423A7643.7D6B@xyzzy.claranet.de> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > What you IIRC really need are both "normative references" and > "informative references", with e.g. RfC 2234 as "normative". > Or as Scott said later RfC 2234bis, this should be ready soon, > unless Bruce finds a problem in the 2234bis draft. Bye, Frank Separation of references into normative and informative subsections is required these days. 2234bis is out: http://www.ietf.org/internet-drafts/draft-crocker-abnf-rfc2234bis-00.txt -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 10:24:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17248; Fri, 18 Mar 2005 10:24:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCJPS-0001Gc-Kp; Fri, 18 Mar 2005 10:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJIx-0007RI-54; Fri, 18 Mar 2005 10:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJIv-0007RC-Hq for ltru@megatron.ietf.org; Fri, 18 Mar 2005 10:22:26 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16970 for ; Fri, 18 Mar 2005 10:22:20 -0500 (EST) Received: from lns-p19-19-idf-82-249-5-14.adsl.proxad.net ([82.249.5.14] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCJIr-0000qd-BO for ltru@lists.ietf.org; Fri, 18 Mar 2005 07:22:22 -0800 Message-Id: <6.1.2.0.2.20050318162045.03657eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Mar 2005 16:22:19 +0100 To: "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags) Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 On 07:13 18/03/2005, Randy Presuhn said: >Hi - > > JFC (Jefsey) Morfin wrote: > > > why do you want to use the IANA? > > > > I'm not exactly sure why, but at the moment I trust that they > > try to work for some common good. I never had any problems > > with ICANN, quite the contrary, I like their WDPRS among other > > things. That's all off topic here, let's stick to the facts, > > at the moment IANA hosts all registries related to RfCs. > >There's a simpler answer. Our charter says that this WG is to >"describe the structure of the IANA registry." Alternatives are >outside the scope of this working group. > >Please, let's focus this energy on the work we were chartered to do. Cool ... Dont' you agree that our job is to discuss an answer to a charter which only assigns us to define the "structure of the IANA registry"? An XML/ASN.1 structure. When IESG does that it is because they want to be very restrictive or not to limit the scope of the debate. My reading is the second one due to the charter last paragraph which implies that we have to revamp of the review process. Many other important questions are not listed. How to define the technical role of the IANA in area? Will it be a repository, a clearinghouse, a registry. Will it act as only a web pages, as a "whatidiom" web service, as an FTP server? How is it to be organized? What is the contingency plan if it changes (this has to do with the adressing of the bases which can be hard coded in millions of programs), the NIC changed a few time since it was created. etc. The first question to consider is what is this structure in that registry going to do for who. There are three classes of people involved: - those who manage the structure - IANA with an important backlog (if Frank is correct): question is why? How can our solution help? And there are many technical solutions to that I am surprised no one considers. - those who fill the data into the structure (among who is Frank, with seemingly some feelings and misunderstandings). It is important to determine the procedure, the guidance, etc. soi they feel at ease and motivated. Some are voluntaries, some are employees of organizations with social, cultural, religious or commercial interests, some are civil servants. Some are linguists, some are network people. We need to keep a balance in the best common interest. Frank is in that sense a good representative of possible feelings (good or bad) we must take into account. Another aspect is the role of the ietf-language list and of its procedures which is depend on all of this. - those who will use it. I represent some of them. All together we need something which will work. jfc ===================================================== For your convenience: Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ===================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ===================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ===================================================== It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. ===================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 11:02:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21532; Fri, 18 Mar 2005 11:02:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCK06-0002qU-NJ; Fri, 18 Mar 2005 11:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJu4-0005fS-BK; Fri, 18 Mar 2005 11:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJu1-0005fJ-T6 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 11:00:46 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21388 for ; Fri, 18 Mar 2005 11:00:42 -0500 (EST) Received: from lns-p19-19-idf-82-249-5-14.adsl.proxad.net ([82.249.5.14] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCJtf-0003UO-LM; Fri, 18 Mar 2005 08:00:27 -0800 Message-Id: <6.1.2.0.2.20050318030616.0398feb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Mar 2005 17:00:21 +0100 To: "LTRU Working Group" From: "JFC (Jefsey) Morfin" In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AA9E6BA@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AA9E6BA@irvmbxw01.quest.com> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com Subject: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0520657625==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ef4e20b714504e8d8d20eccf285dcca --===============0520657625== Content-Type: multipart/alternative; boundary="=====================_22284413==.ALT" --=====================_22284413==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA21388 Content-Transfer-Encoding: quoted-printable I have been questioned on the ietf-languages mailing list. The dialog lea= d=20 to a threat which belongs to this WG. We agreed to transfer it. Here is t= he=20 status of the current relevant exchange. >>[I respond to one question] ... they are/this is more related to the 5=20 >>levels/points underlaying a multilingual internet (I am not sure they a= re=20 >>layers, they just are necessary) Addison comments them and obviously we are in rough agreement (these poin= ts=20 are in the Charter as "identifying languages and language preferences" -=20 like in the Word tools menu. We only disagree on scope and application of= =20 the RFC. I think there are many ways to make the two positions converging= =20 and to see new synergy resulting from it. But I need first to review the=20 draft (I said I will do it early next week). Responses from Addison and=20 Mark to these comments will help, as weel as comments of this WG. On 19:29 17/03/2005, Addison Phillips said: > > - identification of the language (ISO 693 or the like) -> interrelati= on > > between people - we can talk >RFC 3066 and 3066bis call this "primary language" Correct. However a general remark: this is an analysis. It permits the us= e=20 of the words we agree upon, but it is more general. I am interested in th= e=20 users needs and in the network systems' answer to support them in the way= =20 applications/developers may want to perform them. My priority is to the=20 users, to the network and to the applications, not to the RFC or ISO=20 document. And I live in a real world. I am not interested in good documen= t=20 you cannot implement due to (may be stupid but real) external objections. - as a user I consider myself (the need I know the best), the people I=20 develop/consult for in my position of "super IANA like" (CRC) project, th= e=20 Governments I relate with and most of all multilingualism in naming,=20 e-government, day to day life as per the various ITU, WSIS, UNESCO=20 unanimous declarations. - as far as network are concerned I consider the Internet current=20 architecture, the Interbox architecture I work on (first guidelines a=20 delayed by all this and current debates, presented to Govs and ITU last=20 months: roughly a virtual user centric NGN permitting the transition from= =20 current Internet), the management of the few extended services of the=20 Internet architecture (name space - DNS, ONS, Handles, PAD, OPES, ONES),=20 the dramatic architectural impact on a robust yet rustic end to end=20 oriented architecture of multilingualism. - as far as applications are concerned I am interested in the consistency= =20 of the different existing tools, but I am also interested in all the=20 applications delayed by the limitations of the current systems. I am=20 advocating the most robust, simple and open common basis to permit to=20 develop compatible tools rather than standardizing one single application= =20 which will become overloaded with incompatible demands. A good example of= a=20 success in that direction is the DNS which has well resisted since 1983=20 (RFC 920). - as a Registry Manager involved for 30 years in the international public= =20 and private real intergovernance. > > - internationalization (what discusses RFC 3066 - ISO 15924) -> > > interoperation between machines - we can write >RFC 3066bis calls this "script" Yes. Same as above. Also, users are not bond to scripting. Other supports (voice, signals,=20 commands, icons, images, fax, Minitel, music, etc.) are OK with this=20 analysis. In your context we agree. > > > - multinationalization (taking into account ISO 3166 or other=20 > geopolitical > > attribute) -> interculturization between communities - we can share s= ame > > cultural references, the same meanings (for example, what may be miss= ing > > in > > here). >RFC 3066 and 3066bis call this "region" Yes. Same as above. But in your context you refer to a region. IAnalysis = is=20 not limited only to that. It can be a Diaspora, a Church, a culture, etc.= =20 Look at Tamils for example, as a population. > > - multilingualization (semantic, grammar, dictionary, syntax, etc.) -= > > > interintelligibility -> we can understand each other > >RFC 3066bis calls this a "variant"--variations within a language, which=20 >may take many forms (orthography, dialect, etc. etc.). RFC 3066 allows=20 >entries that represent this to be registered (but doesn't identify them=20 >explicitly with a name). Both allow multiple variations to be applied to= a=20 >text. Here I think we have a real difference. If I read you correctly, you discuss of variation _within_ a language. I=20 discuss of what describes a language. I suppose that you will translate=20 this into a different code/description permitting someone to qualify a te= xt=20 with a different tag. I will translate that into a CD including all the=20 data necessary to describe the language to a computer, to permit to=20 authenticate the origin of the text and to write and edit the text. > > - vernacularization (procedures, styles, tools, etc.) -> interusabili= ty -> > > we can do something together > >Language tags identify text, not the processes that are applied to them. This is the contentious point we have from the very beginning. Would you=20 have included that sentence in the RFC 3066 bis it would be an applauded=20 RFC by everyone. I will come back below on this key point. >A French text that has had French hyphenation rules applied to it is jus= t=20 >a French text. Particular vernacular distinctions may be candidates for=20 >registration, though, although this dives into more difficulty: is it=20 >another language or merely stylistic license? Merriam-Webster defines=20 >vernacular thus: > >1 a : using a language or dialect native to a region or country rather=20 >than a literary, cultured, or foreign language b : of, relating to, or=20 >being a nonstandard language or dialect of a place, region, or country c= :=20 >of, relating to, or being the normal spoken form of a language. The interest of this langtag is to show that the questions you rise are=20 structurally well addressed by our common analysis. The lang3tag you=20 propose relates to a region and matches (a) and (b). But these are old=20 description outdated by the current world which is more generally describ= ed=20 in (c). Here you have a problem because your tag could (but your ISO 3166= =20 oriented approach prevents that) to use virtual regions. Obviously we lack the common usage of a model where we could spot these=20 issues as I am accustomed in my working groups. But you are in W3C and yo= u=20 know about web services. When two web services interacts they actually us= e=20 a vernacular and their Man/machine interface will try to accommodate it t= o=20 the users' language and brainware (the way people commonly use a network=20 system). This results in a web vernacular, in a mail vernacular which=20 currently is an ASCII vernacular but should multilingualize (and RVC 3066= =20 is a key building block). When I see To: From: these are vernacular terms= .=20 This is very interesting to see when people know/can change the mail answ= er=20 back line to see the formula they use from English "said" to Latin "Scrip= sit". Obviously vernacular with that meaning includes a quasi illimited type of= =20 procedures. >In other words, Twain's "Pudd'nhead Wilson" is written in a particular=20 >vernacular form of U.S. English. One can register a variant (under=20 >3066bis--or a tag under 3066) that conveys this distinction (perhaps=20 >"en-US-twain"): > >"Say it ag'in! En keep on sayin' it! It's all de pay a >body kin want in dis worl', en it's mo' den enough. >Laws bless you, honey, when I's slav' aroun', en dey 'buses me, >if I knows you's a-sayin' dat, 'way off yonder somers, >it'll heal up all de sore places, en I kin stan' 'em." > >Generally though this is considered unnecessary. There are many=20 >vernaculars in the world. Only in exceptional cases does it become=20 >necessary to identify a particular language variation as distinct. But=20 >this does not obviate the point that RFC 3066 (and its proposed successo= r)=20 >already provide a mechanism for doing exactly that to identify text in t= he=20 >cases where the differences matter. I do not dispute the case. I just document an analysis. I am glad to see=20 that even if we may have slight differences, we are basically in agreemen= t.=20 And that you testify that what I say is in RFC 3066. I documented that in= =20 telling that I could encapsulate the RFC 3066 in my own approach. And ask= ed=20 if the way I was doing it was reducing in anyway your proposition. The on= ly=20 objections I received were on my own part, not on my support of yours. >(For that matter, 3066bis relaxes strictures surrounding the use of=20 >private use subtags so that specialists can identify various dialects or= =20 >vernacular usages among themselves without the use of registration:=20 >"en-US-x-twain".) This is internal to your proposition. I am glad you increase flexibility.= =20 The only remarks I have is that I am not only concerned in specialists bu= t=20 in every Internet user. I have observed that what is supposed to be=20 reserved to specialists is quickly used by everyone with easy to use tool= s=20 and support. This is what RFCs call scalability. Everything has to be=20 documented and planned in a standard as if it was going to be used by=20 everyone all the time. RFC 1958. >So how is what you're saying different from RFC 3066bis? Heck, how is it= =20 >different from RFC 3066?!? In the way RFC 3066 is actually used, it is not. This is what we are tryi= ng=20 to tell you for two months. The problem is: - if we are perfectly happy with RFC 3066 as it is applied today and we c= an=20 stay happy for ever. - you documented you are not. And we certainly want your needs to be=20 satisfied, but in making us unsatisfied. And I extensively documented what is detrimental, I can come back again o= n it. I will use some HTML to make the presentation clearer. I hope all the=20 readers can use it. RFC 3066 IS NOT APPLIED RFC 3066 works well because it is not really applied. What you want will=20 make it applied and will show its lacks and the lacks of its=20 implementation. This lacks are to be corrected. There are mainly three. 1. the ietf-language mailing list The ietf-languages mailing list is not the IANA list presented in the RFC= =20 3066. It should be managed and archived by IANA and documented on the IAN= A=20 site to get the necessary exposure, participation and recognition by the=20 international community. This would most probably help it to self correct= =20 what I reproach to it. One of the things it would probably have permitted= =20 to evaluate is its moderation and the reviewer which should probably be a= =20 three persons committee selected as two linguistic experts of English and= =20 of French culture and one network expert. 2. a consistency with the considered (ISO) lists The RFC 3066 confuse the process and the deliverable. Up to now this is n= ot=20 too much notice because RFC 3066 is only occasionally used and the tables= =20 updated. It will change when it is extensively used. The deliverable is the IANA added code. It should be consistent with the=20 ISO lists it intend to complete. There is too much confusing information=20 (name of the referent, documentation of the language). And there is no=20 French translation. If someone needs the additional subtag she will know=20 what it is. All the subtags must be of same weight and definition. How do= I=20 know that an ISO 693 code is really what I mean and if someone is not goi= ng=20 to introduce a new IANA code which will better define my need? How do I=20 know what ISO meant when I know what IANA means. On an other end what=20 should I do when the IANA added code match my need but not the descriptio= n?=20 How do I make its use consistent with the use of the other ISO codes? 3. the default format being unique RFC 3066 to my knowledge is used by your W3C applications, by Unicode, et= c.=20 outside of Internet documents and IANA except for IDNs. This obviously do= es=20 not help to identify this problem and I am taxed to underline it, people=20 focusing in the only example at hand, rather than on the fundamental pro= blem. RFC 3066 starts with the conclusion. The format proposed format should be= =20 tone of the conclusion of the analysis. As the use, as the registration=20 procedure, etc. Because you use a given format in a certain kind of=20 applications, you want to use that format for ever. By this token UNIX=20 would use DOS which would use DEC file format. Life is more flexible and=20 innovation comes from flexibility. The format you propose does not suit m= y=20 needs. It should not be a big deal to stay compatible. 4. You do not care about others' needs The lack of RFC 3066 apparent use in other areas than your current=20 applications gives the feeling that RFC 3066 can conduct the world. The=20 idea that Countries may be taught to ask for ISO 3166 langtag compliant=20 codes from other countries experience seems odd. This also does not help to understand that you are shaking an existing=20 stable situation and status quo. But you actually come and propose change= s,=20 you do not care about those who are affected ("you" - at large - even wan= t=20 to expel them). Multilingual Internet The status quo is based upon the very low interest in multilingualism by=20 IAB. Demonstrated by the only RFC 3066, the low consideration of Paul=20 Hoffman's initial work, and the clear disinterest signal of the IAB's RFC= =20 3869 (which lists the development priorities to be funded by the=20 Governments - of every nations and languages - and does not even allude t= o=20 multilingualism). Now, you want to make it a core issue interfering with=20 the core issue of country codes through your ability to discuss ISO 3166,= =20 but more questioning the entire Internet architecture! To understand this, you have remember how a network is built. Every=20 network. Even if it is quite buried in the Internet defaults. A network=20 permits a class of users to relate with a group of resources in using=20 common identifier they register and manage in a registry (NIC) and=20 parameters they store in a common repository (IANA, CRC). The initial=20 international public network technology (1971) we deployed fully supporte= d=20 classes and groups and permitted to support an unlimited number of=20 national, linguistic, corporate, public interest externets (a class, a=20 group, a registry, a context supported by reference center). OSI principl= es=20 (1975?) reduced externets to the notion of closed user groups, making the= =20 class (users) and the group a single list. Internet (1978-83) as a privat= e=20 network internetting (Vint Cerf/Bob Khan) into a DoD catenet (Louis Pouzi= n)=20 only considered the Internet users class ("IN" and the "CHAOS" test class= )=20 and did not really mind about groups (DNS views can very partly reproduce= ,=20 as well as intra/extranets). This permitted to dramatically reduce the=20 intelligence expected from the network and to build a robust (but quite=20 rustic!) network based upon the two "core values": dumb network, end to e= nd. Now, multilingualism was initially started (Japan, EBCDIC and=20 France/Minitel) in using classes of non ASCII users interacting with grou= p=20 of resources able to respond them. This would correspond in the Internet = to=20 create 1.600.000 classes and to implement a group support which is totall= y=20 inexplored today. A totally new DNS technology. Also, to speed up routing= =20 the group support would probably call for a different IPv6 structuring su= ch=20 as the one proposed for the ITU-T /3 block. We will have to come to that,= =20 but not now! Let experiment the transition first. IDN introduced the idea of supporting multilingualism in the ASCII class = in=20 using internationalization. But this does not work because the analysis i= s=20 not correct. It just focused on the DN and not on the FQDN and introduced= a=20 hierarchy (punycode or not are filtered) in the label rather than in the=20 namespace. This means that they did not identified the need for virtual=20 zones (sub-classes in the IN class) and the need of consistence of the=20 vernacular (IDN Tables) used in that virtual zones. Result: the current=20 homographs problem. The correct solution consists in respecting the=20 standard network architecture in a scalable way and to force the=20 multilingual FQDN (FQMLDN) to be consistent from the TLD to the last leve= l.=20 Due to the inclusion on the IN class and its existing number of TLD there= =20 must be a _presentation_ of the zone (lingual SLD) as a single label (ex=20 nnn.chinesetag.cn being displayed as nnn.chinese_printing_of_cn) and a=20 filtering of all the codes which are not permitted in a correct FQMLDN. F= or=20 that all the concerned machine must have the necessary (limited)=20 information of how to present a lingual SLD as a lingual TLD, and the=20 corresponding IDN Table. There are three places to distribute them: eithe= r=20 the IANA and the CRCs, either a dynamic repository like Akamai, or the Lo= cales. So, you understand that langtags are actually the names of the lingual=20 externets or their aliases. Also, that depending on the way they are=20 organized, they may fit or not into the DNS as it is managed today. Also,= =20 that while the WSIS is discussing the intergovernance there are a lot of=20 interest to play it clearly, not to confuse the issues. Applications you consider only the applications you know. But you disregard the=20 applications others are/should be (:-) working on (like OPES at the WG-OP= ES=20 and ONES in other places, the CRCs as far I am concerned). And all those = a=20 correct support of multilingualism and vernacular could unlock. The web i= s=20 a dazibao. One does spend our life reading. As Hitch says: 90% of the hum= an=20 communication is not with words. This leaves a large number of=20 applications to develop. Their tagging needs are as much important than=20 any other. THE KEY ISSUE The key issue is what the langtag for? The charter says: they are necessary from (a) cataloging to (b) processin= g. You say: "Language tags (c) identify text, (d) not the processes that are= =20 applied to them". The Draft says: "This document describes the structure, content,=20 construction, and semantics of language tags for use in cases where it is= =20 desirable to (e) indicate the language used in an information object. " Introduction of the draft says: "(f) Information about a user's language=20 preferences commonly needs to be identified (g) so that appropriate=20 processing can be applied" Dictionary.com says: "indicate": (h) to show the way to or the direction of; point out: an arrow indicatin= g=20 north; indicated the right road by nodding toward it. (i) to serve as a sign, symptom, or token of; signify: "The cracking and=20 booming of the ice indicate a change of temperature" (Henry David Thoreau= ). (j) to suggest or demonstrate the necessity, expedience, or advisability=20 of: The symptoms indicate immediate surgery. (k) to state or express briefly: indicated his wishes in a letter;=20 indicating her approval with a nod. If the purpose is informative, the way I read (a), (c), (d), (e), (f), (i= ),=20 things are OK with me. If the purpose is normative, the way I read (b), (g), (h), (j) and possib= ly=20 (k), things are not in the present status of the document. Due to the limited use of RFC 3066 discusses above the question was not=20 risen. They were used the way you say, to qualify/catalog texts in=20 different applications and for IDN Tables. But RFC 3066 - and you and Charter - uses a wording and you use examples=20 (Introduction) which creates ambiguity and confusion about the intended u= se=20 of the langtags. You can qualify a text with any descriptor you want, thi= s=20 creates no problem. You can use the langtags as a search key the way you = want. But to document the definition of the way a text is to be processed, you=20 need at least all the five the descriptors we described. This is not=20 something you can dispute or you kill the analysis you described as being= =20 also the RFC 3066 analysis. If you do not provide these 5 elements, you actually imply the defaults a= re=20 to be used. There is no default documented in the RFC 3066 and in your=20 draft, except the name of the registrant/referent. He the becomes the=20 default to tell what are the missing parameters. If the name is of a=20 person, the opposition to that person will unnecessarily creates an=20 opposition of the lingual community - even if the tag is correct. If the=20 name is of a corporation or associated to a corporation this may be worse= =20 and detrimental to the interest of the voluntaries who carried the effort. >>> didn't think any Microsoft product dealt with "style" or "authority" >>>attributes, nor in script except to the extent that is covered by >>>registered RFC 3066 tags. >> >>Name the reference/authority, etc. the way you want. Authoritative in i= ts=20 >>domain is an usual concept in the Internet culture. You can certainly=20 >>find other words. This is what says a computer that when I write in=20 >>French this is not Greek, or what make you sure that when I write in=20 >>Provencal it is not Berrichon. >> >>I gave in my response to Peer how and where the Word system does that. >>- tools - languages : language, script, country (you can qualify even = if=20 >>you do not understand). >>- tools - options (preferences?) : dictionary, style (you need them to=20 >>understand and write). >>Which system do you use? Does it support the same descriptors? This addresses an objection you made in another email, saying that these = 5=20 points were not covered by Word and that your Word 2003 was great because= =20 it did not support RFC 3066 which was not yet published. Actually, I do u= se=20 Word. My copy is Word 97, and even in these ancient times, these points w= e=20 identified/share are here. It only add the proof of the age. >>This being said, I understand your remark about what I name the=20 >>multilingualization level. You say English is not defined. I belong to = a=20 >>culture where definition is known and supported for 4 centuries. This=20 >>makes me more aware of this point. Actually English, in a way is more=20 >>defined than French. When we introduce a computer in a culture, we do i= n=20 >>a few months, a few years, what Richelieu and France did a long ago and= =20 >>matured over centuries: we create an "Acad=E9mie de cette Langue". BTW this is probably a very interesting and exciting field of work. >>What I object is that this Acad=E9mie may belong to anyone else than to= the=20 >>people sharing that culture. And naming is already a way to own. As lon= g=20 >>as it is to qualify the culture it is OK because there is a need. When = it=20 >>comes to enter in its definition this is - IMHO - an intrusion. And I=20 >>refuse to share in that kind of intrusion. To the contrary my approach= =20 >>is to say we are here to serve, help, educate so they can first share i= n=20 >>this process, comment it and eventually conduct it for themselves. I fully understand and support (with may be some tunings, like the suppor= t=20 of namespace related information) the Unicode CLDR project - which is in=20 the IESG charter but not documented - I wonder why. But I would strongly=20 object to it if it was not carried under the supervision of Members of th= e=20 concerned communities. Frank hates Governments. I tend to think they are=20 our only protectors against e-colonization. Each of us have our fancies. >>I note that three days ago this list had 2 Greek languages. Now 3 and=20 >>probably 4. Because Greek persons stepped in and documented _their_ own= =20 >>languages. This is the way it should happen for every language, the=20 >>request should come from each Internet community. This is the spirit of= =20 >>the text of RFC 3066. I fully understand that people may want urgently=20 >>scan the cultural patrimonies of others, to sell it or to protect it fr= om=20 >>being merchandized, want to speed up the process. I do not think it is=20 >>commercially or charity advisable to by-pass their future=20 >>customers/friends in this process (as the reactions to the Google's=20 >>annoucement show it). To the contrary they should help empowering the=20 >>language and help their cultural, linguistic, political authorities=20 >>through the registration process. >> >>For example, I fully agree with you that the name of the langtag=20 >>registrant is not necessary. But I would suggest to remove it only when= =20 >>the registration is by an outsider. I note that if two languages are used at ISO (while UNESCO and ITU use 6=20 languages) there is probably good reasons, which may be to make sure that= =20 several and at least two cultures shared into the analysis (for defining=20 the tag and when using it). This forces an openness of mind we often need= .=20 It means alternative thinking, searching, etc. Back-up is always a good=20 thing. Two languages help also help the user to make sure the code she=20 wants to use is the good one. Acceptance of a bilingual table will be far= =20 higher in a multilingual context than an ASCII only table. Coopetition tends to foster quality. I hope that this will eventually help. jfc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D For your convenience: Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.t= xt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process= : http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far a= s possible, without of course using this argument to reject improvements." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D It seems that what works for countries and ISO 3166 since 1978 should apply to languages and to ISO 693. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --=====================_22284413==.ALT Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA21388 Content-Transfer-Encoding: quoted-printable I have been questioned on the ietf-languages mailing list. The dialog lead to a threat which belongs to this WG. We agreed to transfer it. Here is the status of the current relevant exchange.

[I respond to one question] ... they are/this is more related to the 5 levels/points underlaying a multilingual internet (I am not sure they are layers, they just are necessary)

Addison comments them and obviously we are in rough agreement (these points are in the Charter as "identifying languages and language preferences" - like in the Word tools menu. We only disagree on scope and application of the RFC. I think there are many ways to make the two positions converging and to see new synergy resulting from it. But I need first to review the draft (I said I will do it early next week). Responses from Addison and Mark to these comments will help, as weel as comments of this WG.

On 19:29 17/03/2005, Addison Phillips said:
> - identification of t= he language (ISO 693 or the like) -> interrelation
> between people - we can talk
RFC 3066 and 3066bis call this "primary language"

Correct. However a general remark: this is an analysis. It permits the use of the words we agree upon, but it is more general. I am interested in the users needs and in the network systems' answer to support them in the way applications/developers may want to perform them. My priority is to the users, to the network and to the applications, not to the RFC or ISO document. And I live in a real world. I am not interested in good document you cannot implement due to (may be stupid but real) external objections.

- as a user I consider myself (the need I know the best), the people I develop/consult for in my position of "super IANA like" (CRC) project, the Governments I relate with and most of all multilingualism in naming, e-government, day to day life as per the various ITU, WSIS, UNESCO unanimous declarations.

- as far as network are concerned I consider the Internet current architecture, the Interbox architecture I work on (first guidelines a delayed by all this and current debates, presented to Govs and ITU last months: roughly a virtual user centric NGN permitting the transition from current Internet), the management of the few extended services of the Internet architecture (name space - DNS, ONS, Handles, PAD, OPES, ONES), the dramatic architectural impact on a robust yet rustic end to end oriented architecture of multilingualism.

- as far as applications are concerned I am interested in the consistency of the different existing tools, but I am also interested in all the applications delayed by the limitations of the current systems. I am advocating the most robust, simple and open common basis to permit to develop compatible tools rather than standardizing one single application which will become overloaded with incompatible demands. A good example of a success in that direction is the DNS which has well resisted since 1983 (RFC 920).

- as a Registry Manager involved for 30 years in the international public and private real intergovernance.

> - internationalizatio= n (what discusses RFC 3066 - ISO 15924) ->
> interoperation between machines - we can write
RFC 3066bis calls this "script"

Yes. Same as above.
Also, users are not bond to scripting. Other supports (voice, signals, commands, icons, images, fax, Minitel, music, etc.) are OK with this analysis. In your context we agree.

> > - multinationali= zation (taking into account ISO 3166 or other geopolitical
> attribute) -> interculturization between communities - we can share same
> cultural references, the same meanings (for example, what may be missing
> in
> here).
RFC 3066 and 3066bis call this "region"

Yes. Same as above. But in your context you refer to a region. IAnalysis is not limited only to that. It can be a Diaspora, a Church, a culture, etc. Look at Tamils for example, as a population.

> - multilingualization (semantic, grammar, dictionary, syntax, etc.) ->
> interintelligibility -> we can understand each other

RFC 3066bis calls this a "variant"--variations within a language, which may take many forms (orthography, dialect, etc. etc.). RFC 3066 allows entries that represent this to be registered (but doesn't identify them explicitly with a name). Both allow multiple variations to be applied to a text.

Here I think we have a real difference.

If I read you correctly, you discuss of variation _within_ a language. I discuss of what describes a language. I suppose that you will translate this into a different code/description permitting someone to qualify a text with a different tag. I will translate that into a CD including all the data necessary to describe the language to a computer, to permit to authenticate the origin of the text and to write and edit the text.

> - vernacularization (procedures, styles, tools, etc.) -> interusability ->
> we can do something together

Language tags identify text, not the processes that are applied to them.

This is the contentious point we have from the very beginning. Would you have included that sentence in the RFC 3066 bis it would be an applauded RFC by everyone. I will come back below on this key point.

A French text that has had French hyphenation rules applied to it is just a French text. Particular vernacular distinctions may be candidates for registration, though, although this dives into more difficulty: is it another language or merely stylistic license? Merriam-Webster defines vernacular thus:

1 a : using a language or dialect native to a region or country rather than a literary, cultured, or foreign language b : of, relating to, or being a nonstandard language or dialect of a place, region, or country c : of, relating to, or being the normal spoken form of a language.

The interest of this langtag is to show that the questions you rise are structurally well addressed by our common analysis. The lang3tag you propose relates to a region and matches (a) and (b). But these are old description outdated by the current world which is more generally described in (c). Here you have a problem because your tag could (but your ISO 3166 oriented approach prevents that) to use virtual regions.

Obviously we lack the common usage of a model where we could spot these issues as I am accustomed in my working groups. But you are in W3C and you know about web services. When two web services interacts they actually use a vernacular and their Man/machine interface will try to accommodate it to the users' language and brainware (the way people commonly use a network system). This results in a web vernacular, in a mail vernacular which currently is an ASCII vernacular but should multilingualize (and RVC 3066 is a key building block). When I see To: From: these are vernacular terms. This is very interesting to see when people know/can change the mail answer back line to see the formula they use from English "said" to Latin=20 "Scripsit".

Obviously vernacular with that meaning includes a quasi illimited type of procedures.

In other words, Twain's "Pudd'nhead Wilson" is written in a particular vernacular form of U.S. English. One can register a variant (under 3066bis--or a tag under 3066) that conveys this distinction (perhaps "en-US-twain"):

"Say it ag'in! En keep on sayin' it! It's all de pay a
body kin want in dis worl', en it's mo' den enough.
Laws bless you, honey, when I's slav' aroun', en dey 'buses me,
if I knows you's a-sayin' dat, 'way off yonder somers,
it'll heal up all de sore places, en I kin stan' 'em."

Generally though this is considered unnecessary. There are many vernaculars in the world. Only in exceptional cases does it become necessary to identify a particular language variation as distinct. But this does not obviate the point that RFC 3066 (and its proposed successor) already provide a mechanism for doing exactly that to identify text in the cases where the differences matter.

I do not dispute the case. I just document an analysis. I am glad to see that even if we may have slight differences, we are basically in agreement. And that you testify that what I say is in RFC 3066. I documented that in telling that I could encapsulate the RFC 3066 in my own approach. And asked if the way I was doing it was reducing in anyway your proposition. The only objections I received were on my own part, not on my support of yours.

(For that matter, 3066bis relaxes strictures surrounding the use of private use subtags so that specialists can identify various dialects or vernacular usages among themselves without the use of registration: "en-US-x-twain".)

This is internal to your proposition. I am glad you increase flexibility. The only remarks I have is that I am not only concerned in specialists but in every Internet user. I have observed that what is supposed to be reserved to specialists is quickly used by everyone with easy to use tools and support. This is what RFCs call scalability. Everything has to be documented and planned in a standard as if it was going to be used by everyone all the time. RFC 1958.

So how is what you're sayi= ng different from RFC 3066bis? Heck, how is it different from RFC 3066?!?

In the way RFC 3066 is actually used, it is not. This is what we are trying to tell you for two months. The problem is:
- if we are perfectly happy with RFC 3066 as it is applied today and we can stay happy for ever.
- you documented you are not. And we certainly want your needs to be satisfied, but in making us unsatisfied.
And I extensively documented what is detrimental, I can come back again on it.

I will use some HTML to make the presentation clearer. I hope all the readers can use it.



RFC 3066 IS NOT APPLIED
RFC 3066 works well because it is not really applied. What you want will make it applied and will show its lacks and the lacks of its implementation. This lacks are to be corrected. There are mainly three.

1. the ietf-language mailing list

The ietf-languages mailing list is not the IANA list presented in the RFC 3066. It should be managed and archived by IANA and documented on the IANA site to get the necessary exposure, participation and recognition by the international community. This would most probably help it to self correct what I reproach to it. One of the things it would probably have permitted to evaluate is its moderation and the reviewer which should probably be a three persons committee selected as two linguistic experts of English and of French culture and one network expert.

2. a consistency with the considered (ISO) lists
The RFC 3066 confuse the process and the deliverable. Up to now this is not too much notice because RFC 3066 is only occasionally used and the tables updated. It will change when it is extensively used.

The deliverable is the IANA added code. It should be consistent with the ISO lists it intend to complete. There is too much confusing information (name of the referent, documentation of the language). And there is no French translation. If someone needs the additional subtag she will know what it is. All the subtags must be of same weight and definition. How do I know that an ISO 693 code is really what I mean and if someone is not going to introduce a new IANA code which will better define my need? How do I know what ISO meant when I know what IANA means. On an other end what should I do when the IANA added code match my need but not the description? How do I make its use consistent with the use of the other ISO codes?

3. the default format being unique
RFC 3066 to my knowledge is used by your W3C applications, by Unicode, etc. outside of Internet documents and IANA except for IDNs. This obviously does not help to identify this problem and I am taxed to underline it, people focusing in the only example at hand, rather than on the  fundamental problem.

RFC 3066 starts with the conclusion. The format proposed format should be tone of the conclusion of the analysis. As the use, as the registration procedure, etc. Because you use a given format in a certain kind of applications, you want to use that format for ever. By this token UNIX would use DOS which would use DEC file format. Life is more flexible and innovation comes from flexibility. The format you propose does not suit my needs. It should not be a big deal to stay compatible.

4. You do not care about others' needs
The lack of RFC 3066 apparent use in other areas than your current applications gives the feeling that RFC 3066 can conduct the world. The idea that Countries may be taught to ask for ISO 3166 langtag compliant codes from other countries experience seems odd.

This also does not help to understand that you are shaking an existing stable situation and status quo. But you actually come and propose changes, you do not care about those who are affected ("you" - at large - even want to expel them).

Multilingual Internet

The status quo is based upon the very low interest in multilingualism by IAB. Demonstrated by the only RFC 3066, the low consideration of  Paul Hoffman's initial work, and the clear disinterest signal of the IAB's RFC 3869 (which lists the development priorities to be funded by the Governments - of every nations and languages - and does not even allude to multilingualism). Now, you want to make it a core issue interfering with the core issue of country codes through your ability to discuss ISO 3166, but more questioning the entire Internet architecture!

To understand this, you have remember how a network is built. Every network. Even if it is quite buried in the Internet defaults. A network permits a class of users to relate with a group of resources in using common identifier they register and manage in a registry (NIC) and parameters they store in a common repository (IANA, CRC). The initial international public network technology (1971) we deployed fully supported classes and groups and permitted to support an unlimited number of national, linguistic, corporate, public interest externets (a class, a group, a registry, a context supported by reference center). OSI principles (1975?) reduced externets to the notion of closed user groups, making the class (users) and the group a single list. Internet (1978-83) as a private network internetting (Vint Cerf/Bob Khan) into a DoD catenet (Louis Pouzin) only considered the Internet users class ("IN" and the "CHAOS" test class) and did not really mind about groups (DNS views can very partly reproduce, as well as intra/extranets). This permitted to dramatically reduce the intelligence expected from the network and to build a robust (but quite rustic!) network based upon the two "core values": dumb network, end to end.

Now, multilingualism was initially started (Japan, EBCDIC and France/Minitel) in using classes of non ASCII users interacting with group of resources able to respond them. This would correspond in the Internet to create 1.600.000 classes and to implement a group support which is totally inexplored today. A totally new DNS technology. Also, to speed up routing the group support would probably call for a different IPv6 structuring such as the one proposed for the ITU-T /3 block. We will have to come to that, but not now! Let experiment the transition first.

IDN introduced the idea of supporting multilingualism in the ASCII class in using internationalization. But this does not work because the analysis is not correct. It just focused on the DN and not on the FQDN and introduced a hierarchy (punycode or not are filtered) in the label rather than in the namespace. This means that they did not identified the need for virtual zones (sub-classes in the IN class) and the need of consistence of the vernacular (IDN Tables) used in that virtual zones. Result: the current homographs problem. The correct solution consists in respecting the standard network architecture in a scalable way and to force the multilingual FQDN (FQMLDN) to be consistent from the TLD to the last level. Due to the inclusion on the IN class and its existing number of TLD there must be a _presentation_ of the zone (lingual SLD) as a single label (ex nnn.chinesetag.cn being displayed as nnn.chinese_printing_of_cn) and a filtering of all the codes which are not permitted in a correct FQMLDN. For that all the concerned machine must have the necessary (limited) information of how to present a lingual SLD as a lingual TLD, and the corresponding IDN Table. There are three places to distribute them: either the IANA and the CRCs, either a dynamic repository like Akamai, or the Locales.

So, you understand that langtags are actually the names of the lingual externets or their aliases. Also, that depending on the way they are organized, they may fit or not into the DNS as it is managed today. Also, that while the WSIS is discussing the intergovernance there are a lot of interest to play it clearly, not to confuse the issues.

Applications
you consider only the applications you know. But you disregard the applications others are/should be (:-) working on (like OPES at the WG-OPES and ONES in other places, the CRCs as far I am concerned). And all those a correct support of multilingualism and vernacular could unlock. The web is a dazibao. One does spend our life reading. As Hitch says: 90% of the human communication is not with words. This leaves   a large number of applications  to develop. Their tagging needs are as much important than any other.


THE KEY ISSUE

The key issue is what the langtag for?
The charter says: they are necessary from (a) cataloging to (b) processing.
You say: "Language tags (c) identify text, (d) not the processes that are applied to them".
The Draft says:  "This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to (e) indicate the language used in an information object. "
Introduction of the draft says: "(f) Information about a user's language preferences commonly needs to be identified (g) so that appropriate processing can be applied"

Dictionary.com says:
"indicate":
(h) to show the way to or the direction of; point out: an arrow indicating north; indicated the right road by nodding toward it.
(i) to serve as a sign, symptom, or token of; signify: =93The cracking an= d booming of the ice indicate a change of temperature=94 (Henry David Thoreau).
(j) to suggest or demonstrate the necessity, expedience, or advisability of: The symptoms indicate immediate surgery.
(k) to state or express briefly: indicated his wishes in a letter; indicating her approval with a nod.

If the purpose is informative, the way I read (a), (c), (d), (e), (f), (i), things are OK with me.
If the purpose is normative, the way I read (b), (g), (h), (j) and possibly (k), things are not in the present status of the document.

Due to the limited use of RFC 3066  discusses above the question was not risen. They were used the way you say, to qualify/catalog texts in different applications and for IDN Tables.

But RFC 3066 - and you and Charter - uses a wording and you use examples (Introduction) which creates ambiguity and confusion about the intended use of the langtags. You can qualify a text with any descriptor you want, this creates no problem. You can use the langtags as a search key the way you want.

But to document the definition of the way a text is to be processed, you need at least all the five the descriptors we described. This is not something you can dispute or you kill the analysis you described as being also the RFC 3066 analysis.

If you do not provide these 5 elements, you actually imply the defaults are to be used. There is no default documented in the RFC 3066 and in your draft, except the name of the registrant/referent. He the becomes the default to tell what are the missing parameters. If the name is of a person, the opposition to that person will unnecessarily creates an opposition of the lingual community - even if the tag is correct. If the name is of a corporation or associated to a corporation this may be worse and detrimental to the interest of the voluntaries who carried the effort.

 = ;didn't think any Microsoft product dealt with "style" or "authority"
attributes, nor in script except to the extent that is covered by
registered RFC 3066 tags.

Name the reference/authority, etc. the way you want. Authoritative in its domain is an usual concept in the Internet culture. You can certainly find other words. This is what says a computer that when I write in French this is not Greek, or what make you sure that when I write in Provencal it is not Berrichon.

I gave in my response to Peer how and where the Word system does that.
- tools - languages : language, script, country  (you can qualify even if you do not understand).
- tools - options (preferences?) : dictionary, style (you need them to understand and write).
Which system do you use? Does it support the same descriptors?

This addresses an objection you made in another email, saying that these 5 points were not covered by Word and that your Word 2003 was great because it did not support RFC 3066 which was not yet published. Actually, I do use Word. My copy is Word 97, and even in these ancient times, these points we identified/share are here. It only add the proof of the age.

This being said, I understand your remark about what I name the multilingualization level. You say English is not defined. I belong to a culture where definition is known and supported for 4 centuries. This makes me more aware of this point. Actually English, in a way is more defined than French. When we introduce a computer in a culture, we do in a few months, a few years, what Richelieu and France did a long ago and matured over centuries: we create an "Acad=E9mie de cette Langue".

BTW this is probably a very interesting and exciting field of work.

What I object is that this Acad=E9mie may belong to anyone else than to the people sharing that culture. And naming is already a way to own. As long as it is to qualify the culture it is OK because there is a need. When it comes to enter in its definition this is - IMHO - an intrusion. And I refuse to share in that kind of intrusion.  To the contrary my approach is to say we are here to serve, help, educate so they can first share in this process, comment it and eventually conduct it for themselves.

I fully understand and support (with may be some tunings, like the support of namespace related information) the Unicode CLDR project - which is in the IESG charter but not documented - I wonder why. But I would strongly object to it if it was not carried under the supervision of Members of the concerned communities. Frank hates Governments. I tend to think they are our only protectors against e-colonization. Each of us have our fancies.

I note that three days ago this list had 2 Greek languages. Now 3 and probably 4. Because Greek persons stepped in and documented _their_ own languages. This is the way it should happen for every language, the request should come from each Internet community. This is the spirit of the text of RFC 3066. I fully understand that people may want urgently scan the cultural patrimonies of others, to sell it or to protect it from being merchandized, want to speed up the process. I do not think it is commercially or charity advisable to by-pass their future customers/friends in this process (as the reactions to the Google's annoucement show it). To the contrary they should help empowering the language and help their cultural, linguistic, political authorities through the registration process.

For example, I fully agree with you that the name of the langtag registrant is not necessary. But I would suggest to remove it only when the registration is by an outsider.

I note that if two languages are used at ISO (while UNESCO and ITU use 6 languages) there is probably good reasons, which may be to make sure that several and at least two cultures shared into the analysis (for defining the tag and when using it). This forces an openness of mind we often need. It means alternative thinking, searching, etc. Back-up is always a good thing. Two languages help also help the user to make sure the code she wants to use is the good one. Acceptance of a bilingual table will be far higher in a multilingual context than an ASCII only table.

Coopetition tends to foster quality.

I hope that this will eventually help.
jfc






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
For your convenience:
If you were Bcced for information and not familliar with the IETF process:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
 as a basis for country code top-level domain names was made with
 the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to. 
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
--=====================_22284413==.ALT-- --===============0520657625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0520657625==-- From ltru-bounces@ietf.org Fri Mar 18 11:21:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24712; Fri, 18 Mar 2005 11:21:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCKIp-00041O-5u; Fri, 18 Mar 2005 11:26:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCKE6-0001n8-Dd; Fri, 18 Mar 2005 11:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCKE5-0001ly-BN for ltru@megatron.ietf.org; Fri, 18 Mar 2005 11:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24674 for ; Fri, 18 Mar 2005 11:21:25 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCKIX-00040J-7e for ltru@ietf.org; Fri, 18 Mar 2005 11:26:06 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 08:20:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] singleton (was: First draft published, please comment) Date: Fri, 18 Mar 2005 08:20:25 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EBA3@irvmbxw01.quest.com> Thread-Topic: [Ltru] singleton (was: First draft published, please comment) Thread-Index: AcUrhR16gbmGGWMoRgWrVGeZoPBdPAAUSApg From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 18 Mar 2005 16:20:26.0430 (UTC) FILETIME=[64D05DE0:01C52BD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Thanks! I'll remove dead references then. Mark and I are prepared to = produce the next I-D based on the current round of comments. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 17 mars 2005 22:37 > To: ltru@ietf.org > Subject: Re: [Ltru] singleton (was: First draft published, please = comment) >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: > > Sent: Thursday, March 17, 2005 9:56 AM > > Subject: RE: [Ltru] singleton (was: First draft published, please > comment) > ... > > I have not made the change regarding references. > > There needs to be direction about what, if anything, > > to do with dead references. >=20 > (As contributor): delete dead references. > (As WG co-chair): Removing dead references is a "pure" editorial task = akin > to fixing grammar or spelling. You've alerted the WG to the problem; = if > anyone feels strongly about it, it is incumbent on them to speak up. = I > recommend deleting the dead references. >=20 > ... > > I will not incorporate any text until you tell me to do so. >=20 > > If you wish me to create a mockup of changes or a > > checkpoint version for the purposes of debate, I'm happy to do that. >=20 > The i-d itself normally serves that purpose. Integers are cheap, > and, except during IETF meeting week, the secretariat gives > fast service. >=20 > > Please let me know what form any such documents should > > take or any additional guidance you wish to supply. >=20 > Several issues have been discussed during this first week of ltru. > Martin and I will make a quick pass through the threads, and send > out "consensus call" messages for the issues that have been > brought up where we think there may be a rough consensus. That > will give anyone with strong objections to those proposed resolutions > the opportunity to present alternatives. >=20 > After we've sent out those consensus calls: > If anyone on this list thinks there's an issue that's reached > consensus that we've overlooked, please post to the list. > If we get it wrong, please post to the list. > If we don't see objections in a day or two, the editors should > go ahead with the changes. >=20 > Randy > Ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 11:44:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26795; Fri, 18 Mar 2005 11:44:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCKfA-0004zV-JC; Fri, 18 Mar 2005 11:49:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCKYj-00069u-LF; Fri, 18 Mar 2005 11:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCKYh-00069p-G7 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 11:42:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26617 for ; Fri, 18 Mar 2005 11:42:44 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCKdA-0004sq-6l for ltru@ietf.org; Fri, 18 Mar 2005 11:47:25 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 08:42:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] follow-up of an exchange on ietf-languages@alvestrand.no Date: Fri, 18 Mar 2005 08:42:35 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EBF4@irvmbxw01.quest.com> Thread-Topic: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no Thread-Index: AcUr09ArwkYabisFSYuPbs3cn1i9TwABW3hA From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "LTRU Working Group" X-OriginalArrivalTime: 18 Mar 2005 16:42:36.0840 (UTC) FILETIME=[7DCCD280:01C52BD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e535e8fdae689580ce57283401d548ee Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e5f3c965579421381eb58464afed5da Content-Transfer-Encoding: quoted-printable > But I need > first to review the draft (I said I will do it early next week). You send us all this without having actually read the draft?=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: vendredi 18 mars 2005 08:00 > To: LTRU Working Group > Subject: [Ltru] follow-up of an exchange on = ietf-languages@alvestrand.no >=20 > I have been questioned on the ietf-languages mailing list. The dialog = lead > to a threat which belongs to this WG. We agreed to transfer it. Here = is > the status of the current relevant exchange. >=20 >=20 >=20 > [I respond to one question] ... they are/this is more related > to the 5 levels/points underlaying a multilingual internet (I am not = sure > they are layers, they just are necessary) >=20 >=20 > Addison comments them and obviously we are in rough agreement (these > points are in the Charter as "identifying languages and language > preferences" - like in the Word tools menu. We only disagree on scope = and > application of the RFC. I think there are many ways to make the two > positions converging and to see new synergy resulting from it. But I = need > first to review the draft (I said I will do it early next week). = Responses > from Addison and Mark to these comments will help, as weel as comments = of > this WG. >=20 > On 19:29 17/03/2005, Addison Phillips said: >=20 >=20 > > - identification of the language (ISO 693 or the like) -> > interrelation > > between people - we can talk > RFC 3066 and 3066bis call this "primary language" >=20 >=20 > Correct. However a general remark: this is an analysis. It permits the = use > of the words we agree upon, but it is more general. I am interested in = the > users needs and in the network systems' answer to support them in the = way > applications/developers may want to perform them. My priority is to = the > users, to the network and to the applications, not to the RFC or ISO > document. And I live in a real world. I am not interested in good = document > you cannot implement due to (may be stupid but real) external = objections. >=20 > - as a user I consider myself (the need I know the best), the people I > develop/consult for in my position of "super IANA like" (CRC) project, = the > Governments I relate with and most of all multilingualism in naming, = e- > government, day to day life as per the various ITU, WSIS, UNESCO = unanimous > declarations. >=20 > - as far as network are concerned I consider the Internet current > architecture, the Interbox architecture I work on (first guidelines a > delayed by all this and current debates, presented to Govs and ITU = last > months: roughly a virtual user centric NGN permitting the transition = from > current Internet), the management of the few extended services of the > Internet architecture (name space - DNS, ONS, Handles, PAD, OPES, = ONES), > the dramatic architectural impact on a robust yet rustic end to end > oriented architecture of multilingualism. >=20 > - as far as applications are concerned I am interested in the = consistency > of the different existing tools, but I am also interested in all the > applications delayed by the limitations of the current systems. I am > advocating the most robust, simple and open common basis to permit to > develop compatible tools rather than standardizing one single = application > which will become overloaded with incompatible demands. A good example = of > a success in that direction is the DNS which has well resisted since = 1983 > (RFC 920). >=20 > - as a Registry Manager involved for 30 years in the international = public > and private real intergovernance. >=20 >=20 >=20 > > - internationalization (what discusses RFC 3066 - ISO 15924) -> > > interoperation between machines - we can write > RFC 3066bis calls this "script" >=20 >=20 > Yes. Same as above. > Also, users are not bond to scripting. Other supports (voice, signals, > commands, icons, images, fax, Minitel, music, etc.) are OK with this > analysis. In your context we agree. >=20 >=20 >=20 > > > - multinationalization (taking into account ISO 3166 or other > geopolitical > > attribute) -> interculturization between communities - we can > share same > > cultural references, the same meanings (for example, what may be > missing > > in > > here). > RFC 3066 and 3066bis call this "region" >=20 >=20 > Yes. Same as above. But in your context you refer to a region. = IAnalysis > is not limited only to that. It can be a Diaspora, a Church, a = culture, > etc. Look at Tamils for example, as a population. >=20 >=20 >=20 > > - multilingualization (semantic, grammar, dictionary, syntax, etc.) > -> > > interintelligibility -> we can understand each other >=20 > RFC 3066bis calls this a "variant"--variations within a language, > which may take many forms (orthography, dialect, etc. etc.). RFC 3066 > allows entries that represent this to be registered (but doesn't = identify > them explicitly with a name). Both allow multiple variations to be = applied > to a text. >=20 >=20 > Here I think we have a real difference. >=20 > If I read you correctly, you discuss of variation _within_ a language. = I > discuss of what describes a language. I suppose that you will = translate > this into a different code/description permitting someone to qualify a > text with a different tag. I will translate that into a CD including = all > the data necessary to describe the language to a computer, to permit = to > authenticate the origin of the text and to write and edit the text. >=20 >=20 >=20 > > - vernacularization (procedures, styles, tools, etc.) -> > interusability -> > > we can do something together >=20 > Language tags identify text, not the processes that are applied to > them. >=20 >=20 > This is the contentious point we have from the very beginning. Would = you > have included that sentence in the RFC 3066 bis it would be an = applauded > RFC by everyone. I will come back below on this key point. >=20 >=20 >=20 > A French text that has had French hyphenation rules applied to it is > just a French text. Particular vernacular distinctions may be = candidates > for registration, though, although this dives into more difficulty: is = it > another language or merely stylistic license? Merriam-Webster defines > vernacular thus: >=20 > 1 a : using a language or dialect native to a region or country > rather than a literary, cultured, or foreign language b : of, relating = to, > or being a nonstandard language or dialect of a place, region, or = country > c : of, relating to, or being the normal spoken form of a language. >=20 >=20 > The interest of this langtag is to show that the questions you rise = are > structurally well addressed by our common analysis. The lang3tag you > propose relates to a region and matches (a) and (b). But these are old > description outdated by the current world which is more generally > described in (c). Here you have a problem because your tag could (but = your > ISO 3166 oriented approach prevents that) to use virtual regions. >=20 > Obviously we lack the common usage of a model where we could spot = these > issues as I am accustomed in my working groups. But you are in W3C and = you > know about web services. When two web services interacts they actually = use > a vernacular and their Man/machine interface will try to accommodate = it to > the users' language and brainware (the way people commonly use a = network > system). This results in a web vernacular, in a mail vernacular which > currently is an ASCII vernacular but should multilingualize (and RVC = 3066 > is a key building block). When I see To: From: these are vernacular = terms. > This is very interesting to see when people know/can change the mail > answer back line to see the formula they use from English "said" to = Latin > "Scripsit". >=20 > Obviously vernacular with that meaning includes a quasi illimited type = of > procedures. >=20 >=20 >=20 > In other words, Twain's "Pudd'nhead Wilson" is written in a > particular vernacular form of U.S. English. One can register a variant > (under 3066bis--or a tag under 3066) that conveys this distinction > (perhaps "en-US-twain"): >=20 > "Say it ag'in! En keep on sayin' it! It's all de pay a > body kin want in dis worl', en it's mo' den enough. > Laws bless you, honey, when I's slav' aroun', en dey 'buses me, > if I knows you's a-sayin' dat, 'way off yonder somers, > it'll heal up all de sore places, en I kin stan' 'em." >=20 > Generally though this is considered unnecessary. There are many > vernaculars in the world. Only in exceptional cases does it become > necessary to identify a particular language variation as distinct. But > this does not obviate the point that RFC 3066 (and its proposed = successor) > already provide a mechanism for doing exactly that to identify text in = the > cases where the differences matter. >=20 >=20 > I do not dispute the case. I just document an analysis. I am glad to = see > that even if we may have slight differences, we are basically in = agreement. > And that you testify that what I say is in RFC 3066. I documented that = in > telling that I could encapsulate the RFC 3066 in my own approach. And > asked if the way I was doing it was reducing in anyway your = proposition. > The only objections I received were on my own part, not on my support = of > yours. >=20 >=20 >=20 > (For that matter, 3066bis relaxes strictures surrounding the use of > private use subtags so that specialists can identify various dialects = or > vernacular usages among themselves without the use of registration: = "en- > US-x-twain".) >=20 >=20 > This is internal to your proposition. I am glad you increase = flexibility. > The only remarks I have is that I am not only concerned in specialists = but > in every Internet user. I have observed that what is supposed to be > reserved to specialists is quickly used by everyone with easy to use = tools > and support. This is what RFCs call scalability. Everything has to be > documented and planned in a standard as if it was going to be used by > everyone all the time. RFC 1958. >=20 >=20 >=20 > So how is what you're saying different from RFC 3066bis? Heck, how > is it different from RFC 3066?!? >=20 >=20 > In the way RFC 3066 is actually used, it is not. This is what we are > trying to tell you for two months. The problem is: > - if we are perfectly happy with RFC 3066 as it is applied today and = we > can stay happy for ever. > - you documented you are not. And we certainly want your needs to be > satisfied, but in making us unsatisfied. > And I extensively documented what is detrimental, I can come back = again on > it. >=20 > I will use some HTML to make the presentation clearer. I hope all the > readers can use it. >=20 >=20 >=20 > RFC 3066 IS NOT APPLIED > RFC 3066 works well because it is not really applied. What you want = will > make it applied and will show its lacks and the lacks of its > implementation. This lacks are to be corrected. There are mainly = three. >=20 > 1. the ietf-language mailing list >=20 > The ietf-languages mailing list is not the IANA list presented in the = RFC > 3066. It should be managed and archived by IANA and documented on the = IANA > site to get the necessary exposure, participation and recognition by = the > international community. This would most probably help it to self = correct > what I reproach to it. One of the things it would probably have = permitted > to evaluate is its moderation and the reviewer which should probably = be a > three persons committee selected as two linguistic experts of English = and > of French culture and one network expert. >=20 > 2. a consistency with the considered (ISO) lists > The RFC 3066 confuse the process and the deliverable. Up to now this = is > not too much notice because RFC 3066 is only occasionally used and the > tables updated. It will change when it is extensively used. >=20 > The deliverable is the IANA added code. It should be consistent with = the > ISO lists it intend to complete. There is too much confusing = information > (name of the referent, documentation of the language). And there is no > French translation. If someone needs the additional subtag she will = know > what it is. All the subtags must be of same weight and definition. How = do > I know that an ISO 693 code is really what I mean and if someone is = not > going to introduce a new IANA code which will better define my need? = How > do I know what ISO meant when I know what IANA means. On an other end = what > should I do when the IANA added code match my need but not the = description? > How do I make its use consistent with the use of the other ISO codes? >=20 > 3. the default format being unique > RFC 3066 to my knowledge is used by your W3C applications, by Unicode, = etc. > outside of Internet documents and IANA except for IDNs. This obviously > does not help to identify this problem and I am taxed to underline it, > people focusing in the only example at hand, rather than on the > fundamental problem. >=20 > RFC 3066 starts with the conclusion. The format proposed format should = be > tone of the conclusion of the analysis. As the use, as the = registration > procedure, etc. Because you use a given format in a certain kind of > applications, you want to use that format for ever. By this token UNIX > would use DOS which would use DEC file format. Life is more flexible = and > innovation comes from flexibility. The format you propose does not = suit my > needs. It should not be a big deal to stay compatible. >=20 > 4. You do not care about others' needs > The lack of RFC 3066 apparent use in other areas than your current > applications gives the feeling that RFC 3066 can conduct the world. = The > idea that Countries may be taught to ask for ISO 3166 langtag = compliant > codes from other countries experience seems odd. >=20 > This also does not help to understand that you are shaking an existing > stable situation and status quo. But you actually come and propose = changes, > you do not care about those who are affected ("you" - at large - even = want > to expel them). >=20 > Multilingual Internet >=20 > The status quo is based upon the very low interest in multilingualism = by > IAB. Demonstrated by the only RFC 3066, the low consideration of Paul > Hoffman's initial work, and the clear disinterest signal of the IAB's = RFC > 3869 (which lists the development priorities to be funded by the > Governments - of every nations and languages - and does not even = allude to > multilingualism). Now, you want to make it a core issue interfering = with > the core issue of country codes through your ability to discuss ISO = 3166, > but more questioning the entire Internet architecture! >=20 > To understand this, you have remember how a network is built. Every > network. Even if it is quite buried in the Internet defaults. A = network > permits a class of users to relate with a group of resources in using > common identifier they register and manage in a registry (NIC) and > parameters they store in a common repository (IANA, CRC). The initial > international public network technology (1971) we deployed fully = supported > classes and groups and permitted to support an unlimited number of > national, linguistic, corporate, public interest externets (a class, a > group, a registry, a context supported by reference center). OSI > principles (1975?) reduced externets to the notion of closed user = groups, > making the class (users) and the group a single list. Internet = (1978-83) > as a private network internetting (Vint Cerf/Bob Khan) into a DoD = catenet > (Louis Pouzin) only considered the Internet users class ("IN" and the > "CHAOS" test class) and did not really mind about groups (DNS views = can > very partly reproduce, as well as intra/extranets). This permitted to > dramatically reduce the intelligence expected from the network and to > build a robust (but quite rustic!) network based upon the two "core > values": dumb network, end to end. >=20 > Now, multilingualism was initially started (Japan, EBCDIC and > France/Minitel) in using classes of non ASCII users interacting with = group > of resources able to respond them. This would correspond in the = Internet > to create 1.600.000 classes and to implement a group support which is > totally inexplored today. A totally new DNS technology. Also, to speed = up > routing the group support would probably call for a different IPv6 > structuring such as the one proposed for the ITU-T /3 block. We will = have > to come to that, but not now! Let experiment the transition first. >=20 > IDN introduced the idea of supporting multilingualism in the ASCII = class > in using internationalization. But this does not work because the = analysis > is not correct. It just focused on the DN and not on the FQDN and > introduced a hierarchy (punycode or not are filtered) in the label = rather > than in the namespace. This means that they did not identified the = need > for virtual zones (sub-classes in the IN class) and the need of > consistence of the vernacular (IDN Tables) used in that virtual zones. > Result: the current homographs problem. The correct solution consists = in > respecting the standard network architecture in a scalable way and to > force the multilingual FQDN (FQMLDN) to be consistent from the TLD to = the > last level. Due to the inclusion on the IN class and its existing = number > of TLD there must be a _presentation_ of the zone (lingual SLD) as a > single label (ex nnn.chinesetag.cn being displayed as > nnn.chinese_printing_of_cn) and a filtering of all the codes which are = not > permitted in a correct FQMLDN. For that all the concerned machine must > have the necessary (limited) information of how to present a lingual = SLD > as a lingual TLD, and the corresponding IDN Table. There are three = places > to distribute them: either the IANA and the CRCs, either a dynamic > repository like Akamai, or the Locales. >=20 > So, you understand that langtags are actually the names of the lingual > externets or their aliases. Also, that depending on the way they are > organized, they may fit or not into the DNS as it is managed today. = Also, > that while the WSIS is discussing the intergovernance there are a lot = of > interest to play it clearly, not to confuse the issues. >=20 > Applications > you consider only the applications you know. But you disregard the > applications others are/should be (:-) working on (like OPES at the = WG- > OPES and ONES in other places, the CRCs as far I am concerned). And = all > those a correct support of multilingualism and vernacular could = unlock. > The web is a dazibao. One does spend our life reading. As Hitch says: = 90% > of the human communication is not with words. This leaves a large = number > of applications to develop. Their tagging needs are as much important > than any other. >=20 >=20 > THE KEY ISSUE >=20 > The key issue is what the langtag for? > The charter says: they are necessary from (a) cataloging to (b) = processing. > You say: "Language tags (c) identify text, (d) not the processes that = are > applied to them". > The Draft says: "This document describes the structure, content, > construction, and semantics of language tags for use in cases where it = is > desirable to (e) indicate the language used in an information object. = " > Introduction of the draft says: "(f) Information about a user's = language > preferences commonly needs to be identified (g) so that appropriate > processing can be applied" >=20 > Dictionary.com says: > "indicate": > (h) to show the way to or the direction of; point out: an arrow = indicating > north; indicated the right road by nodding toward it. > (i) to serve as a sign, symptom, or token of; signify: "The cracking = and > booming of the ice indicate a change of temperature" (Henry David = Thoreau). > (j) to suggest or demonstrate the necessity, expedience, or = advisability > of: The symptoms indicate immediate surgery. > (k) to state or express briefly: indicated his wishes in a letter; > indicating her approval with a nod. >=20 > If the purpose is informative, the way I read (a), (c), (d), (e), (f), = (i), > things are OK with me. > If the purpose is normative, the way I read (b), (g), (h), (j) and > possibly (k), things are not in the present status of the document. >=20 > Due to the limited use of RFC 3066 discusses above the question was = not > risen. They were used the way you say, to qualify/catalog texts in > different applications and for IDN Tables. >=20 > But RFC 3066 - and you and Charter - uses a wording and you use = examples > (Introduction) which creates ambiguity and confusion about the = intended > use of the langtags. You can qualify a text with any descriptor you = want, > this creates no problem. You can use the langtags as a search key the = way > you want. >=20 > But to document the definition of the way a text is to be processed, = you > need at least all the five the descriptors we described. This is not > something you can dispute or you kill the analysis you described as = being > also the RFC 3066 analysis. >=20 > If you do not provide these 5 elements, you actually imply the = defaults > are to be used. There is no default documented in the RFC 3066 and in = your > draft, except the name of the registrant/referent. He the becomes the > default to tell what are the missing parameters. If the name is of a > person, the opposition to that person will unnecessarily creates an > opposition of the lingual community - even if the tag is correct. If = the > name is of a corporation or associated to a corporation this may be = worse > and detrimental to the interest of the voluntaries who carried the = effort. >=20 >=20 >=20 > didn't think any Microsoft product dealt with "style" > or "authority" > attributes, nor in script except to the extent that is > covered by > registered RFC 3066 tags. >=20 >=20 > Name the reference/authority, etc. the way you want. > Authoritative in its domain is an usual concept in the Internet = culture. > You can certainly find other words. This is what says a computer that = when > I write in French this is not Greek, or what make you sure that when I > write in Provencal it is not Berrichon. >=20 > I gave in my response to Peer how and where the Word system > does that. > - tools - languages : language, script, country (you can > qualify even if you do not understand). > - tools - options (preferences?) : dictionary, style (you need > them to understand and write). > Which system do you use? Does it support the same descriptors? >=20 >=20 > This addresses an objection you made in another email, saying that = these 5 > points were not covered by Word and that your Word 2003 was great = because > it did not support RFC 3066 which was not yet published. Actually, I = do > use Word. My copy is Word 97, and even in these ancient times, these > points we identified/share are here. It only add the proof of the age. >=20 >=20 >=20 > This being said, I understand your remark about what I name > the multilingualization level. You say English is not defined. I = belong to > a culture where definition is known and supported for 4 centuries. = This > makes me more aware of this point. Actually English, in a way is more > defined than French. When we introduce a computer in a culture, we do = in a > few months, a few years, what Richelieu and France did a long ago and > matured over centuries: we create an "Acad=E9mie de cette Langue". >=20 >=20 > BTW this is probably a very interesting and exciting field of work. >=20 >=20 >=20 > What I object is that this Acad=E9mie may belong to anyone else > than to the people sharing that culture. And naming is already a way = to > own. As long as it is to qualify the culture it is OK because there is = a > need. When it comes to enter in its definition this is - IMHO - an > intrusion. And I refuse to share in that kind of intrusion. To the > contrary my approach is to say we are here to serve, help, educate so = they > can first share in this process, comment it and eventually conduct it = for > themselves. >=20 >=20 > I fully understand and support (with may be some tunings, like the = support > of namespace related information) the Unicode CLDR project - which is = in > the IESG charter but not documented - I wonder why. But I would = strongly > object to it if it was not carried under the supervision of Members of = the > concerned communities. Frank hates Governments. I tend to think they = are > our only protectors against e-colonization. Each of us have our = fancies. >=20 >=20 >=20 > I note that three days ago this list had 2 Greek languages. > Now 3 and probably 4. Because Greek persons stepped in and documented > _their_ own languages. This is the way it should happen for every = language, > the request should come from each Internet community. This is the = spirit > of the text of RFC 3066. I fully understand that people may want = urgently > scan the cultural patrimonies of others, to sell it or to protect it = from > being merchandized, want to speed up the process. I do not think it is > commercially or charity advisable to by-pass their future > customers/friends in this process (as the reactions to the Google's > annoucement show it). To the contrary they should help empowering the > language and help their cultural, linguistic, political authorities > through the registration process. >=20 > For example, I fully agree with you that the name of the > langtag registrant is not necessary. But I would suggest to remove it = only > when the registration is by an outsider. >=20 >=20 > I note that if two languages are used at ISO (while UNESCO and ITU use = 6 > languages) there is probably good reasons, which may be to make sure = that > several and at least two cultures shared into the analysis (for = defining > the tag and when using it). This forces an openness of mind we often = need. > It means alternative thinking, searching, etc. Back-up is always a = good > thing. Two languages help also help the user to make sure the code she > wants to use is the good one. Acceptance of a bilingual table will be = far > higher in a multilingual context than an ASCII only table. >=20 > Coopetition tends to foster quality. >=20 > I hope that this will eventually help. > jfc >=20 >=20 >=20 >=20 >=20 >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > For your convenience: > Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry- > 00.txt > Charter: http://ietf.org/html.charters/ltru-charter.html > gmane: http://dir.gmane.org/gmane.ietf.ltru > If you were Bcced for information and not familliar with the IETF = process: > http://www.ietf.org/rfc/rfc2026.txt > http://www.ietf.org/rfc/rfc2418.txt > http://www.ietf.org/rfc/rfc3934.txt > http://www.ietf.org/rfc/rfc3669.txt > http://www.ietf.org/rfc/rfc3160.txt > http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Jon Postel (RFC 1591): "The IANA is not in the business of deciding > what is and what is not a country. The selection of the ISO 3166 list > as a basis for country code top-level domain names was made with > the knowledge that ISO has a procedure for determining which > entities should be and should not be on that list." > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing = the > same thing, choose one. If a previous design, in the Internet context > or elsewhere, has successfully solved the same problem, choose the > same solution unless there is a good technical reason not to. > Duplication of the same protocol functionality should be avoided as = far as > possible, without of course using this argument to reject = improvements." > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > It seems that what works for countries and ISO 3166 since 1978 should > apply to languages and to ISO 693. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 12:24:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00263; Fri, 18 Mar 2005 12:24:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLHQ-0006aV-Jo; Fri, 18 Mar 2005 12:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLAE-0006Aw-2m; Fri, 18 Mar 2005 12:21:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLAC-0006Ar-A1 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 12:21:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29957 for ; Fri, 18 Mar 2005 12:21:28 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLEe-0006PF-TO for ltru@ietf.org; Fri, 18 Mar 2005 12:26:10 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2IHLKJo025536; Fri, 18 Mar 2005 12:21:20 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 18 Mar 2005 12:21:20 -0500 Date: Fri, 18 Mar 2005 12:21:20 -0500 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no Message-ID: <20050318172120.GB23167@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AA9E6BA@irvmbxw01.quest.com> <6.1.2.0.2.20050318030616.0398feb0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050318030616.0398feb0@mail.jefsey.com> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j2IHLKJo025536 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin scripsit: > I have been questioned on the ietf-languages mailing list. The dialog l= ead=20 > to a threat which belongs to this WG.=20 Since we are on the record here, it is important to clarify whether this = was a threat or a thread. As a participant in both lists, I believe it was a= thread. --=20 H=EDggledy-p=ECggledy / XML programmers John Cowan Try to escape those / I-eighteen-N woes; http://www.ccil.org/~cowa= n Incontrovertibly / What we need more of is http://www.reutershealth.= com Unicode weenies and / Fran=E7ois Yergeaus. jcowan@reutershealth.co= m _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 13:34:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08350; Fri, 18 Mar 2005 13:34:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMNh-000196-EL; Fri, 18 Mar 2005 13:39:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMIY-0003WW-CH; Fri, 18 Mar 2005 13:34:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMIW-0003WR-HB for ltru@megatron.ietf.org; Fri, 18 Mar 2005 13:34:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08310 for ; Fri, 18 Mar 2005 13:34:08 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMMz-00018B-Kn for ltru@ietf.org; Fri, 18 Mar 2005 13:38:51 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2IIXquY021333; Fri, 18 Mar 2005 10:33:56 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DRD7>; Fri, 18 Mar 2005 10:33:52 -0800 Message-ID: From: "McDonald, Ira" To: "'Scott Hollenbeck'" , "'Frank Ellermann'" , ltru@ietf.org Date: Fri, 18 Mar 2005 10:33:48 -0800 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: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ltru] Normative vs Informative references X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi, Separating references has a more important impact - it makes clear where the main body text should have a section labelled something like '4.2 Blazzle (Informative)', because all of the dependencies are informative. Also, the list of normative references should stay short! If not, there are always ambiguities about _which_ normative reference to believe in case of conflicts. Cheers, - Ira PS - If other working group members contribute text, please specify the references as normative or informative right then. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Scott Hollenbeck Sent: Friday, March 18, 2005 6:58 AM To: 'Frank Ellermann'; ltru@ietf.org Subject: RE: [Ltru] Re: singleton > What you IIRC really need are both "normative references" and > "informative references", with e.g. RfC 2234 as "normative". > Or as Scott said later RfC 2234bis, this should be ready soon, > unless Bruce finds a problem in the 2234bis draft. Bye, Frank Separation of references into normative and informative subsections is required these days. 2234bis is out: http://www.ietf.org/internet-drafts/draft-crocker-abnf-rfc2234bis-00.txt -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 14:18:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12863; Fri, 18 Mar 2005 14:18:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCN4A-0002vb-LB; Fri, 18 Mar 2005 14:23:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMyd-0003ZK-Pa; Fri, 18 Mar 2005 14:17:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMyc-0003ZF-Ou for ltru@megatron.ietf.org; Fri, 18 Mar 2005 14:17:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12776 for ; Fri, 18 Mar 2005 14:17:40 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCN36-0002u9-En for ltru@ietf.org; Fri, 18 Mar 2005 14:22:21 -0500 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCMyZ-0002pT-00 for ltru@ietf.org; Fri, 18 Mar 2005 11:17:39 -0800 Message-ID: <004901c52bef$3aab2540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Normative vs Informative references Date: Fri, 18 Mar 2005 11:18:12 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi - (as a technical contributor) > From: "McDonald, Ira" > To: "'Scott Hollenbeck'" ; "'Frank Ellermann'" ; > Sent: Friday, March 18, 2005 10:33 AM > Subject: [Ltru] Normative vs Informative references ... > Separating references has a more important impact - it makes > clear where the main body text should have a section labelled > something like '4.2 Blazzle (Informative)', because all of the > dependencies are informative. Although I agree that informative sections of material benefit from being clearly labeled, one cannot use the absence of normative references in a section to characterize that section as non-normative. For example, a section could read: Implementations MUST do X in situation Y. For an explanation of why this is required, see the analysis in section Z of [unrelated-protocol-informative-reference]. This would be perfectly good normative material, with a perfectly good informative reference. > Also, the list of normative references should stay short! If possible. ... > PS - If other working group members contribute text, please > specify the references as normative or informative right then. ... Good suggestion. Note however, that some references to a particular specification might be informative, and others normative. If *any* of the references to a specification are normative, then it goes into the normative references section. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 14:34:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14556; Fri, 18 Mar 2005 14:34:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNJ2-0003VR-4X; Fri, 18 Mar 2005 14:38:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNDj-0006TZ-D8; Fri, 18 Mar 2005 14:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNDh-0006TU-9z for ltru@megatron.ietf.org; Fri, 18 Mar 2005 14:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14449 for ; Fri, 18 Mar 2005 14:33:15 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNIB-0003UM-Hy for ltru@ietf.org; Fri, 18 Mar 2005 14:37:56 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2IJX6t4024400; Fri, 18 Mar 2005 11:33:06 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DRZA>; Fri, 18 Mar 2005 11:33:06 -0800 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , ltru@ietf.org Subject: RE: [Ltru] Normative vs Informative references Date: Fri, 18 Mar 2005 11:33:03 -0800 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: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hi Randy, What I meant to say is if the section does include references and they are all informative, then that section is most likely informative (your example of MUST language is interesting, but if there's no normative source, it seems questionable, unless it's part of a whole new protocol feature). Re whether a given reference is normative or informative, neither the IESG standards process (nor any other I've ever seen) allows this hair-splitting. If ANY reference to a given source document is Normative, then they ALL must be Normative, or hand-waving is being used. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Randy Presuhn Sent: Friday, March 18, 2005 2:18 PM To: ltru@ietf.org Subject: Re: [Ltru] Normative vs Informative references Hi - (as a technical contributor) > From: "McDonald, Ira" > To: "'Scott Hollenbeck'" ; "'Frank Ellermann'" ; > Sent: Friday, March 18, 2005 10:33 AM > Subject: [Ltru] Normative vs Informative references ... > Separating references has a more important impact - it makes > clear where the main body text should have a section labelled > something like '4.2 Blazzle (Informative)', because all of the > dependencies are informative. Although I agree that informative sections of material benefit from being clearly labeled, one cannot use the absence of normative references in a section to characterize that section as non-normative. For example, a section could read: Implementations MUST do X in situation Y. For an explanation of why this is required, see the analysis in section Z of [unrelated-protocol-informative-reference]. This would be perfectly good normative material, with a perfectly good informative reference. > Also, the list of normative references should stay short! If possible. ... > PS - If other working group members contribute text, please > specify the references as normative or informative right then. ... Good suggestion. Note however, that some references to a particular specification might be informative, and others normative. If *any* of the references to a specification are normative, then it goes into the normative references section. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 14:52:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17163; Fri, 18 Mar 2005 14:52:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNbH-0004Pd-QP; Fri, 18 Mar 2005 14:57:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNWF-0001Vc-6k; Fri, 18 Mar 2005 14:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNWE-0001VX-30 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 14:52:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17138 for ; Fri, 18 Mar 2005 14:52:22 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNag-0004IN-Mu for ltru@ietf.org; Fri, 18 Mar 2005 14:57:04 -0500 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCNW9-00049z-00 for ltru@ietf.org; Fri, 18 Mar 2005 11:52:21 -0800 Message-ID: <007001c52bf4$13d57ce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Normative vs Informative references Date: Fri, 18 Mar 2005 11:52:55 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi - > From: "McDonald, Ira" > To: "'Randy Presuhn'" ; > Sent: Friday, March 18, 2005 11:33 AM > Subject: RE: [Ltru] Normative vs Informative references ... > What I meant to say is if the section does include references > and they are all informative, then that section is most likely > informative (your example of MUST language is interesting, but > if there's no normative source, it seems questionable, unless > it's part of a whole new protocol feature). That's precisely the point. Context, along with the nature of the cited material, determines whether a given citation of a reference is normative or not. > Re whether a given reference is normative or informative, neither > the IESG standards process (nor any other I've ever seen) allows > this hair-splitting. If ANY reference to a given source document > is Normative, then they ALL must be Normative, or hand-waving is > being used. ... Refutation by counter-example, at risk of spinning wildly off-topic for this list: Take a look at RFC 3417 section 5.3.3: An NBP name to DDP address mapping can also be confirmed implicitly using only SNMP transactions. For example, an SNMP entity supporting command generator applications issuing a retrieval operation could also retrieve the relevant objects from the NBP group [RFC1742] for the SNMP entity supporting the command responder application. This information can then be correlated with the source DDP address of the response. This is an *informative* citation, since it is used only as an example of how to do something, even though it's in the midst of normative material. If, elsewhere in the document, there were a normative citation, saying that for some other operation on MUST access the NBP group, this particular citation would still be informative, even though the reference itself would have to be listed as normative. "For example" means just that, even if the citation is of material that appears in a document listed (for other reasons) among the normative references. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 14:57:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17708; Fri, 18 Mar 2005 14:57:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNg5-0004at-84; Fri, 18 Mar 2005 15:02:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNak-00020A-83; Fri, 18 Mar 2005 14:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNai-0001zw-PW for ltru@megatron.ietf.org; Fri, 18 Mar 2005 14:57:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17606 for ; Fri, 18 Mar 2005 14:57:02 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNfE-0004Yu-0j for ltru@ietf.org; Fri, 18 Mar 2005 15:01:44 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 11:56:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Normative vs Informative references Date: Fri, 18 Mar 2005 11:56:48 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.com> Thread-Topic: [Ltru] Normative vs Informative references Thread-Index: AcUr76rSMXAdlpCCRamLypkmYv+A5gAAWmfg From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 18 Mar 2005 19:56:48.0899 (UTC) FILETIME=[9EF7ED30:01C52BF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable I have split the references into informative and normative. I have eliminated the following dead references: RFC 1327 RFC 1521 RFC 3639 RFC 2616 (is cited by the matching draft) RFC 2396 The informative references consist of two items: ISO 639 Principles (referenced in a note in section 2.2.1) RFC 2231 (MIME parameter values, cited as an example in Section 2.1.1) The normative references consist of: ISO 639-1:2002 ISO 639-2:1998 ISO 15924:2003 ISO 3166:1988 UN M.49 RFC 1766 (mostly for historical reasons, could be informative) RFC 2026 (obviously) RFC 2028 (organizations involved in ietf process) RFC 2119 (normative language) RFC 2234 (ABNF) RFC 2434 (writing IANA considerations sections) RFC 2860 (defined IANA) RFC 3066 (obviously) RFC 3339 (defines ISO 8601 and the date format used in the registry) Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: vendredi 18 mars 2005 11:18 > To: ltru@ietf.org > Subject: Re: [Ltru] Normative vs Informative references >=20 > Hi - >=20 > (as a technical contributor) >=20 > > From: "McDonald, Ira" > > To: "'Scott Hollenbeck'" ; "'Frank Ellermann'" > ; > > Sent: Friday, March 18, 2005 10:33 AM > > Subject: [Ltru] Normative vs Informative references > ... > > Separating references has a more important impact - it makes > > clear where the main body text should have a section labelled > > something like '4.2 Blazzle (Informative)', because all of the > > dependencies are informative. >=20 > Although I agree that informative sections of material benefit > from being clearly labeled, one cannot use the absence of > normative references in a section to characterize that section > as non-normative. >=20 > For example, a section could read: >=20 > Implementations MUST do X in situation Y. For an explanation > of why this is required, see the analysis in section Z of > [unrelated-protocol-informative-reference]. >=20 > This would be perfectly good normative material, with a perfectly > good informative reference. >=20 > > Also, the list of normative references should stay short! >=20 > If possible. >=20 > ... > > PS - If other working group members contribute text, please > > specify the references as normative or informative right then. > ... >=20 > Good suggestion. Note however, that some references to a particular > specification might be informative, and others normative. If *any* of > the references to a specification are normative, then it goes into the > normative references section. >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 15:20:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21042; Fri, 18 Mar 2005 15:20:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO1W-0005Tw-Ho; Fri, 18 Mar 2005 15:24:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNwY-0005Zb-Jr; Fri, 18 Mar 2005 15:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNwX-0005X1-2l for ltru@megatron.ietf.org; Fri, 18 Mar 2005 15:19:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20955 for ; Fri, 18 Mar 2005 15:19:34 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO11-0005Sg-PD for ltru@ietf.org; Fri, 18 Mar 2005 15:24:17 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2IKJQ1t026793; Fri, 18 Mar 2005 15:19:26 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 18 Mar 2005 15:19:37 -0500 Date: Fri, 18 Mar 2005 15:19:37 -0500 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Normative vs Informative references Message-ID: <20050318201937.GF23167@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Addison Phillips scripsit: > The normative references consist of: > > RFC 1766 (mostly for historical reasons, could be informative) > RFC 3066 (obviously) These should be informative, not normative. Making them normative implies that you can't understand the new document without referring to them, which is untrue. -- Samuel Johnson on playing the violin: John Cowan "Difficult do you call it, Sir? jcowan@reutershealth.com I wish it were impossible." http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 15:21:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21279; Fri, 18 Mar 2005 15:21:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO2l-0005Vh-JW; Fri, 18 Mar 2005 15:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNxb-0005oI-SF; Fri, 18 Mar 2005 15:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCNxa-0005oD-F9 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 15:20:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21115 for ; Fri, 18 Mar 2005 15:20:40 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCO25-0005Ui-6O for ltru@ietf.org; Fri, 18 Mar 2005 15:25:22 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 12:20:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Normative vs Informative references Date: Fri, 18 Mar 2005 12:20:30 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EE23@irvmbxw01.quest.com> Thread-Topic: [Ltru] Normative vs Informative references Thread-Index: AcUr98829UWH2iypTdymphvj8k4jxQAABeWw From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 18 Mar 2005 20:20:31.0298 (UTC) FILETIME=[EEC8CA20:01C52BF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Agreed and done. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: vendredi 18 mars 2005 12:20 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Normative vs Informative references >=20 > Addison Phillips scripsit: >=20 > > The normative references consist of: > > > > RFC 1766 (mostly for historical reasons, could be informative) > > RFC 3066 (obviously) >=20 > These should be informative, not normative. Making them normative = implies > that you can't understand the new document without referring to them, > which is untrue. >=20 > -- > Samuel Johnson on playing the violin: John Cowan > "Difficult do you call it, Sir? = jcowan@reutershealth.com > I wish it were impossible." = http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 15:53:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28700; Fri, 18 Mar 2005 15:53:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOXe-00088l-69; Fri, 18 Mar 2005 15:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOCp-0001AY-6K; Fri, 18 Mar 2005 15:36:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOCo-0001AS-Bo for ltru@megatron.ietf.org; Fri, 18 Mar 2005 15:36:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23535 for ; Fri, 18 Mar 2005 15:36:23 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOHH-0006DA-7l for ltru@ietf.org; Fri, 18 Mar 2005 15:41:04 -0500 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCOCe-0005DM-00 for ltru@ietf.org; Fri, 18 Mar 2005 12:36:16 -0800 Message-ID: <000801c52bfa$36954de0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.com> <20050318201937.GF23167@skunk.reutershealth.com> Subject: Re: [Ltru] Normative vs Informative references Date: Fri, 18 Mar 2005 12:36:50 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi - (as technical contributor) > From: "John Cowan" > To: "Addison Phillips" > Cc: > Sent: Friday, March 18, 2005 12:19 PM > Subject: Re: [Ltru] Normative vs Informative references > > Addison Phillips scripsit: > > > The normative references consist of: > > > > RFC 1766 (mostly for historical reasons, could be informative) > > RFC 3066 (obviously) > > These should be informative, not normative. Making them normative implies > that you can't understand the new document without referring to them, > which is untrue. ... Agreed. The references to both are informative. The passages where the string "3066" occurs that seem to have the most normative weight refer to the registrations that have happened under that regime, rather than the document itself. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 17:07:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13934; Fri, 18 Mar 2005 17:07:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPhJ-0005sb-3t; Fri, 18 Mar 2005 17:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPcj-0005UW-RE; Fri, 18 Mar 2005 17:07:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCPci-0005Tc-Q7 for ltru@megatron.ietf.org; Fri, 18 Mar 2005 17:07:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13917 for ; Fri, 18 Mar 2005 17:07:11 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCPhD-0005s2-0A for ltru@ietf.org; Fri, 18 Mar 2005 17:11:55 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2IM6twW001766; Fri, 18 Mar 2005 14:06:59 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DTJY>; Fri, 18 Mar 2005 14:06:56 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Randy Presuhn , ltru@ietf.org Subject: RE: [Ltru] Normative vs Informative references Date: Fri, 18 Mar 2005 14:06:52 -0800 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: 36b1f8810cb91289d885dc8ab4fc8172 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Hi, I would suggest that you add to your 'Security Considerations' section an informative reference to RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on Security Considerations". So revise text from: The evaluation of the exact magnitude of the threat, and any possible countermeasures, is left to each application protocol. to: The evaluation of the exact magnitude of the threat, and any possible countermeasures, is left to each application protocol (see [RFC3552] for best practice guidance on security threats and defenses). 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Addison Phillips Sent: Friday, March 18, 2005 2:57 PM To: Randy Presuhn; ltru@ietf.org Subject: RE: [Ltru] Normative vs Informative references I have split the references into informative and normative. I have eliminated the following dead references: RFC 1327 RFC 1521 RFC 3639 RFC 2616 (is cited by the matching draft) RFC 2396 The informative references consist of two items: ISO 639 Principles (referenced in a note in section 2.2.1) RFC 2231 (MIME parameter values, cited as an example in Section 2.1.1) The normative references consist of: ISO 639-1:2002 ISO 639-2:1998 ISO 15924:2003 ISO 3166:1988 UN M.49 RFC 1766 (mostly for historical reasons, could be informative) RFC 2026 (obviously) RFC 2028 (organizations involved in ietf process) RFC 2119 (normative language) RFC 2234 (ABNF) RFC 2434 (writing IANA considerations sections) RFC 2860 (defined IANA) RFC 3066 (obviously) RFC 3339 (defines ISO 8601 and the date format used in the registry) Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: vendredi 18 mars 2005 11:18 > To: ltru@ietf.org > Subject: Re: [Ltru] Normative vs Informative references > > Hi - > > (as a technical contributor) > > > From: "McDonald, Ira" > > To: "'Scott Hollenbeck'" ; "'Frank Ellermann'" > ; > > Sent: Friday, March 18, 2005 10:33 AM > > Subject: [Ltru] Normative vs Informative references > ... > > Separating references has a more important impact - it makes > > clear where the main body text should have a section labelled > > something like '4.2 Blazzle (Informative)', because all of the > > dependencies are informative. > > Although I agree that informative sections of material benefit > from being clearly labeled, one cannot use the absence of > normative references in a section to characterize that section > as non-normative. > > For example, a section could read: > > Implementations MUST do X in situation Y. For an explanation > of why this is required, see the analysis in section Z of > [unrelated-protocol-informative-reference]. > > This would be perfectly good normative material, with a perfectly > good informative reference. > > > Also, the list of normative references should stay short! > > If possible. > > ... > > PS - If other working group members contribute text, please > > specify the references as normative or informative right then. > ... > > Good suggestion. Note however, that some references to a particular > specification might be informative, and others normative. If *any* of > the references to a specification are normative, then it goes into the > normative references section. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 17:53:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18527; Fri, 18 Mar 2005 17:53:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQQE-0007dj-68; Fri, 18 Mar 2005 17:58:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQKr-0007rV-TV; Fri, 18 Mar 2005 17:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQKp-0007pU-5r for ltru@megatron.ietf.org; Fri, 18 Mar 2005 17:52:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18471 for ; Fri, 18 Mar 2005 17:52:47 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQPL-0007Zw-Kt for ltru@ietf.org; Fri, 18 Mar 2005 17:57:32 -0500 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCQKm-0002Mc-00 for ltru@ietf.org; Fri, 18 Mar 2005 14:52:48 -0800 Message-ID: <003201c52c0d$49bc4780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050314001938.PAYD5424.mta6.adelphia.net@megatron.ietf.org> <002701c52833$a99cdd00$030aa8c0@DEWELL> <6.1.2.0.2.20050314024326.03f4fd20@mail.jefsey.com> <006201c52843$6b79ee40$030aa8c0@DEWELL> <6.1.2.0.2.20050314120015.03fe3cf0@mail.jefsey.com> <42364EDB.197@xyzzy.claranet.de> <6.1.2.0.2.20050315102933.03405df0@mail.jefsey.com> <42382C1F.762A@freenet.de> <6.1.2.0.2.20050316144451.044824d0@mail.jefsey.com> <42390A9E.9DA@xyzzy.claranet.de> <004801c52b81$a7ac7540$7f1afea9@oemcomputer> <6.1.2.0.2.20050318114546.035deeb0@mail.jefsey.com> Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags) Date: Fri, 18 Mar 2005 14:53:22 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Hi - (Co-chair hat mostly on) > Return-Path: > Message-Id: <6.1.2.0.2.20050318114546.035deeb0@mail.jefsey.com> > X-Sender: jefsey+jefsey.com@mail.jefsey.com > X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 > Date: Fri, 18 Mar 2005 12:13:50 +0100 > To: "Randy Presuhn" > From: "JFC (Jefsey) Morfin" > Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags) > Cc: "LTRU Working Group" PLEASE don't CC people when you know they are subscribed to the WG mailing list. We get too much email as it is. This comment is directed at *several* active participants on this list, not just JFC. ... > Dont' you agree that our job is to discuss an answer to a charter which > only assigns us to define the "structure of the IANA registry"? An > XML/ASN.1 structure. No. This is not the time to discuss changes to the charter. After the WG has completed its work, we can go into the re-charter / shutdown discussion. > When IESG does that it is because they want to be very restrictive or not > to limit the scope of the debate. The latter has never been my experience in the IETF. The latter interpretation might be more defensible in the IRTF, but this is not the IRTF. > My reading is the second one due to the > charter last paragraph which implies that we have to revamp of the review > process. I do not follow your reasoning. Are we reading the same document? The last paragraph of the charter states: | This working group will not take over the existing review function of | the ietf-languages list. The ietf-languages list will continue to | review tags according to RFC 3066 until the first document produced by | the WG is approved by the IESG for publication as an RFC. Then it will | review according to whatever procedures the first document specifies. This paragraph limits the scope of the WG's activity and discussion. I do not see how it can be interpreted as supporting the claim that the IESG did not want to limit the scope of the debate. > Many other important questions are not listed. Of course. Many important issues are out of scope for this WG. E.g.: Why did my forsythias bloom so late this year, while my apple trees bloomed early? > How to define the technical role of the IANA in area? As others have explained, IANA does the clerical work. > Will it be a repository, a clearinghouse, a registry. This working group is called "Language Tag Registry Update", so I guess "registry" would be a safe bet. :-) > Will it act as only a web pages, as a > "whatidiom" web service, as an FTP server? Out of scope. > How is it to be organized? What > is the contingency plan if it changes (this has to do with the adressing of > the bases which can be hard coded in millions of programs), the NIC changed > a few time since it was created. etc. Although this is out of scope, you might benefit from reading http://www.ietf.org/internet-drafts/draft-ietf-grow-embed-addr-05.txt > The first question to consider is what is this structure in that registry > going to do for who. There are three classes of people involved: > > - those who manage the structure - IANA with an important backlog (if Frank > is correct): question is why? How can our solution help? And there are many > technical solutions to that I am surprised no one considers. Out of scope. > - those who fill the data into the structure (among who is Frank, with > seemingly some feelings and misunderstandings). It is important to > determine the procedure, the guidance, etc. soi they feel at ease and > motivated. Some are voluntaries, some are employees of organizations with > social, cultural, religious or commercial interests, some are civil > servants. Some are linguists, some are network people. We need to keep a > balance in the best common interest. Frank is in that sense a good > representative of possible feelings (good or bad) we must take into > account. The *procedures* for registration are at the heart of our charter. Although the usability of the procedures we define is important to consider, the mix of people who ultimately make use of the procedures is not our concern. The experience of those who have used the existing procedures should be our guide here, in my opinion. > Another aspect is the role of the ietf-language list and of its > procedures which is depend on all of this. The charter is crystal clear: | The ietf-languages list will continue to | review tags according to RFC 3066 until the first document produced by | the WG is approved by the IESG for publication as an RFC. Then it will | review according to whatever procedures the first document specifies. > - those who will use it. I represent some of them. Participation in the IETF is by *individuals*, not representatives. > All together we need something which will work. Agreed. > jfc > > > ===================================================== > For your convenience: ... Annoyingly long signature deleted. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 18:04:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20175; Fri, 18 Mar 2005 18:04:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQau-0008F3-Jr; Fri, 18 Mar 2005 18:09:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQU0-0001rb-AN; Fri, 18 Mar 2005 18:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQTy-0001rO-Uk for ltru@megatron.ietf.org; Fri, 18 Mar 2005 18:02:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19865 for ; Fri, 18 Mar 2005 18:02:15 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQYW-00088J-3Y for ltru@ietf.org; Fri, 18 Mar 2005 18:07:00 -0500 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCQTx-0004sH-00 for ltru@ietf.org; Fri, 18 Mar 2005 15:02:17 -0800 Message-ID: <004501c52c0e$9ceeff00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Normative vs Informative references Date: Fri, 18 Mar 2005 15:02:51 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi - > From: "McDonald, Ira" > To: "'Addison Phillips'" ; "Randy Presuhn" ; > Sent: Friday, March 18, 2005 2:06 PM > Subject: RE: [Ltru] Normative vs Informative references > > Hi, > > I would suggest that you add to your 'Security Considerations' > section an informative reference to RFC 3552 / BCP 72 > "Guidelines for Writing RFC Text on Security Considerations". > > So revise text from: > > The evaluation of the exact magnitude of the threat, and any possible > countermeasures, is left to each application protocol. > > to: > > The evaluation of the exact magnitude of the threat, and any possible > countermeasures, is left to each application protocol (see [RFC3552] > for best practice guidance on security threats and defenses). ... As a technical contributor, I'd suggest making the citation in terms of the BCP number. Thus: | The evaluation of the exact magnitude of the threat, and any possible | countermeasures, is left to each application protocol (see BCP 72, | RFC 3552 [RFC3552] for best current practice guidance on security | threats and defenses). The motivation behind BCP and STD numbers is twofold: to be able to refer to multi-document sets, and, important in this case, to refer to whatever RFC(s) hold the current version of a specification. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 18:13:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21520; Fri, 18 Mar 2005 18:13:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQjs-000095-8z; Fri, 18 Mar 2005 18:18:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQee-0004dX-9K; Fri, 18 Mar 2005 18:13:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQec-0004dO-Bh for ltru@megatron.ietf.org; Fri, 18 Mar 2005 18:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21410 for ; Fri, 18 Mar 2005 18:13:15 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQj8-0008WJ-HP for ltru@ietf.org; Fri, 18 Mar 2005 18:17:59 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 15:13:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Normative vs Informative references Date: Fri, 18 Mar 2005 15:13:06 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EF45@irvmbxw01.quest.com> Thread-Topic: [Ltru] Normative vs Informative references Thread-Index: AcUsDtzwfjuIgw2CTsiIZj5DuJ2nIQAAP4XQ From: "Addison Phillips" To: X-OriginalArrivalTime: 18 Mar 2005 23:13:06.0044 (UTC) FILETIME=[0AB1A3C0:01C52C10] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable I changed the text as noted below (including the BCP number). =20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: vendredi 18 mars 2005 15:03 > To: ltru@ietf.org > Subject: Re: [Ltru] Normative vs Informative references >=20 > Hi - >=20 > > From: "McDonald, Ira" > > To: "'Addison Phillips'" ; "Randy = Presuhn" > ; > > Sent: Friday, March 18, 2005 2:06 PM > > Subject: RE: [Ltru] Normative vs Informative references > > >=20 > > Hi, > > > > I would suggest that you add to your 'Security Considerations' > > section an informative reference to RFC 3552 / BCP 72 > > "Guidelines for Writing RFC Text on Security Considerations". > > > > So revise text from: > > > > The evaluation of the exact magnitude of the threat, and any = possible > > countermeasures, is left to each application protocol. > > > > to: > > > > The evaluation of the exact magnitude of the threat, and any = possible > > countermeasures, is left to each application protocol (see [RFC3552] > > for best practice guidance on security threats and defenses). > ... >=20 > As a technical contributor, I'd suggest making the citation in terms = of > the BCP number. Thus: >=20 > | The evaluation of the exact magnitude of the threat, and any = possible > | countermeasures, is left to each application protocol (see BCP 72, > | RFC 3552 [RFC3552] for best current practice guidance on security > | threats and defenses). >=20 > The motivation behind BCP and STD numbers is twofold: to be able to > refer to multi-document sets, and, important in this case, to refer to > whatever RFC(s) hold the current version of a specification. >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 20:52:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04631; Fri, 18 Mar 2005 20:52:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCTDf-0006QG-Kp; Fri, 18 Mar 2005 20:57:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCT7u-0000sW-T8; Fri, 18 Mar 2005 20:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCT7t-0000s9-7S for ltru@megatron.ietf.org; Fri, 18 Mar 2005 20:51:41 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04126 for ; Fri, 18 Mar 2005 20:51:38 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DCT68-0005XS-1r for ltru@lists.ietf.org; Sat, 19 Mar 2005 02:49:52 +0100 Received: from 62.80.58.7 ([62.80.58.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2005 02:49:52 +0100 Received: from nobody by 62.80.58.7 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2005 02:49:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 19 Mar 2005 02:50:13 +0100 Organization: Lines: 27 Message-ID: <423B8554.4F7E@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.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: 62.80.58.7 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Normative vs Informative references X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > The normative references consist of: [...] > ISO 3166:1988 I'd prefer a newer edition, maybe we want 3166-3 later as a source for canonical values where UN M.49 doesn't help (like DDDE, YDYE, etc.) And their public Web site corresponds to their 5th edition. > RFC 1766 (mostly for historical reasons, could be > informative) Yes, informative, maybe the same for RfC 3066 as John said. As long as you stick to "obsoletes 3066" that's no problem. > RFC 2860 (defined IANA) That's an informational RfC with the MoU between the IETF and ICANN about IANA, not what I'd consider as "normative". Your BCP 11 (RfC 2028) reference is IMHO good enough to define IANA, if you replace IANA [17] => 2860 by IANA [10] => BCP 11 in 2.2. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 21:01:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06227; Fri, 18 Mar 2005 21:01:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCTM8-00074H-Ur; Fri, 18 Mar 2005 21:06:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCTH9-0007lQ-V7; Fri, 18 Mar 2005 21:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCTH8-0007lL-KZ for ltru@megatron.ietf.org; Fri, 18 Mar 2005 21:01:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06158 for ; Fri, 18 Mar 2005 21:01:12 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCTLg-0006xC-BK for ltru@ietf.org; Fri, 18 Mar 2005 21:05:57 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 18:01:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Normative vs Informative references Date: Fri, 18 Mar 2005 18:01:01 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EF91@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Normative vs Informative references Thread-Index: AcUsJl7UEZtmgtrCQnKkvOIBYg/mcwAAHZlQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 19 Mar 2005 02:01:00.0386 (UTC) FILETIME=[7F783C20:01C52C27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable If we end up wanting ISO 3166-3, we should have a separate reference to = that part.=20 I see that there is an ISO 3166-1:1997. I'll update the reference to use = that (which appears to be most recent). The RFC 2860 reference I inherited, I think. I only glanced at the text = where it is referenced to see if it "looked normative". Your suggestion = sounds like a better choice. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: vendredi 18 mars 2005 17:50 > To: ltru@ietf.org > Subject: [Ltru] Re: Normative vs Informative references >=20 > Addison Phillips wrote: >=20 > > The normative references consist of: >=20 > [...] > > ISO 3166:1988 >=20 > I'd prefer a newer edition, maybe we want 3166-3 later as a > source for canonical values where UN M.49 doesn't help (like > DDDE, YDYE, etc.) And their public Web site corresponds to > their 5th edition. >=20 > > RFC 1766 (mostly for historical reasons, could be > > informative) >=20 > Yes, informative, maybe the same for RfC 3066 as John said. > As long as you stick to "obsoletes 3066" that's no problem. >=20 > > RFC 2860 (defined IANA) >=20 > That's an informational RfC with the MoU between the IETF and > ICANN about IANA, not what I'd consider as "normative". Your > BCP 11 (RfC 2028) reference is IMHO good enough to define IANA, > if you replace IANA [17] =3D> 2860 by IANA [10] =3D> BCP 11 in 2.2. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 18 21:14:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07530; Fri, 18 Mar 2005 21:14:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCTYk-0007W2-OJ; Fri, 18 Mar 2005 21:19:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCTTB-0003J9-Sx; Fri, 18 Mar 2005 21:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCTT9-0003J1-Sk for ltru@megatron.ietf.org; Fri, 18 Mar 2005 21:13:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07464 for ; Fri, 18 Mar 2005 21:13:37 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCTXh-0007V3-DA for ltru@ietf.org; Fri, 18 Mar 2005 21:18:22 -0500 Received: from h-64-105-136-105.snvacaid.dynamic.covad.net ([64.105.136.105] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCTT6-0003zG-00 for ltru@ietf.org; Fri, 18 Mar 2005 18:13:36 -0800 Message-ID: <000801c52c29$572d6040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.com> <423B8554.4F7E@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Normative vs Informative references Date: Fri, 18 Mar 2005 18:14:11 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - As a contributor... > From: "Frank Ellermann" > To: > Sent: Friday, March 18, 2005 5:50 PM > Subject: [Ltru] Re: Normative vs Informative references ... > > RFC 2860 (defined IANA) > > That's an informational RfC with the MoU between the IETF and > ICANN about IANA, not what I'd consider as "normative". Your > BCP 11 (RfC 2028) reference is IMHO good enough to define IANA, > if you replace IANA [17] => 2860 by IANA [10] => BCP 11 in 2.2. ... We don't need to say very much *about* IANA. It's understood to the point of being one of those few well-known acronyms (like IP) that don't need to be expanded on first use. After all, an "IANA Considerations" section is required for any internet draft needing IESG approval to become an RFC. For details, see http://www.ietf.org/ID-Checklist.html section 2.2 (7). Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 01:24:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25699; Sat, 19 Mar 2005 01:24:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCXSk-0007lX-Ci; Sat, 19 Mar 2005 01:29:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCXMw-0004V7-G6; Sat, 19 Mar 2005 01:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCXMu-0004Uz-1s for ltru@megatron.ietf.org; Sat, 19 Mar 2005 01:23:28 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25631 for ; Sat, 19 Mar 2005 01:23:26 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DCXL4-000300-N9 for ltru@lists.ietf.org; Sat, 19 Mar 2005 07:21:34 +0100 Received: from 62.80.58.7 ([62.80.58.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2005 07:21:34 +0100 Received: from nobody by 62.80.58.7 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2005 07:21:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 19 Mar 2005 07:21:53 +0100 Organization: Lines: 23 Message-ID: <423BC501.77E0@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AA9EDEC@irvmbxw01.quest.com> <423B8554.4F7E@xyzzy.claranet.de> <000801c52c29$572d6040$7f1afea9@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: 62.80.58.7 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Normative vs Informative references X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > We don't need to say very much *about* IANA. Sure, but IFF we'd want it, then BCP 11 already used elsewhere as reference also explains IANA and IESG. I've checked what similar BCPs do (charsets, headers, URNs), most mention 2026, one mentions 2028, none has 2860. > It's understood to the point of being one of those few > well-known acronyms (like IP) that don't need to be expanded > on first use. We should create en-Latn-US-ietf as show case. Of course it's fine to say IANA without reference. Only IANA [17] could be a trap if the IANA MoU in [17] is "normative" and modified later. > an "IANA Considerations" section is required And IANA probably knows what it is without a normative 2860 ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 09:03:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22293; Sat, 19 Mar 2005 09:03:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCecb-0000wS-9r; Sat, 19 Mar 2005 09:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCeX9-0004rC-HF; Sat, 19 Mar 2005 09:02:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCeX7-0004r3-Vf for ltru@megatron.ietf.org; Sat, 19 Mar 2005 09:02:30 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22217 for ; Sat, 19 Mar 2005 09:02:27 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DCeVA-00072S-U9 for ltru@lists.ietf.org; Sat, 19 Mar 2005 15:00:28 +0100 Received: from 62.80.58.7 ([62.80.58.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2005 15:00:28 +0100 Received: from nobody by 62.80.58.7 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2005 15:00:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 19 Mar 2005 14:56:50 +0100 Organization: Lines: 41 Message-ID: <423C2FA2.2B1B@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: 62.80.58.7 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, so far en-Latn-US-boont not matching en-boont is one of my standard examples why I have a problem with 3066bis as it is. This could be solved later by a smarter matching strategy. Or by subtags used in the order of their importance, something like en-boont-Latn-US would match en-boont with the normal RTL strategy. But it would require complex restrictions allowing to identify the class of some subtags independent of their position. Most probably that was discussed years ago before the first of the old drafts, and it simply doesn't work. So the last chance is smart matching. To be smart the matching algorithm needs some input. For variants this input could be the corresponding default language. If boont has a pointer to en, or if 1996 has a pointer to de, a smart matching algorithm could identify fr-1996 or sl-boont as "garbage" and stop any attempt to be smart. For laguages the registry could list a default script, with a "SHOULD NOT be used" somewhere in the draft. For de / en / fr that would be Latn, and the SHOULD NOT then reduces a dubious en-Latn-boont to en-boont. Or a de-Latn-1996 to de-1996. The smart matching algorithm knows this and reduces all kinds of en-Latn-* to en-* in a second matching attempt. It also knows that the US in any en-US-* is "only" a region code, so it could start a third pass with en-*. The longest match after up to three attempts (default script removed, region removed) wins. Then en-Latn-US-boont finally matches en-boont. And it would not match en-other-boont or en-other-US-boont with en-boont. For de-Latn-*-boont-* it would give up after the reduction to de-boont-* shows that it's not a known en-boont-*. So de-Latn-US-boot won't match de-boont, because boont is only registered for use with en. Does that make any sense ? If yes we need optional default scripts for languages, and maybe also default languages for all variants in the registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 13:02:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11113; Sat, 19 Mar 2005 13:02:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCiMb-0002rX-UQ; Sat, 19 Mar 2005 13:07:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCiGM-0005OZ-6c; Sat, 19 Mar 2005 13:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCiGL-0005OO-Jm for ltru@megatron.ietf.org; Sat, 19 Mar 2005 13:01:25 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11073 for ; Sat, 19 Mar 2005 13:01:22 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050319180053.JSVO5402.mta11.adelphia.net@DEWELL> for ; Sat, 19 Mar 2005 13:00:53 -0500 Message-ID: <004301c52cad$64af46a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050319170759.FMLU5424.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 19 Mar 2005 09:59:26 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 1.2 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Hi, so far en-Latn-US-boont not matching en-boont is one of my > standard examples why I have a problem with 3066bis as it is. > > This could be solved later by a smarter matching strategy. Or > by subtags used in the order of their importance, something > like en-boont-Latn-US would match en-boont with the normal RTL > strategy. Have you read the new draft on "Matching Language Identifiers"? It explains that the "default" matching algorithm is not the only possibility. > But it would require complex restrictions allowing to identify > the class of some subtags independent of their position. Most > probably that was discussed years ago before the first of the > old drafts, and it simply doesn't work. This is not correct. First, the registry draft sets out specific rules for the position and length of subtags, for the exact reason you state: so that parsers can identify the pieces algorithmically. It does work, and it's not all that complex. For instance, given a fictitious tag "pu-rud-Blaz-FU-scrog-f-vlad-x-druz", I can tell you exactly what each of the subtags "means" (that is, its "class"), even though none of them is assigned in the registry. The tag is well-formed but not valid. I can also tell you that the tags "a1" and "en-US-Fullerton" and "zh-CN-Hant" and "de-a-b-frank" are not valid, because one or more of the subtags breaks the rules or because something is wrong with the order or other syntax of the tag. Try it yourself. Send me any tag and I will tell you whether it's valid, well-formed, or neither. I promise to do it visually first, before running it through the validating parser I wrote for this purpose. :-) > So the last chance is smart matching. To be smart the matching > algorithm needs some input. For variants this input could be > the corresponding default language. If boont has a pointer to > en, or if 1996 has a pointer to de, a smart matching algorithm > could identify fr-1996 or sl-boont as "garbage" and stop any > attempt to be smart. Variant subtags already have a "recommended prefix," which is not restricted to language alone, although all the entries in the draft registry happen to be primary languages. Take a look at the entry for 'boont': variant | boont | Boontling | 2003-02-14 | | en The "en" at the end is the recommended prefix. This tells a process that "en-boont" is an example of using 'boont' for its intended purpose, while "sl-boont" is an example of abusing it. The registry draft allows you to write "sl-boont" but warns that "this is probably a poor choice" (Section 3.3). (N.B. Note the difference between "registry draft" and "draft registry." We need better terminology for this, don't we?) > For laguages the registry could list a default script, with a > "SHOULD NOT be used" somewhere in the draft. For de / en / fr > that would be Latn, and the SHOULD NOT then reduces a dubious > en-Latn-boont to en-boont. Or a de-Latn-1996 to de-1996. This is a more slippery slope, as I mentioned in my response on ietf-languages. Section 2.3 of the registry draft says: "Avoid using subtags that are not important for distinguishing content in an application. For example, including the script subtag in "en-Latn-US" is generally unnecessary, since nearly all English texts are written in the Latin script and it is generally not important to filter out those few that are not." This leaves it up to the generator to decide when a script tag is necessary and when it is not. This is a good thing. People and processes should tag content wisely. > The smart matching algorithm knows this and reduces all kinds > of en-Latn-* to en-* in a second matching attempt. It also > knows that the US in any en-US-* is "only" a region code, so > it could start a third pass with en-*. The longest match after > up to three attempts (default script removed, region removed) > wins. Then en-Latn-US-boont finally matches en-boont. I claim, as I think you are doing here, that a fully RFC 3066bis-aware matching algorithm should be able to take apart the entire tag (using the rules explained above, which again are not all that complex) and perform matching based on the pieces. Thus if you want to match "en-Latn-US-boont" with "en-boont", it is enough to disassemble both tags and observe that all the subtags in the second tag are also present in the first. If this is what you call a "match," then you have found one. Other needs might call for different kinds of "matching," and the matching draft accounts for this. > And it would not match en-other-boont or en-other-US-boont with > en-boont. I don't see why not. Nothing in the registry definition of 'boont' defines it as being specifically Latn or specifically US, although historically that is what Boontling was. If "en-Latn-US-boont" is a match for "en-boont", then so is "en-Ogam-MV-boont". > For de-Latn-*-boont-* it would give up after the > reduction to de-boont-* shows that it's not a known en-boont-*. Likewise, even though "de-*-boont" is silly, matching does not depend on considerations of silliness. John Cowan likes to point out that "nv-DK" is silly but perfectly valid. The same applies to combinations like the one you are describing. > So de-Latn-US-boot won't match de-boont, because boont is only > registered for use with en. Does that make any sense ? If yes > we need optional default scripts for languages, and maybe also > default languages for all variants in the registry. As stated, we already have recommended prefixes for variants, but they are not normative. And the project of determining default scripts for *all* languages (not just the 80% or 90% for which this task is easy) is not something that anyone on this list, or perhaps anywhere else, is qualified to tackle. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 13:20:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12445; Sat, 19 Mar 2005 13:20:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCidG-0003jT-U7; Sat, 19 Mar 2005 13:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCiY4-0000mR-EL; Sat, 19 Mar 2005 13:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCiY3-0000mM-Jw for ltru@megatron.ietf.org; Sat, 19 Mar 2005 13:19:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12410 for ; Sat, 19 Mar 2005 13:19:40 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCick-0003iQ-TL for ltru@ietf.org; Sat, 19 Mar 2005 13:24:35 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2JIJN5u006448; Sat, 19 Mar 2005 13:19:24 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 19 Mar 2005 13:19:28 -0500 Date: Sat, 19 Mar 2005 13:19:27 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Preparations for smart matching Message-ID: <20050319181927.GB26179@skunk.reutershealth.com> References: <423C2FA2.2B1B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423C2FA2.2B1B@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Frank Ellermann scripsit: > Hi, so far en-Latn-US-boont not matching en-boont is one of my > standard examples why I have a problem with 3066bis as it is. The real trouble is with en-boont, which is not even remotely mutually intelligible with other kinds of en; it really isn't a "variety" in the usual sense. In an RFC 3066bis regime, I would probably press for it to be registered as simply boont. (This particular argument probably makes more sense for en, which is not really a very variable language as languages go.) > But it would require complex restrictions allowing to identify > the class of some subtags independent of their position. Most > probably that was discussed years ago before the first of the > old drafts, and it simply doesn't work. In fact it does work, provided that the algorithm keeps around a short list of exceptions (much less than the whole registry). Other than the exceptions, one can identify a tag's class knowing only if it is initial or non-initial, thus: 2-letter initial: ISO 639-1 language 3-letter initial: ISO 639-2 language, may also be an ISO 639-3 language in RFC 3066ter 5-or-more-letters initial: currently not allowed, will be a language in RFC 3066bis 2-letter non-initial: ISO 3166-1 country 3-letter non-initial: currently not allowed, will be an ISO 639-3 language in RFC 3066ter 4-letter non-initial: ISO 15924 script 3-digit non-initial: UN M.49 country anything else non-initial: variety Note that ISO 639-2 and ISO 639-3 language codes are compatible, so one does not need to determine (in an RFC 3066ter regime) which is which. > So the last chance is smart matching. I think it will be straightforward to design an algorithm that does matching on the above facts, without having to worry about what-goes-with-what rules. (Indeed, if another language turned out to have reformed its spelling in 1996, it would make sense to reuse the variety tag "1996" for it.) -- John Cowan http://www.ccil.org/~cowan "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 13:35:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13303; Sat, 19 Mar 2005 13:35:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCis2-0004NA-M0; Sat, 19 Mar 2005 13:40:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCimK-0003Ee-Qn; Sat, 19 Mar 2005 13:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCimJ-0003EZ-BD for ltru@megatron.ietf.org; Sat, 19 Mar 2005 13:34:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13212 for ; Sat, 19 Mar 2005 13:34:24 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCiqz-0004GW-V1 for ltru@ietf.org; Sat, 19 Mar 2005 13:39:19 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2JIYGxo006563; Sat, 19 Mar 2005 13:34:16 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 19 Mar 2005 13:34:32 -0500 Date: Sat, 19 Mar 2005 13:34:31 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Preparations for smart matching Message-ID: <20050319183431.GE26179@skunk.reutershealth.com> References: <423C2FA2.2B1B@xyzzy.claranet.de> <20050319181927.GB26179@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050319181927.GB26179@skunk.reutershealth.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Scripsi: > In fact it does work, provided that the algorithm keeps around a short list > of exceptions (much less than the whole registry). Other than the > exceptions, one can identify a tag's class knowing only if it is initial > or non-initial, thus: I meant to add here that we do not need to match language-ranges lacking an initial subtag; a range like *-Latn wouldn't represent any Real World requirement. -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he jcowan@reutershealth.com that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 13:41:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13713; Sat, 19 Mar 2005 13:41:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCiyD-0004ea-Ud; Sat, 19 Mar 2005 13:46:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCisb-0004bH-TE; Sat, 19 Mar 2005 13:40:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCisa-0004b8-1U for ltru@megatron.ietf.org; Sat, 19 Mar 2005 13:40:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13659 for ; Sat, 19 Mar 2005 13:40:52 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCixG-0004bf-Eo for ltru@ietf.org; Sat, 19 Mar 2005 13:45:47 -0500 Received: from Lugh (83-70-47-245.b-ras1.prp.dublin.eircom.net [83.70.47.245]) by postie2.hosting365.ie (Postfix) with ESMTP id 398D3214EFD63 for ; Sat, 19 Mar 2005 18:40:39 +0000 (GMT) From: "Jon Hanna" To: Subject: RE: [Ltru] Preparations for smart matching Date: Sat, 19 Mar 2005 18:42:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050319183431.GE26179@skunk.reutershealth.com> Thread-Index: AcUssm6F7tvR7aBGSeK3uHrsvP15fwAANwdA Message-Id: <20050319184039.398D3214EFD63@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > I meant to add here that we do not need to match > language-ranges lacking > an initial subtag; a range like *-Latn wouldn't represent any Real > World requirement. There are no real world systems capable of dealing with Latin text in any language but not with all scripts? Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 13:49:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14044; Sat, 19 Mar 2005 13:49:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCj5B-0004us-Sk; Sat, 19 Mar 2005 13:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCj00-0005nw-CV; Sat, 19 Mar 2005 13:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCizz-0005nr-3Y for ltru@megatron.ietf.org; Sat, 19 Mar 2005 13:48:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13999 for ; Sat, 19 Mar 2005 13:48:31 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCj4f-0004uR-Dp for ltru@ietf.org; Sat, 19 Mar 2005 13:53:26 -0500 Received: from h-68-164-242-42.snvacaid.dynamic.covad.net ([68.164.242.42] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCizv-0001NO-00 for ltru@ietf.org; Sat, 19 Mar 2005 10:48:31 -0800 Message-ID: <003e01c52cb4$54b1c8c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050319170759.FMLU5424.mta6.adelphia.net@megatron.ietf.org> <004301c52cad$64af46a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Preparations for smart matching Date: Sat, 19 Mar 2005 10:48:10 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, March 19, 2005 9:59 AM > Subject: [Ltru] Re: Preparations for smart matching ... > Have you read the new draft on "Matching Language Identifiers"? It > explains that the "default" matching algorithm is not the only > possibility. ... Has the i-d been posted? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 14:37:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16198; Sat, 19 Mar 2005 14:37:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCjqT-0006vz-2G; Sat, 19 Mar 2005 14:42:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCjkp-0005PJ-38; Sat, 19 Mar 2005 14:36:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCjkn-0005PE-Q1 for ltru@megatron.ietf.org; Sat, 19 Mar 2005 14:36:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16170 for ; Sat, 19 Mar 2005 14:36:56 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCjpU-0006qP-Ud for ltru@ietf.org; Sat, 19 Mar 2005 14:41:50 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2JJajxt006977; Sat, 19 Mar 2005 14:36:45 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 19 Mar 2005 14:36:47 -0500 Date: Sat, 19 Mar 2005 14:36:47 -0500 From: John Cowan To: Jon Hanna Subject: Re: [Ltru] Preparations for smart matching Message-ID: <20050319193647.GG26179@skunk.reutershealth.com> References: <20050319183431.GE26179@skunk.reutershealth.com> <20050319184039.398D3214EFD63@postie2.hosting365.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050319184039.398D3214EFD63@postie2.hosting365.ie> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Jon Hanna scripsit: > There are no real world systems capable of dealing with Latin text in any > language but not with all scripts? Fonts, maybe, but fonts don't care about language one way or another. The Latn subset used by en-Latn isn't the one used by ie-Latn, e.g. -- What asininity could I have uttered John Cowan that they applaud me thus? http://www.reutershealth.com --Phocion, Greek orator http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 14:39:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16263; Sat, 19 Mar 2005 14:39:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCjsO-0006x8-9K; Sat, 19 Mar 2005 14:44:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCjnR-0005pb-Ay; Sat, 19 Mar 2005 14:39:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCjnQ-0005pW-GI for ltru@megatron.ietf.org; Sat, 19 Mar 2005 14:39:40 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16241 for ; Sat, 19 Mar 2005 14:39:38 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050319193906.MRNT5402.mta11.adelphia.net@DEWELL> for ; Sat, 19 Mar 2005 14:39:06 -0500 Message-ID: <007d01c52cbb$10e24d20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 19 Mar 2005 11:37:19 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >> Have you read the new draft on "Matching Language Identifiers"? It >> explains that the "default" matching algorithm is not the only >> possibility. > ... > > Has the i-d been posted? No, sorry. My mistake. There is a document at http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html, but as such it is completely unofficial. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 15:33:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20348; Sat, 19 Mar 2005 15:33:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCkhx-0000nn-9s; Sat, 19 Mar 2005 15:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCkYi-0005Ft-Sq; Sat, 19 Mar 2005 15:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCkYh-0005Fn-6C for ltru@megatron.ietf.org; Sat, 19 Mar 2005 15:28:31 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20174 for ; Sat, 19 Mar 2005 15:28:28 -0500 (EST) Received: from lns-p19-1-idf-82-251-128-48.adsl.proxad.net ([82.251.128.48] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCkYf-0003V0-Bh for ltru@lists.ietf.org; Sat, 19 Mar 2005 12:28:29 -0800 Message-Id: <6.1.2.0.2.20050319211615.030e33d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 19 Mar 2005 21:28:24 +0100 To: "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AA9EBF4@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AA9EBF4@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On 17:42 18/03/2005, Addison Phillips said: > > But I need > > first to review the draft (I said I will do it early next week). > >You send us all this without having actually read the draft? I do not understand how I must take this? If you read me, you know I am only interested in correcting the flaws of RFC 3066 your new use will highlight. I trust you for your own needs. I wish I could only have to go into detail into your final draft to make sure all what would harm us/others has been removed. jfc ====================================================== Standardizing Tags for the Identification of Languages should not be a way to standardize languages and to unify the world under a dominant culture. ====================================================== For your convenience: RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066 Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ====================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ====================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ====================================================== It seems that what works for countries and ISO 3166 since 1978, should apply to languages and to ISO 693. ====================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 16:10:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22179; Sat, 19 Mar 2005 16:10:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DClIW-0002WR-AF; Sat, 19 Mar 2005 16:15:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DClD0-0003Mt-LA; Sat, 19 Mar 2005 16:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DClCy-0003MZ-RB for ltru@megatron.ietf.org; Sat, 19 Mar 2005 16:10:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22104 for ; Sat, 19 Mar 2005 16:10:04 -0500 (EST) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DClHe-0002RG-Ha for ltru@ietf.org; Sat, 19 Mar 2005 16:14:59 -0500 Received: from h-68-164-242-42.snvacaid.dynamic.covad.net ([68.164.242.42] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DClCt-00028r-00 for ltru@ietf.org; Sat, 19 Mar 2005 13:10:03 -0800 Message-ID: <000c01c52cc8$1aaaa700$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AA9EBF4@irvmbxw01.quest.com> <6.1.2.0.2.20050319211615.030e33d0@mail.jefsey.com> Subject: Re: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no Date: Sat, 19 Mar 2005 13:10:39 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi - (Co-chair hat ON) > From: "JFC (Jefsey) Morfin" > To: "LTRU Working Group" > Sent: Saturday, March 19, 2005 12:28 PM > Subject: RE: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no > > On 17:42 18/03/2005, Addison Phillips said: > > > But I need > > > first to review the draft (I said I will do it early next week). > > > >You send us all this without having actually read the draft? > > I do not understand how I must take this? IETF working group participants are strongly encouraged to read and comment on the working group's drafts. Making comments without having read the document under discussion is likely to waste time and energy. All should take to heart advice in section 5.3 of the Tao update http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt The most important thing that everyone (newcomers and seasoned experts) should do before coming to a face-to-face meeting is to read the Internet Drafts and RFCs beforehand. WG meetings are explicitly not for education: they are for developing the group's documents. Even if you do not plan to say anything in the meeting, you should read the group's documents before attending so you can understand what is being said. This isn't just true of face-to-face meetings; it's true of WG mailing list discussions as well. Prefacing a statement with "I haven't read the drafts, but..." is a sure-fire way to ensure that anything you write will be taken cum grano salis, if not ignored. > If you read me, you know I am only interested in correcting the flaws of > RFC 3066 your new use will highlight. I trust you for your own needs. I > wish I could only have to go into detail into your final draft to make sure > all what would harm us/others has been removed. ... Waiting until last call to make comments is a good way to ensure that your comments are not addressed in the way you might like, particularly if they are at odds with the WG consensus in place at that time. So, and this goes for everyone, READ THE DRAFT! If there is material that you think needs to be added: please send suggested text. If there is material that you think needs to be deleted: identify the specific passages. If there is material that you think needs to be modified: please identify the text to be changed, and supply suggested replacement material for discussion. The time for discussing change proposals is NOW. (Co-chair hat OFF) Not ltru-specific, but of general interest to IETF WG participants: A quick read that some participants on this list might find helpful is http://www.ietf.org/internet-drafts/draft-eastlake-prominence-02.txt There's a lot of sound advice there, even for those not interested in prominence. Its author is looking for feedback, especially from those with experience outside the IETF. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 17:05:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26997; Sat, 19 Mar 2005 17:05:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCm9Z-00052n-IT; Sat, 19 Mar 2005 17:10:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCm4Q-0004Wc-0N; Sat, 19 Mar 2005 17:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCm4O-0004WP-HV for ltru@megatron.ietf.org; Sat, 19 Mar 2005 17:05:20 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26990 for ; Sat, 19 Mar 2005 17:05:17 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050319220448.PUAV12278.mta9.adelphia.net@DEWELL> for ; Sat, 19 Mar 2005 17:04:48 -0500 Message-ID: <009201c52ccf$5e9e1d00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 19 Mar 2005 14:02:39 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Populating the initial registry: Languages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Here is my first attempt to describe the process for populating the draft registry with initial records. This first installment deals only with the language records. Subsequent parts will deal with records for other types of subtags. When commenting on this description, please make it clear whether you are commenting on (a) the accuracy and completeness of the description itself or (b) whether you think the end results should be different. These are both good topics for discussion, but they should not be confused for one another. All records are assumed to follow the format described in Section 3.1. Date fields should be set to the date of creation of the record unless otherwise noted (there are no exceptions in this installment). The date record itself is trivial and is not discussed here. All descriptions are taken from the English name in the relevant standard, and are converted to ASCII by removing diacritical marks. Step 1: Current ISO 639 codes * Source: http://www.loc.gov/standards/iso639-2/ISO-639-2_values_8bits.txt * Format is vertical-bar-delimited text. * Fields are (1) alpha-3 bibliographic code, (2) alpha-3 terminologic code (if different from bibliographic), (3) alpha-2 code (if any), (4) English name, (5) French name. * For each entry, create a new language subtag, except for the entry with English name "Reserved for local use" which is handled specially as described in Step 3. * If the entry has an alpha-2 code (field 3), use it for the subtag; else use the alpha-3 terminologic code (field 2). Step 2: Deprecated ISO 639 codes * Source: http://www.loc.gov/standards/iso639-2/codechanges.html * Format is HTML table. * Fields are (1) alpha-2 code (if any), (2) unified alpha-3 code, (3) English name, (4) French name, (5) date of change, (6) type of change, (7) notes. Asterisks, hyphens, and other detritus in fields are ignored. * Read list from bottom to top. * For each entry of type "Add", confirm that a corresponding registry entry exists. (I think there is one language missing from the text file that is present on the change page; confirmation would be welcome.) * For each entry of type "CC" followed (or preceded) by a corresponding entry of type "Dep" (deprecated), confirm that a registry entry already exists for the "CC" entry. Create a new registry entry corresponding to the "Dep" entry, and assign a canonical value equivalent to the code in the "CC" entry. * For each entry of type "Dep" that does not have a corresponding "CC" entry, create a new registry entry, and assign a canonical value of "--" (two dashes). * For each entry of type "NC" (name change) or "NA" (variant name(s) added), confirm that the description of the subtag matches the "new" English name (converted to ASCII). Step 3: Private-use codes * ISO 639 codes in the range "qaa" through "qtz" are for private use. Create a single language subtag entry with value "qaa..qtz" and description "PRIVATE USE" (all caps). Step 4: Sorting (optional) * Separate the records with 2-letter subtags from those with 3-letter subtags. Include "qaa..qtz" with the 3-letter records. * Sort each group in ascending order by subtag. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 17:29:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27962; Sat, 19 Mar 2005 17:29:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCmW9-0005yj-0J; Sat, 19 Mar 2005 17:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCmRM-0008Qu-0p; Sat, 19 Mar 2005 17:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCmRL-0008Qm-5t for ltru@megatron.ietf.org; Sat, 19 Mar 2005 17:29:03 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27958 for ; Sat, 19 Mar 2005 17:29:00 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050319222831.QMCX12278.mta9.adelphia.net@DEWELL> for ; Sat, 19 Mar 2005 17:28:31 -0500 Message-ID: <009b01c52cd2$ab542560$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050319211144.SELB4900.mta8.adelphia.net@megatron.ietf.org> Date: Sat, 19 Mar 2005 14:26:16 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit John Cowan wrote: > In fact it does work, provided that the algorithm keeps around a short > list of exceptions (much less than the whole registry). Other than > the exceptions, one can identify a tag's class knowing only if it is > initial or non-initial, thus: > ... > anything else non-initial: variety Additionally, the singleton 'x' introduces a sequence of one or more private-use subtags until the end of the tag, while singletons other than 'x' introduce a sequence of one or more extension subtags until the next singleton. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 17:35:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28207; Sat, 19 Mar 2005 17:35:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCmc6-0006DZ-BX; Sat, 19 Mar 2005 17:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCmX9-0000qs-Sy; Sat, 19 Mar 2005 17:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCmX9-0000pk-8y for ltru@megatron.ietf.org; Sat, 19 Mar 2005 17:35:03 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28200 for ; Sat, 19 Mar 2005 17:35:00 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050319223431.NQTM4618.mta13.adelphia.net@DEWELL> for ; Sat, 19 Mar 2005 17:34:31 -0500 Message-ID: <00ab01c52cd3$817865c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 19 Mar 2005 14:32:16 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: follow-up of an exchange on ietf-languages@alvestrand.no X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > The ietf-languages mailing list is not the IANA list presented in the > RFC 3066. John Cowan explained on January 17 that the address ietf-languages@alvestrand.no points to the same mailing list as the one referenced in RFC 3066, ietf-languages@iana.org. They are the same list. Some participants post to the alvestrand.no address, others to the iana.org address. It makes no difference. Furthermore, the list is included on the page "IETF Non-WG Mailing Lists" located at https://datatracker.ietf.org/public/nwg_list.cgi. This page, in its own words, "attempts to list all the active, publicly visible lists that are considered to be related to the IETF, but are not the main list of any working group." Clearly the IETF considers ietf-languages to be a legitimate, IETF-related discussion list. I don't know what IANA thinks of it. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 17:48:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28787; Sat, 19 Mar 2005 17:48:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCmoq-0006iB-Jm; Sat, 19 Mar 2005 17:53:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCmjX-00033i-1y; Sat, 19 Mar 2005 17:47:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCmjV-00033d-NG for ltru@megatron.ietf.org; Sat, 19 Mar 2005 17:47:49 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28743 for ; Sat, 19 Mar 2005 17:47:46 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050319224718.OAIS4618.mta13.adelphia.net@DEWELL> for ; Sat, 19 Mar 2005 17:47:18 -0500 Message-ID: <00b401c52cd5$45a62620$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 19 Mar 2005 14:44:54 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Populating the initial registry: Languages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit First corrections: > Step 1: Current ISO 639 codes > ... > * If the entry has an alpha-2 code (field 3), use it for the subtag; > else use the alpha-3 terminologic code (field 2). Should be: * If the entry has an alpha-2 code (field 3), use it for the subtag; else if the entry has an alpha-3 terminologic code (field 2), use that; else use the alpha-3 bibliographic code (field 1). With the current ISO 639 list, the first "else" will always fall through to the second, because there are no codes with different T and B codes that do not also have an alpha-2 code. If we assume this situation will continue to hold true, this step can be collapsed to: * If the entry has an alpha-2 code (field 3), use it for the subtag; else use the alpha-3 bibliographic code (field 1). although that is technically not the same as the rule in Section 2.2.1. > Step 2: Deprecated ISO 639 codes > ... > * Fields are (1) alpha-2 code (if any), (2) unified alpha-3 code, (3) > English name, (4) French name, (5) date of change, (6) type of change, > (7) notes. Asterisks, hyphens, and other detritus in fields are > ignored. Asterisks and hyphens are ignored only in the code fields, not in the name field. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 18:24:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01634; Sat, 19 Mar 2005 18:24:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCnNW-0008BY-Hh; Sat, 19 Mar 2005 18:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCnIB-0000MH-OV; Sat, 19 Mar 2005 18:23:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCnIA-0000MC-3p for ltru@megatron.ietf.org; Sat, 19 Mar 2005 18:23:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01618 for ; Sat, 19 Mar 2005 18:23:35 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCnMu-0008Aj-8O for ltru@ietf.org; Sat, 19 Mar 2005 18:28:32 -0500 Received: from lns-p19-1-idf-82-251-128-48.adsl.proxad.net ([82.251.128.48] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCnI4-0006xY-OW; Sat, 19 Mar 2005 15:23:37 -0800 Message-Id: <6.1.2.0.2.20050320000543.047268c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 20 Mar 2005 00:06:49 +0100 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: follow-up of an exchange on ietf-languages@alvestrand.no In-Reply-To: <00ab01c52cd3$817865c0$030aa8c0@DEWELL> References: <00ab01c52cd3$817865c0$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 At 23:32 19/03/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > > The ietf-languages mailing list is not the IANA list presented in the > > RFC 3066. > I don't know what IANA thinks of it. So, I see we agree. Keep cool: no one knows. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 18:24:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01654; Sat, 19 Mar 2005 18:24:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCnNY-0008Bf-VP; Sat, 19 Mar 2005 18:29:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCnI7-0000M8-IK; Sat, 19 Mar 2005 18:23:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCnI5-0000M3-B8 for ltru@megatron.ietf.org; Sat, 19 Mar 2005 18:23:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01615 for ; Sat, 19 Mar 2005 18:23:30 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCnMp-0008Ae-8K for ltru@ietf.org; Sat, 19 Mar 2005 18:28:27 -0500 Received: from lns-p19-1-idf-82-251-128-48.adsl.proxad.net ([82.251.128.48] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCnI3-0006xY-7H; Sat, 19 Mar 2005 15:23:31 -0800 Message-Id: <6.1.2.0.2.20050319231958.0370be20@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 20 Mar 2005 00:23:26 +0100 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no In-Reply-To: <000c01c52cc8$1aaaa700$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0AA9EBF4@irvmbxw01.quest.com> <6.1.2.0.2.20050319211615.030e33d0@mail.jefsey.com> <000c01c52cc8$1aaaa700$7f1afea9@oemcomputer> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0250702432==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 --===============0250702432== Content-Type: multipart/alternative; boundary="=====================_72125661==.ALT" --=====================_72125661==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:10 19/03/2005, Randy Presuhn wrote: >Hi - > > On 17:42 18/03/2005, Addison Phillips said: > > > > But I need > > > > first to review the draft (I said I will do it early next week). > > > > > >You send us all this without having actually read the draft? > > > > I do not understand how I must take this? > >IETF working group participants are strongly encouraged to read and >comment on the working group's drafts. Dear Randy, shhhh...... this teasing starts being tiring and totally counter productive. I suggest you _read_ the exchange above. Obviously I read the draft ... and make it read! My question was precisely about the hurting supposition that I did not _read_ the draft when I said that I will _review_ it. I am surprised you add your own: the line you removed also added "I will go into details". I do not use to formally comment without having carefully studied the things. I have no intent to waste time in reviewing the draft and propose an alternative draft if Addison has modified it, considers others needs and stops hurting the rest of the planet. This being said I still have not all the feed-backs from the people I polled. I will also wait for the feed-backs from the WG. I only hope that we can reach a consensus. In case we have some misunderstanding between en-FR, en-UK and en-US: Review, v tr. * To look over, study, or examine again. * To consider retrospectively; look back on. * To examine with an eye to criticism or correction: reviewed the research findings. * To write or give a critical report on (a new work or performance, for example). * Law. To reexamine (an action or determination) judicially, especially in a higher court, in order to correct possible errors. * To subject to a formal inspection, especially a military inspection. v. intr. * To go over or restudy material: reviewing for a final exam. * To write critical reviews, especially for a newspaper or magazine. I observe that to date the debate of this WG only concerns minor editing while important structural points are at stake. But it seems that JFC teasing is a priority. If it pleases you .... but in the meanwhile it does not make the things to progress. Take care. jfc --=====================_72125661==.ALT Content-Type: text/html; charset="us-ascii" At 22:10 19/03/2005, Randy Presuhn wrote:
Hi -
> On 17:42 18/03/2005, Addison Phillips said:
> > > But I need
> > > first to review the draft (I said I will do it early next week).
> >
> >You send us all this without having actually read the draft?
>
> I do not understand how I must take this?

IETF working group participants are strongly encouraged to read and
comment on the working group's drafts.

Dear Randy,
shhhh...... this teasing starts being tiring and totally counter productive.
I suggest you  _read_ the exchange above. 
 
Obviously I read the draft ... and make it read! My question was precisely about the hurting supposition that I did not _read_ the draft when I said that I will _review_ it. I am surprised you add your own: the line you removed also added "I will go into details".

I do not use to formally comment without having carefully studied the things. I have no intent to waste time in reviewing the draft and propose an alternative draft if Addison has modified it, considers others needs and stops hurting the rest of the planet.

This being said I still have not all the feed-backs from the people I polled. I will also wait for the feed-backs from the WG. I only hope that we can reach a consensus.

In case we have some misunderstanding between en-FR, en-UK and en-US:

Review, v tr.
  1. To look over, study, or examine again.
  2. To consider retrospectively; look back on.
  3. To examine with an eye to criticism or correction: reviewed the research findings.
  4. To write or give a critical report on (a new work or performance, for example).
  5. Law. To reexamine (an action or determination) judicially, especially in a higher court, in order to correct possible errors.
  6. To subject to a formal inspection, especially a military inspection.
v. intr.
  1. To go over or restudy material: reviewing for a final exam.
  2. To write critical reviews, especially for a newspaper or magazine.
I observe that to date the debate of this WG only concerns minor editing while important structural points are at stake.
But it seems that JFC teasing is a priority. If it pleases you .... but in the meanwhile it does not make the things to progress.
Take care.
jfc

--=====================_72125661==.ALT-- --===============0250702432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0250702432==-- From ltru-bounces@ietf.org Sat Mar 19 18:46:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02769; Sat, 19 Mar 2005 18:46:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCnin-0000dI-3k; Sat, 19 Mar 2005 18:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCnd2-0004Ul-3f; Sat, 19 Mar 2005 18:45:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCncz-0004Ud-T3 for ltru@megatron.ietf.org; Sat, 19 Mar 2005 18:45:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02758 for ; Sat, 19 Mar 2005 18:45:06 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCnhj-0000cg-9l for ltru@ietf.org; Sat, 19 Mar 2005 18:50:04 -0500 Received: from lns-p19-1-idf-82-251-128-48.adsl.proxad.net ([82.251.128.48] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCncx-0003nG-AX; Sat, 19 Mar 2005 15:45:07 -0800 Message-Id: <6.1.2.0.2.20050320004226.036e6d20@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 20 Mar 2005 00:45:02 +0100 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Sorry for the typo: I say the "line you removed". Thank you to read "the line I removed". thx. jfc At 22:10 19/03/2005, JFC wrote: > ... the line you removed also added "I will go into details". _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 20:11:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07449; Sat, 19 Mar 2005 20:11:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCp33-0004H5-GY; Sat, 19 Mar 2005 20:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCoxI-0001xF-6n; Sat, 19 Mar 2005 20:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCoxG-0001x0-F2 for ltru@megatron.ietf.org; Sat, 19 Mar 2005 20:10:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07401 for ; Sat, 19 Mar 2005 20:10:06 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCp21-0004Ar-BA for ltru@ietf.org; Sat, 19 Mar 2005 20:15:05 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 19 Mar 2005 17:09:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] follow-up of an exchange on ietf-languages@alvestrand.no Date: Sat, 19 Mar 2005 17:09:57 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EFD4@irvmbxw01.quest.com> Thread-Topic: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no Thread-Index: AcUs2uGBrWCMsWS7TCKjtuK82JuGVQAB6igQ From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 20 Mar 2005 01:09:58.0127 (UTC) FILETIME=[88A257F0:01C52CE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Jefsey: Could you write a short, simple email with a list of these "important = structural issues"? Could you write a short, simple email that outlines exactly how you = would change 3066bis to address these issues? I was unable to discern these from your previous email(s). Perhaps, as a = despoiler of the planet, I am a sophomore and need things stated in = simple terms. Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: samedi 19 mars 2005 15:23 > To: Randy Presuhn; LTRU Working Group > Subject: Re: [Ltru] follow-up of an exchange on ietf- > languages@alvestrand.no >=20 > At 22:10 19/03/2005, Randy Presuhn wrote: >=20 >=20 > Hi - > > On 17:42 18/03/2005, Addison Phillips said: > > > > But I need > > > > first to review the draft (I said I will do it early next > week). > > > > > >You send us all this without having actually read the draft? > > > > I do not understand how I must take this? >=20 > IETF working group participants are strongly encouraged to read and > comment on the working group's drafts. >=20 >=20 > Dear Randy, > shhhh...... this teasing starts being tiring and totally counter > productive. > I suggest you _read_ the exchange above. >=20 > Obviously I read the draft ... and make it read! My question was = precisely > about the hurting supposition that I did not _read_ the draft when I = said > that I will _review_ it. I am surprised you add your own: the line you > removed also added "I will go into details". >=20 > I do not use to formally comment without having carefully studied the > things. I have no intent to waste time in reviewing the draft and = propose > an alternative draft if Addison has modified it, considers others = needs > and stops hurting the rest of the planet. >=20 > This being said I still have not all the feed-backs from the people I > polled. I will also wait for the feed-backs from the WG. I only hope = that > we can reach a consensus. >=20 > In case we have some misunderstanding between en-FR, en-UK and en-US: >=20 > Review, v tr. >=20 > 1. To look over, study, or examine again. > 2. To consider retrospectively; look back on. > 3. To examine with an eye to criticism or correction: reviewed the > research findings. > 4. To write or give a critical report on (a new work or performance, > for example). > 5. Law. To reexamine (an action or determination) judicially, > especially in a higher court, in order to correct possible errors. > 6. To subject to a formal inspection, especially a military = inspection. >=20 > v. intr. >=20 > 1. To go over or restudy material: reviewing for a final exam. > 2. To write critical reviews, especially for a newspaper or magazine. >=20 > I observe that to date the debate of this WG only concerns minor = editing > while important structural points are at stake. > But it seems that JFC teasing is a priority. If it pleases you .... = but in > the meanwhile it does not make the things to progress. > Take care. > jfc >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 20:29:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09055; Sat, 19 Mar 2005 20:29:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCpL9-00057I-Tx; Sat, 19 Mar 2005 20:34:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCpFt-0005BO-HC; Sat, 19 Mar 2005 20:29:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCpFs-0005BJ-RW for ltru@megatron.ietf.org; Sat, 19 Mar 2005 20:29:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09040 for ; Sat, 19 Mar 2005 20:29:23 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCpKd-00056j-2w for ltru@ietf.org; Sat, 19 Mar 2005 20:34:20 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 19 Mar 2005 17:29:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Preparations for smart matching Date: Sat, 19 Mar 2005 17:29:14 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AA9EFD5@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUsu4wADplydRBCS/+6Gykz/Pp6kAAMBHwA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 20 Mar 2005 01:29:14.0744 (UTC) FILETIME=[3A081780:01C52CEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1263655303==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 --===============1263655303== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCdzIGN1cnJlbnRseSAib2ZmaWNpYWwiIChidXQgbm90IHRoZSB3b3JrIG9mIHRoaXMgV0cp IGlzIHRoZSBwcmV2aW91cyBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdmVyc2lvbiBvZiB0aGF0IGRv Y3VtZW50Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1waGls bGlwcy1sYW5nbWF0Y2hpbmctMDAudHh0DQoNClRoZSAiZWRpdG9yJ3MgY29weSIgYXQgdGhlIGxp bmsgRG91ZyBsaXN0ZWQgYmVsb3cgaXMgbXVjaCBtb3JlIHVwLXRvLWRhdGUsIG9mIGNvdXJzZSwg YXMgaXQgaXMgYmVpbmcgcHJlcGFyZWQgZm9yIHN1Ym1pc3Npb24gYXMgdGhlIHN0YXJ0aW5nIHBv aW50IG9uIG1hdGNoaW5nLiBCb3RoIGRvY3VtZW50cyBtYWtlIHRoZSBwb2ludCB0aGF0IHRoZSBk ZWZhdWx0IG1hdGNoaW5nIHNjaGVtZSBpcyBub3QgdGhlIG9ubHkgb25lIHBvc3NpYmxlLg0KDQpB ZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBR dWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtp bmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlz IGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3Rz LmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiBzYW1lZGkgMTkg bWFycyAyMDA1IDExOjM3DQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogW0x0 cnVdIFJlOiBQcmVwYXJhdGlvbnMgZm9yIHNtYXJ0IG1hdGNoaW5nDQo+IA0KPiBSYW5keSBQcmVz dWhuIDxyYW5keSB1bmRlcnNjb3JlIHByZXN1aG4gYXQgbWluZHNwcmluZyBkb3QgY29tPiAgd3Jv dGU6DQo+IA0KPiA+PiBIYXZlIHlvdSByZWFkIHRoZSBuZXcgZHJhZnQgb24gIk1hdGNoaW5nIExh bmd1YWdlIElkZW50aWZpZXJzIj8gIEl0DQo+ID4+IGV4cGxhaW5zIHRoYXQgdGhlICJkZWZhdWx0 IiBtYXRjaGluZyBhbGdvcml0aG0gaXMgbm90IHRoZSBvbmx5DQo+ID4+IHBvc3NpYmlsaXR5Lg0K PiA+IC4uLg0KPiA+DQo+ID4gSGFzIHRoZSBpLWQgYmVlbiBwb3N0ZWQ/DQo+IA0KPiBObywgc29y cnkuICBNeSBtaXN0YWtlLiAgVGhlcmUgaXMgYSBkb2N1bWVudCBhdA0KPiBodHRwOi8vd3d3Lmlu dGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LW1hdGNoaW5nLTAwLmh0bWwsIGJ1dCBh cw0KPiBzdWNoIGl0IGlzIGNvbXBsZXRlbHkgdW5vZmZpY2lhbC4NCj4gDQo+IC1Eb3VnIEV3ZWxs DQo+ICBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gIGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQv fmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9y Zw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============1263655303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1263655303==-- From ltru-bounces@ietf.org Sat Mar 19 21:45:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13032; Sat, 19 Mar 2005 21:45:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCqWZ-0008BW-8c; Sat, 19 Mar 2005 21:50:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCqQz-0008CK-RM; Sat, 19 Mar 2005 21:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCqQy-0008CF-JD for ltru@megatron.ietf.org; Sat, 19 Mar 2005 21:44:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13004 for ; Sat, 19 Mar 2005 21:44:54 -0500 (EST) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCqVj-0008Au-DH for ltru@ietf.org; Sat, 19 Mar 2005 21:49:52 -0500 Received: from h-68-164-242-42.snvacaid.dynamic.covad.net ([68.164.242.42] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DCqQv-0007Vb-00 for ltru@ietf.org; Sat, 19 Mar 2005 18:44:53 -0800 Message-ID: <004a01c52cf6$df1b1c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AA9EBF4@irvmbxw01.quest.com> <6.1.2.0.2.20050319211615.030e33d0@mail.jefsey.com> <000c01c52cc8$1aaaa700$7f1afea9@oemcomputer> <6.1.2.0.2.20050319231958.0370be20@mail.jefsey.com> Subject: Re: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no Date: Sat, 19 Mar 2005 18:45:26 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi - > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Saturday, March 19, 2005 3:23 PM > Subject: Re: [Ltru] follow-up of an exchange on ietf-languages@alvestrand.no > > At 22:10 19/03/2005, Randy Presuhn wrote: > >Hi - > > > On 17:42 18/03/2005, Addison Phillips said: > > > > > But I need > > > > > first to review the draft (I said I will do it early next week). > > > > > > > >You send us all this without having actually read the draft? > > > > > > I do not understand how I must take this? > > > >IETF working group participants are strongly encouraged to read and > >comment on the working group's drafts. > > Dear Randy, > shhhh...... this teasing starts being tiring and totally counter productive. ... I'm not teasing. I'm deadly serious when I write that IETF working group participants are strongly encouraged to read and comment on the working group's drafts. We are here to get some work done. If you care to make relevant contributions to the effort, e.g. specific comments on the drafts, they would be welcome. Whining and antagonistic posturing are not. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 19 23:15:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18076; Sat, 19 Mar 2005 23:15:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCrvI-0003XG-Ie; Sat, 19 Mar 2005 23:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCrqI-000573-9q; Sat, 19 Mar 2005 23:15:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCrqG-00056x-2H for ltru@megatron.ietf.org; Sat, 19 Mar 2005 23:15:08 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18070 for ; Sat, 19 Mar 2005 23:15:04 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DCroH-0007NB-OP for ltru@lists.ietf.org; Sun, 20 Mar 2005 05:13:05 +0100 Received: from d253214.dialin.hansenet.de ([80.171.253.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Mar 2005 05:13:05 +0100 Received: from nobody by d253214.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Mar 2005 05:13:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 20 Mar 2005 05:09:11 +0100 Organization: Lines: 106 Message-ID: <423CF767.7FC8@xyzzy.claranet.de> References: <20050319170759.FMLU5424.mta6.adelphia.net@megatron.ietf.org> <004301c52cad$64af46a0$030aa8c0@DEWELL> 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: d253214.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Have you read the new draft on "Matching Language > Identifiers"? If you're talking about the split of dradt 9 into draft 10 and a separate draft with a matching strategy - not very carefully: I only saw that it's essentially the same as in draft 9. > It explains that the "default" matching algorithm is not the > only possibility. IIRC that's also the same as in draft 9 and earlier. > "pu-rud-Blaz-FU-scrog-f-vlad-x-druz", You promised that you won't use a parser if I find an example, where it isn't obvious, therefore I have to take this beast without looking in one of the drafts. Language pu, no script (assuming that rud is too short), no region (assuming that rud is too long), so the rest could be variants rud, Blaz, FU, scrog, f-vlad, and something private in x-druz. > I can also tell you that the tags "a1" and "en-US-Fullerton" > and "zh-CN-Hant" and "de-a-b-frank" are not valid That tells me that I got it wrong for FU in your first example. Looking into the ABNF, yes, I completely forgot the reserved "extlang", and FU is too short for a variant. Okay, that allows to identify all pieces in well-formed tags. > variant | boont | Boontling | 2003-02-14 | | en Another error on my side, I always thought that the last (6th) column is a comment and irrelevant for parsers. But it has a structure recomended_prefix "#" comment. Please ignore my stupid idea to get rid of all "#" in another article, the 6th column is not only a comment. Comments have nothing to do with the column, they are simply at the end of a row introduced by "#". So you always have a 6th colum, and for all variants it's the pointer to a language - as I wanted it, I only didn't see that you already have it. Could we rename "recommended_prefix" to "associated_tag", or something in this direction ? Then the 6th column of languages would be free for a pointer to a default script. At the moment the draft says: | The "recommended_prefix" field is empty, except where the | type is "variant" That could be changed to e.g. The "recommended_prefix" is generally empty. In the case of a "variant" it's often the recommended "language" prefix, but could be also a language-script, language-script-region, or language-region prefix. For the type "language" this field can be used to define a default "script" for the correspoding "laguage", and then the resulting tag or prefix language-sript is NOT RECOMMENDED. > (N.B. Note the difference between "registry draft" and > "draft registry." We need better terminology for this, don't > we?) As long as is the state of the art I don't care about the terminology. If you'll submit it as an I-D it would be the "draft registry". BTW, the initial mail header registry now got its own RfC 4021 - so that wasn't lost somewhere in limbo between the IESG and IANA. > Thus if you want to match "en-Latn-US-boont" with "en-boont", > it is enough to disassemble both tags and observe that all > the subtags in the second tag are also present in the first. That's IMFO not good enough. If a client offers en-boont and en-misc (script "misc"), and the server has en-misc-US-boont, then the client should try en-misc, but not en-boont. Because "misc" is probably very important, if it's not "Latn" as in the default for en. > If "en-Latn-US-boont" is a match for "en-boont", then so is > "en-Ogam-MV-boont". Unless you have en-Ogam, then you need to know the default script for en (which isn't Ogam). > the project of determining default scripts for *all* > languages (not just the 80% or 90% for which this task is > easy) is not something that anyone on this list, or perhaps > anywhere else, is qualified to tackle. *all* is not what I proposed. I'm only interested in the 80% where it's easy for humans, but not for parsers. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 14:04:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10050; Sun, 20 Mar 2005 14:04:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD5nO-00069J-9i; Sun, 20 Mar 2005 14:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD5hE-0007nI-2c; Sun, 20 Mar 2005 14:02:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD5hD-0007nD-FK for ltru@megatron.ietf.org; Sun, 20 Mar 2005 14:02:43 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10003 for ; Sun, 20 Mar 2005 14:02:41 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050320190209.EVUW7277.mta10.adelphia.net@DEWELL> for ; Sun, 20 Mar 2005 14:02:09 -0500 Message-ID: <010e01c52d7e$998226a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 20 Mar 2005 10:56:59 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> Have you read the new draft on "Matching Language >> Identifiers"? >> ... >> It explains that the "default" matching algorithm is not the >> only possibility. > > IIRC that's also the same as in draft 9 and earlier. Section 2.2.1 explains that the matching algorithm which involves truncating from the right is simply "the most common implementation," and Section 2.3 describes the possibility of choosing other algorithms. The point is that we don't have to make the grand decision for everyone of whether script, region, or variant is more important, and therefore should appear ahead of the others, just to get matching to work. >> "pu-rud-Blaz-FU-scrog-f-vlad-x-druz", (we seem to agree on this point) > So you always have a 6th colum, and for all variants it's the > pointer to a language - as I wanted it, I only didn't see that > you already have it. > > Could we rename "recommended_prefix" to "associated_tag", or > something in this direction ? Then the 6th column of languages > would be free for a pointer to a default script. I think you missed my point. Trying to determine the "default" script and perform matching based on this assessment is probably *not* a good idea for those languages that are customarily written in more than one script, and probably unnecessary for those that are not. If I make a request for Mongolian-language content, script unspecified, then I need to be prepared for the possibility that I will receive content in either the Mongolian or Cyrillic script (and maybe even Latin, since everything seems to get transliterated into Latin sooner or later). If I want to restrict the content to Cyrillic script, I need to specify "mn-Cyrl" instead of just "mn". Having my "mn" data limited to Mongolian script only, excluding the Cyrillic data, because the LTRU WG decided for me that Mongolian was the "default" script for the Mongolian language, is not a satisfactory option. Maybe I'm able to read both, and I really do want content in either one. If we decide for the user than "mn" is the same as "mn-Mong", then we make it impossible to form a request for "Mongolian, script unspecified." (And no, I do not suggest an additional syntactical construct like "mn-*" or "mn-{Mong, Cyrl}" to patch this defect.) In the opposite case, limiting "en" to mean "en-Latn" is probably an unnecessary layer. Yes, I know about Deseret and Shavian and the like, but the fact is that the overwhelming majority of English-language data is in the Latin script, and people who want English-language data in other scripts will probably ask for it specifically. Requests for "en" alone typically will not fill the user's box with useless (to him) Deseret and Shavian content, because there is so little of it. Adding this "default script" assumption to the matching logic for English accomplishes little. > At the moment the draft says: > > | The "recommended_prefix" field is empty, except where the > | type is "variant" > > That could be changed to e.g. > > The "recommended_prefix" is generally empty. In the case of > a "variant" it's often the recommended "language" prefix, but > could be also a language-script, language-script-region, or > language-region prefix. > > For the type "language" this field can be used to define a > default "script" for the correspoding "laguage", and then the > resulting tag or prefix language-sript is NOT RECOMMENDED. I really don't think this buys us much. Section 2.3, items 1 and 2 tell the user to avoid subtags that don't add information. I think that is sufficient. I'm not comfortable with explicitly recommending against "en-Latn" the way we do with "iw" or "und". > > (N.B. Note the difference between "registry draft" and > > "draft registry." We need better terminology for this, don't > > we?) > > As long as is > the state of the art I don't care about the terminology. If > you'll submit it as an I-D it would be the "draft registry". That's what I'm worried about. "Draft registry" implies that it's an I-D, which it's not, at least not at present. But it seems to be more than just a prototype. >> Thus if you want to match "en-Latn-US-boont" with "en-boont", >> it is enough to disassemble both tags and observe that all >> the subtags in the second tag are also present in the first. > > That's IMFO not good enough. If a client offers en-boont and > en-misc (script "misc"), and the server has en-misc-US-boont, > then the client should try en-misc, but not en-boont. > > Because "misc" is probably very important, if it's not "Latn" > as in the default for en. But "boont" may also be important, because most English is not Boontling. Variants are a catch-all category used for all kinds of things, anywhere from relatively minor orthographic variations ('1901' and '1996') to regional dialects ('boont' and 'scouse') to completely different languages ('guoyu' and 'xiang'). The presence of a variant subtag, in and of itself, really doesn't tell much about whether the tagger considered the variation to be the most important detail or the least. Boontling is cute and fun, but I'd really rather not use it as the metric by which important decisions about tagging and matching are made. >> If "en-Latn-US-boont" is a match for "en-boont", then so is >> "en-Ogam-MV-boont". > > Unless you have en-Ogam, then you need to know the default > script for en (which isn't Ogam). Suppose there were such a thing as Boontling written in Ogham. (I can't believe I just wrote that sentence.) Now if a user requests "en-boont", she may want this content anyway, even though it's in Ogham and not Latin script. Who are we to say she can't read Ogham? And if another user requests "en-Ogam", he may want this Boontling content as well. The proportion of English (any flavor) written in Ogham is likely to be so small that this may be just what he was looking for. My point is that this is not for us to dictate. >> the project of determining default scripts for *all* >> languages (not just the 80% or 90% for which this task is >> easy) is not something that anyone on this list, or perhaps >> anywhere else, is qualified to tackle. > > *all* is not what I proposed. I'm only interested in the 80% > where it's easy for humans, but not for parsers. I don't think most people will be satisfied with the result if we solve this problem for the obvious cases, but not the marginal ones. The nature of this group is to pay attention to the edge cases. Look how much attention we are paying to Boontling! -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 15:23:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17916; Sun, 20 Mar 2005 15:23:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD72V-0000Ff-H8; Sun, 20 Mar 2005 15:28:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD6wT-0001Kp-Dg; Sun, 20 Mar 2005 15:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD6wS-0001Kk-Mu for ltru@megatron.ietf.org; Sun, 20 Mar 2005 15:22:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17742 for ; Sun, 20 Mar 2005 15:22:30 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD71M-0000EC-Jw for ltru@ietf.org; Sun, 20 Mar 2005 15:27:37 -0500 Received: from h-68-165-7-158.snvacaid.dynamic.covad.net ([68.165.7.158] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DD6wN-0007A3-00 for ltru@ietf.org; Sun, 20 Mar 2005 12:22:27 -0800 Message-ID: <001c01c52d8a$a00a6620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Sun, 20 Mar 2005 12:23:05 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ltru] RFC 3934 reminder X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi - When I compare http://www.ietf.org/mail-archive/web/ltru/current/msg00126.html to http://www.ietf.org/mail-archive/web/ltru/current/msg00128.html, it's clear that as co-chair I need to remind folks that taking quotes out of context disrupts the WG process. RFC 3934 gives WG chairs specific authority in dealing with disruptive elements. Please don't put us in the position of having to use that authority. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 16:52:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25964; Sun, 20 Mar 2005 16:52:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD8QW-0003Bb-BI; Sun, 20 Mar 2005 16:57:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD8LL-0003Vt-NI; Sun, 20 Mar 2005 16:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD8LJ-0003U6-W4 for ltru@megatron.ietf.org; Sun, 20 Mar 2005 16:52:18 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25959 for ; Sun, 20 Mar 2005 16:52:15 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050320215146.PTBI4618.mta13.adelphia.net@DEWELL>; Sun, 20 Mar 2005 16:51:46 -0500 Message-ID: <013601c52d96$2c9f2a20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <200503202056.j2KKuAhJ030538@smtp-los02.proxy.aol.com> Subject: Re: [Ltru] Re: Preparations for smart matching Date: Sun, 20 Mar 2005 13:45:45 -0800 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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit With Debbie's permission, I am moving this private thread onto the WG list, where I feel it belongs. Debbie Garside wrote: > IMVHO, you should be as succinct as possible when tagging... tag the > item clearly... whether it is of import to you or not... tag to the > finest detail... this can only enhance the semantic web of the future, > end user implementation and interoperability... I responded: > Are these goals compatible with one another? To me, "be as succinct > as possible" and "tag to the finest detail" seem contradictory. > "Succinct" usually implies leaving out details that one might consider > unnecessary. Debbie replied: > Succinct, in my view, means as clearly and concisely as possible, as > much info as you have at your fingertips... not just the info you need > for your own purpose... think of the wider picture... So Debbie is saying that tags with more information are generally preferable to those with less, even if the additional information could be considered redundant or implicit. For instance, using the examples from Section 2.3, "de-CH-1996" and "en-Latn-US" would be considered preferable to "de" or ("en" or "en-US"). I can sympathize with this to some extent, if matching algorithms are smart enough to interpret such tags properly. The present post, for example, is not simply in "en" but "en-Latn-US". If I were tagging it, I could use either tag -- or, for that matter, "en-Latn" or "en-US" -- and while the additional information (especially 'Latn') might be obvious, it's not harmful. A good matching algorithm, IMHO, should not reject my "en-Latn-US" post when requesting "en" content. Note, however, that this viewpoint does go against what Section 2.3 of the draft says. And there is no guarantee that matching algorithms will meet my definition of "good." Conciseness, in and of itself, really doesn't enter into this. There's no "short way" and "long way" of expressing the exact same thing, except for "deprecated-alias" situations like "i-klingon" versus "tlh". -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 16:54:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26220; Sun, 20 Mar 2005 16:54:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD8SI-0003Ef-83; Sun, 20 Mar 2005 16:59:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD8NJ-0003jQ-EK; Sun, 20 Mar 2005 16:54:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD8NE-0003jL-De for ltru@megatron.ietf.org; Sun, 20 Mar 2005 16:54:16 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26111 for ; Sun, 20 Mar 2005 16:54:13 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050320215345.PUUZ4618.mta13.adelphia.net@DEWELL>; Sun, 20 Mar 2005 16:53:45 -0500 Message-ID: <013c01c52d96$7448ce80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 20 Mar 2005 13:47:45 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Editorial suggestion X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit On a purely editorial note, I suggest that the language subtags 'und' and 'mul' in items 4 and 5 of Section 2.3 should be lowercased. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 17:15:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28877; Sun, 20 Mar 2005 17:15:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD8m8-0004Dc-4z; Sun, 20 Mar 2005 17:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD8gM-00071n-4M; Sun, 20 Mar 2005 17:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD8gL-00071i-Gf for ltru@megatron.ietf.org; Sun, 20 Mar 2005 17:14:01 -0500 Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28825 for ; Sun, 20 Mar 2005 17:13:59 -0500 (EST) Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN9-a423df5832aa; Sun, 20 Mar 2005 17:13:23 -0500 Received: from DEBHOME (ACD7A505.ipt.aol.com [172.215.165.5]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2KMDKnH026385; Sun, 20 Mar 2005 17:13:20 -0500 Message-Id: <200503202213.j2KMDKnH026385@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Preparations for smart matching Date: Sun, 20 Mar 2005 22:12:29 -0000 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: AcUtlwIwHo6TrTMNSDqpeAfp3LTArQAAZ21A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <013601c52d96$2c9f2a20$030aa8c0@DEWELL> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit With the greatest respect, Doug missed out the subscript that I responded to (his response to FE) where he said: Doug Ewell subscript: " The presence of a variant subtag, in and of itself, really doesn't tell much about whether the tagger considered the variation to be the most important detail or the least." My point is... if the information on variant subtag is available, use it... even though you may not need it for your own purpose. This is what I see as facilitating, in particular, the semantic web, knowledge management, archiving and search/query routines. RFC 3066bis seems intent on making tags as small as possible (am I wrong? Just my perception), whereas I for my purposes, always want as much information as possible, split into the tiniest of pieces, I can then include/exclude/use/concatenate in any way required. But then I do have a particular interest in language variants ;-) Debbie -----Original Message----- From: Doug Ewell [mailto:dewell@adelphia.net] Sent: 20 March 2005 21:46 To: LTRU Working Group Cc: Debbie Garside Subject: Re: [Ltru] Re: Preparations for smart matching With Debbie's permission, I am moving this private thread onto the WG list, where I feel it belongs. Debbie Garside wrote: > IMVHO, you should be as succinct as possible when tagging... tag the > item clearly... whether it is of import to you or not... tag to the > finest detail... this can only enhance the semantic web of the future, > end user implementation and interoperability... I responded: > Are these goals compatible with one another? To me, "be as succinct > as possible" and "tag to the finest detail" seem contradictory. > "Succinct" usually implies leaving out details that one might consider > unnecessary. Debbie replied: > Succinct, in my view, means as clearly and concisely as possible, as > much info as you have at your fingertips... not just the info you need > for your own purpose... think of the wider picture... So Debbie is saying that tags with more information are generally preferable to those with less, even if the additional information could be considered redundant or implicit. For instance, using the examples from Section 2.3, "de-CH-1996" and "en-Latn-US" would be considered preferable to "de" or ("en" or "en-US"). I can sympathize with this to some extent, if matching algorithms are smart enough to interpret such tags properly. The present post, for example, is not simply in "en" but "en-Latn-US". If I were tagging it, I could use either tag -- or, for that matter, "en-Latn" or "en-US" -- and while the additional information (especially 'Latn') might be obvious, it's not harmful. A good matching algorithm, IMHO, should not reject my "en-Latn-US" post when requesting "en" content. Note, however, that this viewpoint does go against what Section 2.3 of the draft says. And there is no guarantee that matching algorithms will meet my definition of "good." Conciseness, in and of itself, really doesn't enter into this. There's no "short way" and "long way" of expressing the exact same thing, except for "deprecated-alias" situations like "i-klingon" versus "tlh". -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 19:15:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07454; Sun, 20 Mar 2005 19:15:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDAer-0007Zw-9N; Sun, 20 Mar 2005 19:20:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDAYh-0003Th-Dt; Sun, 20 Mar 2005 19:14:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDAYd-0003Se-DW for ltru@megatron.ietf.org; Sun, 20 Mar 2005 19:14:13 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07389 for ; Sun, 20 Mar 2005 19:14:07 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDAWY-00075J-IW for ltru@lists.ietf.org; Mon, 21 Mar 2005 01:12:02 +0100 Received: from 212.82.251.65 ([212.82.251.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 01:12:02 +0100 Received: from nobody by 212.82.251.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 01:12:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 21 Mar 2005 01:08:22 +0100 Organization: Lines: 57 Message-ID: <423E1076.52F1@xyzzy.claranet.de> References: <200503202056.j2KKuAhJ030538@smtp-los02.proxy.aol.com> <013601c52d96$2c9f2a20$030aa8c0@DEWELL> 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.65 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Doug Ewell wrote: > For instance, using the examples from Section 2.3, > "de-CH-1996" and "en-Latn-US" would be considered > preferable to "de" or ("en" or "en-US"). Depends. When I use de-CH-1996 what I mean is that after one decade too much with US-keyboard layouts I forgot all rules about ß vs. ss in de, and what I learned in school was de-1901, so de-CH-1996 without ß is the best I can use without too many stupid errors. Very disappointing for speakers of de-CH, I'd never say "Velo" instead of "Fahrrad", and I wouldn't understand de-CH audio data. Script Latn and orthography 1996 are irrelevant for audio data (e.g. in a hreflang), it will never help in this case. Legacy software could "think" that it's something I don't want, therefore detailed tags can be harmful. For another example see what your UA did with your article. The default for MIME 1.0 text/plain is us-ascii 7bit. You can explicitly say so or omit it, and arguably saying so is better. But your UA claims that it's using utf-8 7bit. I know that this is the same as us-ascii, but my UA doesn't know utf-8 at all, it's just a piece of software and can't think. Fortunately they made it very robust (= stupid), with the correct result in this case of utf-8 7bit. > The present post, for example, is not simply in "en" but > "en-Latn-US". For Unicode mentioning the script makes sense, but for 8bit- charsets it should be implicit, excl. transliterations for the moment. For existing RfC 3066 software en-Latn-US is gibberish. If this software is a spellchecker it would be forced to guess which en you want. If it picks en-GB then en-Latn-US was a bad idea. That's why I want default scripts and a SHOULD NOT for cases like en-Latn-*. The recommendation to tag wisely is a waste of time for software, it can't think. It doesn't know what audio data is, and if it tries it could fail miserably for captions in video data. > the additional information (especially 'Latn') might be > obvious, it's not harmful. It can be harmful. No RfC 3066 software knows it. It wastes the available space for RfC 2231 "phrases" in header fields. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 20:30:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12554; Sun, 20 Mar 2005 20:30:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDBpI-0001N8-FH; Sun, 20 Mar 2005 20:35:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDBjk-00031L-3d; Sun, 20 Mar 2005 20:29:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDBji-00031B-Hz for ltru@megatron.ietf.org; Sun, 20 Mar 2005 20:29:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12473 for ; Sun, 20 Mar 2005 20:29:40 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDBof-0001ME-Ar for ltru@ietf.org; Sun, 20 Mar 2005 20:34:50 -0500 Received: from lns-p19-8-idf-82-249-11-13.adsl.proxad.net ([82.249.11.13] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDBje-0001Ix-Ax; Sun, 20 Mar 2005 17:29:39 -0800 Message-Id: <6.1.2.0.2.20050320235957.03f63eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 21 Mar 2005 00:12:27 +0100 To: "Debbie Garside" , "'Doug Ewell'" , "'LTRU Working Group'" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Preparations for smart matching In-Reply-To: <200503202213.j2KMDKnH026385@smtp-los04.proxy.aol.com> References: <013601c52d96$2c9f2a20$030aa8c0@DEWELL> <200503202213.j2KMDKnH026385@smtp-los04.proxy.aol.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 At 23:12 20/03/2005, Debbie Garside wrote: >My point is... if the information on variant subtag is available, use it... >even though you may not need it for your own purpose. This is what I see as >facilitating, in particular, the semantic web, knowledge management, >archiving and search/query routines. RFC 3066bis seems intent on making >tags as small as possible (am I wrong? Just my perception), whereas I for my >purposes, always want as much information as possible, split into the >tiniest of pieces, I can then include/exclude/use/concatenate in any way >required. > >But then I do have a particular interest in language variants ;-) Dear Debbie, I am not sure your interest is "particular" (this is a need in my case) in the finest granularity. Could you document your need better? Do you think there could be alternative, for example a primary tag refering to a secondary tag which could be called on demand? Or would you be interested in the subtag's semantic supporting several orthogonal/complementary tokens? I would also be interested if your request corresponds to the qualification (for exemple in a reading) or the definition of the language (for example in a web service). Thank you. jfc >Debbie > >-----Original Message----- >From: Doug Ewell [mailto:dewell@adelphia.net] >Sent: 20 March 2005 21:46 >To: LTRU Working Group >Cc: Debbie Garside >Subject: Re: [Ltru] Re: Preparations for smart matching > >With Debbie's permission, I am moving this private thread onto the WG >list, where I feel it belongs. > >Debbie Garside wrote: > > > IMVHO, you should be as succinct as possible when tagging... tag the > > item clearly... whether it is of import to you or not... tag to the > > finest detail... this can only enhance the semantic web of the future, > > end user implementation and interoperability... > >I responded: > > > Are these goals compatible with one another? To me, "be as succinct > > as possible" and "tag to the finest detail" seem contradictory. > > "Succinct" usually implies leaving out details that one might consider > > unnecessary. > >Debbie replied: > > > Succinct, in my view, means as clearly and concisely as possible, as > > much info as you have at your fingertips... not just the info you need > > for your own purpose... think of the wider picture... > >So Debbie is saying that tags with more information are generally >preferable to those with less, even if the additional information could >be considered redundant or implicit. For instance, using the examples >from Section 2.3, "de-CH-1996" and "en-Latn-US" would be considered >preferable to "de" or ("en" or "en-US"). > >I can sympathize with this to some extent, if matching algorithms are >smart enough to interpret such tags properly. The present post, for >example, is not simply in "en" but "en-Latn-US". If I were tagging it, >I could use either tag -- or, for that matter, "en-Latn" or "en-US" -- >and while the additional information (especially 'Latn') might be >obvious, it's not harmful. A good matching algorithm, IMHO, should not >reject my "en-Latn-US" post when requesting "en" content. > >Note, however, that this viewpoint does go against what Section 2.3 of >the draft says. And there is no guarantee that matching algorithms will >meet my definition of "good." > >Conciseness, in and of itself, really doesn't enter into this. There's >no "short way" and "long way" of expressing the exact same thing, except >for "deprecated-alias" situations like "i-klingon" versus "tlh". > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 20:49:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14320; Sun, 20 Mar 2005 20:49:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDC7x-000224-En; Sun, 20 Mar 2005 20:54:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDC1v-0004yY-3s; Sun, 20 Mar 2005 20:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDC1t-0004yQ-E1 for ltru@megatron.ietf.org; Sun, 20 Mar 2005 20:48:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14305 for ; Sun, 20 Mar 2005 20:48:27 -0500 (EST) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDC6r-0001zr-M9 for ltru@ietf.org; Sun, 20 Mar 2005 20:53:37 -0500 Received: from lns-p19-8-idf-82-249-11-13.adsl.proxad.net ([82.249.11.13] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDC1s-0006jP-7T for ltru@ietf.org; Sun, 20 Mar 2005 17:48:28 -0800 Message-Id: <6.1.2.0.2.20050321023551.031b0790@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 21 Mar 2005 02:48:21 +0100 To: "'LTRU Working Group'" From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ltru] multilingualism X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Does someone knows about an site/effort towards a multilingual support of ISO 3166 and of ISO 693? Today descriptions are in English and in French. This is not adequate to a menu in Chinese or for a Russian user. I suppose most of the main languages have an ISO 3166 translation, but I did not find a site. This also rises the question of the tagging of the languages description themselves in the 7260x7260 matrix of the languages names, plus the country names, plus the TLD lingual version, plus script name, etc. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 20:52:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14580; Sun, 20 Mar 2005 20:52:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDCAe-00028d-3d; Sun, 20 Mar 2005 20:57:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDC5Y-0005H0-O6; Sun, 20 Mar 2005 20:52:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDC5W-0005Gv-C6 for ltru@megatron.ietf.org; Sun, 20 Mar 2005 20:52:15 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14571 for ; Sun, 20 Mar 2005 20:52:12 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDC3T-0006FI-Kq for ltru@lists.ietf.org; Mon, 21 Mar 2005 02:50:07 +0100 Received: from 212.82.251.65 ([212.82.251.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 02:50:07 +0100 Received: from nobody by 212.82.251.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 02:50:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 21 Mar 2005 02:48:07 +0100 Organization: Lines: 90 Message-ID: <423E27D7.3679@xyzzy.claranet.de> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> 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.65 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >>> "pu-rud-Blaz-FU-scrog-f-vlad-x-druz", > (we seem to agree on this point) Yes. Out of curiosity, what's the idea of ISO 639-3 for the reserved "extlang" ? Is it something in the general direction of my "region codes in language tags considered harmful" idea ? > I think you missed my point. Trying to determine the > "default" script and perform matching based on this > assessment is probably *not* a good idea for those languages > that are customarily written in more than one script No, that point is clear. We don't want a mad tag reviewer who sees no problem in deciding what the default script is where it's _not_ obvious. In that case we prefer no default at all. Add TINW where necessary. > and probably unnecessary for those that are not. That's what I think is incorrect, see the parallel thread with Debbie with issues like legacy software, audio data, limited space in RfC 2231 header fields, etc. I'd also like to get as much info as possible, but above all I like correct data, no guesses, and backwards compatible data where possible. If 3066bis makes it this year I'm confident that compatibility issues with RfC 3066 begin to be irrelevant after 2038 with its signed time_t 32 bits issue. So for the next 33 years I want compatibility where possible. Your "mn" example is clear, it's not always possible to get full backwards compatibility. I don't want a default script for "mn" or similar languages, where it's not obvious. > Section 2.3, items 1 and 2 tell the user to avoid subtags > that don't add information. It's not always the user who tags data, often it's software. As user you would probably never say "utf-8 7bit". We need defaults for software implementors, not for ordinary users. ["draft registry"] > it seems to be more than just a prototype. It's just a nice way to see what the actual draft really means. For an I-D and IANA I'd prefer a format as in the IANA charset registry. Maybe with "%%" lines instead of empty lines as the terminator for individual entries. I forgot the name for this format and who proposed %% instead of CRLF>. [en-misc-US-boont] >> "misc" is probably very important, if it's not "Latn" >> as in the default for en. > But "boont" may also be important, because most English is > not Boontling. Yes, probably they are both important. If a client supports both en-misc and en-boont but not en-misc-boont let's hope that it "knows" the best alternative or offers a choice. I still think that the prcocessing of en-Latn-US-boont or the "canonical" en-boont could be different from the processing of en-misc-US-boont / en-misc-boont. E.g a user could configure somewhere that he only knows Latn. Or that he's really interested in misc, not Latn. Or that he loves en-boont independent of the script. > Boontling is cute and fun, but I'd really rather not use it > as the metric by which important decisions about tagging and > matching are made. Yes, I have no idea what "boont" is, that's a problem. Maybe the draft should use another standard example for matching strategies and dialects (my editor counts 17 occurences in 13 lines for "boont" in draft -00) > Who are we to say she can't read Ogham? Of course we won't say this. We only want existing RfC 3066 software to do the right thing for "Latn". This software has no idea what "Latn" is. Maybe it asks whois.iana.org why they now use a funny FOURCC for the country codes Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 21:31:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17959; Sun, 20 Mar 2005 21:31:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDCmV-0003J2-KL; Sun, 20 Mar 2005 21:36:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDCgQ-0000Eu-1A; Sun, 20 Mar 2005 21:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDCgO-0000Eo-TM for ltru@megatron.ietf.org; Sun, 20 Mar 2005 21:30:21 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17860 for ; Sun, 20 Mar 2005 21:30:18 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDCeL-0000Y8-0C for ltru@lists.ietf.org; Mon, 21 Mar 2005 03:28:13 +0100 Received: from 212.82.251.65 ([212.82.251.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 03:28:12 +0100 Received: from nobody by 212.82.251.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 03:28:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 21 Mar 2005 03:29:31 +0100 Organization: Lines: 17 Message-ID: <423E318B.BD2@xyzzy.claranet.de> References: <00b401c52cd5$45a62620$030aa8c0@DEWELL> 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.65 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Populating the initial registry: Languages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> Step 2: Deprecated ISO 639 codes How about a special rule "skip jw" ? The normative references are ISO 639-1:2002 and ISO 639-2:1998, that could justify to omit an old typo fixed 1988 (?) or 2001 (?). What I really want to say: I won't check your tag generators for anything which is no country code, I look at your output. Your second source (codechanges.html) says that it's currently updated. Apparently they forgot the "-" for a "-jw", but you said that your script ignores the "-". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 21:46:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19064; Sun, 20 Mar 2005 21:46:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDD0j-0003m5-Nv; Sun, 20 Mar 2005 21:51:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDCum-0001Gu-Dp; Sun, 20 Mar 2005 21:45:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDCuk-0001Gp-Ue for ltru@megatron.ietf.org; Sun, 20 Mar 2005 21:45:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18912 for ; Sun, 20 Mar 2005 21:45:08 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDCzj-0003jM-5u for ltru@ietf.org; Sun, 20 Mar 2005 21:50:19 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2L2ixVi019660; Sun, 20 Mar 2005 21:44:59 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 20 Mar 2005 21:45:03 -0500 Date: Sun, 20 Mar 2005 21:45:03 -0500 From: John Cowan To: Frank Ellermann Message-ID: <20050321024502.GB15741@skunk.reutershealth.com> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423E27D7.3679@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ltru@ietf.org Subject: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This posting is mostly for background information. The only immediately WG-relevant point is that I agree with Frank Ellerman that using "boont" so heavily as an example in the draft is a bad idea. Frank Ellermann scripsit: > Yes. Out of curiosity, what's the idea of ISO 639-3 for the > reserved "extlang" ? Is it something in the general direction > of my "region codes in language tags considered harmful" idea ? ISO 639-3 will be (if all goes as expected) an extension of ISO 639-2 to provide a 3-letter code, compatible with ISO 639-2, for every known language in the world (about 7000). Most of the work has already been done, and what remains is basically cranking the standardization machinery. Some ISO 639-1/2 codes are, from the viewpoint of ISO 639-3, actually cover terms for multiple languages. For example, "zh" actually covers 13 distinct ISO 639-3 languages: czo, mnp, yue, hsn, wuu, cpx, gan, nan, cmn, cjy, czh, hak, cdo. Instead of allowing these as initial tags in RFC 3066ter, the intent is to allow zh-czo, zh-mnp, zh-yue, etc. (This will mean that several grandfathered zh-??? tags will become redundant instead.) The reason for putting this facility off to RFC 3066ter is that ISO 639-3 is only an editor's draft at this point. The reason for including the syntax in 3066bis is to make 3066bis parsers 3066ter-ready. > For an I-D and IANA I'd prefer a format as in the IANA charset > registry. Maybe with "%%" lines instead of empty lines as the > terminator for individual entries. I forgot the name for this > format and who proposed %% instead of CRLF>. "Record-jar" format, a merger of RFC-822 headers and the cookie-jar format devised by Ken Arnold. > Yes, I have no idea what "boont" is, that's a problem. Most other people don't either. It is a jargon or Rotwelsch used by most of the people living in the small and (then) isolated town of Booneville, California between 1880 and 1920, and sporadically by hobbyists since then. The syntax is mostly that of informal American English, but the jargon vocabulary is so all-encompassing as to make Boontling (itself a jargon term) mutually unintelligible with English. Here are a nursery rhyme and part of a mushroom-collecting guide: # The eeld'm piked for the chigrel nook # For gorms for her bahl beljeemer; # The gorms had shied, the nook was strung, # And the bahl beljeemer had nemer. Literal translation: The old woman went to the cupboard/For food for her excellent hunting dog/The food was gone, the cupboard was empty/ And the excellent hunting dog had nothing. Standard English version: Old Mother Hubbard/Went to the cupboard/ To fetch her poor dog a bone/But when she came there/The cupboard was bare/And so the poor dog had none. # You must do much graymatterin fore pikin for seekin Ite steaks # to gorm, cause the sockers might not be bahlers, but nonchers # with dusties dust, so deek your bok well. Literal translation: You must do much thinking before going out to look for mushrooms (literally "Italian steaks") to eat, because the mushrooms might not be good ones, but bad ones with poison (literally "graveyard dust"), so read your manual well. Don't be troubled that you can't understand it; anglophones can't either. -- Clear? Huh! Why a four-year-old child John Cowan could understand this report. Run out jcowan@reutershealth.com and find me a four-year-old child. I http://www.ccil.org/~cowan can't make head or tail out of it. http://www.reutershealth.com --Rufus T. Firefly on government reports _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 23:03:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26268; Sun, 20 Mar 2005 23:03:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDEDG-0006JP-3O; Sun, 20 Mar 2005 23:08:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDE7Y-0007fL-87; Sun, 20 Mar 2005 23:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDE7W-0007eu-QA for ltru@megatron.ietf.org; Sun, 20 Mar 2005 23:02:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26172 for ; Sun, 20 Mar 2005 23:02:24 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDECU-0006Hk-VM for ltru@ietf.org; Sun, 20 Mar 2005 23:07:36 -0500 Received: from h-68-165-7-158.snvacaid.dynamic.covad.net ([68.165.7.158] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DDE7T-0002Qi-00 for ltru@ietf.org; Sun, 20 Mar 2005 20:02:23 -0800 Message-ID: <000601c52dca$e1e126c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org><010e01c52d7e$998226a0$030aa8c0@DEWELL><423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.com> Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Sun, 20 Mar 2005 20:03:04 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi - > From: "John Cowan" > To: "Frank Ellermann" > Cc: > Sent: Sunday, March 20, 2005 6:45 PM > Subject: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling ... > ISO 639-3 will be (if all goes as expected) an extension > of ISO 639-2 to provide a 3-letter code, compatible with ISO 639-2, > for every known language in the world (about 7000). Most of the > work has already been done, and what remains is basically cranking the > standardization machinery. > > Some ISO 639-1/2 codes are, from the viewpoint of ISO 639-3, actually > cover terms for multiple languages. For example, "zh" actually covers > 13 distinct ISO 639-3 languages: czo, mnp, yue, hsn, wuu, cpx, gan, nan, > cmn, cjy, czh, hak, cdo. Instead of allowing these as initial tags in RFC > 3066ter, the intent is to allow zh-czo, zh-mnp, zh-yue, etc. (This will > mean that several grandfathered zh-??? tags will become redundant instead.) > > The reason for putting this facility off to RFC 3066ter is that ISO 639-3 > is only an editor's draft at this point. The reason for including the > syntax in 3066bis is to make 3066bis parsers 3066ter-ready. ... (co-chair hat OFF) Do you have a rough idea how many ISO 639-1/2 codes will be "cover terms" from the perspective of ISO 639-3? Is the expectation that these other cases would all be handled in the same way as (zh-cao instead of cao)? If we already have a good idea how the ISO specifications will look, wouldn't it make sense to ensure that 3066bis works correctly for those cases, so we don't have to bother doing a 3066ter? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 23:41:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28813; Sun, 20 Mar 2005 23:41:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDEoo-0007TK-OQ; Sun, 20 Mar 2005 23:47:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEjZ-0002YS-0A; Sun, 20 Mar 2005 23:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEjW-0002YN-QN for ltru@megatron.ietf.org; Sun, 20 Mar 2005 23:41:42 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28751 for ; Sun, 20 Mar 2005 23:41:40 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050321044111.IJB7277.mta10.adelphia.net@DEWELL> for ; Sun, 20 Mar 2005 23:41:11 -0500 Message-ID: <002a01c52dcf$2523a3a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050321013121.MOXB2124.mta7.adelphia.net@megatron.ietf.org> Date: Sun, 20 Mar 2005 20:33:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA28751 Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Frank Ellermann wrote: >> For instance, using the examples from Section 2.3, >> "de-CH-1996" and "en-Latn-US" would be considered >> preferable to "de" or ("en" or "en-US"). > > Depends. When I use de-CH-1996 what I mean is that after one > decade too much with US-keyboard layouts I forgot all rules > about ß vs. ss in de, and what I learned in school was > de-1901, so de-CH-1996 without ß is the best I can use > without too many stupid errors. Debbie's premise is that IF you can identify your data correctly using detailed tags, then use the detailed tag rather than a less specific one. Obviously not all data fits neatly into a category like "de-CH-1996"; you might use some elements that are characteristic of Swiss German and some that are not, and you might follow some rules of the spelling reform but not others. In that case, the rule should always be "Don't lie with language tags." > For another example see what your UA did with your article. > The default for MIME 1.0 text/plain is us-ascii 7bit. You > can explicitly say so or omit it, and arguably saying so is > better. > > But your UA claims that it's using utf-8 7bit. I know that > this is the same as us-ascii, but my UA doesn't know utf-8 > at all, it's just a piece of software and can't think. > > Fortunately they made it very robust (=3D stupid), with the > correct result in this case of utf-8 7bit. I have no idea what this has to do with language tags. I always change the encoding of my messages to UTF-8 (except when I forget) and Outlook Express is probably tagging it as UTF-8. I don't know what is "7-bit" about it (UTF-8 is an 8-bit encoding) but I guess if I had any non-ASCII characters in my message they might be wrapped in a 7-bit encoding of some sort. If you care, see what it does with this character: [=C3=97] (I'm sorry to hear that your e-mail UA doesn't know what UTF-8 is, by the way; the Internet Mail Consortium considers it "deficient and lacking in standard internationalization capabilities" for that reason.) > For existing RfC 3066 software en-Latn-US is gibberish. Well, of course it is. I'm talking about parsers that are expected to be able to handle RFC 3066bis tags. To update what I said on ietf-languages: If our goal is to ensure that all future tags can be interpreted by existing RFC 3066 parsers, with no modification, then the best way to do that is to close this WG right now and stop registering new RFC 3066 tags. The RFC 3066bis generative syntax is a superset of the RFC 3066 generative syntax. It allows things to be generated that cannot be generated under RFC 3066. However, it is completely downward compatible, in that everything valid under RFC 3066 is also valid under RFC 3066bis (which would not be true if, for example, we got rid of country codes). > That's why I want default scripts and a SHOULD NOT for cases > like en-Latn-*. The recommendation to tag wisely is a waste > of time for software, it can't think. It doesn't know what > audio data is, and if it tries it could fail miserably for > captions in video data. Audio and video data would not be tagged for script in any event. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 23:42:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28844; Sun, 20 Mar 2005 23:42:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDEp0-0007TV-E1; Sun, 20 Mar 2005 23:47:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEj9-0002Rl-5P; Sun, 20 Mar 2005 23:41:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEj6-0002RY-LV for ltru@megatron.ietf.org; Sun, 20 Mar 2005 23:41:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28696 for ; Sun, 20 Mar 2005 23:41:14 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDEo6-0007S3-9R for ltru@ietf.org; Sun, 20 Mar 2005 23:46:26 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2L4f4Uk020272; Sun, 20 Mar 2005 23:41:06 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 20 Mar 2005 23:41:14 -0500 Date: Sun, 20 Mar 2005 23:41:13 -0500 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Message-ID: <20050321044113.GG15741@skunk.reutershealth.com> References: <20050321024502.GB15741@skunk.reutershealth.com> <000601c52dca$e1e126c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601c52dca$e1e126c0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Randy Presuhn scripsit: > Do you have a rough idea how many ISO 639-1/2 codes will be "cover terms" > from the perspective of ISO 639-3? The current draft contains 56 of them; the technical ISO 639-3 term is "macro-languages". A total of 365 ISO 639-3 languages would be covered by a macro-language code. They do not overlap. > Is the expectation that these other cases would all be handled in the same way Yes. Similarly, fy-fri (West Frisian), fy-frs (East Frisian), and fy-frr (North Frisian), rather than fri, frs, frr. Not all macro-languages have ISO 639-1 codes: the three Baluchi languages would be bal-bcc (Southern), bal-bgn (Western), bal-bgp (Eastern). There would be a few exceptions due to ISO 639 grandfathering: the ISO 639-1 codes nb (Bokmal Norwegian) and nn (Nynorsk Norwegian) would be preferred in RFC 3066ter to no-nob and no-nno. > as (zh-cao instead of cao)? (Presumably zh-czo (Min Zhong) or zh-cdo (Min Dong). cao is a different language altogether, not covered by any macro-language code.) > If we already have a good idea how the ISO specifications will look, wouldn't > it make sense to ensure that 3066bis works correctly for those cases, so > we don't have to bother doing a 3066ter? I think everyone is okay with that except for the timing issue. Currently, ISO 639-3 is an editor's draft, the ISO equivalent of an I-D. There is no guarantee that it would make it through the ISO process before RFC 3066bis makes it through the IETF BCP process, nor that the current concepts will survive intact. Fortunately, Peter Constable is the ISO 639-3 editor, and has been able to bring enormous energy to the task so far. >From what I understand of the IETF process, this WG could go dormant until ISO 639-3 was released, and then wake up for a relatively brief period to incorporate the necessary few paragraphs in RFC 3066bis to create RFC 3066ter. -- John Cowan www.ccil.org/~cowan jcowan@reutershealth.com www.reutershealth.com [P]olice in many lands are now complaining that local arrestees are insisting on having their Miranda rights read to them, just like perps in American TV cop shows. When it's explained to them that they are in a different country, where those rights do not exist, they become outraged. --Neal Stephenson _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 20 23:49:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29593; Sun, 20 Mar 2005 23:49:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDEwO-0007mQ-Fz; Sun, 20 Mar 2005 23:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEqx-0003Xi-Mp; Sun, 20 Mar 2005 23:49:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEqv-0003Xd-Re for ltru@megatron.ietf.org; Sun, 20 Mar 2005 23:49:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29527 for ; Sun, 20 Mar 2005 23:49:19 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDEvv-0007kz-MB for ltru@ietf.org; Sun, 20 Mar 2005 23:54:31 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2L4nAoD020326; Sun, 20 Mar 2005 23:49:11 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 20 Mar 2005 23:49:12 -0500 Date: Sun, 20 Mar 2005 23:49:11 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Preparations for smart matching Message-ID: <20050321044911.GH15741@skunk.reutershealth.com> References: <20050321013121.MOXB2124.mta7.adelphia.net@megatron.ietf.org> <002a01c52dcf$2523a3a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01c52dcf$2523a3a0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Doug Ewell scripsit: > (1) The RFC 3066bis generative syntax is a superset of the RFC 3066 > generative syntax. It allows things to be generated that cannot be > generated under RFC 3066. > (2) [E]verything valid under RFC 3066 is also valid under RFC 3066bis > (which would not be true if, for example, we got rid of country codes). (3) The RFC 3066bis generative syntax is a subset of the RFC 3066 recognizer syntax: every tag that can be generated under RFC 3066bis could be registered under RFC 3066. (I think this point is worth emphasizing.) -- Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): jcowan@reutershealth.com One sentence (two stanzas) / Hexasyllabically http://www.reutershealth.com Challenges poets who / Don't have the time. --robison who's at texas dot net _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 00:06:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00598; Mon, 21 Mar 2005 00:06:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFCq-0008OY-Eu; Mon, 21 Mar 2005 00:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDF6Y-0005WP-Ns; Mon, 21 Mar 2005 00:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDF6W-0005WK-WB for ltru@megatron.ietf.org; Mon, 21 Mar 2005 00:05:29 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00517 for ; Mon, 21 Mar 2005 00:05:25 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050321050456.QEAB12278.mta9.adelphia.net@DEWELL> for ; Mon, 21 Mar 2005 00:04:56 -0500 Message-ID: <003401c52dd2$69fd09a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 20 Mar 2005 20:56:58 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: multilingualism X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Does someone knows about an site/effort towards a multilingual support > of ISO 3166 and of ISO 693? I don't know anything about ISO 693, which is a standard for "Dimensions of seam welding wheel blanks." You might have better luck looking for references on ISO 639, which deals with language codes. > Today descriptions are in English and in French. This is not adequate > to a menu in Chinese or for a Russian user. I suppose most of the main > languages have an ISO 3166 translation, but I did not find a site. > This also rises the question of the tagging of the languages > description themselves in the 7260x7260 matrix of the languages names, > plus the country names, plus the TLD lingual version, plus script > name, etc. The ICU project is probably your best source for common localized resources, such as language names. They currently support resource bundles in 77 different languages (or 80, depending on which reference you read). http://www-306.ibm.com/software/globalization/icu/index.jsp You probably will not ever find a source for translating the names of 7260 languages into 7260 languages. One problem is that many of these languages are nearly extinct and/or have fewer than 10 speakers, who probably do not have the resources, knowledge, or inclination to translate the names of 7259 other languages. Another problem is that there is currently no universally accepted coding system for 7260 languages, which makes a database like this a bit difficult to index. ISO 639-3 will provide codes for 7616 languages, by my count, but it is still only a draft. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 00:10:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00853; Mon, 21 Mar 2005 00:10:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFG1-00005C-EO; Mon, 21 Mar 2005 00:15:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDFA7-0005oF-3D; Mon, 21 Mar 2005 00:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDFA5-0005mr-Te for ltru@megatron.ietf.org; Mon, 21 Mar 2005 00:09:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00720 for ; Mon, 21 Mar 2005 00:09:07 -0500 (EST) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFF4-0008SU-LP for ltru@ietf.org; Mon, 21 Mar 2005 00:14:19 -0500 Received: from korppi.cs.tut.fi (korppi.cs.tut.fi [130.230.4.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 9AA8CB5C for ; Mon, 21 Mar 2005 07:08:57 +0200 (EET) Date: Mon, 21 Mar 2005 07:08:57 +0200 (EET) From: "Jukka K. Korpela" To: "'LTRU Working Group'" Subject: Re: [Ltru] multilingualism In-Reply-To: <6.1.2.0.2.20050321023551.031b0790@mail.jefsey.com> Message-ID: References: <6.1.2.0.2.20050321023551.031b0790@mail.jefsey.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Mon, 21 Mar 2005, JFC (Jefsey) Morfin wrote: > Does someone knows about an site/effort towards a multilingual support of > ISO 3166 and of ISO 693? That's part of the work of the Common Locale Data Repository activity, see http://www.unicode.org/cldr/ which already contains a huge amount of data on names of languages, countries, and other things in different languages. > Today descriptions are in English and in French. This is not adequate to a > menu in Chinese or for a Russian user. I suppose most of the main languages > have an ISO 3166 translation, but I did not find a site. Software vendors have had to define localized names for use in menus and other contexts, but the names have often been incorrect and there have been unnecessary and confusing differences. They really don't want to do such things but implement definitions based on expert work and consensus in different countries. Hence CLDR. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 00:41:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02354; Mon, 21 Mar 2005 00:41:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFk0-0000py-A2; Mon, 21 Mar 2005 00:46:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDFeR-0008Tr-3W; Mon, 21 Mar 2005 00:40:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDFeO-0008Tm-P0 for ltru@megatron.ietf.org; Mon, 21 Mar 2005 00:40:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02331 for ; Mon, 21 Mar 2005 00:40:25 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDFjO-0000oc-DE for ltru@ietf.org; Mon, 21 Mar 2005 00:45:38 -0500 Received: from h-68-165-7-158.snvacaid.dynamic.covad.net ([68.165.7.158] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DDFeM-0000Bv-00 for ltru@ietf.org; Sun, 20 Mar 2005 21:40:26 -0800 Message-ID: <000601c52dd8$94334120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050321024502.GB15741@skunk.reutershealth.com> <000601c52dca$e1e126c0$7f1afea9@oemcomputer> <20050321044113.GG15741@skunk.reutershealth.com> Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Sun, 20 Mar 2005 21:41:06 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - (co-chair hat off) > From: "John Cowan" > To: "Randy Presuhn" > Cc: > Sent: Sunday, March 20, 2005 8:41 PM > Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling ... > From what I understand of the IETF process, this WG could go dormant > until ISO 639-3 was released, and then wake up for a relatively brief > period to incorporate the necessary few paragraphs in RFC 3066bis to > create RFC 3066ter. ... I think it would be really nice if we could put in text now that would not need revision later. It sounds like all that is needed is text that spells out precisely when using the macro-language code is required. However, I wonder if the approach of mandating the use of the macro-language code in some, but not all, cases will make matching algorithms overly complicated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 01:30:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05443; Mon, 21 Mar 2005 01:30:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDGW7-00027R-Ae; Mon, 21 Mar 2005 01:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDGPp-0004EM-E6; Mon, 21 Mar 2005 01:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDGPo-0004EE-0A for ltru@megatron.ietf.org; Mon, 21 Mar 2005 01:29:28 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05314 for ; Mon, 21 Mar 2005 01:29:26 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050321062856.NQFT5402.mta11.adelphia.net@DEWELL> for ; Mon, 21 Mar 2005 01:28:56 -0500 Message-ID: <003701c52dde$0e70f2c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050321044949.GEQD4900.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 20 Mar 2005 22:20:18 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Out of curiosity, what's the idea of ISO 639-3 for the > reserved "extlang" ? Is it something in the general direction > of my "region codes in language tags considered harmful" idea ? It is a way of identifying more languages. It does not replace region subtags in cases where the essential language is the same. There are codes for things like "Liberian English," which differs dramatically from Standard English, but there are not separate codes for en-US and en-GB and en-AU and en-ZA. >> I think you missed my point. Trying to determine the >> "default" script and perform matching based on this >> assessment is probably *not* a good idea for those languages >> that are customarily written in more than one script > > No, that point is clear. We don't want a mad tag reviewer who > sees no problem in deciding what the default script is where > it's _not_ obvious. In that case we prefer no default at all. > Add TINW where necessary. So the problem is reduced to defining a "default" script where that is considered "obvious" -- best to be conservative here -- and establishing a mechanism to indicate the default script in the registry, a matching algorithm that will use this information to dike out "redundant" script subtags, and a recommendation in the draft that users not use any script subtag explicitly that matches the default. Does anyone else besides Frank agree with this, or think it bears investigating? I'd like to hear someone else besides just Frank and me. >> and probably unnecessary for those that are not. > > That's what I think is incorrect, see the parallel thread with > Debbie with issues like legacy software, audio data, limited > space in RfC 2231 header fields, etc. Debbie is saying we should encode as much information as possible. You are saying that we should not encode the script if it is assumed to be the "default." These are fundamentally opposite viewpoints. Let's not talk about audio data and script subtags in the same breath. > I'd also like to get as much info as possible, but above all I > like correct data, no guesses, and backwards compatible data > where possible. Collapsing "en-Latn" to "en" is very much a matter of employing guesswork. You are guessing that users who request "en" don't want the very small amount of content that exists in any script other than Latin, and will know how to request "en-Dsrt" or "en-Shaw" or "en-Brai" if they want that. > If 3066bis makes it this year I'm confident > that compatibility issues with RfC 3066 begin to be irrelevant > after 2038 with its signed time_t 32 bits issue. I guess this means "RFC 3066bis has serious compatibility issues with RFC 3066." Can you enumerate these, please, in a bullet-point list? >> Section 2.3, items 1 and 2 tell the user to avoid subtags >> that don't add information. > > It's not always the user who tags data, often it's software. > As user you would probably never say "utf-8 7bit". We need > defaults for software implementors, not for ordinary users. "User" in software engineering does not have to mean a human. It could be a software process. > For an I-D and IANA I'd prefer a format as in the IANA charset > registry. Maybe with "%%" lines instead of empty lines as the > terminator for individual entries. I forgot the name for this > format and who proposed %% instead of CRLF>. John Cowan suggested the "record-jar" format. I could certainly put together a record-jar version of the registry if desired. Is anyone else interested in seeing this? > Yes, probably they are both important. If a client supports > both en-misc and en-boont but not en-misc-boont let's hope > that it "knows" the best alternative or offers a choice. As I said: it is very difficult to tell, simply from the presence of a variant subtag, whether it represents the most important or least important information for the user. If I request "de" content, say over the Web, I definitely want to receive content in both "de-1901" and "de-1996", not just one or the other. However, if I request "zh" I may not be able to do anything with "zh-hakka". > E.g a user could configure somewhere that he only knows Latn. > Or that he's really interested in misc, not Latn. Or that he > loves en-boont independent of the script. This is all part of the "good" matching strategy I described. You could specify "en-Latn" or "en-Misc" (not an actual script, of course) or "en-boont", and get content in whatever combination you like. All that is needed is for the matching module to compare the langtag of the content with that of your request, decompose the two into subtags, and compare the subtags. If you had something like this, you wouldn't need "en-Latn" to be collapsed to "en" or anything else. >> Who are we to say she can't read Ogham? > > Of course we won't say this. We only want existing RfC 3066 > software to do the right thing for "Latn". This software has > no idea what "Latn" is. If you declare 'Latn' to be the default script for 'en', and use that information to collapse the tag "en-Latn" to "en", then you remove the user's ability to get "en-Ogam" content unless she specifically requests it. This essentially says, "Since you requested English, I'll assume you can only read it in Latin script, and I won't send you English content in any other script." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 01:57:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06979; Mon, 21 Mar 2005 01:57:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDGwO-0002rk-PF; Mon, 21 Mar 2005 02:03:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDGr8-0006lc-Jy; Mon, 21 Mar 2005 01:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDGr7-0006lX-K5 for ltru@megatron.ietf.org; Mon, 21 Mar 2005 01:57:41 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06972 for ; Mon, 21 Mar 2005 01:57:40 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050321065710.OBQF5402.mta11.adelphia.net@DEWELL> for ; Mon, 21 Mar 2005 01:57:10 -0500 Message-ID: <003c01c52de1$f988a2a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050321044949.GEQD4900.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 20 Mar 2005 22:48:21 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Populating the initial registry: Languages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >>> Step 2: Deprecated ISO 639 codes > > How about a special rule "skip jw" ? The normative references > are ISO 639-1:2002 and ISO 639-2:1998, that could justify to > omit an old typo fixed 1988 (?) or 2001 (?). If you don't mind, I'd like to phrase this as a question for the group, instead of simply continung to say "such-and-so could be done," which doesn't seem to generate any WG feedback. QUESTION: Should the rules for populating the registry be changed to exclude ISO 639 codes deprecated before a certain date? If so, what should that date be? PRO: This might reduce user confusion, and would leave the door open for ISO 639 to reassign these codes (which they have never done). CON: Many reference sources actually encouraged users to continue using the old codes 'in', 'iw', and 'he' for years after they were deprecated, on the basis that old software would be more likely to recognize the old codes. A side note: Please don't take the fact that I am presenting this issue as a question for the group as evidence that I support the idea. > Your second source (codechanges.html) says that it's currently > updated. Apparently they forgot the "-" for a "-jw", but you > said that your script ignores the "-". Yes, they did forget the hyphen to indicate that "jw" is now deprecated. BTW, for those who found my e-mail message on this subject difficult to read, I've turned it into a Web page (including errata). Eventually this will include steps to populate the entire registry. I'm waiting for feedback on the language part before finishing the other parts. The address is: http://users.adelphia.net/~dewell/init-registry.html -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 02:17:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24519; Mon, 21 Mar 2005 02:17:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDHF0-0003Ua-BK; Mon, 21 Mar 2005 02:22:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDH8Z-0000ZN-Qc; Mon, 21 Mar 2005 02:15:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDH8Y-0000Z3-4V for ltru@megatron.ietf.org; Mon, 21 Mar 2005 02:15:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22961 for ; Mon, 21 Mar 2005 02:15:41 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDHDY-0003Qz-4y for ltru@ietf.org; Mon, 21 Mar 2005 02:20:53 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2L7FUm5021137; Mon, 21 Mar 2005 02:15:31 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 21 Mar 2005 02:15:34 -0500 Date: Mon, 21 Mar 2005 02:15:34 -0500 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Message-ID: <20050321071534.GI15741@skunk.reutershealth.com> References: <20050321024502.GB15741@skunk.reutershealth.com> <000601c52dca$e1e126c0$7f1afea9@oemcomputer> <20050321044113.GG15741@skunk.reutershealth.com> <000601c52dd8$94334120$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601c52dd8$94334120$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Randy Presuhn scripsit: > I think it would be really nice if we could put in text now that would not > need revision later. It sounds like all that is needed is text that spells > out precisely when using the macro-language code is required. The difficulty there is that we put the extended-language concept in to support a specific mechanism of ISO 639-3 as it is currently conceived of. If ISO/IEC JTC 1 / TC 37 / SC 2 / WG 1 changed its mind about this mechanism, we'd be left hanging out to dry. That said, it seems I was incorrect to say that ISO 639-3 is an editor's draft: it is now a Draft International Standard out for ballot. > However, I wonder if the approach of mandating the use of the macro-language > code in some, but not all, cases will make matching algorithms overly complicated. I don't think so. It's much like mandating the use of ISO 639-1 codes where they exist in place of ISO 639-2 codes. It means that you need to know more to assign a code, but not more to match on one. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 02:35:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00309; Mon, 21 Mar 2005 02:35:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDHXD-0003yR-Nd; Mon, 21 Mar 2005 02:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDHRC-0003g4-Jy; Mon, 21 Mar 2005 02:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDHRA-0003ff-Qo for ltru@megatron.ietf.org; Mon, 21 Mar 2005 02:34:57 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00246 for ; Mon, 21 Mar 2005 02:34:54 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDHP4-0007BJ-4b for ltru@lists.ietf.org; Mon, 21 Mar 2005 08:32:46 +0100 Received: from 212.82.251.65 ([212.82.251.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 08:32:46 +0100 Received: from nobody by 212.82.251.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 08:32:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 21 Mar 2005 08:07:03 +0100 Organization: Lines: 83 Message-ID: <423E7297.726F@xyzzy.claranet.de> References: <20050321013121.MOXB2124.mta7.adelphia.net@megatron.ietf.org> <002a01c52dcf$2523a3a0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=pc-multilingual-850+euro Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.65 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Doug Ewell wrote: > Debbie's premise is that IF you can identify your data > correctly using detailed tags, then use the detailed tag > rather than a less specific one. Sure, she would say en-Latn-US instead of en-US and maybe be disappointed when today's software matches it with en instead of en-US. Browsers, googlebot, spell checkers, etc. for many years. 3066bis could avoid this potential problem by saying that en-Latn-* is NOT RECOMMENDED. Or ru-Cyrl-*, it's not limited to Latn. [utf-8 7bit vs. us-ascii 7bit] > I have no idea what this has to do with language tags. It was only an example for backwards compatibility, my rather old UA often "helps" me to identify such issues. Not for this example, I simply looked into the header. A clever UA could try to guess the script based on the charset, for us-ascii I'd expect it to guess "Latn". And for utf-8 I'd expect that it doesn't try to guess. > I don't know what is "7-bit" about it Another logic decided that you used only us-ascii, and then a transfer-encoding is unnecessary. It was only an example for "many details are not always consistent", keeping it simple is often better. Backwards compatible defaults like us-ascii in 7bit mail or Latn for en are good. > sorry to hear that your e-mail UA doesn't know what UTF-8 is It's no big problem, otherwise I'd change the UA. Generally Latin-1 works for me, and I also know when that's a lie and I have to replace it by windows-1252 manually. > the Internet Mail Consortium considers it "deficient and > lacking in standard internationalization capabilities" Only for UAs created or revised _after_ 1998, and that was two or three years after somebody said "make" for my UA. And it's already in the binary, unfortunately disabled for my platform. Thanks for , I've added it to my collection of charset links. I just checked the final - it still allows me to use windows-1252 where necessary for backwards compatibility. Also added to my link collection. Your test character was =9E, okay, what I've now done is evil. Don't get me started with charsets, it's worse than ccTLDs ;-) >> For existing RfC 3066 software en-Latn-US is gibberish. > Well, of course it is. Then it should be avoided where possible. We only have to make it possible by introducing "default" scripts for the 80% where it's easy, as you said. > everything valid under RFC 3066 is also valid under > RFC 3066bis (which would not be true if, for example, we got > rid of country codes). My proposal to use the last official meaning for all ISO 3166-1 country codes as an alias to stable UN numbers is compatible with RfC 3066. That past or present countries as defined by the UN are no good choice for regional differences in languages is IMHO clear. Maybe 693-3 will allow me to say "Texas", "Wales", or "Bavaria" somehow where that's relevant. > Audio and video data would not be tagged for script in any > event. Not by humans. But with software you never know, if there's a way to get it wrong somebody will implement it, it could be me. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 03:07:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02799; Mon, 21 Mar 2005 03:07:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDI1V-0004vR-Ut; Mon, 21 Mar 2005 03:12:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDHv1-00076J-MM; Mon, 21 Mar 2005 03:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDHuy-00076C-Mx for ltru@megatron.ietf.org; Mon, 21 Mar 2005 03:05:44 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02730 for ; Mon, 21 Mar 2005 03:05:42 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDHss-0002CR-Vz for ltru@lists.ietf.org; Mon, 21 Mar 2005 09:03:35 +0100 Received: from 212.82.251.65 ([212.82.251.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 09:03:34 +0100 Received: from nobody by 212.82.251.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 09:03:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 21 Mar 2005 09:04:05 +0100 Organization: Lines: 38 Message-ID: <423E7FF5.3B6@xyzzy.claranet.de> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.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.65 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [semi-OT] ISO 639-3, record-jars, and Boontling X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit John Cowan wrote: > This posting is mostly for background information. Very interesting, thanks. It promises that I'll be able to say what I mean instead of ad hoc (ab)uses of country codes or UN numbers to identify regional differences. > the intent is to allow zh-czo, zh-mnp, zh-yue, etc. It's probably difficult to find the appropriate sets, but not impossible. > "Record-jar" format, a merger of RFC-822 headers and the > cookie-jar format devised by Ken Arnold. Yes, that was the name. It's not strictly necessary for Doug's registry, if he has something like Section: Language, then the start of the next registry entry is always clear, even without empty line or "%%". But if the "record-jar" format is common, why not. > It is a jargon or Rotwelsch Just for fun, here's a difficult case for a future ISO 639-3: "German-Yiddish-Romani-Rotwelsch" ># The eeld'm piked for the chigrel nook ># For gorms for her bahl beljeemer; ># The gorms had shied, the nook was strung, ># And the bahl beljeemer had nemer. I see, whatever we do, we must try hard that it never matches "en" as long as there is any better choice. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 04:14:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08160; Mon, 21 Mar 2005 04:14:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJ4K-0006xZ-LE; Mon, 21 Mar 2005 04:19:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDIyD-0005G3-5Q; Mon, 21 Mar 2005 04:13:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDIyA-0005Ct-4x for ltru@megatron.ietf.org; Mon, 21 Mar 2005 04:13:07 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08060 for ; Mon, 21 Mar 2005 04:13:03 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDIw3-0001wl-Q6 for ltru@lists.ietf.org; Mon, 21 Mar 2005 10:10:55 +0100 Received: from 212.82.251.65 ([212.82.251.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 10:10:55 +0100 Received: from nobody by 212.82.251.65 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2005 10:10:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 21 Mar 2005 10:09:08 +0100 Organization: Lines: 57 Message-ID: <423E8F34.7A4F@xyzzy.claranet.de> References: <20050321044949.GEQD4900.mta8.adelphia.net@megatron.ietf.org> <003701c52dde$0e70f2c0$030aa8c0@DEWELL> 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.65 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Debbie is saying we should encode as much information as > possible. You are saying that we should not encode the > script if it is assumed to be the "default." These are > fundamentally opposite viewpoints. Yes, because I dare not declare all existing RfC 3066 software to be obsolete soon. For a completely new scheme that's by definition incompatible I'd opt for Debbie's idea. > You are guessing that users who request "en" don't want the > very small amount of content that exists in any script other > than Latin, I'm guessing that users who request "en" want the RfC 3066 idea of "en", any en-?? plus a few registerd en- like en-boont. > and will know how to request "en-Dsrt" or "en-Shaw" or > "en-Brai" if they want that. Yes, if they want that they can say so. I think you've just found another design problem. Even a default "Latn" does not allow to say "en-Latn" and to get any old "en" minus the new "en-Brai" etc. > I guess this means "RFC 3066bis has serious compatibility > issues with RFC 3066." Can you enumerate these, please, in > a bullet-point list? 1 - old software won't recognize en-Brai-LR, but maybe knows en-LR (you said that it's very different from en) 2 - old content is tagged as en-US etc., We can guess that it's en-Latn-US etc. (if we define default scripts), but that guess would be incorrect if it's actually en-Brai-US etc. For "old" read "almost all" until a new 3066bis is published. > If I request "de" content, say over the Web, I definitely > want to receive content in both "de-1901" and "de-1996", not > just one or the other. But not necessarily de-Brai, so there's definitely a problem. So far I thought that a "default script" would help, but now you confused me, is a "default script" actually worse ? Assuming that it is worse, then we'd need Debbie's idea, we SHOULD say de-Latn in new content, and pray that all old pages are updated. Hell, that's impossible, somewhere I lost it. > This essentially says, "Since you requested English, I'll > assume you can only read it in Latin script, and I won't > send you English content in any other script." Bad. Could I try again with en-Zyyy ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 04:50:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10390; Mon, 21 Mar 2005 04:50:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJd0-0007z0-ER; Mon, 21 Mar 2005 04:55:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDJWw-0000ZG-1s; Mon, 21 Mar 2005 04:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDJWt-0000Z8-RQ for ltru@megatron.ietf.org; Mon, 21 Mar 2005 04:49:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10308 for ; Mon, 21 Mar 2005 04:48:57 -0500 (EST) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJbv-0007wA-Vj for ltru@ietf.org; Mon, 21 Mar 2005 04:54:12 -0500 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id BD4B9252ADC; Mon, 21 Mar 2005 09:48:51 +0000 (GMT) From: "Debbie Garside" To: "'JFC (Jefsey) Morfin'" , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Preparations for smart matching Date: Mon, 21 Mar 2005 09:50:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUttXEdOq0EPbk9Rbqy5vBMJ9i4SAARPa8Q In-Reply-To: <6.1.2.0.2.20050320235957.03f63eb0@mail.jefsey.com> Message-Id: <20050321094851.BD4B9252ADC@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hi My interest is that I am currently writing a Committee Draft (CD) for the proposed ISO 639-6 which covers language variation (written/spoken/signed) and provides a meta-model for an object orientated Language Description Framework (or language registry perhaps). Debbie -----Original Message----- From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] Sent: 20 March 2005 23:12 To: Debbie Garside; 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Re: Preparations for smart matching At 23:12 20/03/2005, Debbie Garside wrote: >My point is... if the information on variant subtag is available, use it... >even though you may not need it for your own purpose. This is what I >see as facilitating, in particular, the semantic web, knowledge >management, archiving and search/query routines. RFC 3066bis seems >intent on making tags as small as possible (am I wrong? Just my >perception), whereas I for my purposes, always want as much information >as possible, split into the tiniest of pieces, I can then >include/exclude/use/concatenate in any way required. > >But then I do have a particular interest in language variants ;-) Dear Debbie, I am not sure your interest is "particular" (this is a need in my case) in the finest granularity. Could you document your need better? Do you think there could be alternative, for example a primary tag refering to a secondary tag which could be called on demand? Or would you be interested in the subtag's semantic supporting several orthogonal/complementary tokens? I would also be interested if your request corresponds to the qualification (for exemple in a reading) or the definition of the language (for example in a web service). Thank you. jfc >Debbie > >-----Original Message----- >From: Doug Ewell [mailto:dewell@adelphia.net] >Sent: 20 March 2005 21:46 >To: LTRU Working Group >Cc: Debbie Garside >Subject: Re: [Ltru] Re: Preparations for smart matching > >With Debbie's permission, I am moving this private thread onto the WG >list, where I feel it belongs. > >Debbie Garside wrote: > > > IMVHO, you should be as succinct as possible when tagging... tag the > > item clearly... whether it is of import to you or not... tag to the > > finest detail... this can only enhance the semantic web of the > > future, end user implementation and interoperability... > >I responded: > > > Are these goals compatible with one another? To me, "be as succinct > > as possible" and "tag to the finest detail" seem contradictory. > > "Succinct" usually implies leaving out details that one might > > consider unnecessary. > >Debbie replied: > > > Succinct, in my view, means as clearly and concisely as possible, as > > much info as you have at your fingertips... not just the info you > > need for your own purpose... think of the wider picture... > >So Debbie is saying that tags with more information are generally >preferable to those with less, even if the additional information could >be considered redundant or implicit. For instance, using the examples >from Section 2.3, "de-CH-1996" and "en-Latn-US" would be considered >preferable to "de" or ("en" or "en-US"). > >I can sympathize with this to some extent, if matching algorithms are >smart enough to interpret such tags properly. The present post, for >example, is not simply in "en" but "en-Latn-US". If I were tagging it, >I could use either tag -- or, for that matter, "en-Latn" or "en-US" -- >and while the additional information (especially 'Latn') might be >obvious, it's not harmful. A good matching algorithm, IMHO, should not >reject my "en-Latn-US" post when requesting "en" content. > >Note, however, that this viewpoint does go against what Section 2.3 of >the draft says. And there is no guarantee that matching algorithms >will meet my definition of "good." > >Conciseness, in and of itself, really doesn't enter into this. There's >no "short way" and "long way" of expressing the exact same thing, >except for "deprecated-alias" situations like "i-klingon" versus "tlh". > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 05:08:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12345; Mon, 21 Mar 2005 05:08:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJv1-0000BA-2v; Mon, 21 Mar 2005 05:13:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDJoG-0002T1-F3; Mon, 21 Mar 2005 05:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDJoD-0002Sd-0H for ltru@megatron.ietf.org; Mon, 21 Mar 2005 05:06:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12207 for ; Mon, 21 Mar 2005 05:06:50 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDJtF-000077-Bg for ltru@ietf.org; Mon, 21 Mar 2005 05:12:05 -0500 Received: from lns-p19-1-idf-82-251-137-16.adsl.proxad.net ([82.251.137.16] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDJo1-0006jm-NP; Mon, 21 Mar 2005 02:06:43 -0800 Message-Id: <6.1.2.0.2.20050321101658.031ffd70@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 21 Mar 2005 10:56:34 +0100 To: "Jukka K. Korpela" , "'LTRU Working Group'" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] multilingualism In-Reply-To: References: <6.1.2.0.2.20050321023551.031b0790@mail.jefsey.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be At 06:08 21/03/2005, Jukka K. Korpela wrote: >On Mon, 21 Mar 2005, JFC (Jefsey) Morfin wrote: > > Does someone knows about an site/effort towards a multilingual support of > > ISO 3166 and of ISO 639? > >That's part of the work of the Common Locale Data Repository activity, >see http://www.unicode.org/cldr/ which already contains a huge amount >of data on names of languages, countries, and other things in different >languages. Dear Jukka, thank you for your response. The cldr work is certainly a big starting point, but I have some problem with it: - the copyrights of Unicode which - to my knowledge - make it dependent to the support of Unicode systems. They certainly reviewed that with IESG to obtain that an RFC requires a compatibility with a private project. But to date there is no mention of this agreement and of its consequences in the Draft (nor of locales in general). I even note that one of the Chairs opposed the idea that ccTLD local name be entered in the locale. This is why I rose the point: if the CLDR is not intended to be made available to all without constraints via the IANA, we should read the Charter as to document the cupport of systems like the CLDR and consider how the data be compiled otherwise. - the XML presentation. I look for a formated compact database with easy daily update/downloads. - security and scalabiliy. The obvious problem is cross-consistency checking by concerned people themselves and constant verification tools. Internet has a very stable, proven, database distributed system to support that kind of information: the DNS logic which can be/is used to many other things than the domain names, as an independent system or not. Getting the context of a site from an XML tag calls for a web site. > > Today descriptions are in English and in French. This is not adequate to a > > menu in Chinese or for a Russian user. I suppose most of the main languages > > have an ISO 3166 translation, but I did not find a site. > >Software vendors have had to define localized names for use in menus >and other contexts, but the names have often been incorrect and >there have been unnecessary and confusing differences. They really >don't want to do such things but implement definitions based on >expert work and consensus in different countries. Hence CLDR. Fully true. This is why I ask as I see nothing in the Draft. thank you for your help. jfc ====================================================== Standardizing Tags for the Identification of Languages should not be a way to standardize languages and to unify the world under a dominant culture. ====================================================== For your convenience: RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066 Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ====================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ====================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ====================================================== It seems that what works for countries and ISO 3166 since 1978, should apply to languages and to ISO 693. ====================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 05:55:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16096; Mon, 21 Mar 2005 05:55:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDKe0-0001Ym-Iv; Mon, 21 Mar 2005 06:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDKYO-0008Ph-89; Mon, 21 Mar 2005 05:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDKYN-0008Pc-02 for ltru@megatron.ietf.org; Mon, 21 Mar 2005 05:54:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16059 for ; Mon, 21 Mar 2005 05:54:32 -0500 (EST) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDKdO-0001X4-Jn for ltru@ietf.org; Mon, 21 Mar 2005 05:59:48 -0500 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id B6D54253463; Mon, 21 Mar 2005 10:54:25 +0000 (GMT) From: "Debbie Garside" To: "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Preparations for smart matching Date: Mon, 21 Mar 2005 10:55:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUt9ktkSrx3DthfQDuNT/tk+JlRKwADSa8Q In-Reply-To: <423E8F34.7A4F@xyzzy.claranet.de> Message-Id: <20050321105425.B6D54253463@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Frank Ellerman: wrote "Assuming that it is worse, then we'd need Debbie's idea, we SHOULD say de-Latn in new content, and pray that all old pages are updated. Hell, that's impossible, somewhere I lost it." What I said about detail was really about variant subtags but it is OK to apply it everywhere...consistency is also the name of the game... as it also assists the end user which is my primary focus. I hate to throw a spanner in the works here but still on the subject of detail... Exactly how much detail can be gleaned from a script code... Should we perhaps be looking in even finer detail and at extensibility issues e.g. en-Character_Set-US At least you would end up with something useful, forward looking and extendable... :-) Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Frank Ellermann Sent: 21 March 2005 09:09 To: ltru@ietf.org Subject: [Ltru] Re: Preparations for smart matching Doug Ewell wrote: > Debbie is saying we should encode as much information as possible. > You are saying that we should not encode the script if it is assumed > to be the "default." These are fundamentally opposite viewpoints. Yes, because I dare not declare all existing RfC 3066 software to be obsolete soon. For a completely new scheme that's by definition incompatible I'd opt for Debbie's idea. > You are guessing that users who request "en" don't want the very small > amount of content that exists in any script other than Latin, I'm guessing that users who request "en" want the RfC 3066 idea of "en", any en-?? plus a few registerd en- like en-boont. > and will know how to request "en-Dsrt" or "en-Shaw" or "en-Brai" if > they want that. Yes, if they want that they can say so. I think you've just found another design problem. Even a default "Latn" does not allow to say "en-Latn" and to get any old "en" minus the new "en-Brai" etc. > I guess this means "RFC 3066bis has serious compatibility issues with > RFC 3066." Can you enumerate these, please, in a bullet-point list? 1 - old software won't recognize en-Brai-LR, but maybe knows en-LR (you said that it's very different from en) 2 - old content is tagged as en-US etc., We can guess that it's en-Latn-US etc. (if we define default scripts), but that guess would be incorrect if it's actually en-Brai-US etc. For "old" read "almost all" until a new 3066bis is published. > If I request "de" content, say over the Web, I definitely want to > receive content in both "de-1901" and "de-1996", not just one or the > other. But not necessarily de-Brai, so there's definitely a problem. So far I thought that a "default script" would help, but now you confused me, is a "default script" actually worse ? Assuming that it is worse, then we'd need Debbie's idea, we SHOULD say de-Latn in new content, and pray that all old pages are updated. Hell, that's impossible, somewhere I lost it. > This essentially says, "Since you requested English, I'll assume you > can only read it in Latin script, and I won't send you English content > in any other script." Bad. Could I try again with en-Zyyy ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 09:37:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09641; Mon, 21 Mar 2005 09:37:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDO7T-0001tp-Po; Mon, 21 Mar 2005 09:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDO2G-0008H5-Gf; Mon, 21 Mar 2005 09:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDO2E-0008Gx-Pg for ltru@megatron.ietf.org; Mon, 21 Mar 2005 09:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09608 for ; Mon, 21 Mar 2005 09:37:36 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDO7I-0001tV-89 for ltru@ietf.org; Mon, 21 Mar 2005 09:42:53 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2LEbRsm024119 for ; Mon, 21 Mar 2005 09:37:27 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 21 Mar 2005 09:37:25 -0500 Date: Mon, 21 Mar 2005 09:37:25 -0500 From: John Cowan To: ltru@ietf.org Subject: Re: [Ltru] Re: Preparations for smart matching Message-ID: <20050321143725.GL15741@skunk.reutershealth.com> References: <6.1.2.0.2.20050320235957.03f63eb0@mail.jefsey.com> <20050321094851.BD4B9252ADC@smtp.nildram.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050321094851.BD4B9252ADC@smtp.nildram.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Debbie Garside scripsit: > My interest is that I am currently writing a Committee Draft (CD) for the > proposed ISO 639-6 which covers language variation (written/spoken/signed) > and provides a meta-model for an object orientated Language Description > Framework (or language registry perhaps). I think it worth mentioning that there is no ISO 639-6 on the current programme of work of ISO TC 37 / SC 2. (My reference in an earlier posting to ISO/IEC JTC 1 was a mistake, and should be disregarded.) So at the moment Debbie's draft has no official status with ISO. ISO 639-4 (general principles) and ISO 639-5 (codes for groups of languages) are in progress, but are irrelevant to RFC 3066bis. -- How they ever reached any conclusion at all jcowan@reutershealth.com> is starkly unknowable to the human mind. http://www.reutershealth.com --"Backstage Lensman", Randall Garrett http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 10:11:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14129; Mon, 21 Mar 2005 10:11:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDOeM-0003PJ-1Z; Mon, 21 Mar 2005 10:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOWN-0004DL-0h; Mon, 21 Mar 2005 10:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOWL-0004DF-3g for ltru@megatron.ietf.org; Mon, 21 Mar 2005 10:08:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13730 for ; Mon, 21 Mar 2005 10:08:43 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDObP-0003K7-6N for ltru@ietf.org; Mon, 21 Mar 2005 10:14:00 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2LF8Xt6024373; Mon, 21 Mar 2005 10:08:34 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 21 Mar 2005 10:08:36 -0500 Date: Mon, 21 Mar 2005 10:08:36 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [semi-OT] ISO 639-3, record-jars, and Boontling Message-ID: <20050321150836.GN15741@skunk.reutershealth.com> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.com> <423E7FF5.3B6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423E7FF5.3B6@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Frank Ellermann scripsit: > Just for fun, here's a difficult case for a future ISO 639-3: > > "German-Yiddish-Romani-Rotwelsch" ISO 639-3 is basically Ethnologue with some of the codes changed for various reasons. > I see, whatever we do, we must try hard that it never matches > "en" as long as there is any better choice. Indeed. That's why it really should be registered as a language IMHO. -- John Cowan jcowan@reutershealth.com www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 10:37:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17383; Mon, 21 Mar 2005 10:37:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDP3W-0004Ps-80; Mon, 21 Mar 2005 10:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOxo-0008Gi-N5; Mon, 21 Mar 2005 10:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDOxm-0008GY-PV for ltru@megatron.ietf.org; Mon, 21 Mar 2005 10:37:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17304 for ; Mon, 21 Mar 2005 10:37:04 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDP2r-0004J3-1b for ltru@ietf.org; Mon, 21 Mar 2005 10:42:22 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 07:36:55 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 07:36:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Mon, 21 Mar 2005 07:37:04 -0800 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling thread-index: AcUtwDeytT4PN+TjRzGfgv3asIhTBQAa0ZwQ From: "Peter Constable" To: X-OriginalArrivalTime: 21 Mar 2005 15:36:54.0930 (UTC) FILETIME=[CF7A5720:01C52E2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > The reason for putting this facility off to RFC 3066ter is that ISO 639-3 > is only an editor's draft at this point. Clarification: in ISO-speak: it is at Enquiry Draft stage. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 10:48:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18222; Mon, 21 Mar 2005 10:47:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPDR-0004lA-Hx; Mon, 21 Mar 2005 10:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDP7h-0000xP-T7; Mon, 21 Mar 2005 10:47:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDP7g-0000wk-Uq for ltru@megatron.ietf.org; Mon, 21 Mar 2005 10:47:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18110 for ; Mon, 21 Mar 2005 10:47:18 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPCl-0004j2-64 for ltru@ietf.org; Mon, 21 Mar 2005 10:52:36 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1DDP7U-0006Cp-55; Mon, 21 Mar 2005 10:47:08 -0500 Date: Mon, 21 Mar 2005 10:47:08 -0500 To: Peter Constable Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Message-ID: <20050321154708.GA23615@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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Peter Constable scripsit: > Clarification: in ISO-speak: it is at Enquiry Draft stage. The ISO page on it says it's out for DIS ballot. Is that wrong? -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Allen Brown cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 11:30:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24143; Mon, 21 Mar 2005 11:30:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPsR-0006Rd-UD; Mon, 21 Mar 2005 11:35:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPmT-00005L-70; Mon, 21 Mar 2005 11:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPmS-00005G-1b for ltru@megatron.ietf.org; Mon, 21 Mar 2005 11:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23995 for ; Mon, 21 Mar 2005 11:29:25 -0500 (EST) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPrW-0006Pe-Tq for ltru@ietf.org; Mon, 21 Mar 2005 11:34:44 -0500 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN8-9423ef64b152; Mon, 21 Mar 2005 11:29:00 -0500 Received: from DEBHOME (ACD7A505.ipt.aol.com [172.215.165.5]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2LGSnaq028891; Mon, 21 Mar 2005 11:28:49 -0500 Message-Id: <200503211628.j2LGSnaq028891@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'John Cowan'" , "'Peter Constable'" Subject: RE: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Mon, 21 Mar 2005 16:28:03 -0000 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: AcUuLV5G5qJcR0qVQGGNCMLoFpaVlAABYN5g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050321154708.GA23615@ccil.org> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 2.6 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Alas ...Alack... it seems all cannot be believed on the ISO page... :-) Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of John Cowan Sent: 21 March 2005 15:47 To: Peter Constable Cc: ltru@ietf.org Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Peter Constable scripsit: > Clarification: in ISO-speak: it is at Enquiry Draft stage. The ISO page on it says it's out for DIS ballot. Is that wrong? -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Allen Brown cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 11:31:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24300; Mon, 21 Mar 2005 11:31:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPu1-0006Zf-Hw; Mon, 21 Mar 2005 11:37:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPoO-0000NW-LR; Mon, 21 Mar 2005 11:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPoM-0000NM-Pm for ltru@megatron.ietf.org; Mon, 21 Mar 2005 11:31:26 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24285 for ; Mon, 21 Mar 2005 11:31:24 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050321163052.KKAC12278.mta9.adelphia.net@DEWELL> for ; Mon, 21 Mar 2005 11:30:52 -0500 Message-ID: <001801c52e33$538bae40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050321153725.LWSH2135.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 21 Mar 2005 08:30:41 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> Debbie is saying we should encode as much information as >> possible. You are saying that we should not encode the >> script if it is assumed to be the "default." These are >> fundamentally opposite viewpoints. > > Yes, because I dare not declare all existing RfC 3066 software > to be obsolete soon. For a completely new scheme that's by > definition incompatible I'd opt for Debbie's idea. The vast majority of tags created under RFC 3066bis will NOT contain script subtags. They are there for when someone deems them necessary. >> You are guessing that users who request "en" don't want the >> very small amount of content that exists in any script other >> than Latin, > > I'm guessing that users who request "en" want the RfC 3066 idea > of "en", any en-?? plus a few registerd en- like en-boont. That is not what your suggestion does, though. It collapses "en-Latn" to "en" in matching, on the basis of Latin being considered the "default script" for English. This means either (a) a search for "en" will return only "en-Latn", which is not compatible with the RFC 3066 interpretation, or (b) a search for "en-Latn" will return all "en", which is not what the user asked for. (Bear in mind, throughout this post, that "user" could mean "software" or "user agent." It's software-engineering shorthand.) >> and will know how to request "en-Dsrt" or "en-Shaw" or >> "en-Brai" if they want that. > > Yes, if they want that they can say so. I think you've just > found another design problem. Even a default "Latn" does not > allow to say "en-Latn" and to get any old "en" minus the new > "en-Brai" etc. Well, I think that's a design problem with the whole "default script" idea. And I think asking for "all scripts except Braille" is probably out of scope for this project. >> I guess this means "RFC 3066bis has serious compatibility >> issues with RFC 3066." Can you enumerate these, please, in >> a bullet-point list? > > 1 - old software won't recognize en-Brai-LR, but maybe knows > en-LR (you said that it's very different from en) If the user requests "en-Brai-LR", she is making a very particular request that could not have been fulfilled under RFC 3066 in any circumstance (unless "en-Brai-LR" were explicitly registered. Since this wouldn't have worked under RFC 3066, it seems odd to consider it an incompatibility, unless you are saying that the whole script-subtag idea should be deleted (which would take away one of the main purposes of RFC 3066bis). > 2 - old content is tagged as en-US etc., We can guess that it's > en-Latn-US etc. (if we define default scripts), but that > guess would be incorrect if it's actually en-Brai-US etc. Content tagged as "en-US" cannot be assumed to be in any particular script, although Latin would be a good guess. Content tagged as "en-Latn-US" or "en-Brai-US" can be assumed to be in Latin or Braille respectively. >> If I request "de" content, say over the Web, I definitely >> want to receive content in both "de-1901" and "de-1996", not >> just one or the other. > > But not necessarily de-Brai, so there's definitely a problem. > So far I thought that a "default script" would help, but now > you confused me, is a "default script" actually worse ? I think it is. It assumes certain information that I don't think is safe to assume, and it makes certain types of requests (like "English in any script imaginable") impossible (or at least counterintuitive and non-3066-compatible; see Zyyy example below). A better solution would be to perform matching based on subtags. That way, content can be marked as "en" or "en-US" or "en-Latn-US", and the user can request any of those, and matching will take place as appropriate. > Assuming that it is worse, then we'd need Debbie's idea, we > SHOULD say de-Latn in new content, and pray that all old pages > are updated. Hell, that's impossible, somewhere I lost it. Nobody proposes that old data be "updated." >> This essentially says, "Since you requested English, I'll >> assume you can only read it in Latin script, and I won't >> send you English content in any other script." > > Bad. Could I try again with en-Zyyy ? Bye, Frank OK, you have a point. There is a subtag 'Zyyy' which means "Code for undetermined script." That would allow users to request "English in any script," but in a way that is incompatible with RFC 3066 -- which I know is important to you. Under RFC 3066: "en" means English in any script "en-Latn" is not registered, so not allowed "en-Zyyy" is not registered, so not allowed Under RFC 3066bis, current draft: "en" means English in any script "en-Latn" means English in Latin script "en-Zyyy" means English in any script Under RFC 3066bis with your "default script" idea: "en" means English in Latin script (default) "en-Latn" means English in Latin script (explicit) "en-Zyyy" means English in any script -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 12:11:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27551; Mon, 21 Mar 2005 12:11:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDQWi-0007yZ-HO; Mon, 21 Mar 2005 12:17:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDQR7-0006lv-Ab; Mon, 21 Mar 2005 12:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDQR5-0006k8-A3 for ltru@megatron.ietf.org; Mon, 21 Mar 2005 12:11:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27525 for ; Mon, 21 Mar 2005 12:11:22 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDQW9-0007xW-14 for ltru@ietf.org; Mon, 21 Mar 2005 12:16:41 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2LHB7XP017521 for ; Mon, 21 Mar 2005 12:11:07 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2LHB7N4092324 for ; Mon, 21 Mar 2005 12:11:07 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2LHAvYV030383 for ; Mon, 21 Mar 2005 12:10:57 -0500 Received: from markdavis (sig-9-48-115-56.mts.ibm.com [9.48.115.56]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2LHAuO8029968; Mon, 21 Mar 2005 12:10:56 -0500 Message-ID: <014f01c52e38$f1b9a950$38733009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <20050321044949.GEQD4900.mta8.adelphia.net@megatron.ietf.org> <003c01c52de1$f988a2a0$030aa8c0@DEWELL> Subject: Question: (was Re: [Ltru] Re: Populating the initial registry: Languages) Date: Mon, 21 Mar 2005 09:10:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j2LHB7XP017521 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable > QUESTION: Should the rules for populating the registry be changed to > exclude ISO 639 codes deprecated before a certain date? If so, what > should that date be? > > PRO: This might reduce user confusion, and would leave the door open > for ISO 639 to reassign these codes (which they have never done). > > CON: Many reference sources actually encouraged users to continue usin= g > the old codes 'in', 'iw', and 'he' for years after they were deprecated= , > on the basis that old software would be more likely to recognize the ol= d > codes. The safest and most robust policy is allow all codes that have ever been permitted by the source standards. My reasons are that (a) because of the instability of such sources, it was indeed a reasonabl= e tactic to take use the first defined code for a given semantic, and that tactic was in widespread use, and (b) because 3066 and 1766 did not take into account the instability of th= e source standards, it was never clear which codes were in fact valid at an= y point in time for use in 3066 or 1766, so there was no guidance as to whi= ch code to use, or with what semantics. However, because of the reuse of codes for unrelated entities by the sour= ce standards, we do have to impose some order in those cases where there is = a conflict. For that, we have had in the drafts the use of a cut-off date f= or deciding which semantic to use in case of a conflict, such as with 'CS'. = In that particular case there is sufficient consensus to make that after the redefinition of CS to mean "Serbia and Montenegro": a date of January 1 2= 005 would capture that consensus. It would be safest not to put it at date of publication, simply because that take the risk (probably small, but unfortunately real) that the source standards would redefine a code after the draft has been discussed and approved, but before publication. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Sunday, March 20, 2005 22:48 Subject: [Ltru] Re: Populating the initial registry: Languages > Frank Ellermann wrote: > > >>> Step 2: Deprecated ISO 639 codes > > > > How about a special rule "skip jw" ? The normative references > > are ISO 639-1:2002 and ISO 639-2:1998, that could justify to > > omit an old typo fixed 1988 (?) or 2001 (?). > > If you don't mind, I'd like to phrase this as a question for the group, > instead of simply continung to say "such-and-so could be done," which > doesn't seem to generate any WG feedback. > > QUESTION: Should the rules for populating the registry be changed to > exclude ISO 639 codes deprecated before a certain date? If so, what > should that date be? > > PRO: This might reduce user confusion, and would leave the door open > for ISO 639 to reassign these codes (which they have never done). > > CON: Many reference sources actually encouraged users to continue usin= g > the old codes 'in', 'iw', and 'he' for years after they were deprecated= , > on the basis that old software would be more likely to recognize the ol= d > codes. > > A side note: Please don't take the fact that I am presenting this issue > as a question for the group as evidence that I support the idea. > > > Your second source (codechanges.html) says that it's currently > > updated. Apparently they forgot the "-" for a "-jw", but you > > said that your script ignores the "-". > > Yes, they did forget the hyphen to indicate that "jw" is now deprecated. > > BTW, for those who found my e-mail message on this subject difficult to > read, I've turned it into a Web page (including errata). Eventually > this will include steps to populate the entire registry. I'm waiting > for feedback on the language part before finishing the other parts. Th= e > address is: > > http://users.adelphia.net/~dewell/init-registry.html > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 13:34:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03465; Mon, 21 Mar 2005 13:34:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRo9-0002HX-30; Mon, 21 Mar 2005 13:39:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRgO-0003bg-97; Mon, 21 Mar 2005 13:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDRgM-0003Wg-46 for ltru@megatron.ietf.org; Mon, 21 Mar 2005 13:31:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03290 for ; Mon, 21 Mar 2005 13:31:15 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDRlS-0002EV-53 for ltru@ietf.org; Mon, 21 Mar 2005 13:36:35 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 10:31:07 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 10:31:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Mon, 21 Mar 2005 10:31:17 -0800 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling thread-index: AcUuLT8MMYVzfDm0RqSzuB4NJoah9wAFpS4w From: "Peter Constable" To: X-OriginalArrivalTime: 21 Mar 2005 18:31:07.0231 (UTC) FILETIME=[2588E6F0:01C52E44] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:cowan@ccil.org] > > Clarification: in ISO-speak: it is at Enquiry Draft stage. >=20 > The ISO page on it says it's out for DIS ballot. Is that wrong? No; an Equiry Draft (actually, that's ISO/IEC-speak) is also know in ISO as a DIS. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 21:27:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27714; Mon, 21 Mar 2005 21:27:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDZCO-0005TP-2j; Mon, 21 Mar 2005 21:32:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDZ6K-0008VE-7U; Mon, 21 Mar 2005 21:26:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDZ6J-0008V9-Gm for ltru@megatron.ietf.org; Mon, 21 Mar 2005 21:26:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27665 for ; Mon, 21 Mar 2005 21:26:33 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDZBT-0005SU-CT for ltru@ietf.org; Mon, 21 Mar 2005 21:31:56 -0500 Received: from lns-p19-1-idf-82-251-137-16.adsl.proxad.net ([82.251.137.16] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDZ6B-0008JZ-Go; Mon, 21 Mar 2005 18:26:28 -0800 Message-Id: <6.1.2.0.2.20050322031307.03db5930@pop.online.fr> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 22 Mar 2005 03:26:19 +0100 To: "randy Presuhn" , Martin Duerst From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ltRU Working Group Subject: [Ltru] we will produce another draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 we decided to pursue on your suggestion and to produce another Draft for this WG-ltru. 1. please indicate which file name we should use. The draft will be produced by several WG-ltru Members. (I am not sure I will be among them) 2. we want to make sure this Draft supports the needs of the W3C and CDLR as expressed in the Addison Philips/Mark Davis' Draft. We count on their assistance. 3. we plan having an initial draft presented in two to three weeks. We are interested in hearing about every proposition/need not documented in the current Draft. Best regards. jfc morfin AFRAC, VP R&D http://afrac.org ====================================================== Standardizing Tags for the Identification of Languages should not be a way to standardize languages and to unify the world under a dominant culture. ====================================================== For your convenience: RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066 Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ====================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ====================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ====================================================== It seems that what works for countries and ISO 3166 since 1978, should apply to languages and to ISO 693. ====================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 21:48:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29134; Mon, 21 Mar 2005 21:48:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDZWL-00069u-27; Mon, 21 Mar 2005 21:53:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDZQ5-000402-Mt; Mon, 21 Mar 2005 21:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDP9l-0001LA-Pw for ltru@megatron.ietf.org; Mon, 21 Mar 2005 10:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18514 for ; Mon, 21 Mar 2005 10:49:27 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDPEp-0004qD-Hu for ltru@ietf.org; Mon, 21 Mar 2005 10:54:45 -0500 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 21 Mar 2005 15:47:15 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 15:47:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Mon, 21 Mar 2005 15:47:05 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A143@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUuJFKogZvdvWmxQniAE4HUlvkrlQAAbMLg From: "L.Gillam" To: ltru X-OriginalArrivalTime: 21 Mar 2005 15:47:05.0401 (UTC) FILETIME=[3B58D290:01C52E2D] X-Spam-Score: 1.8 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Mar 2005 21:47:00 -0500 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 1.8 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable John,=20 I think this is a time where one should at least ask = questions of the messenger, and perhaps consider less extreme forms of = punitive actions - please see: http://isotc.iso.org/livelink/livelink/fetch/2000/2122/687806/ISO_TC_037_= _Terminology_and_other_language_resources_.pdf?nodeid=3D1160801&vernum=3D= 0 The ISO NWIP was accepted in August 2004 - status apparently the same as = 639-5. Draft documents, including those written for CD, are part of the = standards workflow. Such a document, when submitted, would undergo = ballot by member bodies of TC 37. CD is a natural progression of a NWIP. = The CD is being prepared in follow-up to the NWIP. If by "official = status" you mean "it hasn't been voted on" then I agree, but your = comment could also be interpreted that what she is writing has nothing = whatsoever to do with this process. 639-5 appears to provide a structure in which to make sense of 639-3 - = looking awfully like the structure of Ethnologue. 639-5 will also fish = the alpha3 pool. A draft (CD perhaps) of 639-5 contains a list of these = alpha3s. Whether this list is included in the final document is not = clear. Currently the alpha3 list of -3 will not be in the published = standard as I understand it (Peter Constable should be able to confirm = whether this position has changed). General principles and groups of = languages may be irrelevant to 3066bis, but eventually - in some = none-too-distant future one suspects - smart matching will also have to = take into account the specialisation/generalisation relationships as = composed by these 2 - which is somewhat orthogonal to current 3066 = "tag-dropping" practice. Additionally, the general principles will form = a mechanism for integration with other ISO 11179-3 metadata registries = such as those under development in other subcommittees of TC 37. -4 as = currently perceived will be something like a "Language Description = Framework", echoing principles applied in development of ISO 16642 (/ISO = 12620 revision) to language codes. The terminology model (language = [concept], language naming section [language section], language names = [terms]) would, one hopes, provide a means for M. Morfin's thesaurus of = language names, although not a fully-functional solution (OT - I've not = yet understood if in having a .uk domain we can't include content in = non-UK languages on a web-site. Perhaps I've missed the point here too). At this point I should promote a related research activity = http://portal.surrey.ac.uk/portal/page?_pageid=3D798,337934&_dad=3Dportal= &_schema=3DPORTAL for which the actual website is in development at = INRIA. Best Regards. > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of John Cowan > Sent: 21 March 2005 14:37 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Preparations for smart matching >=20 >=20 > Debbie Garside scripsit: >=20 > > My interest is that I am currently writing a Committee=20 > Draft (CD) for the > > proposed ISO 639-6 which covers language variation=20 > (written/spoken/signed) > > and provides a meta-model for an object orientated Language=20 > Description > > Framework (or language registry perhaps).=20 >=20 > I think it worth mentioning that there is no ISO 639-6 on the current > programme of work of ISO TC 37 / SC 2. (My reference in an earlier > posting to ISO/IEC JTC 1 was a mistake, and should be disregarded.) > So at the moment Debbie's draft has no official status with ISO. >=20 > ISO 639-4 (general principles) and ISO 639-5 (codes for groups of > languages) are in progress, but are irrelevant to RFC 3066bis. >=20 > --=20 > How they ever reached any conclusion at all =20 > jcowan@reutershealth.com> > is starkly unknowable to the human mind. =20 > http://www.reutershealth.com > --"Backstage Lensman", Randall Garrett =20 > http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 21 22:06:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00675; Mon, 21 Mar 2005 22:06:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDZng-0006r3-13; Mon, 21 Mar 2005 22:11:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDZi0-00074X-FJ; Mon, 21 Mar 2005 22:05:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDZhy-00074P-Bm for ltru@megatron.ietf.org; Mon, 21 Mar 2005 22:05:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00614 for ; Mon, 21 Mar 2005 22:05:28 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDZn7-0006pp-Qv for ltru@ietf.org; Mon, 21 Mar 2005 22:10:52 -0500 Received: from h-68-165-3-16.snvacaid.dynamic.covad.net ([68.165.3.16] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1DDZhp-0000fh-00 for ltru@ietf.org; Mon, 21 Mar 2005 19:05:22 -0800 Message-ID: <001e01c52e8c$14715d00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.1.2.0.2.20050322031307.03db5930@pop.online.fr> Date: Mon, 21 Mar 2005 19:06:01 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] Re: we will produce another draft X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - > From: "JFC (Jefsey) Morfin" > To: "randy Presuhn" ; "Martin Duerst" > Cc: "ltRU Working Group" > Sent: Monday, March 21, 2005 6:26 PM > Subject: we will produce another draft > > we decided to pursue on your suggestion and to produce another Draft for > this WG-ltru. This welcome news. It's helpful to have specific text to discuss. > 1. please indicate which file name we should use. The draft will be > produced by several WG-ltru Members. (I am not sure I will be among them) ... Since this would be an individual submission, the name will have the form draft-AUTHOR-SUBJECT-00.txt where AUTHOR is the surname of one of the authors, and SUBJECT has some mnemonic value. For details on this and other important considerations, please see http://www.ietf.org/ietf/1id-guidelines.txt When the draft has been posted, please forward the accouncement to ltru@ietf.org. Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 01:40:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17138; Tue, 22 Mar 2005 01:40:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDd8s-0005ro-2p; Tue, 22 Mar 2005 01:45:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDd31-0001qU-Nf; Tue, 22 Mar 2005 01:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDd2z-0001qM-6l for ltru@megatron.ietf.org; Tue, 22 Mar 2005 01:39:25 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17099 for ; Tue, 22 Mar 2005 01:39:24 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050322063853.QJXG5402.mta11.adelphia.net@DEWELL> for ; Tue, 22 Mar 2005 01:38:53 -0500 Message-ID: <005301c52ea9$c6346380$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 21 Mar 2005 22:38:34 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit L.Gillam wrote: > (OT - I've not yet understood if in having a .uk domain we can't > include content in non-UK languages on a web-site. Perhaps I've > missed the point here too). As I keep saying: Country codes used as ccTLDs have NOTHING to do with country codes used in language tags. Of course, you can post content on your site in any language you like. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 03:02:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13304; Tue, 22 Mar 2005 03:02:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDeQ9-0008RU-Jl; Tue, 22 Mar 2005 03:07:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDeHO-0000hO-Ak; Tue, 22 Mar 2005 02:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDeHG-0000h9-L7 for ltru@megatron.ietf.org; Tue, 22 Mar 2005 02:58:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13106 for ; Tue, 22 Mar 2005 02:58:13 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDeMU-0008HR-KV for ltru@ietf.org; Tue, 22 Mar 2005 03:03:39 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 23:58:04 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 23:58:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Preparations for smart matching Date: Mon, 21 Mar 2005 23:58:14 -0800 Message-ID: Thread-Topic: [Ltru] Preparations for smart matching thread-index: AcUsjGNsFNye2bekSxeyw1W5bYNkGgCIyXsQ From: "Peter Constable" To: X-OriginalArrivalTime: 22 Mar 2005 07:58:04.0974 (UTC) FILETIME=[E0C22CE0:01C52EB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: Saturday, March 19, 2005 5:57 AM > Hi, so far en-Latn-US-boont not matching en-boont is one of my > standard examples why I have a problem with 3066bis as it is. >=20 > This could be solved later by a smarter matching strategy. Or > by subtags used in the order of their importance, something > like en-boont-Latn-US would match en-boont with the normal RTL > strategy. A couple of comments.=20 First, you haven't defined what the "importance" metric is, and on the surface it appears to be merely that e.g. "boont" is more important wrt "en" than are "Latn" or "US" because there is a registered legacy tag "en-boont". That alone is not a particularly insightful metric -- it is based only on formal properties of the tags and nothing else. I think it would be more useful to define a metric in terms of something like desired functionality in particular scenarios. Secondly, I think this example is not a particularly good one for what you're evaluating since the qualifiers "Latn" and "US" would, in the 99.9% case be redundant / assumed and so would not be included in the tag. It's far more useful to consider scenarios in which qualifying subtags are reasonably likely to be used, as in cases such as e.g. zh-Hans-HK. (If you want to use "en-Latn-US-boont" merely as an example for sake of discussion, that's fine, provided we keep in mind those considerations.) Thirdly, no matter what the order of subtags, there will always be valid scenarios in which left-prefix-based matching does not provide the functionality you'd like. It's just an inherent limitation of that approach to finding matches. (I pointed this out in 2001 when we were discussing the request for de-1901 etc. tags.) The appropriate steps, then, are (i) to identify what ordering of subtags provides the best results generally for important or widely-used algorithms that have this limitation, and (ii) to consider what alternative approaches to matching might be possible. (Of course, hence this thread and work item.) =20 > So the last chance is smart matching. To be smart the matching > algorithm needs some input... Of course, one of the goals for the syntax proposed in the draft is to narrow the set of possible tags from what was allowed under RFC 3066 in a way that allows the type of each subtag always to be determined without knowing what specific entity the subtag actually denotes or refers to. Even if I don't know what specific script "Jpqx" referred to, I know for certain that in "de-Jpqx" this subtag must refer to a script. > So de-Latn-US-boot won't match de-boont, because boont is only > registered for use with en. Does that make any sense ? If yes > we need optional default scripts for languages, and maybe also > default languages for all variants in the registry. Bye, Frank I think it makes sense. On the other hand, the practicality of documenting default scripts for languages and other things of that ilk is not obvious. Not long ago, there was a discussion regarding compiling a list of valid language/country combinations, and one thing that reinforced for me that such tasks are far from trivial undertakings. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 04:13:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20003; Tue, 22 Mar 2005 04:13:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDfXd-0002bd-1P; Tue, 22 Mar 2005 04:19:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDfS4-0006V6-Po; Tue, 22 Mar 2005 04:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDfS2-0006T9-6K for ltru@megatron.ietf.org; Tue, 22 Mar 2005 04:13:26 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19992 for ; Tue, 22 Mar 2005 04:13:23 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDfPW-00005r-Kb for ltru@lists.ietf.org; Tue, 22 Mar 2005 10:10:50 +0100 Received: from c-134-89-65.hh.dial.de.ignite.net ([62.134.89.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 10:10:50 +0100 Received: from nobody by c-134-89-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 10:10:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 22 Mar 2005 10:12:31 +0100 Organization: Lines: 12 Message-ID: <423FE17F.7B0B@xyzzy.claranet.de> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.com> <423E7FF5.3B6@xyzzy.claranet.de> <20050321150836.GN15741@skunk.reutershealth.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: c-134-89-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [semi-OT] ISO 639-3, record-jars, and Boontling X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit John Cowan wrote: > ISO 639-3 is basically Ethnologue with some of the codes > changed for various reasons. And where does it place YEC, de-yec, yi-yec, gem-yec, ... ? RfC 3066 software seeing YEC as "de" content would be a PITA, lust like en-boont as a part of "en". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 04:15:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20051; Tue, 22 Mar 2005 04:15:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDfYp-0002cb-US; Tue, 22 Mar 2005 04:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDfSv-0006oL-65; Tue, 22 Mar 2005 04:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDfSt-0006ml-2a for ltru@megatron.ietf.org; Tue, 22 Mar 2005 04:14:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20025 for ; Tue, 22 Mar 2005 04:14:17 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDfY6-0002bv-Tg for ltru@ietf.org; Tue, 22 Mar 2005 04:19:44 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 22 Mar 2005 09:11:55 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 09:11:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Preparations for smart matching Date: Tue, 22 Mar 2005 09:15:01 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A151@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUuqgEXFkvZU7+eTI6UJ63UbJosBQAE2CLg From: "L.Gillam" To: ltru X-OriginalArrivalTime: 22 Mar 2005 09:11:53.0264 (UTC) FILETIME=[30399B00:01C52EBF] X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1206396810==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f --===============1206396810== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNClRoYW5rcyBEb3VnLCBzYW5pdHkgZnVsbHkgYW5kIGZpbmFsbHkgcmVpbmZvcmNlZC4gDQoN Ckl0J3MgZ29vZCB0aGF0IHdlIGRvbid0IGFsbCBuZWVkIHRvIGdvIGFyb3VuZCByZWdpc3Rlcmlu ZyANCm90aGVyIGRvbWFpbiBuYW1lcyBqdXN0IGJlY2F1c2Ugd2UgaGF2ZSBjb250ZW50IGluIGRp ZmZlcmVudCANCmxhbmd1YWdlcy4gDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB3aGF0IGEgYnVzaW5l c3Mgb3Bwb3J0dW5pdHkuLi4uDQoNCj4gDQo+IEwuR2lsbGFtIDxMIGRvdCBHaWxsYW0gYXQgc3Vy cmV5IGRvdCBhYyBkb3QgdWs+IHdyb3RlOg0KPiANCj4gPiAoT1QgLSBJJ3ZlIG5vdCB5ZXQgdW5k ZXJzdG9vZCBpZiBpbiBoYXZpbmcgYSAudWsgZG9tYWluIHdlIGNhbid0DQo+ID4gaW5jbHVkZSBj b250ZW50IGluIG5vbi1VSyBsYW5ndWFnZXMgb24gYSB3ZWItc2l0ZS4gUGVyaGFwcyBJJ3ZlDQo+ ID4gbWlzc2VkIHRoZSBwb2ludCBoZXJlIHRvbykuDQo+IA0KPiBBcyBJIGtlZXAgc2F5aW5nOiAg Q291bnRyeSBjb2RlcyB1c2VkIGFzIGNjVExEcyBoYXZlIE5PVEhJTkcgDQo+IHRvIGRvIHdpdGgN Cj4gY291bnRyeSBjb2RlcyB1c2VkIGluIGxhbmd1YWdlIHRhZ3MuDQo+IA0KPiBPZiBjb3Vyc2Us IHlvdSBjYW4gcG9zdCBjb250ZW50IG9uIHlvdXIgc2l0ZSBpbiBhbnkgbGFuZ3VhZ2UgeW91IGxp a2UuDQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAgRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ICBodHRw Oi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0 DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydQ0KPiANCg== --===============1206396810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1206396810==-- From ltru-bounces@ietf.org Tue Mar 22 04:39:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22164; Tue, 22 Mar 2005 04:39:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDfw5-0003RO-Ak; Tue, 22 Mar 2005 04:44:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDfq0-0002gK-GF; Tue, 22 Mar 2005 04:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDfpy-0002gC-E3 for ltru@megatron.ietf.org; Tue, 22 Mar 2005 04:38:10 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22078 for ; Tue, 22 Mar 2005 04:38:07 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDfng-0003eG-S8 for ltru@lists.ietf.org; Tue, 22 Mar 2005 10:35:49 +0100 Received: from c-134-89-65.hh.dial.de.ignite.net ([62.134.89.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 10:35:48 +0100 Received: from nobody by c-134-89-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 10:35:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 22 Mar 2005 10:36:28 +0100 Organization: Lines: 37 Message-ID: <423FE71C.247F@xyzzy.claranet.de> References: <20050321044949.GEQD4900.mta8.adelphia.net@megatron.ietf.org> <003c01c52de1$f988a2a0$030aa8c0@DEWELL> <014f01c52e38$f1b9a950$38733009@sanjose.ibm.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: c-134-89-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Mark Davis wrote: > The safest and most robust policy is allow all codes that > have ever been permitted by the source standards. IBTD, a "get rid of old nonsense" strategy for a definition of "old" = before RfC 1766 was published allows to capture the _actual_ state of the relevant standards. Nobody needs an old 639-typo like "jw" in the Internet, it's a zombie like UNICODE-1-1-UTF-7 (yes, I got some mails with this beast in 2003 and 2004) > (a) because of the instability of such sources True. The tactic to get stability by a "frozen copy" is not necessarily convincing, at least not for the region codes. > we do have to impose some order in those cases where there > is a conflict. Or to accept the instability and offer a stable alternative: 3166-1 as it is before 3166-1 as it was (instable), stable version UN M49 as it is or was. 3166-3 as guide to populate some canonical values (in addition to UN M49). > It would be safest not to put it at date of publication, > simply because that take the risk (probably small, but > unfortunately real) that the source standards would redefine > a code after the draft has been discussed and approved, but > before publication. Then let's always take the state of the art at the date of the creation of the future draft registry I-Ds based on the future registry draft I-Ds. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 05:13:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25885; Tue, 22 Mar 2005 05:13:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDgT6-0004hT-CT; Tue, 22 Mar 2005 05:18:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDgMC-0007gI-HH; Tue, 22 Mar 2005 05:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDgMB-0007gA-CR for ltru@megatron.ietf.org; Tue, 22 Mar 2005 05:11:27 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25763 for ; Tue, 22 Mar 2005 05:11:20 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDgJq-0000EU-2n for ltru@lists.ietf.org; Tue, 22 Mar 2005 11:09:02 +0100 Received: from c-134-89-65.hh.dial.de.ignite.net ([62.134.89.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 11:09:02 +0100 Received: from nobody by c-134-89-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 11:09:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 22 Mar 2005 11:05:47 +0100 Organization: Lines: 49 Message-ID: <423FEDFB.7187@xyzzy.claranet.de> References: <423E8F34.7A4F@xyzzy.claranet.de> <20050321105425.B6D54253463@smtp.nildram.co.uk> 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: c-134-89-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Debbie Garside wrote: > consistency is also the name of the game... as it also > assists the end user which is my primary focus. I'm that end user, I use things like lang="en-GB-OED" or xml:lang="de-CH-1996". Not often, generally I prefer a simple lang="en" or xml:lang="de". No problem with RfC 3066 for the wrong reasons, but still no problem is no problem, good enough for an end user. Later with 3066bis I _could_ add -Latn everywhere. Or I could try a stunt like adding -Latn only in the xml:lang but not in the lang, if XHTML allows it. Probably it does not allow it, but it's a very bad sign that I'd check this before dropping the horrible idea. > Should we perhaps be looking in even finer detail and at > extensibility issues e.g. > en-Character_Set-US RfC 3066 and 3066bis are for the Internet (incl. WWW), and there you generally have a charset defined elsewhere, not in a language tag. The worst cases I have on my pages are links to plain text documents (actually scripts), and there I use something like: href="kex/german.kex" type="text/plain" charset="PC-Multilingual-850+euro" No hreflang= in this case because source and target are both "en", and the hotspot text for a potential lang= is also "en". I'm too lazy to find it now, but I'm sure that I have some links with type=, charset=, lang=, and hreflag=. That I don't use xml:lang= in a body of XHTML documents is an idiosyncrasy. There's a certain point where I think that Martin and his I18N cohorts should leave me alone, a redundant xml:lang= is ugly, I won't have it more than once per document. > At least you would end up with something useful, forward > looking and extendable... :-) Where do you miss a charset in language tags ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 08:48:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13428; Tue, 22 Mar 2005 08:48:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDjpH-0003ib-Oi; Tue, 22 Mar 2005 08:53:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDjj1-0007yG-6a; Tue, 22 Mar 2005 08:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDjiT-0007mZ-3z for ltru@megatron.ietf.org; Tue, 22 Mar 2005 08:46:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13262 for ; Tue, 22 Mar 2005 08:46:39 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDjni-0003fb-Md for ltru@ietf.org; Tue, 22 Mar 2005 08:52:08 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2MDkKO0023926 for ; Tue, 22 Mar 2005 05:46:21 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B7715LS>; Tue, 22 Mar 2005 05:46:21 -0800 Message-ID: From: "McDonald, Ira" To: ltru@ietf.org Date: Tue, 22 Mar 2005 05:46:18 -0800 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: d6b246023072368de71562c0ab503126 Subject: [Ltru] Please drop illustrative use of 'en-boont' X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi, Now that I finally know (thanks to John Cowan) what this 'en-boont' is (a tag for a dead ultra-minor language), could RFC3066bis _please_ not use it at all in examples? It seems to me that RFC3066bis should be readable and understandable by someone who isn't a linguist. Just a thought. 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 08:53:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13921; Tue, 22 Mar 2005 08:53:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDjuh-0003xh-BN; Tue, 22 Mar 2005 08:59:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDjnm-0000bt-E8; Tue, 22 Mar 2005 08:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDjnk-0000bW-RA for ltru@megatron.ietf.org; Tue, 22 Mar 2005 08:52:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13711 for ; Tue, 22 Mar 2005 08:52:07 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDjt2-0003sV-3I for ltru@ietf.org; Tue, 22 Mar 2005 08:57:36 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2MDpws5003323; Tue, 22 Mar 2005 08:51:58 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 22 Mar 2005 08:51:59 -0500 Date: Tue, 22 Mar 2005 08:51:59 -0500 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Please drop illustrative use of 'en-boont' Message-ID: <20050322135159.GC26334@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d McDonald, Ira scripsit: > Now that I finally know (thanks to John Cowan) what this > 'en-boont' is (a tag for a dead ultra-minor language), > could RFC3066bis _please_ not use it at all in examples? As I said, I agree that it's a bad case to reason from or to use in the draft. > It seems to me that RFC3066bis should be readable and > understandable by someone who isn't a linguist. In the nature of things, language variants tend to be little-known to those who don't speak the language in question, and sometimes even if they do. Furthermore, most of them are politically controversial to some degree, either for their names (BEV? AAVE? Ebonics?) or for their mere existence. -- John Cowan http://www.ccil.org/~cowan jcowan@reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 08:56:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14206; Tue, 22 Mar 2005 08:56:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDjwx-00043n-SI; Tue, 22 Mar 2005 09:01:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDjlo-0000SU-Lw; Tue, 22 Mar 2005 08:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDjlh-0000OT-Qv for ltru@megatron.ietf.org; Tue, 22 Mar 2005 08:50:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13555 for ; Tue, 22 Mar 2005 08:50:00 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDjqx-0003pJ-Sp for ltru@ietf.org; Tue, 22 Mar 2005 08:55:29 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2MDnk8o003302; Tue, 22 Mar 2005 08:49:46 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 22 Mar 2005 08:49:49 -0500 Date: Tue, 22 Mar 2005 08:49:48 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [semi-OT] ISO 639-3, record-jars, and Boontling Message-ID: <20050322134948.GB26334@skunk.reutershealth.com> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.com> <423E7FF5.3B6@xyzzy.claranet.de> <20050321150836.GN15741@skunk.reutershealth.com> <423FE17F.7B0B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423FE17F.7B0B@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Frank Ellermann scripsit: > And where does [RFC 3066ter] place YEC, "yec" is indeed the correct code for Yeniche in RFC 3066ter. > de-yec, Nobody uses "German" as a cover term to include both German and Yeniche. Consequently, the tag "de" refers to modern standard German and its regional variants (but not the German dialects proper, which have their own codes). > yi-yec, Nobody uses "Yiddish" as a cover term for "Yiddish and Yeniche" either. However, "Yiddish" *is* used as a cover term for both Eastern Yiddish and the nearly extinct Western Yiddish (formerly coterminous with German). Consequently, RFC 3066ter would tag these yi-ydd and yi-yih respectively. Of course, yi will still be usable when the distinction is unimportant. > gem-yec, gem is a 639-2 code for a language collection, the Germanic languages. In current practice, it is only used when more specific 639-2 codes fail to apply. The expectation is that language-collection codes will be rarely if ever used in RFC 3066ter practice. > RfC 3066 software seeing YEC as "de" content would be a PITA, > just like en-boont as a part of "en". Indeed. -- Go, and never darken my towels again! John Cowan --Rufus T. Firefly www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 10:07:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21361; Tue, 22 Mar 2005 10:07:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDl3i-0006gH-Tx; Tue, 22 Mar 2005 10:12:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDkxW-0004mF-7M; Tue, 22 Mar 2005 10:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDkxU-0004m9-4F for ltru@megatron.ietf.org; Tue, 22 Mar 2005 10:06:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21263 for ; Tue, 22 Mar 2005 10:06:14 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDl2l-0006f3-KJ for ltru@ietf.org; Tue, 22 Mar 2005 10:11:43 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2MF62I0003949; Tue, 22 Mar 2005 10:06:05 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 22 Mar 2005 10:06:15 -0500 Date: Tue, 22 Mar 2005 10:06:15 -0500 From: John Cowan To: "L.Gillam" Subject: Re: [Ltru] Re: Preparations for smart matching Message-ID: <20050322150615.GE26334@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A143@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A143@EVS-EC1-NODE1.surrey.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 L.Gillam scripsit: > I think this is a time where one should at least ask > questions of the messenger, and perhaps consider less extreme forms > of punitive actions - please see: I was merely reporting what the official ISO status page said. No hostility to anyone was intended or implied. > http://isotc.iso.org/livelink/livelink/fetch/2000/2122/687806/ISO_TC_037__Terminology_and_other_language_resources_.pdf?nodeid=1160801&vernum=0 Thanks for this pointer. This says that 639-3,4,5,6 are all at stage 20.00, meaning that they are part of the programme of work. This is clearly inaccurate for 639-3, which is elsewhere stated to be at 40.20 (DIS out for ballot). > 639-5 appears to provide a structure in which to make sense of 639-3 - > looking awfully like the structure of Ethnologue. I'm not surprised. > General principles and groups of languages may be irrelevant to > 3066bis, but eventually - in some none-too-distant future one > suspects - smart matching will also have to take into account the > specialisation/generalisation relationships as composed by these 2 - > which is somewhat orthogonal to current 3066 "tag-dropping" practice. I hope not. The trouble with language collections is that if they are defined extensionally (en+nl+de+yi+...) they may or may not reflect anything real, and if they are defined intensionally ("Germanic language") they are theory-dependent and are unstable, changing as linguistic theories change. (Granted, the Germanic family is quite stable, but this isn't true in general.) > At this point I should promote a related research activity > http://portal.surrey.ac.uk/portal/page?_pageid=798,337934&_dad=portal&_schema=PORTAL > for which the actual website is in development at INRIA. Hmm. It would be nice to know what this is actually about. :-) -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan I come from under the hill, and under the hills and over the hills my paths led. And through the air. I am he that walks unseen. I am the clue-finder, the web-cutter, the stinging fly. I was chosen for the lucky number. --Bilbo _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 10:22:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23497; Tue, 22 Mar 2005 10:22:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDlIy-0007D3-A8; Tue, 22 Mar 2005 10:28:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDlCa-00072c-Mh; Tue, 22 Mar 2005 10:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDlCZ-00070z-7G for ltru@megatron.ietf.org; Tue, 22 Mar 2005 10:21:51 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23397 for ; Tue, 22 Mar 2005 10:21:48 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDl3k-0001g9-VN for ltru@lists.ietf.org; Tue, 22 Mar 2005 16:12:45 +0100 Received: from c-134-89-65.hh.dial.de.ignite.net ([62.134.89.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 16:12:44 +0100 Received: from nobody by c-134-89-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 16:12:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 22 Mar 2005 16:07:33 +0100 Organization: Lines: 11 Message-ID: <424034B5.55F6@xyzzy.claranet.de> References: <20050322135159.GC26334@skunk.reutershealth.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: c-134-89-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Please drop illustrative use of 'en-boont' X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit John Cowan wrote: > In the nature of things, language variants tend to be > little-known to those who don't speak the language in > question, and sometimes even if they do. Maybe en-scouse is a better example. Or no-bok for the case of a now deprecated tag. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 10:33:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25023; Tue, 22 Mar 2005 10:33:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDlT2-0007ac-7G; Tue, 22 Mar 2005 10:38:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDlMG-000065-C5; Tue, 22 Mar 2005 10:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDlME-00005x-RG for ltru@megatron.ietf.org; Tue, 22 Mar 2005 10:31:51 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24812 for ; Tue, 22 Mar 2005 10:31:47 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DDlEh-0003Pb-D9 for ltru@lists.ietf.org; Tue, 22 Mar 2005 16:24:04 +0100 Received: from c-134-89-65.hh.dial.de.ignite.net ([62.134.89.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 16:24:03 +0100 Received: from nobody by c-134-89-65.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2005 16:24:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 22 Mar 2005 16:18:51 +0100 Organization: Lines: 14 Message-ID: <4240375B.1E2C@xyzzy.claranet.de> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.com> <423E7FF5.3B6@xyzzy.claranet.de> <20050321150836.GN15741@skunk.reutershealth.com> <423FE17F.7B0B@xyzzy.claranet.de> <20050322134948.GB26334@skunk.reutershealth.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: c-134-89-65.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] extlang (was: [semi-OT] ISO 639-3, record-jars, and Boontling) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit John Cowan wrote: > "yec" is indeed the correct code for Yeniche in RFC 3066ter. Hm, you said that 639-3 codes are organized into about 50 (?) 639-1/2 "sets", and that 3066ter would use the 639-3 code as an "extlang" together with the "set" as "language. That's why I'd expect something like ??-yec or ???-yec in 3066ter. But now you're saying that 639-3 yec will be a language in 3066ter, where does that leave the reserved 3066bis "extlang" ? Do you have an example where "extlang" is needed ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 11:41:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03095; Tue, 22 Mar 2005 11:41:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmWw-00022U-Ru; Tue, 22 Mar 2005 11:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmO5-0001Br-RB; Tue, 22 Mar 2005 11:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmO4-0001BG-LZ for ltru@megatron.ietf.org; Tue, 22 Mar 2005 11:37:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02563 for ; Tue, 22 Mar 2005 11:37:46 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmTN-0001q8-5e for ltru@ietf.org; Tue, 22 Mar 2005 11:43:17 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 08:37:38 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 08:37:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 08:37:46 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUtA4M7YhSLbWhrQ2+p6tCDE9TEewB9ya3g From: "Peter Constable" To: "Frank Ellermann" , X-OriginalArrivalTime: 22 Mar 2005 16:37:38.0175 (UTC) FILETIME=[756F28F0:01C52EFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: Saturday, March 19, 2005 8:09 PM > Could we rename "recommended_prefix" to "associated_tag", or > something in this direction ? Then the 6th column of languages > would be free for a pointer to a default script. A couple of issues: it would not be a trivial task to populate that field in a reasonably accurate way for all languages, and you'd need to allow for cases in which a language is written in several scripts no one of which has a greatest claim to being the default. =20 > At the moment the draft says: >=20 > | The "recommended_prefix" field is empty, except where the > | type is "variant" >=20 > That could be changed to e.g. >=20 > The "recommended_prefix" is generally empty. In the case of > a "variant" it's often the recommended "language" prefix, but > could be also a language-script, language-script-region, or > language-region prefix. That's an interesting suggestion worth some thought. =20 > For the type "language" this field can be used to define a > default "script" for the correspoding "laguage", and then the > resulting tag or prefix language-sript is NOT RECOMMENDED. Ah! You'd use this to indicate a default script for cases in which there is one that is predominant. A better suggestion than what I thought you had in mind. Note, though, that there will be gray areas: 99.99% of all en content is in the common Latin orthography rather than other writing systems, such as IPA or Gregg Shorthand; it's clear we'd consider Latn the default in such a case. What if the proportion were 95%? 90%? 85%? ... What's the threshold at which we begin to assume a default? > > Thus if you want to match "en-Latn-US-boont" with "en-boont", > > it is enough to disassemble both tags and observe that all > > the subtags in the second tag are also present in the first. >=20 > That's IMFO not good enough. If a client offers en-boont and > en-misc (script "misc"), and the server has en-misc-US-boont, > then the client should try en-misc, but not en-boont. >=20 > Because "misc" is probably very important, if it's not "Latn" > as in the default for en. >=20 > > If "en-Latn-US-boont" is a match for "en-boont", then so is > > "en-Ogam-MV-boont". >=20 > Unless you have en-Ogam, then you need to know the default > script for en (which isn't Ogam). Hang on. It's unclear what you're comparing. You need to start qualifying the argument structure here: you're comparing two tags: one is the what is being requested, the other is the attribute of the resource in the repository. You've got to specify which is which. If the request is for "en-boont", then "en-Ogam" in the repository should not be a match (except in a fallback situation, when you must return something, haven't found a match and are looking for the best available alternative -- e.g. software UI resource loading). That's not because the script isn't Latn; it's because the request was specifically for Boontling, and "en-Ogam" is not constrained to that. If the request is for "en-boont", then ideally you'd want "en-Latn-US-boont" (if that were actually used) in the repository to be a match. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 11:43:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03459; Tue, 22 Mar 2005 11:43:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmYf-0002DR-73; Tue, 22 Mar 2005 11:48:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmTG-0002al-03; Tue, 22 Mar 2005 11:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmTF-0002Zd-FW for ltru@megatron.ietf.org; Tue, 22 Mar 2005 11:43:09 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03425 for ; Tue, 22 Mar 2005 11:43:06 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050322164236.HQWF5402.mta11.adelphia.net@DEWELL> for ; Tue, 22 Mar 2005 11:42:36 -0500 Message-ID: <0b6601c52efe$2038ee60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050322153252.PHLK4900.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 22 Mar 2005 08:42:23 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > IBTD, a "get rid of old nonsense" strategy for a definition > of "old" = before RfC 1766 was published allows to capture > the _actual_ state of the relevant standards. Mark just told you that users continued to use the old codes 'in,' 'iw', and 'ji' after they had been deprecated. The fact that an ISO code is deprecated does not mean everyone immediately stops using it. > Nobody needs an old 639-typo like "jw" in the Internet, it's > a zombie like UNICODE-1-1-UTF-7 (yes, I got some mails with > this beast in 2003 and 2004) Are you aware that 'jw' was not documented as an error by ISO 639 RA/JAC until 2002? >> (a) because of the instability of such sources > > True. The tactic to get stability by a "frozen copy" is not > necessarily convincing, at least not for the region codes. Many of us are convinced. >> we do have to impose some order in those cases where there >> is a conflict. > > Or to accept the instability and offer a stable alternative: > 3166-1 as it is before 3166-1 as it was (instable), stable > version UN M49 as it is or was. 3166-3 as guide to populate > some canonical values (in addition to UN M49). Frank, please write a counterproposal. I don't think it's accomplishing anything to continue saying "Or we could totally change the way country codes are handled" without a document that the WG can discuss. >> It would be safest not to put it at date of publication, >> simply because that take the risk (probably small, but >> unfortunately real) that the source standards would redefine >> a code after the draft has been discussed and approved, but >> before publication. > > Then let's always take the state of the art at the date of > the creation of the future draft registry I-Ds based on the > future registry draft I-Ds. Actually I like that idea. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 11:54:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04375; Tue, 22 Mar 2005 11:54:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmjq-0002ba-La; Tue, 22 Mar 2005 12:00:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmdy-0004xE-UC; Tue, 22 Mar 2005 11:54:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmdx-0004x9-G1 for ltru@megatron.ietf.org; Tue, 22 Mar 2005 11:54:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04356 for ; Tue, 22 Mar 2005 11:54:11 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmjF-0002aV-92 for ltru@ietf.org; Tue, 22 Mar 2005 11:59:42 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2MGs17Q004970; Tue, 22 Mar 2005 11:54:02 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 22 Mar 2005 11:54:04 -0500 Date: Tue, 22 Mar 2005 11:54:04 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] extlang (was: [semi-OT] ISO 639-3, record-jars, and Boontling) Message-ID: <20050322165403.GH26334@skunk.reutershealth.com> References: <20050320170358.TLPW4900.mta8.adelphia.net@megatron.ietf.org> <010e01c52d7e$998226a0$030aa8c0@DEWELL> <423E27D7.3679@xyzzy.claranet.de> <20050321024502.GB15741@skunk.reutershealth.com> <423E7FF5.3B6@xyzzy.claranet.de> <20050321150836.GN15741@skunk.reutershealth.com> <423FE17F.7B0B@xyzzy.claranet.de> <20050322134948.GB26334@skunk.reutershealth.com> <4240375B.1E2C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4240375B.1E2C@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Frank Ellermann scripsit: > Hm, you said that 639-3 codes are organized into about 50 (?) > 639-1/2 "sets", and that 3066ter would use the 639-3 code as > an "extlang" together with the "set" as "language. That's > why I'd expect something like ??-yec or ???-yec in 3066ter. Ah, I see. No, I said that about 350 of the nearly 7000 languages in 639-3 are included in about 50 macro-languages listed in ISO 639-1/2 as well as 639-3 itself. These will be coded in 3066ter using xx-yyy codes. The remaining languages of 639-3 will be coded just like the languages of 639-1/2, as a language appearing in both 639-2 and 639-3 will have the same 3-alpha code in both parts. > But now you're saying that 639-3 yec will be a language in > 3066ter, where does that leave the reserved 3066bis "extlang" ? The extlang syntax is solely for use with the 56 macro-languages. > Do you have an example where "extlang" is needed ? For example, "ar" is an ISO 639-1/2 code meaning "Arabic". 639-3 interprets this code as a macro-language. Normally, it refers to modern standard Arabic, but it is also used as a cover term for 30 Arabic languages ("dialects", "colloquials") listed in ISO 639-3. In an RFC 3066ter regime, one could tag something as "ar" to say that it was Arabic generally, or "ar-arb" to refer specifically to modern standard Arabic, or "ar-arz" to refer to Egyptian Spoken Arabic, or "ar-shu" to refer to Chadian Spoken Arabic (which is barely, if at all, mutually intelligible with ar-arb). (Note: the term "Spoken" in the names of these languages does not mean that they are not or cannot be written, but simply that they are not generally written in the countries named; ar-arb or another language altogether is normally used for writing.) Maltese, although linguistically it is just another Arabic colloquial, does not function as one sociolinguistically -- nobody refers to it as "Arabic" -- and in RFC 3066ter it would be coded as "mlt", its ISO 639-3 code. No extlang code is required or permitted. The various Chinese, Nahuatl, Zapotec, Quechua, Romany, Sardinian, and Albanian languages are treated in exactly the same way. Cantonese is "zh-yue" rather than just "yue" because it is thought of as part of the macro-language called ""Chinese; Dungan (which linguistically is just a Mandarin dialect) is not, and so its code is "dng". Likewise, the four main Sardinian languages are "sc-sdn" (Gallurese), "sc-sdc" (Sassarese), "sc-src" (Logudorese), and "sc-sro" (Campidanese), but Algherese is a dialect of Catalan, and coded as "ca", or "ca-alghero" if someone finds the distinction important and registers "alghero". -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 12:25:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07706; Tue, 22 Mar 2005 12:25:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnDr-0003yv-KF; Tue, 22 Mar 2005 12:31:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDn7k-0003BH-Q4; Tue, 22 Mar 2005 12:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDn7j-0003B9-DK for ltru@megatron.ietf.org; Tue, 22 Mar 2005 12:24:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07645 for ; Tue, 22 Mar 2005 12:24:56 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnD1-0003rw-D7 for ltru@ietf.org; Tue, 22 Mar 2005 12:30:28 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 09:24:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Please drop illustrative use of 'en-boont' Date: Tue, 22 Mar 2005 09:24:45 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB8238B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Please drop illustrative use of 'en-boont' Thread-Index: AcUu8wVGbszAs6CfSe2fHSKAmhX0cAAD7v3g From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 22 Mar 2005 17:24:45.0864 (UTC) FILETIME=[0ADE4280:01C52F04] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable That's a good idea. Unless somebody objects I'll replace examples in the = draft that use Boontling to use Scouse instead. It is a better example = for the reasons John pointed out (although we don't have that many = subtags to choose from). Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 22 mars 2005 07:08 > To: ltru@ietf.org > Subject: [Ltru] Re: Please drop illustrative use of 'en-boont' >=20 > John Cowan wrote: >=20 > > In the nature of things, language variants tend to be > > little-known to those who don't speak the language in > > question, and sometimes even if they do. >=20 > Maybe en-scouse is a better example. Or no-bok for the > case of a now deprecated tag. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 12:50:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10475; Tue, 22 Mar 2005 12:50:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnc5-0004xb-Ko; Tue, 22 Mar 2005 12:56:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnTn-0006er-IM; Tue, 22 Mar 2005 12:47:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnTl-0006ea-QX for ltru@megatron.ietf.org; Tue, 22 Mar 2005 12:47:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10179 for ; Tue, 22 Mar 2005 12:47:43 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnZ5-0004qg-2M for ltru@ietf.org; Tue, 22 Mar 2005 12:53:15 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 09:47:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Preparations for smart matching Date: Tue, 22 Mar 2005 09:47:35 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB823BF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUtA4M7YhSLbWhrQ2+p6tCDE9TEewB9ya3gAAJkiWA= From: "Addison Phillips" To: "Peter Constable" , "Frank Ellermann" , X-OriginalArrivalTime: 22 Mar 2005 17:47:36.0215 (UTC) FILETIME=[3BA93A70:01C52F07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable > > At the moment the draft says: > > > > | The "recommended_prefix" field is empty, except where the > > | type is "variant" > > > > That could be changed to e.g. > > > > The "recommended_prefix" is generally empty. In the case of > > a "variant" it's often the recommended "language" prefix, but > > could be also a language-script, language-script-region, or > > language-region prefix. >=20 > That's an interesting suggestion worth some thought. Um...that's what it does say, except that the draft doesn't say what = Frank says it says. It actually says: The field 'recommended prefix' is for use with registered variants and = contains a semicolon separated list of language-ranges considered most = appropriate for use with this subtag. Additional values can be added to = this field for variants only via additional registration. Other = modification of this field (such as removing or changing values) is not = permitted. A language range is defined to allow inclusion of all of the examples = Frank gives. We can (and should) remove the restriction to registered = variants in the text. Another way to accomplish what I think Frank is suggesting is to provide = a canonical mapping section in the registry. We could create specific = "range" entries with canonical mappings in this manner: canonical | en-Latn | English written in Latin Script | en | | # use = 'en' prefix, not en-Latn If users feel strongly about certain combinations they could register = them. Rules would have to be created to prevent abuse (for example, you = couldn't create mappings that create ambiguity, such as mapping both = zh-Hant and zh-Hans to zh). Note that these canonical mappings would be = informational in nature. Tags such as en-Latn-US would still be = well-formed and valid. This would merely allow tag processors in = possession of the registry to ignore the subtag Latn when matching the = tag (by canonicalizing the tag to en-US before matching). Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 >=20 >=20 > > For the type "language" this field can be used to define a > > default "script" for the correspoding "laguage", and then the > > resulting tag or prefix language-sript is NOT RECOMMENDED. >=20 > Ah! You'd use this to indicate a default script for cases in which = there > is one that is predominant. A better suggestion than what I thought = you > had in mind. Note, though, that there will be gray areas: 99.99% of = all > en content is in the common Latin orthography rather than other = writing > systems, such as IPA or Gregg Shorthand; it's clear we'd consider Latn > the default in such a case. What if the proportion were 95%? 90%? 85%? > ... What's the threshold at which we begin to assume a default? >=20 >=20 > > > Thus if you want to match "en-Latn-US-boont" with "en-boont", > > > it is enough to disassemble both tags and observe that all > > > the subtags in the second tag are also present in the first. > > > > That's IMFO not good enough. If a client offers en-boont and > > en-misc (script "misc"), and the server has en-misc-US-boont, > > then the client should try en-misc, but not en-boont. > > > > Because "misc" is probably very important, if it's not "Latn" > > as in the default for en. > > > > > If "en-Latn-US-boont" is a match for "en-boont", then so is > > > "en-Ogam-MV-boont". > > > > Unless you have en-Ogam, then you need to know the default > > script for en (which isn't Ogam). >=20 > Hang on. It's unclear what you're comparing. You need to start > qualifying the argument structure here: you're comparing two tags: one > is the what is being requested, the other is the attribute of the > resource in the repository. You've got to specify which is which. >=20 > If the request is for "en-boont", then "en-Ogam" in the repository > should not be a match (except in a fallback situation, when you must > return something, haven't found a match and are looking for the best > available alternative -- e.g. software UI resource loading). That's = not > because the script isn't Latn; it's because the request was = specifically > for Boontling, and "en-Ogam" is not constrained to that. >=20 > If the request is for "en-boont", then ideally you'd want > "en-Latn-US-boont" (if that were actually used) in the repository to = be > a match. >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 15:13:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26611; Tue, 22 Mar 2005 15:13:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDpq0-0002EB-8T; Tue, 22 Mar 2005 15:18:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDpkG-0007Nh-6o; Tue, 22 Mar 2005 15:12:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDpkE-0007Nb-II for ltru@megatron.ietf.org; Tue, 22 Mar 2005 15:12:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26516 for ; Tue, 22 Mar 2005 15:12:52 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDppX-0002CO-Fk for ltru@ietf.org; Tue, 22 Mar 2005 15:18:24 -0500 Received: from lns-p19-19-idf-82-65-141-10.adsl.proxad.net ([82.65.141.10] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDpjy-0002uc-Qb for ltru@ietf.org; Tue, 22 Mar 2005 12:12:39 -0800 Message-Id: <6.1.2.0.2.20050322200217.03cbda30@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 22 Mar 2005 21:12:30 +0100 To: "ltRU Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Preparations for smart matching In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A151@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A151@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On 10:15 22/03/2005, L.Gillam said: > > Of course, you can post content on your site in any language you like. Just beware that this may change with the IDNs. Registrations are subject to the TLD Manager terms and conditions. The same ICANN imposes conditions on specialized TLDs. There is interest by some ccTLD to require that the language of the IDN be used on the sites, by respect to the users. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 16:27:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09758; Tue, 22 Mar 2005 16:27:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDr0B-00077x-D5; Tue, 22 Mar 2005 16:33:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqt9-0004TK-Ro; Tue, 22 Mar 2005 16:26:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqt7-0004TA-UZ for ltru@megatron.ietf.org; Tue, 22 Mar 2005 16:26:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09629 for ; Tue, 22 Mar 2005 16:26:07 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqyS-00070N-7Z for ltru@ietf.org; Tue, 22 Mar 2005 16:31:40 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2MLPxCi012708 for ; Tue, 22 Mar 2005 16:25:59 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2MLPx27081828 for ; Tue, 22 Mar 2005 16:25:59 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2MLPxra013347 for ; Tue, 22 Mar 2005 16:25:59 -0500 Received: from markdavis (sig-9-48-125-114.mts.ibm.com [9.48.125.114]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2MLPjli012657; Tue, 22 Mar 2005 16:25:48 -0500 Message-ID: <03ee01c52f25$bb24e560$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Peter Constable" , "Frank Ellermann" , References: <634978A7DF025A40BFEF33EB191E13BC0AB823BF@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Preparations for smart matching Date: Tue, 22 Mar 2005 13:25:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j2MLPxCi012708 X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable Some languages are customarily written in multiple scripts, while others = are customarily written in a single script. In the case of English, the overwhelming majority of English text is written with Latin, just as the overwhelming majority of Arabic is written in the Arabic script. But ther= e are, of course, documents that do have ar-Latn, such as certain books teaching Arabic. So to *always* map ar to ar-Arab is a mistake. And it ge= ts fuzzier for cases like Serbian, where while the predominant case of sr is sr-Cyrl, but there are significant amounts of sr-Latn. It really depends on what the matching process is *for*. There are differ= ent usages of language tags that may have different matching strategies. For example: 1. Matching. Use of 'sr' says that you want to match Serbian of whatever form: doesn't depend on the country, doesn't depend on the scrip= t. Use of, say, 'sr-Latn-IT' means that you want Serbian, but limited to Latin script, and as used in Italy. If I want to have a document query, t= hen I could use one of the above to restrict the documents that match my quer= y. I could get back 1000 documents or none, according to what database of documents I am searching and how restrictive my query is. I can also probably structure queries with more capabilities, such as (sr AND (Latn = OR Cyrl)) OR (ru-Cyrl)) 2. Lookup. When you lookup language data, for example, for display on a w= eb page, it is a different process. You typically don't have the choice of displaying nothing if there is not an exact match. Instead, you fall back. If you don't have data exactly matching 'sr-Latn-IT', you fallback to dat= a for 'sr-Latn'. If you don't have that either, you fallback to data for 's= r'. Now, whatever data contents someone has associated with 'sr', it has to b= e a single consistent type of data, so it will be in one of 'Latn' or 'Cyrl'. Similarly, American English may be used in data associated with en for lookup purposes. Any distinctions according to country would be stored separately in an 'en-AU', 'en-CA', 'en-IE', etc., and if available, would= be found in a lookup. But if someone came in with 'en-JP', and there was no separate data source for that, it would fall back to the data associated with 'en', which would be American English. Thus, I think it may be reasonable, in support of lookup fallback strategies, to have a table of data designed for "default" lookup fallbac= k, structured along something like the following lines: fallback | en | en-Latn fallback | sr | sr-Cyrl fallback | pt | pt-BR pt-Latn-BR However, to me this is information that is much more closely associated w= ith matching than with the structure of language tags, and thus should be discussed and elaborated in the context of the matching document, when we start work on that. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Peter Constable" ; "Frank Ellermann" ; Sent: Tuesday, March 22, 2005 09:47 Subject: RE: [Ltru] Re: Preparations for smart matching > > At the moment the draft says: > > > > | The "recommended_prefix" field is empty, except where the > > | type is "variant" > > > > That could be changed to e.g. > > > > The "recommended_prefix" is generally empty. In the case of > > a "variant" it's often the recommended "language" prefix, but > > could be also a language-script, language-script-region, or > > language-region prefix. > > That's an interesting suggestion worth some thought. Um...that's what it does say, except that the draft doesn't say what Fran= k says it says. It actually says: The field 'recommended prefix' is for use with registered variants and contains a semicolon separated list of language-ranges considered most appropriate for use with this subtag. Additional values can be added to t= his field for variants only via additional registration. Other modification o= f this field (such as removing or changing values) is not permitted. A language range is defined to allow inclusion of all of the examples Fra= nk gives. We can (and should) remove the restriction to registered variants = in the text. Another way to accomplish what I think Frank is suggesting is to provide = a canonical mapping section in the registry. We could create specific "rang= e" entries with canonical mappings in this manner: canonical | en-Latn | English written in Latin Script | en | | # use 'en' prefix, not en-Latn If users feel strongly about certain combinations they could register the= m. Rules would have to be created to prevent abuse (for example, you couldn'= t create mappings that create ambiguity, such as mapping both zh-Hant and zh-Hans to zh). Note that these canonical mappings would be informational= in nature. Tags such as en-Latn-US would still be well-formed and valid. Thi= s would merely allow tag processors in possession of the registry to ignore the subtag Latn when matching the tag (by canonicalizing the tag to en-US before matching). Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > > > > For the type "language" this field can be used to define a > > default "script" for the correspoding "laguage", and then the > > resulting tag or prefix language-sript is NOT RECOMMENDED. > > Ah! You'd use this to indicate a default script for cases in which ther= e > is one that is predominant. A better suggestion than what I thought you > had in mind. Note, though, that there will be gray areas: 99.99% of all > en content is in the common Latin orthography rather than other writing > systems, such as IPA or Gregg Shorthand; it's clear we'd consider Latn > the default in such a case. What if the proportion were 95%? 90%? 85%? > ... What's the threshold at which we begin to assume a default? > > > > > Thus if you want to match "en-Latn-US-boont" with "en-boont", > > > it is enough to disassemble both tags and observe that all > > > the subtags in the second tag are also present in the first. > > > > That's IMFO not good enough. If a client offers en-boont and > > en-misc (script "misc"), and the server has en-misc-US-boont, > > then the client should try en-misc, but not en-boont. > > > > Because "misc" is probably very important, if it's not "Latn" > > as in the default for en. > > > > > If "en-Latn-US-boont" is a match for "en-boont", then so is > > > "en-Ogam-MV-boont". > > > > Unless you have en-Ogam, then you need to know the default > > script for en (which isn't Ogam). > > Hang on. It's unclear what you're comparing. You need to start > qualifying the argument structure here: you're comparing two tags: one > is the what is being requested, the other is the attribute of the > resource in the repository. You've got to specify which is which. > > If the request is for "en-boont", then "en-Ogam" in the repository > should not be a match (except in a fallback situation, when you must > return something, haven't found a match and are looking for the best > available alternative -- e.g. software UI resource loading). That's not > because the script isn't Latn; it's because the request was specificall= y > for Boontling, and "en-Ogam" is not constrained to that. > > If the request is for "en-boont", then ideally you'd want > "en-Latn-US-boont" (if that were actually used) in the repository to be > a match. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 16:39:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10810; Tue, 22 Mar 2005 16:39:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDrB0-0007Uh-Tt; Tue, 22 Mar 2005 16:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDr5N-00078d-Fn; Tue, 22 Mar 2005 16:38:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDr5L-00078H-QU for ltru@megatron.ietf.org; Tue, 22 Mar 2005 16:38:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10800 for ; Tue, 22 Mar 2005 16:38:45 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDrAh-0007UD-0x for ltru@ietf.org; Tue, 22 Mar 2005 16:44:19 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2MLccbq030362 for ; Tue, 22 Mar 2005 16:38:38 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2MLcZ27090488 for ; Tue, 22 Mar 2005 16:38:38 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2MLcZeX018512 for ; Tue, 22 Mar 2005 16:38:35 -0500 Received: from markdavis (sig-9-48-125-114.mts.ibm.com [9.48.125.114]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2MLcLVI017826; Tue, 22 Mar 2005 16:38:28 -0500 Message-ID: <040901c52f27$7f5bf490$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Martin Duerst" , Date: Tue, 22 Mar 2005 13:38:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j2MLccbq030362 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group Subject: [Ltru] Getting back on track X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable The discussion has meandered around a bit: I'd like to see us get back on track. Here is how I suggest we proceed. Within the next week, anyone who has any issues with the text of the curr= ent draft does the following: a. Composes a separate message on each issue, with a meaningful title. b. Suggests exact replacement text, with clear instructions on where to m= ake the change. c. Describes the pros and cons of making the change. We review by email each request. If there is consensus for if, then we record that. If not, we leave it alone. Once we have processed all the issues, we issue a new draft that incorporates all the changes. We circul= ate that, and if there are no problems with the incorporation of all the changes, then we advance the document. =E2=80=8EMark _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 17:20:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13843; Tue, 22 Mar 2005 17:20:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDrpX-0000SF-EO; Tue, 22 Mar 2005 17:26:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDrii-000587-6B; Tue, 22 Mar 2005 17:19:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDrig-000582-OS for ltru@megatron.ietf.org; Tue, 22 Mar 2005 17:19:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13729 for ; Tue, 22 Mar 2005 17:19:24 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDro1-0000Pn-1C for ltru@ietf.org; Tue, 22 Mar 2005 17:24:58 -0500 Received: from lns-p19-19-idf-82-65-141-10.adsl.proxad.net ([82.65.141.10] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDrid-0001Ew-Ki; Tue, 22 Mar 2005 14:19:24 -0800 Message-Id: <6.1.2.0.2.20050322230225.03758330@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 22 Mar 2005 23:15:51 +0100 To: "Mark Davis" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Getting back on track In-Reply-To: <040901c52f27$7f5bf490$727d3009@sanjose.ibm.com> References: <040901c52f27$7f5bf490$727d3009@sanjose.ibm.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 On 22:38 22/03/2005, Mark Davis said: >The discussion has meandered around a bit: I'd like to see us get back on >track. Here is how I suggest we proceed. >Within the next week, anyone who has any issues with the text of the current >draft does the following: > >a. Composes a separate message on each issue, with a meaningful title. >b. Suggests exact replacement text, with clear instructions on where to make >the change. >c. Describes the pros and cons of making the change. > >We review by email each request. If there is consensus for if, then we >record that. If not, we leave it alone. Once we have processed all the >issues, we issue a new draft that incorporates all the changes. We circulate >that, and if there are no problems with the incorporation of all the >changes, then we advance the document. As indicated we will not be in a position to issue a draft before at least two weeks. It will certainly substantially differ from the current draft. And will probably be amended during its further international review. But the support of your propositions should be as much possible included in it. So this schedule seems OK if the Chairs agree. We should have your elements in time. I have however two missing information: - when do you/Addison intend to comment the inputs he required from me, so I can organize our schedule? - we have discussed nothing on the CLDR aspect. You are the best suited to tell us what are the requirements of the CLDR project in the RFC 3066 context and how we can best address them? I am also obviously concerned about the copyright issue as the RFC should indicate that the CLDR is public domain. Or we would have to investigate a public domain alternative. Thank you for your cooperation. jfc ====================================================== Standardizing Tags for the Identification of Languages should not be a way to standardize languages and to unify the world under a dominant culture. ====================================================== For your convenience: RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066 Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ====================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ====================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ====================================================== It seems that what works for countries and ISO 3166 since 1978, should apply to languages and to ISO 693. ====================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 17:21:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13884; Tue, 22 Mar 2005 17:21:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDrqH-0000T6-Er; Tue, 22 Mar 2005 17:27:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDrin-00058T-HG; Tue, 22 Mar 2005 17:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDril-00058O-OJ for ltru@megatron.ietf.org; Tue, 22 Mar 2005 17:19:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13735 for ; Tue, 22 Mar 2005 17:19:29 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDro6-0000Q7-Kn for ltru@ietf.org; Tue, 22 Mar 2005 17:25:03 -0500 Received: from lns-p19-19-idf-82-65-141-10.adsl.proxad.net ([82.65.141.10] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DDric-0001Ew-9y; Tue, 22 Mar 2005 14:19:22 -0800 Message-Id: <6.1.2.0.2.20050322230033.0375b200@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 22 Mar 2005 23:02:08 +0100 To: "Mark Davis" , "Addison Phillips" , "Peter Constable" , "Frank Ellermann" , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Preparations for smart matching In-Reply-To: <03ee01c52f25$bb24e560$727d3009@sanjose.ibm.com> References: <634978A7DF025A40BFEF33EB191E13BC0AB823BF@irvmbxw01.quest.com> <03ee01c52f25$bb24e560$727d3009@sanjose.ibm.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.9 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 At 22:25 22/03/2005, Mark Davis wrote: >It really depends on what the matching process is *for*. There are different >usages of language tags that may have different matching strategies. For >example: Is that not a good documentation of the reason why we need a semantic rather than a single universal format? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 18:11:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18660; Tue, 22 Mar 2005 18:11:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDscm-0002BL-Un; Tue, 22 Mar 2005 18:17:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDsX7-0005EV-Uq; Tue, 22 Mar 2005 18:11:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDsX4-0005CO-U4 for ltru@megatron.ietf.org; Tue, 22 Mar 2005 18:11:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18565 for ; Tue, 22 Mar 2005 18:11:27 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDscQ-0002Ak-1U for ltru@ietf.org; Tue, 22 Mar 2005 18:17:02 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 15:11:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Preparations for smart matching Date: Tue, 22 Mar 2005 15:11:18 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB8261C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUvJcAJJl18Zi8yRT6iYO3XbfXeLQAAfs2g From: "Addison Phillips" To: "Mark Davis" , X-OriginalArrivalTime: 22 Mar 2005 23:11:19.0442 (UTC) FILETIME=[74CE7720:01C52F34] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0356084484==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c --===============0356084484== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBleGFjdGx5LiBJbiBmYWN0IEkndmUgYmVlbiBtZW50YWxseSBydW1pbmF0aW5nIChidXQg aGF2ZW4ndCBoYWQgdGltZSB0byBzZXQgZG93biBpbiBlbWFpbCkgYWJvdXQgaG93IGJldHRlciB0 byByZWZsZWN0IHRoZXNlIGlzc3VlcyBpbiB0aGUgbWF0Y2hpbmcgZHJhZnQuDQoNCkluIG15IHRo aW5raW5nIGFib3V0IHRoZSBiZWxvdyBJIG1lbnRhbGx5IGVudmlzaW9uZWQgYSBzZXBhcmF0ZSBk YXRhIHRhYmxlLCBzb21ld2hhdCBsaWtlIHRoZSBhbmNpbGxhcnkgdGFibGVzIGluIHRoZSBVQ0Qu IFdhbnRpbmcgdGhlIGNvcmUgZGF0YSB0YWJsZSB0byBkbyBldmVyeXRoaW5nIHN0cmlrZXMgbWUg YXMgYSBiaXQgbWVzc3kgZm9yIG5vIGFwcGFyZW50IGdhaW4gaW4gdXRpbGl0eS4NCg0KVGhlIHJl YWwgaXNzdWUgaGVyZSBpcyB3aGF0IGZvcm0gbGFuZ3VhZ2UgdGFncyBzaG91bGQgdGFrZS4gTWF0 Y2hpbmcgaXNzdWVzIG1heSBndWlkZSB1cyBpbiBzZWxlY3RpbmcgYSBwYXJ0aWN1bGFyIHN1YnRh ZyBwYXR0ZXJuLCBidXQgSSBoYXZlbid0IHNlZW4gYW55IHBhcnRpY3VsYXIgaWRlYXMgYWJvdXQg aG93IHRvIHByb2NlZWQgdGhhdCBkb24ndCBlbnRhaWwgbWF0Y2hpbmcgaXNzdWVzIG9mIGFueSBz b3J0Lg0KDQpUaGUgbWF0Y2hpbmcgc2NoZW1lIGRlc2NyaWJlZCBpbiBSRkMgMzA2NiBpcyBub3Qg c3VpdGFibGUgZm9yIChhbmQsIGluIHByYWN0aWNlLCBpc24ndCB1c2VkIGluKSBhbGwgY2FzZXMg ZXZlbiB0b2RheS4NCg0KSW4gZmFjdCwgaWYgeW91IHRoaW5rIGFib3V0IGl0LCBtb3N0IG9mIHdo YXQgaXMgY2FsbGVkICJsYW5ndWFnZSB0YWcgbWF0Y2hpbmciIGlzICpyZWFsbHkqIGEgZm9ybSBv ZiBjb250ZW50IGZpbHRlcmluZy4gVGhlIFJGQyAzMDY2IG1hdGNoaW5nIGFsZ29yaXRobSAod2hh dCBNYXJrIGRlc2NyaWJlcyBpbiAjMSBiZWxvdykgbWF0Y2hlcyBhIHByZWZpeCBhZ2FpbnN0IHRh Z3MuIFNwZWNpZnlpbmcgInh4LVlZIiBmaWx0ZXJzIG91dCBhbGwgY29udGVudCB0aGF0IGlzIG5v dCAqYXQgbGVhc3QqIHRhZ2dlZCAieHgtWVkiIChhbmQgc2VsZWN0cyBjb250ZW50IHRoYXQgbWF5 IGJlIGluYXBwcm9wcmlhdGUsIGxpa2Ugb3VyIGZyaWVuZCAiZW4tYm9vbnQiIGlzIHBpY2tlZCB1 cCBieSAiZW4iKQ0KDQpUaGUgZGUgZmFjdG8gY29udGVudCBsb29rdXAgbWVjaGFuaXNtICh3aGF0 IE1hcmsgZGVzY3JpYmVzIGluICMyIGJlbG93IGFuZCB3aGljaCBpcyBhbHNvIHVzZWQgYnkgV2Vi IGFwcGxpY2F0aW9ucyBvZiBhbGwgc3RyaXBlcyBmb3IgY29udHJvbGxpbmcgbG9jYWxlIHByZWZl cmVuY2VzIHdoZW4gZ2VuZXJhdGluZyBjb250ZW50IG9yIGZvcm1hdHRpbmcgZW1iZWRkZWQgaW4g dGV4dCkgZmFsbHMgYmFjayBmcm9tIHRoZSBzcGVjaWZpZWQgdGFnIHRvd2FyZCBkZWZhdWx0IGNv bnRlbnQuIFRoaXMgaXMgbm90IGZpbHRlcmluZywgcGxlYXNlIG5vdGUuDQoNCkluIHRoZXNlIGNh c2VzLCBJIHRoaW5rIE1hcmsgaXMgY29ycmVjdCBhYm91dCBob3cgdG8gcHJvY2VlZC4gSW4gYWRk aXRpb24sIEkgd291bGQgc3RpcHVsYXRlIHRoYXQgb25jZSBvbmUgaW50cm9kdWNlcyBhZGRpdGlv bmFsIGZpZWxkcyBpbnRvIHRoZSBnZW5lcmF0aXZlIG1lY2hhbmlzbSAoZXZlbiB2aWEgUkZDIDMw NjYgcmVnaXN0cmF0aW9uLCB3aGljaCwgd2hpbGUgaXQgZG9lc24ndCByZWNvZ25pemUgc3VidGFn cyBhcyBzdWNoLCBkb2VzIHJlY29nbml6ZSB0aGVpciB1c2UgaW4gbWF0Y2hpbmchISksIHRoZXJl IHdpbGwgYWx3YXlzIGJlIGNhc2VzIHdoZXJlIHRyYWRpdGlvbmFsICJtYXRjaGluZyIgcHJvZHVj ZXMgcmVzdWx0cyB0aGF0IG1pZ2h0IGJlIHF1ZXN0aW9uZWQgYnkgYSBodW1hbiBlbmQgdXNlciAo d2hvIGNhbiBzZWUgdGhlIHRhZyBhbmQgcmVhc29uIGl0cyBtZWFuaW5nKS4gDQoNCkluIG90aGVy IHdvcmRzLCByZWdpc3RlcmVkIHRhZ3MgUkZDIDMwNjYgYWxyZWFkeSBoYXZlIG1hdGNoaW5nIHBy b2JsZW1zLiBDb25zaWRlciB0aGUgImRlLTE5eHgiLyJkZS1DQy0xOXh4IiBjb2xsZWN0aW9uIG9m IHRhZ3MsIHdoaWNoIGFscmVhZHkgZGVtb25zdHJhdGVzIHRoZSAic3VidGFnIGluIHRoZSBtaWRk bGUiIHNlbGVjdGlvbiBwcm9ibGVtLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMN Ckdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRl cm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRp b24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2 aXNAanRjc3YuY29tXQ0KPiBTZW50OiBtYXJkaSAyMiBtYXJzIDIwMDUgMTM6MjYNCj4gVG86IEFk ZGlzb24gUGhpbGxpcHM7IFBldGVyIENvbnN0YWJsZTsgRnJhbmsgRWxsZXJtYW5uOyBsdHJ1QGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gUmU6IFByZXBhcmF0aW9ucyBmb3Igc21hcnQg bWF0Y2hpbmcNCj4gDQo+IFNvbWUgbGFuZ3VhZ2VzIGFyZSBjdXN0b21hcmlseSB3cml0dGVuIGlu IG11bHRpcGxlIHNjcmlwdHMsIHdoaWxlIG90aGVycw0KPiBhcmUNCj4gY3VzdG9tYXJpbHkgd3Jp dHRlbiBpbiBhIHNpbmdsZSBzY3JpcHQuIEluIHRoZSBjYXNlIG9mIEVuZ2xpc2gsIHRoZQ0KPiBv dmVyd2hlbG1pbmcgbWFqb3JpdHkgb2YgRW5nbGlzaCB0ZXh0IGlzIHdyaXR0ZW4gd2l0aCBMYXRp biwganVzdCBhcyB0aGUNCj4gb3ZlcndoZWxtaW5nIG1ham9yaXR5IG9mIEFyYWJpYyBpcyB3cml0 dGVuIGluIHRoZSBBcmFiaWMgc2NyaXB0LiBCdXQgdGhlcmUNCj4gYXJlLCBvZiBjb3Vyc2UsIGRv Y3VtZW50cyB0aGF0IGRvIGhhdmUgYXItTGF0biwgc3VjaCBhcyBjZXJ0YWluIGJvb2tzDQo+IHRl YWNoaW5nIEFyYWJpYy4gU28gdG8gKmFsd2F5cyogbWFwIGFyIHRvIGFyLUFyYWIgaXMgYSBtaXN0 YWtlLiBBbmQgaXQNCj4gZ2V0cw0KPiBmdXp6aWVyIGZvciBjYXNlcyBsaWtlIFNlcmJpYW4sIHdo ZXJlIHdoaWxlIHRoZSBwcmVkb21pbmFudCBjYXNlIG9mIHNyIGlzDQo+IHNyLUN5cmwsIGJ1dCB0 aGVyZSBhcmUgc2lnbmlmaWNhbnQgYW1vdW50cyBvZiBzci1MYXRuLg0KPiANCj4gSXQgcmVhbGx5 IGRlcGVuZHMgb24gd2hhdCB0aGUgbWF0Y2hpbmcgcHJvY2VzcyBpcyAqZm9yKi4gVGhlcmUgYXJl DQo+IGRpZmZlcmVudA0KPiB1c2FnZXMgb2YgbGFuZ3VhZ2UgdGFncyB0aGF0IG1heSBoYXZlIGRp ZmZlcmVudCBtYXRjaGluZyBzdHJhdGVnaWVzLiBGb3INCj4gZXhhbXBsZToNCj4gDQo+IDEuIE1h dGNoaW5nLiBVc2Ugb2YgJ3NyJyBzYXlzIHRoYXQgeW91IHdhbnQgdG8gbWF0Y2ggU2VyYmlhbiBv Zg0KPiB3aGF0ZXZlciBmb3JtOiBkb2Vzbid0IGRlcGVuZCBvbiB0aGUgY291bnRyeSwgZG9lc24n dCBkZXBlbmQgb24gdGhlIHNjcmlwdC4NCj4gVXNlIG9mLCBzYXksICdzci1MYXRuLUlUJyBtZWFu cyB0aGF0IHlvdSB3YW50IFNlcmJpYW4sIGJ1dCBsaW1pdGVkIHRvDQo+IExhdGluIHNjcmlwdCwg YW5kIGFzIHVzZWQgaW4gSXRhbHkuIElmIEkgd2FudCB0byBoYXZlIGEgZG9jdW1lbnQgcXVlcnks DQo+IHRoZW4NCj4gSSBjb3VsZCB1c2Ugb25lIG9mIHRoZSBhYm92ZSB0byByZXN0cmljdCB0aGUg ZG9jdW1lbnRzIHRoYXQgbWF0Y2ggbXkgcXVlcnkuDQo+IEkgY291bGQgZ2V0IGJhY2sgMTAwMCBk b2N1bWVudHMgb3Igbm9uZSwgYWNjb3JkaW5nIHRvIHdoYXQgZGF0YWJhc2Ugb2YNCj4gZG9jdW1l bnRzIEkgYW0gc2VhcmNoaW5nIGFuZCBob3cgcmVzdHJpY3RpdmUgbXkgcXVlcnkgaXMuIEkgY2Fu IGFsc28NCj4gcHJvYmFibHkgc3RydWN0dXJlIHF1ZXJpZXMgd2l0aCBtb3JlIGNhcGFiaWxpdGll cywgc3VjaCBhcyAoc3IgQU5EIChMYXRuDQo+IE9SDQo+IEN5cmwpKSBPUiAocnUtQ3lybCkpDQo+ IA0KPiAyLiBMb29rdXAuIFdoZW4geW91IGxvb2t1cCBsYW5ndWFnZSBkYXRhLCBmb3IgZXhhbXBs ZSwgZm9yIGRpc3BsYXkgb24gYQ0KPiB3ZWINCj4gcGFnZSwgaXQgaXMgYSBkaWZmZXJlbnQgcHJv Y2Vzcy4gWW91IHR5cGljYWxseSBkb24ndCBoYXZlIHRoZSBjaG9pY2Ugb2YNCj4gZGlzcGxheWlu ZyBub3RoaW5nIGlmIHRoZXJlIGlzIG5vdCBhbiBleGFjdCBtYXRjaC4gSW5zdGVhZCwgeW91IGZh bGwgYmFjay4NCj4gSWYgeW91IGRvbid0IGhhdmUgZGF0YSBleGFjdGx5IG1hdGNoaW5nICdzci1M YXRuLUlUJywgeW91IGZhbGxiYWNrIHRvIGRhdGENCj4gZm9yICdzci1MYXRuJy4gSWYgeW91IGRv bid0IGhhdmUgdGhhdCBlaXRoZXIsIHlvdSBmYWxsYmFjayB0byBkYXRhIGZvcg0KPiAnc3InLg0K PiBOb3csIHdoYXRldmVyIGRhdGEgY29udGVudHMgc29tZW9uZSBoYXMgYXNzb2NpYXRlZCB3aXRo ICdzcicsIGl0IGhhcyB0byBiZQ0KPiBhDQo+IHNpbmdsZSBjb25zaXN0ZW50IHR5cGUgb2YgZGF0 YSwgc28gaXQgd2lsbCBiZSBpbiBvbmUgb2YgJ0xhdG4nIG9yICdDeXJsJy4NCj4gDQo+IFNpbWls YXJseSwgQW1lcmljYW4gRW5nbGlzaCBtYXkgYmUgdXNlZCBpbiBkYXRhIGFzc29jaWF0ZWQgd2l0 aCBlbiBmb3INCj4gbG9va3VwIHB1cnBvc2VzLiBBbnkgZGlzdGluY3Rpb25zIGFjY29yZGluZyB0 byBjb3VudHJ5IHdvdWxkIGJlIHN0b3JlZA0KPiBzZXBhcmF0ZWx5IGluIGFuICdlbi1BVScsICdl bi1DQScsICdlbi1JRScsIGV0Yy4sIGFuZCBpZiBhdmFpbGFibGUsIHdvdWxkDQo+IGJlDQo+IGZv dW5kIGluIGEgbG9va3VwLiBCdXQgaWYgc29tZW9uZSBjYW1lIGluIHdpdGggJ2VuLUpQJywgYW5k IHRoZXJlIHdhcyBubw0KPiBzZXBhcmF0ZSBkYXRhIHNvdXJjZSBmb3IgdGhhdCwgaXQgd291bGQg ZmFsbCBiYWNrIHRvIHRoZSBkYXRhIGFzc29jaWF0ZWQNCj4gd2l0aCAnZW4nLCB3aGljaCB3b3Vs ZCBiZSBBbWVyaWNhbiBFbmdsaXNoLg0KPiANCj4gVGh1cywgSSB0aGluayBpdCBtYXkgYmUgcmVh c29uYWJsZSwgaW4gc3VwcG9ydCBvZiBsb29rdXAgZmFsbGJhY2sNCj4gc3RyYXRlZ2llcywgdG8g aGF2ZSBhIHRhYmxlIG9mIGRhdGEgZGVzaWduZWQgZm9yICJkZWZhdWx0IiBsb29rdXAgZmFsbGJh Y2ssDQo+IHN0cnVjdHVyZWQgYWxvbmcgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyBsaW5l czoNCj4gDQo+IGZhbGxiYWNrIHwgZW4gfCBlbi1MYXRuDQo+IGZhbGxiYWNrIHwgc3IgfCBzci1D eXJsDQo+IGZhbGxiYWNrIHwgcHQgfCBwdC1CUiBwdC1MYXRuLUJSDQo+IA0KPiBIb3dldmVyLCB0 byBtZSB0aGlzIGlzIGluZm9ybWF0aW9uIHRoYXQgaXMgbXVjaCBtb3JlIGNsb3NlbHkgYXNzb2Np YXRlZA0KPiB3aXRoDQo+IG1hdGNoaW5nIHRoYW4gd2l0aCB0aGUgc3RydWN0dXJlIG9mIGxhbmd1 YWdlIHRhZ3MsIGFuZCB0aHVzIHNob3VsZCBiZQ0KPiBkaXNjdXNzZWQgYW5kIGVsYWJvcmF0ZWQg aW4gdGhlIGNvbnRleHQgb2YgdGhlIG1hdGNoaW5nIGRvY3VtZW50LCB3aGVuIHdlDQo+IHN0YXJ0 IHdvcmsgb24gdGhhdC4NCj4gDQo+IOKAjk1hcmsNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCj4gRnJvbTogIkFkZGlzb24gUGhpbGxpcHMiIDxhZGRpc29uLnBoaWxsaXBzQHF1 ZXN0LmNvbT4NCj4gVG86ICJQZXRlciBDb25zdGFibGUiIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29t PjsgIkZyYW5rIEVsbGVybWFubiINCj4gPG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT47IDxsdHJ1 QGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAyMiwgMjAwNSAwOTo0Nw0KPiBTdWJq ZWN0OiBSRTogW0x0cnVdIFJlOiBQcmVwYXJhdGlvbnMgZm9yIHNtYXJ0IG1hdGNoaW5nDQo+IA0K PiANCj4gPiA+IEF0IHRoZSBtb21lbnQgdGhlIGRyYWZ0IHNheXM6DQo+ID4gPg0KPiA+ID4gfCBU aGUgInJlY29tbWVuZGVkX3ByZWZpeCIgZmllbGQgaXMgZW1wdHksIGV4Y2VwdCB3aGVyZSB0aGUN Cj4gPiA+IHwgdHlwZSBpcyAidmFyaWFudCINCj4gPiA+DQo+ID4gPiBUaGF0IGNvdWxkIGJlIGNo YW5nZWQgdG8gZS5nLg0KPiA+ID4NCj4gPiA+ICAgVGhlICJyZWNvbW1lbmRlZF9wcmVmaXgiIGlz IGdlbmVyYWxseSBlbXB0eS4gIEluIHRoZSBjYXNlIG9mDQo+ID4gPiAgIGEgInZhcmlhbnQiIGl0 J3Mgb2Z0ZW4gdGhlIHJlY29tbWVuZGVkICJsYW5ndWFnZSIgcHJlZml4LCBidXQNCj4gPiA+ICAg Y291bGQgYmUgYWxzbyBhIGxhbmd1YWdlLXNjcmlwdCwgbGFuZ3VhZ2Utc2NyaXB0LXJlZ2lvbiwg b3INCj4gPiA+ICAgbGFuZ3VhZ2UtcmVnaW9uIHByZWZpeC4NCj4gPg0KPiA+IFRoYXQncyBhbiBp bnRlcmVzdGluZyBzdWdnZXN0aW9uIHdvcnRoIHNvbWUgdGhvdWdodC4NCj4gDQo+IFVtLi4udGhh dCdzIHdoYXQgaXQgZG9lcyBzYXksIGV4Y2VwdCB0aGF0IHRoZSBkcmFmdCBkb2Vzbid0IHNheSB3 aGF0IEZyYW5rDQo+IHNheXMgaXQgc2F5cy4gSXQgYWN0dWFsbHkgc2F5czoNCj4gDQo+IDxxdW90 ZT4NCj4gVGhlIGZpZWxkICdyZWNvbW1lbmRlZCBwcmVmaXgnIGlzIGZvciB1c2Ugd2l0aCByZWdp c3RlcmVkIHZhcmlhbnRzIGFuZA0KPiBjb250YWlucyBhIHNlbWljb2xvbiBzZXBhcmF0ZWQgbGlz dCBvZiBsYW5ndWFnZS1yYW5nZXMgY29uc2lkZXJlZCBtb3N0DQo+IGFwcHJvcHJpYXRlIGZvciB1 c2Ugd2l0aCB0aGlzIHN1YnRhZy4gQWRkaXRpb25hbCB2YWx1ZXMgY2FuIGJlIGFkZGVkIHRvDQo+ IHRoaXMNCj4gZmllbGQgZm9yIHZhcmlhbnRzIG9ubHkgdmlhIGFkZGl0aW9uYWwgcmVnaXN0cmF0 aW9uLiBPdGhlciBtb2RpZmljYXRpb24gb2YNCj4gdGhpcyBmaWVsZCAoc3VjaCBhcyByZW1vdmlu ZyBvciBjaGFuZ2luZyB2YWx1ZXMpIGlzIG5vdCBwZXJtaXR0ZWQuDQo+IDwvcXVvdGU+DQo+IA0K PiBBIGxhbmd1YWdlIHJhbmdlIGlzIGRlZmluZWQgdG8gYWxsb3cgaW5jbHVzaW9uIG9mIGFsbCBv ZiB0aGUgZXhhbXBsZXMNCj4gRnJhbmsNCj4gZ2l2ZXMuIFdlIGNhbiAoYW5kIHNob3VsZCkgcmVt b3ZlIHRoZSByZXN0cmljdGlvbiB0byByZWdpc3RlcmVkIHZhcmlhbnRzDQo+IGluDQo+IHRoZSB0 ZXh0Lg0KPiANCj4gQW5vdGhlciB3YXkgdG8gYWNjb21wbGlzaCB3aGF0IEkgdGhpbmsgRnJhbmsg aXMgc3VnZ2VzdGluZyBpcyB0byBwcm92aWRlIGENCj4gY2Fub25pY2FsIG1hcHBpbmcgc2VjdGlv biBpbiB0aGUgcmVnaXN0cnkuIFdlIGNvdWxkIGNyZWF0ZSBzcGVjaWZpYw0KPiAicmFuZ2UiDQo+ IGVudHJpZXMgd2l0aCBjYW5vbmljYWwgbWFwcGluZ3MgaW4gdGhpcyBtYW5uZXI6DQo+IA0KPiAN Cj4gY2Fub25pY2FsIHwgZW4tTGF0biB8IEVuZ2xpc2ggd3JpdHRlbiBpbiBMYXRpbiBTY3JpcHQg fCBlbiB8IHwgIyB1c2UgJ2VuJw0KPiBwcmVmaXgsIG5vdCBlbi1MYXRuDQo+IA0KPiBJZiB1c2Vy cyBmZWVsIHN0cm9uZ2x5IGFib3V0IGNlcnRhaW4gY29tYmluYXRpb25zIHRoZXkgY291bGQgcmVn aXN0ZXIgdGhlbS4NCj4gUnVsZXMgd291bGQgaGF2ZSB0byBiZSBjcmVhdGVkIHRvIHByZXZlbnQg YWJ1c2UgKGZvciBleGFtcGxlLCB5b3UgY291bGRuJ3QNCj4gY3JlYXRlIG1hcHBpbmdzIHRoYXQg Y3JlYXRlIGFtYmlndWl0eSwgc3VjaCBhcyBtYXBwaW5nIGJvdGggemgtSGFudCBhbmQNCj4gemgt SGFucyB0byB6aCkuIE5vdGUgdGhhdCB0aGVzZSBjYW5vbmljYWwgbWFwcGluZ3Mgd291bGQgYmUg aW5mb3JtYXRpb25hbA0KPiBpbg0KPiBuYXR1cmUuIFRhZ3Mgc3VjaCBhcyBlbi1MYXRuLVVTIHdv dWxkIHN0aWxsIGJlIHdlbGwtZm9ybWVkIGFuZCB2YWxpZC4gVGhpcw0KPiB3b3VsZCBtZXJlbHkg YWxsb3cgdGFnIHByb2Nlc3NvcnMgaW4gcG9zc2Vzc2lvbiBvZiB0aGUgcmVnaXN0cnkgdG8gaWdu b3JlDQo+IHRoZSBzdWJ0YWcgTGF0biB3aGVuIG1hdGNoaW5nIHRoZSB0YWcgKGJ5IGNhbm9uaWNh bGl6aW5nIHRoZSB0YWcgdG8gZW4tVVMNCj4gYmVmb3JlIG1hdGNoaW5nKS4NCj4gDQo+IEJlc3Qg UmVnYXJkcywNCj4gDQo+IEFkZGlzb24NCj4gDQo+IEFkZGlzb24gUC4gUGhpbGxpcHMNCj4gR2xv YmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQo+IENoYWlyLCBXM0MgSW50ZXJu YXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQo+IA0KPiBJbnRlcm5hdGlvbmFsaXph dGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiBJdCBpcyBhbiBhcmNoaXRlY3R1cmUuDQo+IA0KPiA+ DQo+ID4NCj4gPiA+ICAgRm9yIHRoZSB0eXBlICJsYW5ndWFnZSIgdGhpcyBmaWVsZCBjYW4gYmUg dXNlZCB0byBkZWZpbmUgYQ0KPiA+ID4gICBkZWZhdWx0ICJzY3JpcHQiIGZvciB0aGUgY29ycmVz cG9kaW5nICJsYWd1YWdlIiwgYW5kIHRoZW4gdGhlDQo+ID4gPiAgIHJlc3VsdGluZyB0YWcgb3Ig cHJlZml4IGxhbmd1YWdlLXNyaXB0IGlzIE5PVCBSRUNPTU1FTkRFRC4NCj4gPg0KPiA+IEFoISBZ b3UnZCB1c2UgdGhpcyB0byBpbmRpY2F0ZSBhIGRlZmF1bHQgc2NyaXB0IGZvciBjYXNlcyBpbiB3 aGljaCB0aGVyZQ0KPiA+IGlzIG9uZSB0aGF0IGlzIHByZWRvbWluYW50LiBBIGJldHRlciBzdWdn ZXN0aW9uIHRoYW4gd2hhdCBJIHRob3VnaHQgeW91DQo+ID4gaGFkIGluIG1pbmQuIE5vdGUsIHRo b3VnaCwgdGhhdCB0aGVyZSB3aWxsIGJlIGdyYXkgYXJlYXM6IDk5Ljk5JSBvZiBhbGwNCj4gPiBl biBjb250ZW50IGlzIGluIHRoZSBjb21tb24gTGF0aW4gb3J0aG9ncmFwaHkgcmF0aGVyIHRoYW4g b3RoZXIgd3JpdGluZw0KPiA+IHN5c3RlbXMsIHN1Y2ggYXMgSVBBIG9yIEdyZWdnIFNob3J0aGFu ZDsgaXQncyBjbGVhciB3ZSdkIGNvbnNpZGVyIExhdG4NCj4gPiB0aGUgZGVmYXVsdCBpbiBzdWNo IGEgY2FzZS4gV2hhdCBpZiB0aGUgcHJvcG9ydGlvbiB3ZXJlIDk1JT8gOTAlPyA4NSU/DQo+ID4g Li4uICBXaGF0J3MgdGhlIHRocmVzaG9sZCBhdCB3aGljaCB3ZSBiZWdpbiB0byBhc3N1bWUgYSBk ZWZhdWx0Pw0KPiA+DQo+ID4NCj4gPiA+ID4gVGh1cyBpZiB5b3Ugd2FudCB0byBtYXRjaCAiZW4t TGF0bi1VUy1ib29udCIgd2l0aCAiZW4tYm9vbnQiLA0KPiA+ID4gPiBpdCBpcyBlbm91Z2ggdG8g ZGlzYXNzZW1ibGUgYm90aCB0YWdzIGFuZCBvYnNlcnZlIHRoYXQgYWxsDQo+ID4gPiA+IHRoZSBz dWJ0YWdzIGluIHRoZSBzZWNvbmQgdGFnIGFyZSBhbHNvIHByZXNlbnQgaW4gdGhlIGZpcnN0Lg0K PiA+ID4NCj4gPiA+IFRoYXQncyBJTUZPIG5vdCBnb29kIGVub3VnaC4gIElmIGEgY2xpZW50IG9m ZmVycyBlbi1ib29udCBhbmQNCj4gPiA+IGVuLW1pc2MgKHNjcmlwdCAibWlzYyIpLCBhbmQgdGhl IHNlcnZlciBoYXMgZW4tbWlzYy1VUy1ib29udCwNCj4gPiA+IHRoZW4gdGhlIGNsaWVudCBzaG91 bGQgdHJ5IGVuLW1pc2MsIGJ1dCBub3QgZW4tYm9vbnQuDQo+ID4gPg0KPiA+ID4gQmVjYXVzZSAi bWlzYyIgaXMgcHJvYmFibHkgdmVyeSBpbXBvcnRhbnQsIGlmIGl0J3Mgbm90ICJMYXRuIg0KPiA+ ID4gYXMgaW4gdGhlIGRlZmF1bHQgZm9yIGVuLg0KPiA+ID4NCj4gPiA+ID4gSWYgImVuLUxhdG4t VVMtYm9vbnQiIGlzIGEgbWF0Y2ggZm9yICJlbi1ib29udCIsIHRoZW4gc28gaXMNCj4gPiA+ID4g ImVuLU9nYW0tTVYtYm9vbnQiLg0KPiA+ID4NCj4gPiA+IFVubGVzcyB5b3UgaGF2ZSBlbi1PZ2Ft LCB0aGVuIHlvdSBuZWVkIHRvIGtub3cgdGhlIGRlZmF1bHQNCj4gPiA+IHNjcmlwdCBmb3IgZW4g KHdoaWNoIGlzbid0IE9nYW0pLg0KPiA+DQo+ID4gSGFuZyBvbi4gSXQncyB1bmNsZWFyIHdoYXQg eW91J3JlIGNvbXBhcmluZy4gWW91IG5lZWQgdG8gc3RhcnQNCj4gPiBxdWFsaWZ5aW5nIHRoZSBh cmd1bWVudCBzdHJ1Y3R1cmUgaGVyZTogeW91J3JlIGNvbXBhcmluZyB0d28gdGFnczogb25lDQo+ ID4gaXMgdGhlIHdoYXQgaXMgYmVpbmcgcmVxdWVzdGVkLCB0aGUgb3RoZXIgaXMgdGhlIGF0dHJp YnV0ZSBvZiB0aGUNCj4gPiByZXNvdXJjZSBpbiB0aGUgcmVwb3NpdG9yeS4gWW91J3ZlIGdvdCB0 byBzcGVjaWZ5IHdoaWNoIGlzIHdoaWNoLg0KPiA+DQo+ID4gSWYgdGhlIHJlcXVlc3QgaXMgZm9y ICJlbi1ib29udCIsIHRoZW4gImVuLU9nYW0iIGluIHRoZSByZXBvc2l0b3J5DQo+ID4gc2hvdWxk IG5vdCBiZSBhIG1hdGNoIChleGNlcHQgaW4gYSBmYWxsYmFjayBzaXR1YXRpb24sIHdoZW4geW91 IG11c3QNCj4gPiByZXR1cm4gc29tZXRoaW5nLCBoYXZlbid0IGZvdW5kIGEgbWF0Y2ggYW5kIGFy ZSBsb29raW5nIGZvciB0aGUgYmVzdA0KPiA+IGF2YWlsYWJsZSBhbHRlcm5hdGl2ZSAtLSBlLmcu IHNvZnR3YXJlIFVJIHJlc291cmNlIGxvYWRpbmcpLiBUaGF0J3Mgbm90DQo+ID4gYmVjYXVzZSB0 aGUgc2NyaXB0IGlzbid0IExhdG47IGl0J3MgYmVjYXVzZSB0aGUgcmVxdWVzdCB3YXMgc3BlY2lm aWNhbGx5DQo+ID4gZm9yIEJvb250bGluZywgYW5kICJlbi1PZ2FtIiBpcyBub3QgY29uc3RyYWlu ZWQgdG8gdGhhdC4NCj4gPg0KPiA+IElmIHRoZSByZXF1ZXN0IGlzIGZvciAiZW4tYm9vbnQiLCB0 aGVuIGlkZWFsbHkgeW91J2Qgd2FudA0KPiA+ICJlbi1MYXRuLVVTLWJvb250IiAoaWYgdGhhdCB3 ZXJlIGFjdHVhbGx5IHVzZWQpIGluIHRoZSByZXBvc2l0b3J5IHRvIGJlDQo+ID4gYSBtYXRjaC4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBQZXRlciBDb25zdGFibGUNCj4gPg0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTHRydSBtYWlsaW5nIGxp c3QNCj4gPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMu aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K DQoNCg== --===============0356084484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0356084484==-- From ltru-bounces@ietf.org Tue Mar 22 18:38:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21440; Tue, 22 Mar 2005 18:38:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDt2b-00033r-FA; Tue, 22 Mar 2005 18:44:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDswJ-0001Ek-NR; Tue, 22 Mar 2005 18:37:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDswI-0001Ee-83 for ltru@megatron.ietf.org; Tue, 22 Mar 2005 18:37:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21409 for ; Tue, 22 Mar 2005 18:37:31 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDt1e-000331-Ea for ltru@ietf.org; Tue, 22 Mar 2005 18:43:06 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 15:37:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Getting back on track Date: Tue, 22 Mar 2005 15:37:24 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82644@irvmbxw01.quest.com> Thread-Topic: [Ltru] Getting back on track Thread-Index: AcUvLYAW9jymUYs9Qe2u7FyoevHDNwACPw0w From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "Mark Davis" X-OriginalArrivalTime: 22 Mar 2005 23:37:24.0682 (UTC) FILETIME=[19C322A0:01C52F38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable JFC, You have not presented a list of comments about the current draft. = Neither have you proposed an alternate design. Why should the WG wait = for many weeks while you write an individual submission Internet-Draft = if you can't be bothered to debate the existing design or propose a new = design? You'll note that before Mark and I wrote the very first draft of what is = today the registry document we discussed the design in public. In my = opinion, you should do the same thing. If there is a consensus favoring = your design, then it can be incorporated into the working group's draft = as appropriate. With regard to your question about my schedule: how about 'never'? I = don't have time to help you write your document. I'm busy editing the = official draft and engaging in necessary debate on this list. If you = want to write a document, you're on your own. Both Mark and I have = numerous publicly available documents describing our view of the = requirements and our intentions. No doubt if we have objections to your = proposal we will enumerate them in the proper way and at the proper = time. With regard to CLDR, which is really Mark's area rather than mine, I = will note that the current registry draft has *no* dependency on CLDR, = nor should it. Copyright issues in your individual submission are your = problem, although I can't imagine any that would arise from referencing = an external standard. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: mardi 22 mars 2005 14:16 > To: Mark Davis > Cc: ltru@ietf.org > Subject: Re: [Ltru] Getting back on track >=20 > On 22:38 22/03/2005, Mark Davis said: > >The discussion has meandered around a bit: I'd like to see us get = back on > >track. Here is how I suggest we proceed. >=20 > >Within the next week, anyone who has any issues with the text of the > current > >draft does the following: > > > >a. Composes a separate message on each issue, with a meaningful = title. > >b. Suggests exact replacement text, with clear instructions on where = to > make > >the change. > >c. Describes the pros and cons of making the change. > > > >We review by email each request. If there is consensus for if, then = we > >record that. If not, we leave it alone. Once we have processed all = the > >issues, we issue a new draft that incorporates all the changes. We > circulate > >that, and if there are no problems with the incorporation of all the > >changes, then we advance the document. >=20 > As indicated we will not be in a position to issue a draft before at = least > two weeks. It will certainly substantially differ from the current = draft. > And will probably be amended during its further international review. = But > the support of your propositions should be as much possible included = in it. > So this schedule seems OK if the Chairs agree. We should have your > elements > in time. >=20 > I have however two missing information: > - when do you/Addison intend to comment the inputs he required from = me, so > I can organize our schedule? > - we have discussed nothing on the CLDR aspect. You are the best = suited to > tell us what are the requirements of the CLDR project in the RFC 3066 > context and how we can best address them? I am also obviously = concerned > about the copyright issue as the RFC should indicate that the CLDR is > public domain. Or we would have to investigate a public domain = alternative. >=20 > Thank you for your cooperation. > jfc >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Standardizing Tags for the Identification of Languages should not be a = way > to standardize languages and to unify the world under a dominant = culture. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > For your convenience: > RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3D3066 > Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry- > 00.txt > Charter: http://ietf.org/html.charters/ltru-charter.html > gmane: http://dir.gmane.org/gmane.ietf.ltru > If you were Bcced for information and not familliar with the IETF = process: > http://www.ietf.org/rfc/rfc2026.txt > http://www.ietf.org/rfc/rfc2418.txt > http://www.ietf.org/rfc/rfc3934.txt > http://www.ietf.org/rfc/rfc3669.txt > http://www.ietf.org/rfc/rfc3160.txt > http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Jon Postel (RFC 1591): "The IANA is not in the business of deciding > what is and what is not a country. The selection of the ISO 3166 list > as a basis for country code top-level domain names was made with > the knowledge that ISO has a procedure for determining which > entities should be and should not be on that list." > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing = the > same thing, choose one. If a previous design, in the Internet context > or elsewhere, has successfully solved the same problem, choose the > same solution unless there is a good technical reason not to. > Duplication of the same protocol functionality should be avoided as = far as > possible, without of course using this argument to reject = improvements." > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > It seems that what works for countries and ISO 3166 since 1978, should > apply to languages and to ISO 693. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 22 20:31:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02735; Tue, 22 Mar 2005 20:31:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDunc-0007nV-Jr; Tue, 22 Mar 2005 20:36:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDui3-00007t-9l; Tue, 22 Mar 2005 20:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDui1-00005n-FC for ltru@megatron.ietf.org; Tue, 22 Mar 2005 20:30:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02722 for ; Tue, 22 Mar 2005 20:30:54 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDunI-0007ja-Hw for ltru@ietf.org; Tue, 22 Mar 2005 20:36:29 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2N1UMqc000907 for ; Tue, 22 Mar 2005 20:30:22 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2N1UL0c209972 for ; Tue, 22 Mar 2005 20:30:22 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2N1ULw2018259 for ; Tue, 22 Mar 2005 20:30:21 -0500 Received: from markdavis (sig-9-48-125-114.mts.ibm.com [9.48.125.114]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2N1UKsn018220; Tue, 22 Mar 2005 20:30:21 -0500 Message-ID: <047f01c52f47$e0f519f0$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "JFC \(Jefsey\) Morfin" References: <634978A7DF025A40BFEF33EB191E13BC0AB82644@irvmbxw01.quest.com> Subject: Re: [Ltru] Getting back on track Date: Tue, 22 Mar 2005 17:30:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id j2N1UMqc000907 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable I agree entirely with what Addison said, and want to emphasize that none = of this has any dependence on CLDR whatsoever. Addison and I have been working on the current draft for quite a while, a= nd have benefited from feedback from a wide variety of people. If you want t= o write your own document, you are of course free to, but I have the feelin= g that the direction that you are headed is far outside of the scope of the current working group's charter. He and I will be focusing on comments on the current draft. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "JFC (Jefsey) Morfin" ; "Mark Davis" Cc: Sent: Tuesday, March 22, 2005 15:37 Subject: RE: [Ltru] Getting back on track JFC, You have not presented a list of comments about the current draft. Neithe= r have you proposed an alternate design. Why should the WG wait for many we= eks while you write an individual submission Internet-Draft if you can't be bothered to debate the existing design or propose a new design? You'll note that before Mark and I wrote the very first draft of what is today the registry document we discussed the design in public. In my opinion, you should do the same thing. If there is a consensus favoring y= our design, then it can be incorporated into the working group's draft as appropriate. With regard to your question about my schedule: how about 'never'? I don'= t have time to help you write your document. I'm busy editing the official draft and engaging in necessary debate on this list. If you want to write= a document, you're on your own. Both Mark and I have numerous publicly available documents describing our view of the requirements and our intentions. No doubt if we have objections to your proposal we will enumerate them in the proper way and at the proper time. With regard to CLDR, which is really Mark's area rather than mine, I will note that the current registry draft has *no* dependency on CLDR, nor sho= uld it. Copyright issues in your individual submission are your problem, although I can't imagine any that would arise from referencing an externa= l standard. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: mardi 22 mars 2005 14:16 > To: Mark Davis > Cc: ltru@ietf.org > Subject: Re: [Ltru] Getting back on track > > On 22:38 22/03/2005, Mark Davis said: > >The discussion has meandered around a bit: I'd like to see us get back= on > >track. Here is how I suggest we proceed. > > >Within the next week, anyone who has any issues with the text of the > current > >draft does the following: > > > >a. Composes a separate message on each issue, with a meaningful title. > >b. Suggests exact replacement text, with clear instructions on where t= o > make > >the change. > >c. Describes the pros and cons of making the change. > > > >We review by email each request. If there is consensus for if, then we > >record that. If not, we leave it alone. Once we have processed all the > >issues, we issue a new draft that incorporates all the changes. We > circulate > >that, and if there are no problems with the incorporation of all the > >changes, then we advance the document. > > As indicated we will not be in a position to issue a draft before at le= ast > two weeks. It will certainly substantially differ from the current draf= t. > And will probably be amended during its further international review. B= ut > the support of your propositions should be as much possible included in it. > So this schedule seems OK if the Chairs agree. We should have your > elements > in time. > > I have however two missing information: > - when do you/Addison intend to comment the inputs he required from me,= so > I can organize our schedule? > - we have discussed nothing on the CLDR aspect. You are the best suited= to > tell us what are the requirements of the CLDR project in the RFC 3066 > context and how we can best address them? I am also obviously concerned > about the copyright issue as the RFC should indicate that the CLDR is > public domain. Or we would have to investigate a public domain alternative. > > Thank you for your cooperation. > jfc > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Standardizing Tags for the Identification of Languages should not be a = way > to standardize languages and to unify the world under a dominant cultur= e. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > For your convenience: > RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3D3066 > Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry- > 00.txt > Charter: http://ietf.org/html.charters/ltru-charter.html > gmane: http://dir.gmane.org/gmane.ietf.ltru > If you were Bcced for information and not familliar with the IETF proce= ss: > http://www.ietf.org/rfc/rfc2026.txt > http://www.ietf.org/rfc/rfc2418.txt > http://www.ietf.org/rfc/rfc3934.txt > http://www.ietf.org/rfc/rfc3669.txt > http://www.ietf.org/rfc/rfc3160.txt > http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Jon Postel (RFC 1591): "The IANA is not in the business of deciding > what is and what is not a country. The selection of the ISO 3166 list > as a basis for country code top-level domain names was made with > the knowledge that ISO has a procedure for determining which > entities should be and should not be on that list." > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the > same thing, choose one. If a previous design, in the Internet context > or elsewhere, has successfully solved the same problem, choose the > same solution unless there is a good technical reason not to. > Duplication of the same protocol functionality should be avoided as far= as > possible, without of course using this argument to reject improvements.= " > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > It seems that what works for countries and ISO 3166 since 1978, should > apply to languages and to ISO 693. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 00:50:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27660; Wed, 23 Mar 2005 00:50:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDyr1-0008J7-SO; Wed, 23 Mar 2005 00:56:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyl7-0004m0-73; Wed, 23 Mar 2005 00:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyl5-0004lv-47 for ltru@megatron.ietf.org; Wed, 23 Mar 2005 00:50:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27568 for ; Wed, 23 Mar 2005 00:50:20 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDyqT-0008I9-KB for ltru@ietf.org; Wed, 23 Mar 2005 00:55:59 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 21:50:10 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 21:50:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 21:50:22 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUtlwIwHo6TrTMNSDqpeAfp3LTArQAAZ21AAHQh/CA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 23 Mar 2005 05:50:10.0397 (UTC) FILETIME=[2CC468D0:01C52F6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Debbie Garside > My point is... if the information on variant subtag is available, use it... > even though you may not need it for your own purpose. This is what I see > as > facilitating, in particular, the semantic web, knowledge management, > archiving and search/query routines. RFC 3066bis seems intent on making > tags as small as possible (am I wrong? Just my perception), whereas I for > my > purposes, always want as much information as possible, split into the > tiniest of pieces, I can then include/exclude/use/concatenate in any way > required. There's validity to this point: you can't reliably infer information that isn't there, so if an item is tagged in a way that doesn't specify all the relevant attributes that are known, then anybody making use of that metadata later will not be able to benefit from the knowledge that existed but was not recorded and therefore lost. Putting it another way, you can't query using finer distinctions than exist in the data. This has to be applied within a given context, however. For instance, if a library in Thailand is serving primarily a Thai-speaking population and somehow happens to have a dozen items in various South American Indian languages, they could tag the items down to dialects of particular villages, but it would likely be costly for them to do that and there would be a limited expectation of realized benefit for that expense. For them, tagging the language of those items in a non-granular way such as "sai" is adequate for their purposes. If attributes for an item are already known / inexpensive to determine, then in general it shouldn't hurt to specify more than may be needed for immediate purposes -- provided the system within which the info is being used can accommodate the extra details without adding to the cost of developing or maintaining the system and without hindering the required functionality.=20 I.e., if it doesn't cost to use a more specific tag, you might as well use it, as you may not be able to anticipate when that knowledge about a given item will provide to be useful (and if that knowledge turns out to be needed later, it will likely be costly to rediscover that knowledge). Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 01:02:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28420; Wed, 23 Mar 2005 01:02:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDz2A-0000Gl-9Q; Wed, 23 Mar 2005 01:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyuG-0005ue-Tb; Wed, 23 Mar 2005 00:59:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyuE-0005qJ-M5 for ltru@megatron.ietf.org; Wed, 23 Mar 2005 00:59:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28166 for ; Wed, 23 Mar 2005 00:59:47 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDyze-00009z-GQ for ltru@ietf.org; Wed, 23 Mar 2005 01:05:26 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 21:59:40 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 21:59:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 21:59:53 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUtqyMw8oHQmp0xR76qP0IJruNwwQBwU9Sw From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 05:59:40.0720 (UTC) FILETIME=[80B4CB00:01C52F6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > For Unicode mentioning the script makes sense, but for 8bit- > charsets it should be implicit, excl. transliterations for > the moment. But keep in mind that if there is any possibility of the encoding of an item being converted at any point between sender and receiver, then the knowledge inherent in the original charset ID could be lost. If someone sends a message to an online group using Big5 and the message gets converted to Unicode when sent to some or all group members, then those recipients don't benefit from whatever knowledge would be conveyed by the fact that the data had originally been encded in Big5. > That's why I want default scripts and a SHOULD NOT for cases > like en-Latn-*. The recommendation to tag wisely is a waste > of time for software, it can't think. I think these are valid ideas. (But then I would, having written about the significance of default script in a paper a few years back.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 01:29:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00970; Wed, 23 Mar 2005 01:29:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzSh-0001Ct-WC; Wed, 23 Mar 2005 01:35:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzNG-0001Ej-Nw; Wed, 23 Mar 2005 01:29:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzNF-0001DI-HA for ltru@megatron.ietf.org; Wed, 23 Mar 2005 01:29:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00966 for ; Wed, 23 Mar 2005 01:29:48 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzSf-0001Ch-7k for ltru@ietf.org; Wed, 23 Mar 2005 01:35:25 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 22:29:39 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 22:29:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 22:29:52 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUtuLLXd5zVp0EZRxaLngrcg/F5KwBtPQcw From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 06:29:39.0429 (UTC) FILETIME=[B0D20150:01C52F71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Yes. Out of curiosity, what's the idea of ISO 639-3 for the > reserved "extlang" ? This was my idea, which arose as a result of a convergence between a couple of issues I was facing.=20 In preparing to work on ISO 639-3, my colleague, Gary Simons, and I had to figure out how an ID like "zh" should relate to a collection of IDs for specific languages such as Mandarin, Cantonese, etc. Initially, we adopted a set of principles for mapping every item in ISO 639-1/-2 to entries in the Ethnologue. Using those principles, we probably would have said that "zh" denotes specifically Mandarin, it being the most developed of the Chinese languages. But then on reflecting on the tags already registered under RFC 3066, I realized this would be a problem as there already were tags "zh-yue" etc. that applied "zh" in a tag for things other than Mandarin. At that point, my choice was to force a deprecation of the "zh-yue" etc. tags, or to accept that "zh" means something broader than one individual language. There were other cases in which a similar struggle between IDs for specific languages versus IDs being used more broadly seemed to exist. This led me, while preparing ISO/CD 639-3 to add an additional level of scope for language IDs, which I called "macrolanguage". (Not my proudest act of naming, but I still can't think of anything better.) The point of macrolanguage IDs is that they de facto are used in ways that encompass multiple varieties that, for other purposes, would be considered distinct individual languages. To put another angle on it, macrolanguage categories are part of the folk taxonomy that people actually use every day that don't correspond to the categories that a linguist would otherwise identify. Now, coming back to the "zh-yue" tags, I noticed that several of these had a second subtag of three letters, and it occurred to me that, if there were way that these could be made redundant under a revised language tagging spec rather than grandfathered, that that might be beneficial. I also had to think about what to do with ISO 639-3 IDs for things like Cantonese, or like Northern Frisian, at a point at which ISO 639-3 were integrated into a revised language tag RFC: if someone wants to use an ISO 639-3 alpha-3 tag to identify the content specifically as Northern Frisian, but we've already got content being tagged using "fy" for 'Frisian' (without further qualification), then how do you do that in a way that lends itself to interoperability?=20 The obvious answer is that you do what's already done for Cantonese (using a registered tag): you combine the macrolanguage ID "fy" with the individual-language ID "frr" to create a composite tag "fy-frr", analogous to "zh-yue". That way you can tag an items specifically as Frisian and people can request at that level of granularity, but you will still be able to provide a match for the more likely requests for generic 'Frisian' using "fy". I'll leave it at that for the moment. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 01:31:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01067; Wed, 23 Mar 2005 01:31:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzUi-0001HY-5r; Wed, 23 Mar 2005 01:37:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzOJ-0001SV-2g; Wed, 23 Mar 2005 01:30:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzOH-0001S6-NM for ltru@megatron.ietf.org; Wed, 23 Mar 2005 01:30:53 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01013 for ; Wed, 23 Mar 2005 01:30:52 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050323063021.IYUF4618.mta13.adelphia.net@DEWELL> for ; Wed, 23 Mar 2005 01:30:21 -0500 Message-ID: <004601c52f71$c574c020$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050322221955.GVZB2124.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 22 Mar 2005 22:30:12 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Mark Davis wrote: > 1. Matching. Use of 'sr' says that you want to match Serbian of > whatever form: doesn't depend on the country, doesn't depend on the > script. Use of, say, 'sr-Latn-IT' means that you want Serbian, but > limited to Latin script, and as used in Italy. Fine so far. > 2. Lookup. When you lookup language data, for example, for display on > a web page, it is a different process. You typically don't have the > choice of displaying nothing if there is not an exact match. Instead, > you fall back. If you don't have data exactly matching 'sr-Latn-IT', > you fallback to data for 'sr-Latn'. If you don't have that either, you > fallback to data for 'sr'. Now, whatever data contents someone has > associated with 'sr', it has to be a single consistent type of data, > so it will be in one of 'Latn' or 'Cyrl'. But this is just prefix matching. Falling back from "sr-Latn-IT" to "sr-Latn" to "sr" doesn't require us or anyone else to define a default script for Serbian. And when we get to "sr" and finally find a match, we have whatever resources we have. They might be either Latin or Cyrillic. The choice won't depend on which script someone decided was the default. > Similarly, American English may be used in data associated with en for > lookup purposes. Any distinctions according to country would be stored > separately in an 'en-AU', 'en-CA', 'en-IE', etc., and if available, > would be found in a lookup. But if someone came in with 'en-JP', and > there was no separate data source for that, it would fall back to the > data associated with 'en', which would be American English. Not if the content provider is in Australia or Canada or Ireland. Their data will be in their own flavor of English, which is what they would logically call "en". > Thus, I think it may be reasonable, in support of lookup fallback > strategies, to have a table of data designed for "default" lookup > fallback, structured along something like the following lines: > > fallback | en | en-Latn > fallback | sr | sr-Cyrl > fallback | pt | pt-BR pt-Latn-BR I really don't like the idea of this. People will see it as a recommendation or a Diktat that en "means" en-Latn, or (worse) that sr "means" sr-Cyrl. We've never gotten involved with second-guessing what people mean when they write a certain language tag, or choosing one script or region as "preferred" over another. I see no reason to start doing so now. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 01:40:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01512; Wed, 23 Mar 2005 01:40:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzd7-0001YG-3r; Wed, 23 Mar 2005 01:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzWn-00029z-Oa; Wed, 23 Mar 2005 01:39:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzWm-00029u-8R for ltru@megatron.ietf.org; Wed, 23 Mar 2005 01:39:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01445 for ; Wed, 23 Mar 2005 01:39:39 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzcB-0001RV-E9 for ltru@ietf.org; Wed, 23 Mar 2005 01:45:16 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 22:39:29 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 22:39:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 22:39:42 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUt0Gf9FzMqAJfASpGjlF7NlJxWrQBohA0Q From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 23 Mar 2005 06:39:29.0750 (UTC) FILETIME=[10ADD760:01C52F73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > The RFC 3066bis generative syntax is a superset of the RFC 3066 > generative syntax. It allows things to be generated that cannot be > generated under RFC 3066. This needs a little clarification:=20 RFC 3066 has a weak syntax that permits lots of strings; it sanctions a small set of those, requiring others to be registered explicitly. RFC3066bis has a stronger syntax that permits a much more restrictive set of strings than does RFC 3066. On the other hand, it sanctions a much larger portion of the strings its syntax permits, making the need for registration (as well as the possibilities for registration) more limited. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 01:45:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02048; Wed, 23 Mar 2005 01:45:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzhy-0001iP-78; Wed, 23 Mar 2005 01:51:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzbo-0003No-Gh; Wed, 23 Mar 2005 01:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzbn-0003Ni-Ac for ltru@megatron.ietf.org; Wed, 23 Mar 2005 01:44:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01994 for ; Wed, 23 Mar 2005 01:44:50 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzhD-0001h1-IF for ltru@ietf.org; Wed, 23 Mar 2005 01:50:27 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 22:44:41 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 22:44:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Tue, 22 Mar 2005 22:44:54 -0800 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling thread-index: AcUt2JIxV7JeJJWURh2Gy5ie20L3ggBmqUyA From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 06:44:41.0936 (UTC) FILETIME=[CAC1A500:01C52F73] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > However, I wonder if the approach of mandating the use of the macro- > language > code in some, but not all, cases will make matching algorithms overly > complicated. ISO 639-3 will include normative mappings between macrolanguage IDs and the individual-language IDs that they encompass. The availability of those mappings should make it easier to get parsers and matchers to handle this. An important consideration, though, is how to deal with changes in ISO 639-3 such as the introduction of new macro-language IDs. (I don't know that new macrolanguage IDs would ever be added, but I can't predict that it will never happen.) Issues of that nature would need to be incorporated into the text of whatever RFC were to incorporate ISO 639-3 and implement the extlang subtag. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 01:46:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02108; Wed, 23 Mar 2005 01:46:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzig-0001mI-1p; Wed, 23 Mar 2005 01:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzc0-0003Pu-Nc; Wed, 23 Mar 2005 01:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzbz-0003Pg-J7 for ltru@megatron.ietf.org; Wed, 23 Mar 2005 01:45:03 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02012 for ; Wed, 23 Mar 2005 01:45:02 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050323064432.JFIU4618.mta13.adelphia.net@DEWELL> for ; Wed, 23 Mar 2005 01:44:32 -0500 Message-ID: <006201c52f73$bba93420$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 22 Mar 2005 22:44:15 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit At least one person expressed some interest in seeing the draft / proposed / sample registry in record-jar format, so here it is: http://users.adelphia.net/~dewell/lstreg-rj.txt This has no official sanction or consensus; it's just there so people can visualize it (which I guess is true for the other one as well). -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 02:07:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10263; Wed, 23 Mar 2005 02:07:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE02n-0002UG-9w; Wed, 23 Mar 2005 02:12:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzvZ-0006Ca-K5; Wed, 23 Mar 2005 02:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzvX-0006CU-MP for ltru@megatron.ietf.org; Wed, 23 Mar 2005 02:05:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08488 for ; Wed, 23 Mar 2005 02:05:14 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE00w-0002Lo-UJ for ltru@ietf.org; Wed, 23 Mar 2005 02:10:52 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 23:05:04 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 23:05:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 23:05:04 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUt35bc3fCpyWOYTSG1CC5AlpfblgBlHgEQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 23 Mar 2005 07:05:04.0554 (UTC) FILETIME=[A37E58A0:01C52F76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > If I request "de" content, say over the Web, I definitely want to > receive content in both "de-1901" and "de-1996", not just one or the > other. However, if I request "zh" I may not be able to do anything with > "zh-hakka". Of course, if you request "de" content, you might also get back content that's German but written in various ways not useful to the user, such as phonetic transcription, some kind of shorthand, or in Devanagari script, say. That's not different from the "zh-hakka" example. > If you declare 'Latn' to be the default script for 'en', and use that > information to collapse the tag "en-Latn" to "en", then you remove the > user's ability to get "en-Ogam" content unless she specifically requests > it. This essentially says, "Since you requested English, I'll assume > you can only read it in Latin script, and I won't send you English > content in any other script." If a user requests specifically "en-Ogam", that request should never be reduced to "en" -- and I don't think Frank was suggesting that. The real issue is whether a request for "en" should return content tagged "en-Ogam". Existing left-prefix implementations would match, though a "smarter" matching algorithm might of course work differently. It is an issue to be considered. So is the reality that there's a ton of data tagged "en" where that's assumed to mean "en-Latn". Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 02:16:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20333; Wed, 23 Mar 2005 02:16:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0CG-0002nQ-SW; Wed, 23 Mar 2005 02:22:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE052-00080j-Bd; Wed, 23 Mar 2005 02:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE04K-0007kC-5U for ltru@megatron.ietf.org; Wed, 23 Mar 2005 02:14:20 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17286 for ; Wed, 23 Mar 2005 02:14:17 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DE01u-00069x-Ou for ltru@lists.ietf.org; Wed, 23 Mar 2005 08:11:50 +0100 Received: from du-042-145.access.de.clara.net ([213.221.65.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 08:11:50 +0100 Received: from nobody by du-042-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 08:11:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 23 Mar 2005 08:13:15 +0100 Organization: Lines: 35 Message-ID: <4241170B.1485@xyzzy.claranet.de> References: <006201c52f73$bba93420$030aa8c0@DEWELL> 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-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Doug Ewell wrote: > http://users.adelphia.net/~dewell/lstreg-rj.txt Great, thanks, but we still need the normal RfC (2)822 folding for a proper I-D e.g. in line 4068 (107 characters). The idea is to replace a space by : %% Type: grandfathered Subtag: zh-min-nan Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo Date: 2001-03-26 %% You could also use in these cases: %% Type: grandfathered Subtag: zh-min-nan Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo Date: 2001-03-26 %% > This has no official sanction or consensus As soon as it's an I-D it's an "official draft registry". At the moment I'm more worried about the size of the future registry for 7000+ languages, IANA is probably forced to split it somehow on its Web pages. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 02:22:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27668; Wed, 23 Mar 2005 02:22:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0Hd-000307-Rm; Wed, 23 Mar 2005 02:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0B7-0000u4-H7; Wed, 23 Mar 2005 02:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0B4-0000to-PC for ltru@megatron.ietf.org; Wed, 23 Mar 2005 02:21:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26123 for ; Wed, 23 Mar 2005 02:21:17 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0GT-0002tc-Ml for ltru@ietf.org; Wed, 23 Mar 2005 02:26:55 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 23:21:07 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 23:21:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 23:21:19 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUt9lzyI6gp3edlRGar+PNCo1cUSABgafeQ From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 07:21:07.0339 (UTC) FILETIME=[E15BADB0:01C52F78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > But not necessarily de-Brai, so there's definitely a problem. > So far I thought that a "default script" would help, but now > you confused me, is a "default script" actually worse ? Well, there is an issue (one that has been pointed out in the past -- this isn't a new discovery, though it hasn't been heavily discussed before now). But it's hard to say the idea of a default script makes things worse when that is effectively what gets used now -- "en" being used in 99.9999% of cases for English written using the common English alphabet is effectively making "en" to be an alias for "en-Latn". =20 > Assuming that it is worse, then we'd need Debbie's idea, we > SHOULD say de-Latn in new content, and pray that all old pages > are updated. Hell, that's impossible, somewhere I lost it. As long as that's impossible, then we can't say that the idea of recognizing certain defaults is worse. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 02:31:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07486; Wed, 23 Mar 2005 02:31:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0Q0-0003Fq-4s; Wed, 23 Mar 2005 02:36:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0Jf-0002ql-AD; Wed, 23 Mar 2005 02:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0Jb-0002ox-Cf for ltru@megatron.ietf.org; Wed, 23 Mar 2005 02:30:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06662 for ; Wed, 23 Mar 2005 02:30:06 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0P0-0003DT-Qq for ltru@ietf.org; Wed, 23 Mar 2005 02:35:44 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 23:29:52 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 23:29:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 23:30:05 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUuI6PvPHvlFOg+Q1eOFpTgL2gfowBVXTcQ From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 07:29:52.0371 (UTC) FILETIME=[1A4D3430:01C52F7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > I think it worth mentioning that there is no ISO 639-6 on the current > programme of work of ISO TC 37 / SC 2. (My reference in an earlier > posting to ISO/IEC JTC 1 was a mistake, and should be disregarded.) > So at the moment Debbie's draft has no official status with ISO. Not so. There is an approved new work item for ISO 639-6, so Debbie is indeed doing ISO TC 37/SC 2-sanctioned work. In terms of ISO stages, I'd guess it's probably at stage 10.99 -- the project has been approved, but it is not yet registered in the TC 37/SC 2 program of work (hasn't yet shown up on the ISO site listed as a new project). =20 > ISO 639-4 (general principles) and ISO 639-5 (codes for groups of > languages) are in progress, but are irrelevant to RFC 3066bis. I can't say for certain that ISO 639-4 would not have any relevance (it may prove to have some relevance, or it may not); I'd agree though wrt ISO 639-5, as I don't think we should allow additional collective IDs in subtags (if anything, I'd restrict what we already allow). Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 02:41:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11878; Wed, 23 Mar 2005 02:41:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0Zk-0003ct-TP; Wed, 23 Mar 2005 02:46:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0Sj-0004L3-Ed; Wed, 23 Mar 2005 02:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0Sc-0004Ke-Pe for ltru@megatron.ietf.org; Wed, 23 Mar 2005 02:39:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11562 for ; Wed, 23 Mar 2005 02:39:25 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0Y3-0003Wh-8D for ltru@ietf.org; Wed, 23 Mar 2005 02:45:03 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 23:39:17 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 23:39:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 23:39:30 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUuJFKogZvdvWmxQniAE4HUlvkrlQAAbMLgAFVJ6FA= From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 23 Mar 2005 07:39:18.0517 (UTC) FILETIME=[6BC03A50:01C52F7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of L.Gillam > I think this is a time where one should at least ask > questions of the messenger, and perhaps consider less extreme forms of > punitive actions - please see: >=20 > http://isotc.iso.org/livelink/livelink/fetch/2000/2122/687806/ISO_TC_037 __ > = Terminology_and_other_language_resources_.pdf?nodeid=3D1160801&vernum=3D0= Please note that this document is a little bit out of date. For instance, "ISO NWIP 639-3", described as being at stage 20.00, should actually be "ISO DIS 639-3", -- it is at stage 40.20. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 02:46:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12516; Wed, 23 Mar 2005 02:46:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0ef-0003pN-IY; Wed, 23 Mar 2005 02:51:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0Yx-0005Pz-TE; Wed, 23 Mar 2005 02:45:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0Yv-0005PW-SL for ltru@megatron.ietf.org; Wed, 23 Mar 2005 02:45:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12457 for ; Wed, 23 Mar 2005 02:45:56 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0eL-0003lp-D6 for ltru@ietf.org; Wed, 23 Mar 2005 02:51:34 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 22 Mar 2005 23:45:48 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 23:45:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Tue, 22 Mar 2005 23:46:00 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUt9ktkSrx3DthfQDuNT/tk+JlRKwADSa8QAF4cBUA= From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 07:45:47.0178 (UTC) FILETIME=[536930A0:01C52F7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Debbie Garside > I hate to throw a spanner in the works here but still on the subject of > detail... Exactly how much detail can be gleaned from a script code... > Should we perhaps be looking in even finer detail and at extensibility > issues e.g. > en-Character_Set-US > At least you would end up with something useful, forward looking and > extendable... :-) We definitely want extensibility in ways that have potential usefulness for the future. If by "Character_Set" you are suggesting that language tags should include a "charset" component to indicate the character set encoding used for the data, then I think that would not be a good idea: that's not an attribute related to the linguistic content; it's an attribute of the digital representation. The two should really be kept separate. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 03:02:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13859; Wed, 23 Mar 2005 03:02:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0uk-0004OP-9P; Wed, 23 Mar 2005 03:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0od-0007MH-48; Wed, 23 Mar 2005 03:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE0oH-0007Ff-Te for ltru@megatron.ietf.org; Wed, 23 Mar 2005 03:01:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13796 for ; Wed, 23 Mar 2005 03:01:48 -0500 (EST) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE0ti-0004N1-F2 for ltru@ietf.org; Wed, 23 Mar 2005 03:07:26 -0500 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN7-842412256b3; Wed, 23 Mar 2005 03:01:27 -0500 Received: from DEBHOME (ACD7A505.ipt.aol.com [172.215.165.5]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2N81NTX019784; Wed, 23 Mar 2005 03:01:23 -0500 Message-Id: <200503230801.j2N81NTX019784@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Re: Preparations for smart matching Date: Wed, 23 Mar 2005 08:00:48 -0000 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: AcUt9ktkSrx3DthfQDuNT/tk+JlRKwADSa8QAF4cBUAAADKnIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Peter Constable wrote: >We definitely want extensibility in ways that have potential usefulness >for the future. Then surely there is a case for tagging down to the lowest level of variant available/known... even though you may not need it now... should this become a rule? It may help in future document retrieval/archival processes. > If by "Character_Set" you are suggesting that language tags should include >a "charset" component to indicate the character set encoding used for the >data, then I think that would not be a good idea: that's not an attribute >related to the linguistic content; it's an attribute of the digital >representation. The two should really be kept separate. My remark was a little "tongue in cheek" and in relation to my "detail remark" as I am unsure of the use of script codes as they seem so broad... Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Peter Constable Sent: 23 March 2005 07:46 To: ltru@ietf.org Subject: RE: [Ltru] Re: Preparations for smart matching > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Debbie Garside > I hate to throw a spanner in the works here but still on the subject of > detail... Exactly how much detail can be gleaned from a script code... > Should we perhaps be looking in even finer detail and at extensibility > issues e.g. > en-Character_Set-US > At least you would end up with something useful, forward looking and > extendable... :-) We definitely want extensibility in ways that have potential usefulness for the future. If by "Character_Set" you are suggesting that language tags should include a "charset" component to indicate the character set encoding used for the data, then I think that would not be a good idea: that's not an attribute related to the linguistic content; it's an attribute of the digital representation. The two should really be kept separate. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 03:19:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14982; Wed, 23 Mar 2005 03:19:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1Ax-0004wY-1h; Wed, 23 Mar 2005 03:25:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE149-0000pW-Cw; Wed, 23 Mar 2005 03:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE147-0000pP-FB for ltru@megatron.ietf.org; Wed, 23 Mar 2005 03:18:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14866 for ; Wed, 23 Mar 2005 03:18:09 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE19W-0004rY-B7 for ltru@ietf.org; Wed, 23 Mar 2005 03:23:48 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 00:17:59 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 00:17:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Wed, 23 Mar 2005 00:18:12 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUt9ktkSrx3DthfQDuNT/tk+JlRKwADSa8QAF4cBUAAADKnIAAAq/mA From: "Peter Constable" To: X-OriginalArrivalTime: 23 Mar 2005 08:17:59.0681 (UTC) FILETIME=[D345BF10:01C52F80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > If by "Character_Set" you are suggesting that language tags should > include > >a "charset" component to indicate the character set encoding used for the > >data, then I think that would not be a good idea: that's not an attribute > >related to the linguistic content; it's an attribute of the digital > >representation. The two should really be kept separate. >=20 > My remark was a little "tongue in cheek" and in relation to my "detail > remark" as I am unsure of the use of script codes as they seem so broad... Ah! It's true, they are pretty broad, and that can be an issue. For instance, I've been wondering for a while what the best way would be to tag e.g. English content written in a Latin-base phonetic transcription, such as IPA (IPA uses a few Greek characters but otherwise is predominantly Latin), or other Latin-based systems for phonetic transcription. "Latn" could in principle encompass any of these. What would really be ideal would be a handy set of IDs for writing systems, which would not far from IDs for inventories of characters -- for character sets. Unfortunately, we don't have any obvious candidate for such a set of IDs, nor is it obvious that creating a set of such IDs in any comprehensive way would really be practical.=20 Script IDs are practical, and if some flexibility is allowed for in adding categories in the list of scripts, such as Hans and Hant, or Latf and Latg, then that can go a long way toward our needs. It may not be able to cover all cases of interest to users, though. (The recent discussion of Greek on the other list explores the limits to which script IDs can be stretched.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 03:32:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16240; Wed, 23 Mar 2005 03:32:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1Mx-0005QS-29; Wed, 23 Mar 2005 03:37:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1Gs-0002Uf-7X; Wed, 23 Mar 2005 03:31:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1Gp-0002UQ-NS for ltru@megatron.ietf.org; Wed, 23 Mar 2005 03:31:20 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16171 for ; Wed, 23 Mar 2005 03:31:17 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DE1EQ-0003VP-Ba for ltru@lists.ietf.org; Wed, 23 Mar 2005 09:28:50 +0100 Received: from c-134-88-231.hh.dial.de.ignite.net ([62.134.88.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 09:28:50 +0100 Received: from nobody by c-134-88-231.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 09:28:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 23 Mar 2005 09:27:19 +0100 Organization: Lines: 45 Message-ID: <42412867.11E2@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: c-134-88-231.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Peter Constable wrote: ["associated_tag"] > A couple of issues: it would not be a trivial task to > populate that field in a reasonably accurate way for all > languages Yes, where it's not trivial don't try it. > What if the proportion were 95%? 90%? 85%? ... What's the > threshold at which we begin to assume a default? Anything below "99%" (defined as "almost all today") doesn't qualify as an obvious or trivial default. It could be still hard to decide this for cases like sr, but OTOH the job of a tag reviewer should be more than copying various ISO sources into a communal IANA registry. [[ That could be even an IPR or copyright issue - IANAL but paranoid. ]] [en-Ogam-US-boont] > If the request is for "en-boont", then "en-Ogam" in the > repository should not be a match Sure, the request was for en-Ogam-US-boont or en-Ogam-boont, and the server offers only en-Ogam or en-boont. Or it only offers en-Ogam-US or en-US-boont - that's a better example, because it challenges any simple matching strategy. So should it "know" (assume) that en-boont is most probably en-Latn-boont ? If yes it needs a default. But Doug found queries where a default is misleading, and the best way to bypass this problem is to add a script everywhere. Which is not the best solution for 3066-software, but OTOH potential problems of 3066-software with en-boont are irrelevant. If the alternative is "no default, add Latn everywhere", the real problem with 3066 software are cases like en-GB, asking for en-Latn-GB won't match en-GB with legacy software. And vice versa, if I create a new document I'm trapped, either I say en-Latn-GB or en-GB. The former is a problem for legacy software, the latter is vague for new software, could it mean en-Ogam-GB ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 03:49:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17637; Wed, 23 Mar 2005 03:49:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1da-00061u-Qf; Wed, 23 Mar 2005 03:54:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1Xl-0004o1-Or; Wed, 23 Mar 2005 03:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1Xj-0004nw-3V for ltru@megatron.ietf.org; Wed, 23 Mar 2005 03:48:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17622 for ; Wed, 23 Mar 2005 03:48:45 -0500 (EST) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1dA-0005yR-EL for ltru@ietf.org; Wed, 23 Mar 2005 03:54:24 -0500 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN2-342412d5dda; Wed, 23 Mar 2005 03:48:29 -0500 Received: from DEBHOME (ACD7A505.ipt.aol.com [172.215.165.5]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2N8mHjx025341; Wed, 23 Mar 2005 03:48:17 -0500 Message-Id: <200503230848.j2N8mHjx025341@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Re: Preparations for smart matching Date: Wed, 23 Mar 2005 08:47:43 -0000 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: AcUt9ktkSrx3DthfQDuNT/tk+JlRKwADSa8QAF4cBUAAADKnIAAAq/mAAAFNwuA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Peter Constable wrote: >Ah! It's true, they are pretty broad, and that can be an issue. For >instance, I've been wondering for a while what the best way would be to tag >e.g. English content written in a Latin-base phonetic transcription, such >as IPA (IPA uses a few Greek characters but otherwise is predominantly >Latin), or other Latin-based systems for phonetic transcription. "Latn" >could in principle encompass any of these. What would really be ideal would >be a handy set of IDs for writing systems, which would not far from IDs for >inventories of characters -- for character sets. >Unfortunately, we don't have any obvious candidate for such a set of IDs, >nor is it obvious that creating a set of such IDs in any comprehensive way >would really be practical. I agree... but hopefully -6 will give the structure so that character sets, at least, can be attached to language variants... should you so wish... >Script IDs are practical, and if some flexibility is allowed for in adding >categories in the list of scripts, such as Hans and Hant, or Latf and Latg, >then that can go a long way toward our needs. It may not be able to cover >all cases of interest to users, though. (The recent discussion of Greek on >the other list explores the limits to which script IDs can be stretched.) Thank you for clarifying Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Peter Constable Sent: 23 March 2005 08:18 To: ltru@ietf.org Subject: RE: [Ltru] Re: Preparations for smart matching > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > If by "Character_Set" you are suggesting that language tags should > include > >a "charset" component to indicate the character set encoding used for the > >data, then I think that would not be a good idea: that's not an attribute > >related to the linguistic content; it's an attribute of the digital > >representation. The two should really be kept separate. > > My remark was a little "tongue in cheek" and in relation to my "detail > remark" as I am unsure of the use of script codes as they seem so broad... Ah! It's true, they are pretty broad, and that can be an issue. For instance, I've been wondering for a while what the best way would be to tag e.g. English content written in a Latin-base phonetic transcription, such as IPA (IPA uses a few Greek characters but otherwise is predominantly Latin), or other Latin-based systems for phonetic transcription. "Latn" could in principle encompass any of these. What would really be ideal would be a handy set of IDs for writing systems, which would not far from IDs for inventories of characters -- for character sets. Unfortunately, we don't have any obvious candidate for such a set of IDs, nor is it obvious that creating a set of such IDs in any comprehensive way would really be practical. Script IDs are practical, and if some flexibility is allowed for in adding categories in the list of scripts, such as Hans and Hant, or Latf and Latg, then that can go a long way toward our needs. It may not be able to cover all cases of interest to users, though. (The recent discussion of Greek on the other list explores the limits to which script IDs can be stretched.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 04:04:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19182; Wed, 23 Mar 2005 04:04:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1sm-0006nd-51; Wed, 23 Mar 2005 04:10:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1n3-0007JH-W0; Wed, 23 Mar 2005 04:04:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1ms-0007IM-Ft for ltru@megatron.ietf.org; Wed, 23 Mar 2005 04:04:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19098 for ; Wed, 23 Mar 2005 04:04:24 -0500 (EST) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1sJ-0006lt-Pt for ltru@ietf.org; Wed, 23 Mar 2005 04:10:04 -0500 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN4-54241310f1c0; Wed, 23 Mar 2005 04:04:15 -0500 Received: from DEBHOME (ACD7A505.ipt.aol.com [172.215.165.5]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2N947CQ012447; Wed, 23 Mar 2005 04:04:07 -0500 Message-Id: <200503230904.j2N947CQ012447@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Debbie Garside'" , "'Peter Constable'" , Subject: RE: [Ltru] Re: Preparations for smart matching Date: Wed, 23 Mar 2005 09:03:33 -0000 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: AcUt9ktkSrx3DthfQDuNT/tk+JlRKwADSa8QAF4cBUAAADKnIAAAq/mAAAFNwuAAAIg4oA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200503230848.j2N8mHjx025341@smtp-los04.proxy.aol.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.6 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Peter Constable wrote: >Ah! It's true, they are pretty broad, and that can be an issue. For >instance, I've been wondering for a while what the best way would be to tag >e.g. English content written in a Latin-base phonetic transcription, such >as IPA (IPA uses a few Greek characters but otherwise is predominantly >Latin), or other Latin-based systems for phonetic transcription. "Latn" >could in principle encompass any of these. What would really be ideal would >be a handy set of IDs for writing systems, which would not far from IDs for >inventories of characters -- for character sets. >Unfortunately, we don't have any obvious candidate for such a set of IDs, >nor is it obvious that creating a set of such IDs in any comprehensive way >would really be practical. Debbie Garside wrote: >I agree... but hopefully -6 will give the structure so that character >sets,at least, can be attached to language variants... should you so >wish... In fact, on reflection, it can be added as an object in the hierarchy of -6 with a hyperlink to the info... if required... although I am not sure I personally have the time to develop this aspect... but it is conceivable Debbie >Script IDs are practical, and if some flexibility is allowed for in adding >categories in the list of scripts, such as Hans and Hant, or Latf and Latg, >then that can go a long way toward our needs. It may not be able to cover >all cases of interest to users, though. (The recent discussion of Greek on >the other list explores the limits to which script IDs can be stretched.) Thank you for clarifying Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Peter Constable Sent: 23 March 2005 08:18 To: ltru@ietf.org Subject: RE: [Ltru] Re: Preparations for smart matching > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > If by "Character_Set" you are suggesting that language tags should > include > >a "charset" component to indicate the character set encoding used for the > >data, then I think that would not be a good idea: that's not an attribute > >related to the linguistic content; it's an attribute of the digital > >representation. The two should really be kept separate. > > My remark was a little "tongue in cheek" and in relation to my "detail > remark" as I am unsure of the use of script codes as they seem so broad... Ah! It's true, they are pretty broad, and that can be an issue. For instance, I've been wondering for a while what the best way would be to tag e.g. English content written in a Latin-base phonetic transcription, such as IPA (IPA uses a few Greek characters but otherwise is predominantly Latin), or other Latin-based systems for phonetic transcription. "Latn" could in principle encompass any of these. What would really be ideal would be a handy set of IDs for writing systems, which would not far from IDs for inventories of characters -- for character sets. Unfortunately, we don't have any obvious candidate for such a set of IDs, nor is it obvious that creating a set of such IDs in any comprehensive way would really be practical. Script IDs are practical, and if some flexibility is allowed for in adding categories in the list of scripts, such as Hans and Hant, or Latf and Latg, then that can go a long way toward our needs. It may not be able to cover all cases of interest to users, though. (The recent discussion of Greek on the other list explores the limits to which script IDs can be stretched.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 04:20:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20327; Wed, 23 Mar 2005 04:20:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE27o-0007GG-0G; Wed, 23 Mar 2005 04:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE21z-0001c1-8H; Wed, 23 Mar 2005 04:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE21r-0001bC-0z for ltru@megatron.ietf.org; Wed, 23 Mar 2005 04:19:55 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20314 for ; Wed, 23 Mar 2005 04:19:52 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DE1zQ-0000Yw-7c for ltru@lists.ietf.org; Wed, 23 Mar 2005 10:17:24 +0100 Received: from c-134-88-231.hh.dial.de.ignite.net ([62.134.88.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 10:17:24 +0100 Received: from nobody by c-134-88-231.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 10:17:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 23 Mar 2005 10:17:27 +0100 Organization: Lines: 42 Message-ID: <42413427.4053@xyzzy.claranet.de> References: <20050322153252.PHLK4900.mta8.adelphia.net@megatron.ietf.org> <0b6601c52efe$2038ee60$030aa8c0@DEWELL> 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: c-134-88-231.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Are you aware that 'jw' was not documented as an error by > ISO 639 RA/JAC until 2002? No, it wasn't clear whether this was a typo fixed 1988 or a typo fixed 2001, or maybe an old typo fixed long ago but now officially documented. The in, iw, etc. cases are different, they were no typos. Actually it's not very important, do whatever you like, but don't use it to justify FQ or RH later when we come to the region codes. ;-) > Frank, please write a counterproposal. I don't think it's > accomplishing anything to continue saying "Or we could > totally change the way country codes are handled" without a > document that the WG can discuss. I've already done that using the worst case CS as an example how it would work for a 3066bis-my-way introduced about 1989. Addison added the 3066bis-your-way version for the same case. IMHO these examples were clear, in a 3066bis-your-way all obsolete ISO 3166-1 codes are preserved using UN numbers for some new regions, in a 3066-bis-my-way ISO 3166-1 is used as is, if somebody wants a stable tag (guaranteed for centuries) he's forced to use UN numbers instead of ISO 3166-1. >> let's always take the state of the art at the date of >> the creation of the future draft registry I-Ds based on >> the future registry draft I-Ds. > Actually I like that idea. Let's hope that "they" don't deprecate any country code while we are desperately trying to find a compromise. We still want compatibility with anything that was valid under 1766 / 3066. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 04:30:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21286; Wed, 23 Mar 2005 04:30:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2HS-0007ea-Ma; Wed, 23 Mar 2005 04:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Az-0003X0-F5; Wed, 23 Mar 2005 04:29:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Av-0003WX-Qt for ltru@megatron.ietf.org; Wed, 23 Mar 2005 04:29:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21209 for ; Wed, 23 Mar 2005 04:29:15 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DE2GN-0007dA-6W for ltru@ietf.org; Wed, 23 Mar 2005 04:34:55 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 23 Mar 2005 09:23:37 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:23:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Wed, 23 Mar 2005 09:23:36 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A18A@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: RE: [Ltru] Re: Preparations for smart matching Thread-Index: AcUviuKwrswD32VvQdiHRKjcElbPHw== From: "L.Gillam" To: ltru X-OriginalArrivalTime: 23 Mar 2005 09:23:36.0462 (UTC) FILETIME=[FDC6DAE0:01C52F89] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] [snip] > http://isotc.iso.org/livelink/livelink/fetch/2000/2122/687806/ > ISO_TC_037__Terminology_and_other_language_resources_.pdf?node > id=3D1160801&vernum=3D0 >=20 > Thanks for this pointer. This says that 639-3,4,5,6 are all at stage > 20.00, meaning that they are part of the programme of work. This is > clearly inaccurate for 639-3, which is elsewhere stated to be at 40.20 > (DIS out for ballot). Ah, beaten to it by Peter Constable. Since the document is dated = 2004-12-15 and 639 DIS ballot began on 2005-02-04 and terminates on 2005-07-04, I = don't think the accuracy of the document is in question - just that progress = has since been made. [snip] > > General principles and groups of languages may be irrelevant to > > 3066bis, but eventually - in some none-too-distant future one > > suspects - smart matching will also have to take into account the > > specialisation/generalisation relationships as composed by these 2 - > > which is somewhat orthogonal to current 3066 "tag-dropping"=20 > practice. >=20 > I hope not. The trouble with language collections is that if they are > defined extensionally (en+nl+de+yi+...) they may or may not reflect > anything real, and if they are defined intensionally=20 > ("Germanic language") > they are theory-dependent and are unstable, changing as=20 > linguistic theories > change. (Granted, the Germanic family is quite stable, but this isn't > true in general.) Would you include the 639-3 "macrolanguages" that Peter described as being so extensionally defined? The 639-5 language groups? I wonder how you'd create a theory-independent system? >=20 > > At this point I should promote a related research activity > >=20 > > = http://portal.surrey.ac.uk/portal/page?_pageid=3D798,337934&_dad=3Dportal= &_schema=3DPORTAL > > for which the actual website is in development at INRIA. > Hmm. It would be nice to know what this is actually about. :-) Ok, I'll point you at the project website when it's ready - and = user-focussed workshops are planned in the near future also. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 04:37:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22421; Wed, 23 Mar 2005 04:37:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2Oj-00080W-2i; Wed, 23 Mar 2005 04:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2G7-00047m-7j; Wed, 23 Mar 2005 04:34:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Fo-00046r-CV for ltru@megatron.ietf.org; Wed, 23 Mar 2005 04:34:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21968 for ; Wed, 23 Mar 2005 04:34:18 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DE2LF-0007pW-3Q for ltru@ietf.org; Wed, 23 Mar 2005 04:39:58 -0500 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 23 Mar 2005 09:27:32 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:27:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Wed, 23 Mar 2005 09:27:31 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A18C@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUvIgfGpj4u4LTHQPeORBf4we8sVgAaLHAg From: "L.Gillam" To: ltru X-OriginalArrivalTime: 23 Mar 2005 09:27:32.0204 (UTC) FILETIME=[8A4A3AC0:01C52F8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable These people should be given a little test: Q: What is the language of the UK? If they say it's English, they just offended quite a lot of users. > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of JFC (Jefsey) Morfin > > Just beware that this may change with the IDNs. Registrations=20 > are subject=20 > to the TLD Manager terms and conditions. The same ICANN=20 > imposes conditions=20 > on specialized TLDs. There is interest by some ccTLD to=20 > require that the=20 > language of the IDN be used on the sites, by respect to the users. > jfc =20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 04:40:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22566; Wed, 23 Mar 2005 04:40:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2Qv-000868-Et; Wed, 23 Mar 2005 04:45:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Kf-00054K-24; Wed, 23 Mar 2005 04:39:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Jn-0004cz-8N for ltru@megatron.ietf.org; Wed, 23 Mar 2005 04:38:27 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22484 for ; Wed, 23 Mar 2005 04:38:24 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DE2HJ-0002VJ-Sc for ltru@lists.ietf.org; Wed, 23 Mar 2005 10:35:53 +0100 Received: from c-134-88-231.hh.dial.de.ignite.net ([62.134.88.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 10:35:53 +0100 Received: from nobody by c-134-88-231.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 10:35:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 23 Mar 2005 10:37:08 +0100 Organization: Lines: 24 Message-ID: <424138C4.404B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AB823BF@irvmbxw01.quest.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: c-134-88-231.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Addison Phillips wrote: >>> At the moment the draft says: >>> >>> | The "recommended_prefix" field is empty, except where the >>> | type is "variant" > the draft doesn't say what Frank says it says Oops, that was a quote of lines 1131 and 1132 in the file draft-ietf-ltru-registry-00.txt. What you quote is in lines 1192..1197. > We can (and should) remove the restriction to registered > variants in the text. Yes, that could allow other uses for other types. I've no idea what that could be except from "default script" for a language. But maybe there are scripts which are only used for a small set of languages, this set could be enumerated in the "recommended_prefix" column of the script. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 04:43:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22727; Wed, 23 Mar 2005 04:43:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2UV-0008Aw-8A; Wed, 23 Mar 2005 04:49:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Oz-0005tl-7a; Wed, 23 Mar 2005 04:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2OW-0005p3-7r for ltru@megatron.ietf.org; Wed, 23 Mar 2005 04:43:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22702 for ; Wed, 23 Mar 2005 04:43:18 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DE2Tx-0008AL-3K for ltru@ietf.org; Wed, 23 Mar 2005 04:48:58 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 23 Mar 2005 09:35:04 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:35:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Wed, 23 Mar 2005 09:35:03 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A18D@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUuI6PvPHvlFOg+Q1eOFpTgL2gfowBVXTcQAAS9RgA= From: "L.Gillam" To: ltru X-OriginalArrivalTime: 23 Mar 2005 09:35:04.0384 (UTC) FILETIME=[97CF6C00:01C52F8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > > ISO 639-4 (general principles) and ISO 639-5 (codes for groups of > > languages) are in progress, but are irrelevant to RFC 3066bis. >=20 > I can't say for certain that ISO 639-4 would not have any=20 > relevance (it > may prove to have some relevance, or it may not); I'd agree though wrt > ISO 639-5, as I don't think we should allow additional=20 > collective IDs in > subtags (if anything, I'd restrict what we already allow). I guess the response to this one is along the lines of=20 - They are irrelevant to 3066bis. They may be relevant to 3066ter. Or some future iteration. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 05:25:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27039; Wed, 23 Mar 2005 05:25:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE39F-0001Ha-Us; Wed, 23 Mar 2005 05:31:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE30Y-0003Fk-LR; Wed, 23 Mar 2005 05:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE30W-0003Fe-Qj for ltru@megatron.ietf.org; Wed, 23 Mar 2005 05:22:37 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26761 for ; Wed, 23 Mar 2005 05:22:34 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DE2xu-00074j-Im for ltru@lists.ietf.org; Wed, 23 Mar 2005 11:19:54 +0100 Received: from c-134-88-231.hh.dial.de.ignite.net ([62.134.88.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 11:19:54 +0100 Received: from nobody by c-134-88-231.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Mar 2005 11:19:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 23 Mar 2005 11:20:23 +0100 Organization: Lines: 57 Message-ID: <424142E7.58E6@xyzzy.claranet.de> References: <20050321153725.LWSH2135.mta2.adelphia.net@megatron.ietf.org> <001801c52e33$538bae40$030aa8c0@DEWELL> 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: c-134-88-231.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Doug Ewell wrote: > The vast majority of tags created under RFC 3066bis will NOT > contain script subtags. They are there for when someone > deems them necessary. And how am I supposed to decide this without a default for my pages ? I have some "en" pages and one "en-GB-OED", but I've no en-Ogam. Apparently you're saying that there are defaults, but you do not want to document them. If somebody tries to implement it he probably hardwires some cases like en-Latn, but ignores other cases like fy-Latn, because he has no idea what fy is. > I think asking for "all scripts except Braille" is probably > out of scope for this project. Yes, but "only Braille" and "only Latin" are relevant. The former works, the latter doesn't (for languages where "Latn" is the undocumented default). > If the user requests "en-Brai-LR", she is making a very > particular request that could not have been fulfilled under > RFC 3066 in any circumstance RfC 3066 has en-LR, and that includes any future en-Brai-LR. > it seems odd to consider it an incompatibility You could also consider it as a case of tough luck if the user doesn't find existing en-Brai-LR content looking for en-Brai-LR only because it was tagged as en-LR under 1766 / 3066. In that case I'd say that any "old" en-LR is probably "Latn", so not finding it as en-Brai-LR is a feature and no bug. But it's less funny if en-Latn-LR doesn't find en-LR. > Content tagged as "en-US" cannot be assumed to be in any > particular script, although Latin would be a good guess. And who tells me what a good guess is for languages I've never before heard of ? The publisher of the documents should know what a good guess is, but he's not the implementor of the used software. There are numerous languages in your list where I'm lost, I couldn't implement a "guess" for these languages. What I could do, if you offer good guesses (= defaults), is to implement a ??-Zyyy plan B. > Nobody proposes that old data be "updated." I'd consider it, after all I really offer no Brai or Ogam, so users looking for these scripts shouldn't be forced to check my pages. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 06:21:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01715; Wed, 23 Mar 2005 06:21:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE40s-0002wq-Gp; Wed, 23 Mar 2005 06:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE3vM-00032n-A8; Wed, 23 Mar 2005 06:21:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE3vG-000313-DU for ltru@megatron.ietf.org; Wed, 23 Mar 2005 06:21:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01690 for ; Wed, 23 Mar 2005 06:21:11 -0500 (EST) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE40j-0002wb-1m for ltru@ietf.org; Wed, 23 Mar 2005 06:26:53 -0500 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id BDB8B25D30C; Wed, 23 Mar 2005 11:21:06 +0000 (GMT) From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Re: Preparations for smart matching Date: Wed, 23 Mar 2005 11:22:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcUtqyMw8oHQmp0xR76qP0IJruNwwQBwU9SwAAtRPEA= In-Reply-To: Message-Id: <20050323112106.BDB8B25D30C@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Peter Constable wrote: >But keep in mind that if there is any possibility of the encoding of an item being converted at any point between sender >and receiver, then the knowledge inherent in the original charset ID could be lost. If someone sends a message to an >online group using Big5 and the message gets converted to Unicode when sent to some or all group members, then those >recipients don't benefit from whatever knowledge would be conveyed by the fact that the data had originally been encded >in Big5. A look at Shannon/Weaver and/or Scramms Mass communications models would be helpful... I believe you are refering to "semantic dissonance" and "noise" Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Peter Constable Sent: 23 March 2005 06:00 To: ltru@ietf.org Subject: RE: [Ltru] Re: Preparations for smart matching > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > For Unicode mentioning the script makes sense, but for 8bit- charsets > it should be implicit, excl. transliterations for the moment. But keep in mind that if there is any possibility of the encoding of an item being converted at any point between sender and receiver, then the knowledge inherent in the original charset ID could be lost. If someone sends a message to an online group using Big5 and the message gets converted to Unicode when sent to some or all group members, then those recipients don't benefit from whatever knowledge would be conveyed by the fact that the data had originally been encded in Big5. > That's why I want default scripts and a SHOULD NOT for cases like > en-Latn-*. The recommendation to tag wisely is a waste of time for > software, it can't think. I think these are valid ideas. (But then I would, having written about the significance of default script in a paper a few years back.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 08:20:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12410; Wed, 23 Mar 2005 08:20:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE5rw-0005u2-Vp; Wed, 23 Mar 2005 08:25:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE5ln-0003Nf-3h; Wed, 23 Mar 2005 08:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE5lk-0003NS-Re for ltru@megatron.ietf.org; Wed, 23 Mar 2005 08:19:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12355 for ; Wed, 23 Mar 2005 08:19:31 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE5rD-0005t0-2N for ltru@ietf.org; Wed, 23 Mar 2005 08:25:12 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2NDJGKK012405; Wed, 23 Mar 2005 08:19:17 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 23 Mar 2005 08:19:15 -0500 Date: Wed, 23 Mar 2005 08:19:15 -0500 From: John Cowan To: Peter Constable Subject: Re: [Ltru] Re: Preparations for smart matching Message-ID: <20050323131914.GB3429@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Peter Constable scripsit: > Ah! It's true, they are pretty broad, and that can be an issue. For > instance, I've been wondering for a while what the best way would be to > tag e.g. English content written in a Latin-base phonetic transcription, > such as IPA (IPA uses a few Greek characters but otherwise is > predominantly Latin), or other Latin-based systems for phonetic > transcription. "Latn" could in principle encompass any of these. I've pressed for "Ipaa" (or perhaps "Latp") in the past, to which "Fupa" (or "Latu"?) should probably be added. -- Said Agatha Christie / To E. Philips Oppenheim John Cowan "Who is this Hemingway? / Who is this Proust? jcowan@reutershealth.com Who is this Vladimir / Whatchamacallum, http://www.reutershealth.com This neopostrealist / Rabble?" she groused. http://www.ccil.org/cowan --author unknown to me; any suggestions? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 09:14:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17261; Wed, 23 Mar 2005 09:14:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6ip-0007D4-Nv; Wed, 23 Mar 2005 09:20:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6cm-00033F-4v; Wed, 23 Mar 2005 09:14:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6cl-000337-6A for ltru@megatron.ietf.org; Wed, 23 Mar 2005 09:14:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17212 for ; Wed, 23 Mar 2005 09:14:17 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6iF-0007CD-Eo for ltru@ietf.org; Wed, 23 Mar 2005 09:19:59 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2NEE9Wl012799; Wed, 23 Mar 2005 09:14:09 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 23 Mar 2005 09:14:07 -0500 Date: Wed, 23 Mar 2005 09:14:07 -0500 From: John Cowan To: "L.Gillam" Subject: Re: [Ltru] Re: Preparations for smart matching Message-ID: <20050323141407.GC3429@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A188@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A188@EVS-EC1-NODE1.surrey.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb L.Gillam scripsit: > Would you include the 639-3 "macrolanguages" that Peter described as > being so extensionally defined? They are extensionally defined, and what they reflect is that (as Peter doesn't quite say) ISO 639-2 is a folk taxonomy, and as such doesn't match up very well with 639-3's rather more scientific coverage of the same ground. In principle, there's an ISO 639-2 code for every text, but only on the principle of "split local things, lump remote things" that folk taxonomies generally employ. > The 639-5 language groups? I haven't seen even an editor's draft of -5 [*], so I can't comment specifically. But I will note that in Linnaean taxonomy, heroic attempts are made to preserve stability for both entities (where the facts permit it) and labels (to the point where ordinary meaning is flatly disregarded) at the species level, but no such attempts are made at higher taxonomic levels, which change all the time and are the subject of many disagreements. ([*] The notion of ISO that people are going to *pay* for drafts, and in the two figures of CHF at that, is simply laughable.) > I wonder how you'd create a theory-independent system? I wouldn't even try. I'd accept the collective-language codes of -2 as a regrettable consequence of the way it was designed, or rather not designed, and leave it at that. -- John Cowan http://www.ccil.org/~cowan jcowan@reutershealth.com Please leave your values Check your assumptions. In fact, at the front desk. check your assumptions at the door. --sign in Paris hotel --Cordelia Vorkosigan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 10:07:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23006; Wed, 23 Mar 2005 10:07:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7Y6-0000Im-CD; Wed, 23 Mar 2005 10:13:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7Rl-0003WR-QL; Wed, 23 Mar 2005 10:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7Rk-0003WM-0Y for ltru@megatron.ietf.org; Wed, 23 Mar 2005 10:07:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22865 for ; Wed, 23 Mar 2005 10:06:58 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DE7XE-0000Gt-If for ltru@ietf.org; Wed, 23 Mar 2005 10:12:40 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 23 Mar 2005 15:02:58 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 15:02:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Wed, 23 Mar 2005 15:02:57 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A1A9@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUvtBc85/jE9lTlSCOjvu7KDFBr3gAAci1g From: "L.Gillam" To: ltru X-OriginalArrivalTime: 23 Mar 2005 15:02:57.0825 (UTC) FILETIME=[66184910:01C52FB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > > > Would you include the 639-3 "macrolanguages" that Peter described as > > being so extensionally defined? >=20 > They are extensionally defined, and what they reflect is that=20 > (as Peter > doesn't quite say) ISO 639-2 is a folk taxonomy, and as such doesn't > match up very well with 639-3's rather more scientific coverage of the > same ground. In principle, there's an ISO 639-2 code for every text, > but only on the principle of "split local things, lump remote things" > that folk taxonomies generally employ. The original point here was that "smart matching" would have to do a bit more than "tag-dropping", fallback or, perhaps fall-forward as seems to be being suggested. Association between 639-2 and 639-3 is just that little bit more because of this. Where -5 fishes the same alpha3 pool, anybody deciding to incorporate this also would have further such work to do because of associations. Deciding whether group membership or generalisation/specialisation governs the relationship will produce interesting algorithms I suspect. > > The 639-5 language groups? >=20 > I haven't seen even an editor's draft of -5 [*], so I can't comment > specifically. But I will note that in Linnaean taxonomy, heroic > attempts are made to preserve stability for both entities (where the > facts permit it) and labels (to the point where ordinary meaning is > flatly disregarded) at the species level, but no such=20 > attempts are made > at higher taxonomic levels, which change all the time and are=20 > the subject > of many disagreements. But perhaps this is where a "framework of distinctions" (e.g.=20 http://www.jfsowa.com/ontology/), or "facet analysis" (e.g. http://www.kmconnection.com/DOC100100.htm) may provide a bridge -=20 the hierarchy is to some extent fixed - dependencies between some facets but not necessarily others - but to others derived. "script" is one facet, "country" another. It's already being done anyway in the tag requests themselves, it's just that the tag currently resembles the request.=20 > ([*] The notion of ISO that people are going to *pay* for drafts, and > in the two figures of CHF at that, is simply laughable.) I'm happy to make the draft available for expert comment - the ISO = process definitely allows for this. I don't believe you can actually *buy* the drafts anywhere - I may be wrong, and perhaps ISO is missing a business opportunity here! > > I wonder how you'd create a theory-independent system? >=20 > I wouldn't even try. I'd accept the collective-language codes of -2 > as a regrettable consequence of the way it was designed, or rather not > designed, and leave it at that. Accept but reduce dependency on, or keep using because of "legacy code"? I discovered yesterday, to my sheer horror, that an Oracle V10 client = could not speak to an Oracle V8.1.5 server. But, an Oracle V8.1.5 server will = apparently not work on a RedHat FC3 or RHEL 3 platform, and the platform it is = currrently on cannot be hack-proofed for web accesses. Do Microsoft still support Windows 95/98? There are ways to work around the problem, but as time = goes by the work arounds become an artform - and I'm not a great fan of art. = :-( _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 10:39:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26810; Wed, 23 Mar 2005 10:39:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE82t-00016k-CN; Wed, 23 Mar 2005 10:45:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7vh-0008F2-Lr; Wed, 23 Mar 2005 10:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7vg-0008Ex-5r for ltru@megatron.ietf.org; Wed, 23 Mar 2005 10:37:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26401 for ; Wed, 23 Mar 2005 10:37:54 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE819-00011A-VZ for ltru@ietf.org; Wed, 23 Mar 2005 10:43:37 -0500 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 23 Mar 2005 15:37:40 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IDT0067TA2O1A@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 23 Mar 2005 15:37:36 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Wed, 23 Mar 2005 15:37:29 +0000 Date: Wed, 23 Mar 2005 15:37:14 +0000 From: Misha Wolf Subject: RE: [Ltru] Reading legacy data To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Reading legacy data Thread-Index: AcUvtBc85/jE9lTlSCOjvu7KDFBr3gAAci1gAAH2fyA= content-class: urn:content-classes:message X-OriginalArrivalTime: 23 Mar 2005 15:37:29.0730 (UTC) FILETIME=[390BE620:01C52FBE] X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable L.Gillam [L.Gillam@surrey.ac.uk] wrote: Accept but reduce dependency on, or keep using because of "legacy code"? I discovered yesterday, to my sheer horror, that an Oracle V10 client could not speak to an Oracle V8.1.5 server. But, an Oracle V8.1.5 server will apparently not work on a RedHat FC3 or RHEL 3 platform, and the platform it is currrently on cannot be hack-proofed for web accesses. Do Microsoft still support Windows 95/98? There are ways to work around the problem, but as time goes by the work arounds become an artform - and I'm not a great fan of art. :-( Hence all important documents should be carved into cave walls. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 12:23:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09443; Wed, 23 Mar 2005 12:23:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9fP-0004Oh-0o; Wed, 23 Mar 2005 12:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9Z9-0000yY-Rc; Wed, 23 Mar 2005 12:22:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9Z7-0000y8-Vo for ltru@megatron.ietf.org; Wed, 23 Mar 2005 12:22:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09405 for ; Wed, 23 Mar 2005 12:22:43 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9ec-0004NW-Lc for ltru@ietf.org; Wed, 23 Mar 2005 12:28:27 -0500 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DE9Z2-0005qJ-9P; Wed, 23 Mar 2005 09:22:42 -0800 Message-Id: <6.1.2.0.2.20050323143349.03ca8b50@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 23 Mar 2005 18:22:21 +0100 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Preparations for smart matching In-Reply-To: References: Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da At 09:18 23/03/2005, Peter Constable wrote: >Script IDs are practical, and if some flexibility is allowed for in >adding categories in the list of scripts, such as Hans and Hant, or Latf >and Latg, then that can go a long way toward our needs. It may not be >able to cover all cases of interest to users, though. (The recent >discussion of Greek on the other list explores the limits to which >script IDs can be stretched.) Seems odd to read this. What is the target of this WG? to conform to norms and to outdated practices, or to conform standards to users needs and to help transitionning the past? Yesterday we had an interesting lunch discussion with among others a dictionary and a localization normalizers of different European cultures. We went into this proposition "15 years later you cannot republish a dictionary" vs. "a computer runs the 15 years old dictionary if its program release if 15 years old". I proposed there are three classes of languages users to consider: class 1. the lingua franca related mother's tongue people class 2. the computers class 3. the others. and that their needs are orthogonal. This immediately seemed obvious to all of us and we discussed the similar situation of various Lingua Francae in Geography as well as History and even in business and human relations. Class 1 is the majority of the members in here. Class 2 is only partly represented. Class 3 (while a substantial part of the mankind) is not very interested in IETF. There are various reasons explored in an RFC and in one or two complementary draft. But the real problem is the scalability of the technology. By essence the lingua franca's culture has vision, interests, priorities others do not understand (I speak with the experience of the former lingua francae - French and Latin). But it permits a simple, robust, ASCII Internet. One of the priority of class 1 is to use their language to stabilize an environment where only one language can be used. Their richness is this cultural community and stabilization (with formal registered language tags for example), calling internationalization the external description of all what differs from their language. While others have diversity as their richness, with the added value of an occasional (degraded) use of the lingua franca, which help their quasi opposed way to conceive "internationalization" (what they have in common). It would interesting to read the Bible back, about Babel. Forcing a single way to describe languages, in a way is to have a single language. Babel was not to create the mankind a problem: it was to free it. As long as class 1, 2 and 3 needs are not equally considered and efficiently addressed, it is likely there will be no consensus to enter data into the core reference of the class 2 - what is the target of the discussed RFC proposal. The target is not to make it work in ASCII RFC 3066 ter ABNFed langtags. The target is to make any system, in any format, in any language and culture and circumstance able to understand what is the language (version) of any given content. RFC 3066 only proposed a solution. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 12:24:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09479; Wed, 23 Mar 2005 12:24:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9fw-0004PI-6r; Wed, 23 Mar 2005 12:29:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9ZH-0000zk-86; Wed, 23 Mar 2005 12:22:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9ZG-0000zc-Bv for ltru@megatron.ietf.org; Wed, 23 Mar 2005 12:22:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09411 for ; Wed, 23 Mar 2005 12:22:51 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9em-0004Ni-17 for ltru@ietf.org; Wed, 23 Mar 2005 12:28:36 -0500 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DE9ZA-0005qJ-Gu; Wed, 23 Mar 2005 09:22:51 -0800 Message-Id: <6.1.2.0.2.20050323130745.049410a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 23 Mar 2005 17:33:46 +0100 To: "Mark Davis" , "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Getting back on track In-Reply-To: <047f01c52f47$e0f519f0$727d3009@sanjose.ibm.com> References: <634978A7DF025A40BFEF33EB191E13BC0AB82644@irvmbxw01.quest.com> <047f01c52f47$e0f519f0$727d3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09411 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: quoted-printable On 02:30 23/03/2005, Mark Davis said: >I agree entirely with what Addison said, and want to emphasize that none= of >this has any dependence on CLDR whatsoever. I respond to both authors one shot. I understand nothing of your responses. 1. I only note that Mark's proposed agenda will permit us to match the=20 Charter agenda. 2. I note that after having asked a long work, Addison's responses are in= =20 the records. 3. I remind that the Charter specifies that: "The RFC 3066 standard for=20 language tags has been widely adopted in various protocols and text=20 formats, including HTML, XML, and CLDR, as the best means of identifying=20 languages and language preferences.". So, I will only quote your response= s=20 on CLDR and Unicode copyrigths in a waiver about the support of CLDR. Up = to=20 the IESG to decide if they maintain their Charter consideration on CLDR. >Addison and I have been working on the current draft for quite a while, = and >have benefited from feedback from a wide variety of people. If you want = to >write your own document, you are of course free to, but I have the feeli= ng >that the direction that you are headed is far outside of the scope of th= e >current working group's charter. What we all want is a consensus, not a conflict. The conflict comes from=20 you desire of exclusiveness when we all want inclusion. Everyone will be=20 more that happy to include your propositions to address your needs in a=20 general resolution. There will be no consensus otherwise. >He and I will be focusing on comments on the current draft. We all expect that. But it happens that you both are the authoritative experts in closed=20 consortia applications the WG Charter makes us to consider (HTML and XML=20 for Addison as W3C, and CLDR for Mark as Unicode). It also happens that t= he=20 matter discussed for a standardization in this WG is also subject to a=20 current normalization work, and active international thinking, in various= =20 international technical, academical, societal, economical, political and=20 governmental fora we must first evangelize the participants about your wo= rk=20 (hence the footing of my WG-ltru mails, and the delay in preparing a=20 framework). This obviously delays us. jfc >=E2=80=8EMark > >----- Original Message ----- >From: "Addison Phillips" >To: "JFC (Jefsey) Morfin" ; "Mark Davis" > >Cc: >Sent: Tuesday, March 22, 2005 15:37 >Subject: RE: [Ltru] Getting back on track > > >JFC, > >You have not presented a list of comments about the current draft. Neith= er >have you proposed an alternate design. Why should the WG wait for many w= eeks >while you write an individual submission Internet-Draft if you can't be >bothered to debate the existing design or propose a new design? > >You'll note that before Mark and I wrote the very first draft of what is >today the registry document we discussed the design in public. In my >opinion, you should do the same thing. If there is a consensus favoring = your >design, then it can be incorporated into the working group's draft as >appropriate. > >With regard to your question about my schedule: how about 'never'? I don= 't >have time to help you write your document. I'm busy editing the official >draft and engaging in necessary debate on this list. If you want to writ= e a >document, you're on your own. Both Mark and I have numerous publicly >available documents describing our view of the requirements and our >intentions. No doubt if we have objections to your proposal we will >enumerate them in the proper way and at the proper time. > >With regard to CLDR, which is really Mark's area rather than mine, I wil= l >note that the current registry draft has *no* dependency on CLDR, nor sh= ould >it. Copyright issues in your individual submission are your problem, >although I can't imagine any that would arise from referencing an extern= al >standard. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] On > > Behalf Of JFC (Jefsey) Morfin > > Sent: mardi 22 mars 2005 14:16 > > To: Mark Davis > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Getting back on track > > > > On 22:38 22/03/2005, Mark Davis said: > > >The discussion has meandered around a bit: I'd like to see us get ba= ck on > > >track. Here is how I suggest we proceed. > > > > >Within the next week, anyone who has any issues with the text of the > > current > > >draft does the following: > > > > > >a. Composes a separate message on each issue, with a meaningful titl= e. > > >b. Suggests exact replacement text, with clear instructions on where= to > > make > > >the change. > > >c. Describes the pros and cons of making the change. > > > > > >We review by email each request. If there is consensus for if, then = we > > >record that. If not, we leave it alone. Once we have processed all t= he > > >issues, we issue a new draft that incorporates all the changes. We > > circulate > > >that, and if there are no problems with the incorporation of all the > > >changes, then we advance the document. > > > > As indicated we will not be in a position to issue a draft before at = least > > two weeks. It will certainly substantially differ from the current dr= aft. > > And will probably be amended during its further international review.= But > > the support of your propositions should be as much possible included = in >it. > > So this schedule seems OK if the Chairs agree. We should have your > > elements > > in time. > > > > I have however two missing information: > > - when do you/Addison intend to comment the inputs he required from m= e, so > > I can organize our schedule? > > - we have discussed nothing on the CLDR aspect. You are the best suit= ed to > > tell us what are the requirements of the CLDR project in the RFC 3066 > > context and how we can best address them? I am also obviously concern= ed > > about the copyright issue as the RFC should indicate that the CLDR is > > public domain. Or we would have to investigate a public domain >alternative. > > > > Thank you for your cooperation. > > jfc > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Standardizing Tags for the Identification of Languages should not be = a way > > to standardize languages and to unify the world under a dominant cult= ure. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > For your convenience: > > RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3D3066 > > Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry- > > 00.txt > > Charter: http://ietf.org/html.charters/ltru-charter.html > > gmane: http://dir.gmane.org/gmane.ietf.ltru > > If you were Bcced for information and not familliar with the IETF pro= cess: > > http://www.ietf.org/rfc/rfc2026.txt > > http://www.ietf.org/rfc/rfc2418.txt > > http://www.ietf.org/rfc/rfc3934.txt > > http://www.ietf.org/rfc/rfc3669.txt > > http://www.ietf.org/rfc/rfc3160.txt > > http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Jon Postel (RFC 1591): "The IANA is not in the business of deciding > > what is and what is not a country. The selection of the ISO 3166 list > > as a basis for country code top-level domain names was made with > > the knowledge that ISO has a procedure for determining which > > entities should be and should not be on that list." > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing t= he > > same thing, choose one. If a previous design, in the Internet context > > or elsewhere, has successfully solved the same problem, choose the > > same solution unless there is a good technical reason not to. > > Duplication of the same protocol functionality should be avoided as f= ar as > > possible, without of course using this argument to reject improvement= s." > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > It seems that what works for countries and ISO 3166 since 1978, shoul= d > > apply to languages and to ISO 693. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 12:57:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12822; Wed, 23 Mar 2005 12:57:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEABq-0005L4-6t; Wed, 23 Mar 2005 13:02:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEA5g-0006qJ-S2; Wed, 23 Mar 2005 12:56:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEA5f-0006nq-Ci for ltru@megatron.ietf.org; Wed, 23 Mar 2005 12:56:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12772 for ; Wed, 23 Mar 2005 12:56:20 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEABB-0005JL-1A for ltru@ietf.org; Wed, 23 Mar 2005 13:02:05 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:56:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Preparations for smart matching Date: Wed, 23 Mar 2005 09:56:07 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82A50@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUvjEqRbbScCMafR++xnoCak4N6bgARLiRg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 23 Mar 2005 17:56:07.0792 (UTC) FILETIME=[96FF6F00:01C52FD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable > Oops, that was a quote of lines 1131 and 1132 in the file > draft-ietf-ltru-registry-00.txt. What you quote is in lines > 1192..1197. Yes, you're right. I missed that sentence when I searched for it = somehow. And (I think) you're correct that your original quote should be = modified to match the later content I quoted in meaning. >=20 > Yes, that could allow other uses for other types. I've no > idea what that could be except from "default script" for a > language. But maybe there are scripts which are only used > for a small set of languages, this set could be enumerated > in the "recommended_prefix" column of the script. The difference is that any subtag could then have a prefix. Scripts = would be one possibility. Regions are another (if we were to encode 200, = for example, it might bear a couple of prefixes). Note that recommended prefix is a different thing than canonical mapping = or implied suffix, either of which is what I take default script to be.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mercredi 23 mars 2005 01:37 > To: ltru@ietf.org > Subject: [Ltru] Re: Preparations for smart matching >=20 > Addison Phillips wrote: >=20 > >>> At the moment the draft says: > >>> > >>> | The "recommended_prefix" field is empty, except where the > >>> | type is "variant" >=20 > > the draft doesn't say what Frank says it says >=20 > Oops, that was a quote of lines 1131 and 1132 in the file > draft-ietf-ltru-registry-00.txt. What you quote is in lines > 1192..1197. >=20 > > We can (and should) remove the restriction to registered > > variants in the text. >=20 > Yes, that could allow other uses for other types. I've no > idea what that could be except from "default script" for a > language. But maybe there are scripts which are only used > for a small set of languages, this set could be enumerated > in the "recommended_prefix" column of the script. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 12:59:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13010; Wed, 23 Mar 2005 12:59:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEADt-0005OC-BD; Wed, 23 Mar 2005 13:04:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEA7c-0007L2-Dt; Wed, 23 Mar 2005 12:58:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEA7a-0007Ia-W4 for ltru@megatron.ietf.org; Wed, 23 Mar 2005 12:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12972 for ; Wed, 23 Mar 2005 12:58:20 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAD7-0005NK-5G for ltru@ietf.org; Wed, 23 Mar 2005 13:04:05 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:58:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Preparations for smart matching Date: Wed, 23 Mar 2005 09:58:13 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82A56@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUt35bc3fCpyWOYTSG1CC5AlpfblgBlHgEQABOGBbA= From: "Addison Phillips" To: "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 23 Mar 2005 17:58:13.0682 (UTC) FILETIME=[E208B920:01C52FD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable > If a user requests specifically "en-Ogam", that request should never = be > reduced to "en" -- and I don't think Frank was suggesting that. The = real > issue is whether a request for "en" should return content tagged > "en-Ogam". Existing left-prefix implementations would match, though a > "smarter" matching algorithm might of course work differently. This problem exists (albeit in a very small way) with en-boont, eh? = Left-prefix matching relies on the premise (stated to often be false in = RFC 3066 itself!) that content which shares a prefix is mutually = understandable. >=20 > It is an issue to be considered. So is the reality that there's a ton = of > data tagged "en" where that's assumed to mean "en-Latn". Not really. The problems are: 1. Users who request en-something (en-US for example) won't get content = tagged "en-Latn-something" using left-prefix matching. 2. Users requesting en-Latn won't get content tagged merely "en" using = left-prefix matching. (which is what you're saying above)=20 The ton of data tagged "en" is *probably* in Latin script, but the = author's intentions in that regard are unknown. This has bearing on = those languages where script is a possible confusion. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: mardi 22 mars 2005 23:05 > To: LTRU Working Group > Subject: RE: [Ltru] Re: Preparations for smart matching >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Doug Ewell >=20 >=20 > > If I request "de" content, say over the Web, I definitely want to > > receive content in both "de-1901" and "de-1996", not just one or the > > other. However, if I request "zh" I may not be able to do anything > with > > "zh-hakka". >=20 > Of course, if you request "de" content, you might also get back = content > that's German but written in various ways not useful to the user, such > as phonetic transcription, some kind of shorthand, or in Devanagari > script, say. That's not different from the "zh-hakka" example. >=20 >=20 > > If you declare 'Latn' to be the default script for 'en', and use = that > > information to collapse the tag "en-Latn" to "en", then you remove = the > > user's ability to get "en-Ogam" content unless she specifically > requests > > it. This essentially says, "Since you requested English, I'll = assume > > you can only read it in Latin script, and I won't send you English > > content in any other script." >=20 > If a user requests specifically "en-Ogam", that request should never = be > reduced to "en" -- and I don't think Frank was suggesting that. The = real > issue is whether a request for "en" should return content tagged > "en-Ogam". Existing left-prefix implementations would match, though a > "smarter" matching algorithm might of course work differently. >=20 > It is an issue to be considered. So is the reality that there's a ton = of > data tagged "en" where that's assumed to mean "en-Latn". >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 13:08:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14544; Wed, 23 Mar 2005 13:08:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEANP-0005h8-Ob; Wed, 23 Mar 2005 13:14:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAGy-0000D7-CC; Wed, 23 Mar 2005 13:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAGw-0000D2-PF for ltru@megatron.ietf.org; Wed, 23 Mar 2005 13:08:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14261 for ; Wed, 23 Mar 2005 13:07:59 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAMS-0005ea-Pi for ltru@ietf.org; Wed, 23 Mar 2005 13:13:45 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 10:07:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Preparations for smart matching Date: Wed, 23 Mar 2005 10:07:52 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82A66@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Preparations for smart matching Thread-Index: AcUvce9asDhZhpq/T8ejP5Hym/cPuQATlhEg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 23 Mar 2005 18:07:53.0147 (UTC) FILETIME=[3B6C10B0:01C52FD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1629761400==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 --===============1629761400== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiA+IFNpbWlsYXJseSwgQW1lcmljYW4gRW5nbGlzaCBtYXkgYmUgdXNlZCBpbiBkYXRhIGFzc29j aWF0ZWQgd2l0aCBlbiBmb3INCj4gPiBsb29rdXAgcHVycG9zZXMuIEFueSBkaXN0aW5jdGlvbnMg YWNjb3JkaW5nIHRvIGNvdW50cnkgd291bGQgYmUgc3RvcmVkDQo+ID4gc2VwYXJhdGVseSBpbiBh biAnZW4tQVUnLCAnZW4tQ0EnLCAnZW4tSUUnLCBldGMuLCBhbmQgaWYgYXZhaWxhYmxlLA0KPiA+ IHdvdWxkIGJlIGZvdW5kIGluIGEgbG9va3VwLiBCdXQgaWYgc29tZW9uZSBjYW1lIGluIHdpdGgg J2VuLUpQJywgYW5kDQo+ID4gdGhlcmUgd2FzIG5vIHNlcGFyYXRlIGRhdGEgc291cmNlIGZvciB0 aGF0LCBpdCB3b3VsZCBmYWxsIGJhY2sgdG8gdGhlDQo+ID4gZGF0YSBhc3NvY2lhdGVkIHdpdGgg J2VuJywgd2hpY2ggd291bGQgYmUgQW1lcmljYW4gRW5nbGlzaC4NCj4gDQo+IE5vdCBpZiB0aGUg Y29udGVudCBwcm92aWRlciBpcyBpbiBBdXN0cmFsaWEgb3IgQ2FuYWRhIG9yIElyZWxhbmQuICBU aGVpcg0KPiBkYXRhIHdpbGwgYmUgaW4gdGhlaXIgb3duIGZsYXZvciBvZiBFbmdsaXNoLCB3aGlj aCBpcyB3aGF0IHRoZXkgd291bGQNCj4gbG9naWNhbGx5IGNhbGwgImVuIi4NCg0KV2l0aCB0aGUg cHJvdmlzbyB0aGF0IHRoZSBjb3VudHJ5IG9mIHRleHR1YWwgb3JpZ2luIGFuZCB0aGUgbGFuZ3Vh Z2UgdGFnIGRvIG5vdCBhbHdheXMgbWF0Y2guIFJlZ2lvbnMgYXJlIGhlbHBmdWwgaW4gaWRlbnRp ZnlpbmcgbGFuZ3VhZ2Ugb25seSBpbnNvZmFyIGFzIHRoZXkgZGVzY3JpYmUgYSBwYXJ0aWN1bGFy IGxhbmd1YWdlIHZhcmlhdGlvbi4gU29tZSB2YXJpYXRpb25zIGp1c3QgZG9uJ3Qgb2NjdXIsIGV2 ZW4gaWYgdGhlIGxhbmd1YWdlIGlzIHNwb2tlbiB0aGVyZS4NCg0KRm9yIGV4YW1wbGUsIHRoZXJl IGFyZSBwbGVudHkgb2YgSmFwYW5lc2Ugd2hvIHNwZWFrIEVuZ2xpc2gsIGJ1dCAiZW4tSlAiIGlz bid0IHRoZSBsYW5ndWFnZSB0aGF0IHRoZXkgYXJlIHNwZWFraW5nOiBpdCBpcyBwcm9iYWJseSAi ZW4iIG9yIG9uZSBvZiB0aGUgImVuIiB2YXJpYXRpb25zIHN1Y2ggYXMgImVuLVVTIiBvciAiZW4t R0IiLg0KDQo+IEkgcmVhbGx5IGRvbid0IGxpa2UgdGhlIGlkZWEgb2YgdGhpcy4gIFBlb3BsZSB3 aWxsIHNlZSBpdCBhcyBhDQo+IHJlY29tbWVuZGF0aW9uIG9yIGEgRGlrdGF0IHRoYXQgZW4gIm1l YW5zIiBlbi1MYXRuLCBvciAod29yc2UpIHRoYXQgc3INCj4gIm1lYW5zIiBzci1DeXJsLg0KPiAN Cj4gV2UndmUgbmV2ZXIgZ290dGVuIGludm9sdmVkIHdpdGggc2Vjb25kLWd1ZXNzaW5nIHdoYXQg cGVvcGxlIG1lYW4gd2hlbg0KPiB0aGV5IHdyaXRlIGEgY2VydGFpbiBsYW5ndWFnZSB0YWcsIG9y IGNob29zaW5nIG9uZSBzY3JpcHQgb3IgcmVnaW9uIGFzDQo+ICJwcmVmZXJyZWQiIG92ZXIgYW5v dGhlci4gIEkgc2VlIG5vIHJlYXNvbiB0byBzdGFydCBkb2luZyBzbyBub3cuDQoNCkkgdGVuZCB0 byBhZ3JlZS4gQnV0IHRoaXMgaXNzdWUga2VlcHMgYmVpbmcgYnJvdWdodCB1cCwgc28gaXQgbWFr ZXMgc2Vuc2UgdG8gdGFsayBhYm91dCBhbHRlcm5hdGl2ZSB3YXlzIG9mIGFkZHJlc3NpbmcgaXQu IFRoZSBpZGVhIG9mIGEgZGVmYXVsdCBzY3JpcHQgc2VlbXMgcmF0aW9uYWwgb3IgcGxhdXNpYmxl IGF0IHRoZSBvdXRzZXQsIGJ1dCBpdCBvbmx5IGJlY29tZXMgYSBwcm9ibGVtIHdoZW4gdXNlZCBp biBjb25qdW5jdGlvbiB3aXRoIG90aGVyIHN1YnRhZ3MgaW4gdGhlIGRlZmF1bHQgbWF0Y2hpbmcg c2NoZW1lLg0KDQpUaGF0IGlzLCB0aGVyZSBpcyBubyBwcm9ibGVtIHdpdGggInpoLUhhbnQiICh0 byBwaWNrIGFuIGV4YW1wbGUpIG9yIHdpdGggInpoLVRXIi4gQm90aCBvZiB0aGVzZSB0YWdzIGlk ZW50aWZ5IHNwZWNpZmljIGFzcGVjdHMgb2YgQ2hpbmVzZSBsYW5ndWFnZS4gVGhlIHByb2JsZW1z IG9ubHkgb2NjdXIgd2hlbiB5b3Ugd2lzaCB0byBjb21iaW5lIHRoZSBzY3JpcHQgYW5kIHJlZ2lv bmFsIHZhcmlhdGlvbnMgaW50byAiemgtSGFudC1UVyIgYmVjYXVzZSBwcmVmaXgtYmFzZWQgbWF0 Y2hpbmcgKHNlZW1zIHRvKSBjcmVhdGUgYSB0ZW5zaW9uIGJldHdlZW4gY2hvb3NpbmcgdGhlIHNj cmlwdCBhbmQgY2hvb3NpbmcgdGhlIHJlZ2lvbiAoY291cGxlZCB3aXRoIHRoZSBmYWN0IHRoYXQg b25lIHRhZyBwcmVkYXRlcyB0aGUgb3RoZXIgYW5kIGhhcyBiZWVuIHVzZWQgcmF0aGVyIGxpYmVy YWxseSB0byBtZWFuIHRoZSBvdGhlciBpbiBzb21lIGNhc2VzKS4NCg0KSSBiZWxpZXZlIHRoYXQg MzA2NmJpcyBzb2x2ZXMgbW9zdCBvZiB0aGUgKmlkZW50aWZpY2F0aW9uKiBwcm9ibGVtcyBvbmUg Y2FuIGVudmlzaW9uIChvbiB2YXJ5aW5nIHNjYWxlcyBvZiBncmFudWxhcml0eSkuIFRoZSBwcm9i bGVtIGl0IGRvZXMgbm90IGNvbXBsZXRlbHkgc29sdmUgaXMgdGhhdCBvZiBtYXRjaGluZyBpbiB0 aGUgZmFjZSBvZiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgKG9mIGxlZnQtcHJlZml4IG1hdGNo aW5nKS4gT25seSBjb21wcm9taXNlcyBhcmUgcG9zc2libGUgb25jZSB5b3UgY29uc2lkZXIgYWRk aXRpb25hbCBzdWJ0YWdzIChubyBtYXR0ZXIgd2hhdCBvcmRlciB5b3UgcHV0IHRoZSBzdWJ0YWdz IGludG8sIGFsdGhvdWdoLCBwYWNlIEZyYW5rIEVsbGVybWFubiwgd2UgY2FuIGRpc2N1c3MgaG93 IGJlc3QgdG8gb3JkZXIgdGhlbSB3aGVuIGZvcm1pbmcgdGFncykuDQoNCkkgdGhpbmsgdGhhdCwg aW4gdGhpcyBsaWdodCwgd2hhdCBJIHdhcyBzYXlpbmcgaXMgdGhhdCBzb21lIGluZm9ybWF0aXZl IGluZm9ybWF0aW9uIHRvIGFzc2lzdCBjdXJyZW50IGFuZCBmdXR1cmUgaW1wbGVtZW50YXRpb25z IHdpdGggdGhpcyBpcyB3b3J0aHkgb2YgY29uc2lkZXJhdGlvbiwgcHJvYmFibHkgaW4gdGhlIG1h dGNoaW5nIGRyYWZ0Lg0KDQpBbmQsIG9mIGNvdXJzZSwgUnVsZSAwIG9mIGxhbmd1YWdlIHRhZ2dp bmcgc2hvdWxkIGJlIHJlc3RhdGVkIGhlcmU6ICJDaG9vc2UgbGFuZ3VhZ2UgdGFncyB3aXNlbHku Ig0KDQpUaGUgZGVmaW5pdGlvbiBvZiB3aXNkb20gaXMgb3BlbiBhbmQgZnVuZ2libGUgb3ZlciB0 aW1lLiBPbmUgcG9zc2liaWxpdHkgdGhhdCBJIHdvdWxkIGxpa2UgdG8gKHJlLSlyYWlzZSBpcyB0 aGF0IHRoZSBkcmFmdCBtaWdodCBub3QgbmVlZCB0byBhZGRyZXNzIGRpcmVjdGx5IHRoZSBjaG9p Y2Ugb2Ygd2hldGhlciBvciBub3QgdG8gdXNlIGEgcGFydGljdWxhciBzY3JpcHQgc3VidGFnLiBJ dCBtYXkgdHVybiBvdXQgdGhhdCwgb3ZlciB0aW1lLCBEZWJiaWUgR2Fyc2lkZSBpcyBjb3JyZWN0 IGFuZCB0aGF0IGNvbnRlbnQgYXV0aG9ycyB3aWxsIGFkb3B0IHRoZSBjdXJyZW50bHkgc3VwZXJm bHVvdXMgJ0xhdG4nIHN1YnRhZyBmb3IgdXNlIHdpdGggImVuIiB0YWdzIChmb3IgZXhhbXBsZSks IGFzIG1vcmUgY2FwYWJsZSBsYW5ndWFnZSB0YWcgcHJvY2Vzc2luZyBiZWNvbWVzIHRoZSBub3Jt LiBUaGluayBvZiBpdCBhcyB0aGUgIm5hdHVyYWwgc2VsZWN0aW9uIiBvZiBsYW5ndWFnZSB0YWdz IGluIHJlc3BvbnNlIHRvIHRoZSBldm9sdXRpb24gb2YgYWxnb3JpdGhtcy4NCg0KQmVzdCBSZWdh cmRzLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJj aGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBD b3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVy ZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3Vu Y2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiBt YXJkaSAyMiBtYXJzIDIwMDUgMjI6MzANCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJq ZWN0OiBbTHRydV0gUmU6IFByZXBhcmF0aW9ucyBmb3Igc21hcnQgbWF0Y2hpbmcNCj4gDQo+IE1h cmsgRGF2aXMgPG1hcmsgZG90IGRhdmlzIGF0IGp0Y3N2IGRvdCBjb20+IHdyb3RlOg0KPiANCj4g PiAxLiBNYXRjaGluZy4gVXNlIG9mICdzcicgc2F5cyB0aGF0IHlvdSB3YW50IHRvIG1hdGNoIFNl cmJpYW4gb2YNCj4gPiB3aGF0ZXZlciBmb3JtOiBkb2Vzbid0IGRlcGVuZCBvbiB0aGUgY291bnRy eSwgZG9lc24ndCBkZXBlbmQgb24gdGhlDQo+ID4gc2NyaXB0LiBVc2Ugb2YsIHNheSwgJ3NyLUxh dG4tSVQnIG1lYW5zIHRoYXQgeW91IHdhbnQgU2VyYmlhbiwgYnV0DQo+ID4gbGltaXRlZCB0byBM YXRpbiBzY3JpcHQsIGFuZCBhcyB1c2VkIGluIEl0YWx5Lg0KPiANCj4gRmluZSBzbyBmYXIuDQo+ IA0KPiA+IDIuIExvb2t1cC4gV2hlbiB5b3UgbG9va3VwIGxhbmd1YWdlIGRhdGEsIGZvciBleGFt cGxlLCBmb3IgZGlzcGxheSBvbg0KPiA+IGEgd2ViIHBhZ2UsIGl0IGlzIGEgZGlmZmVyZW50IHBy b2Nlc3MuIFlvdSB0eXBpY2FsbHkgZG9uJ3QgaGF2ZSB0aGUNCj4gPiBjaG9pY2Ugb2YgZGlzcGxh eWluZyBub3RoaW5nIGlmIHRoZXJlIGlzIG5vdCBhbiBleGFjdCBtYXRjaC4gSW5zdGVhZCwNCj4g PiB5b3UgZmFsbCBiYWNrLiBJZiB5b3UgZG9uJ3QgaGF2ZSBkYXRhIGV4YWN0bHkgbWF0Y2hpbmcg J3NyLUxhdG4tSVQnLA0KPiA+IHlvdSBmYWxsYmFjayB0byBkYXRhIGZvciAnc3ItTGF0bicuIElm IHlvdSBkb24ndCBoYXZlIHRoYXQgZWl0aGVyLCB5b3UNCj4gPiBmYWxsYmFjayB0byBkYXRhIGZv ciAnc3InLiBOb3csIHdoYXRldmVyIGRhdGEgY29udGVudHMgc29tZW9uZSBoYXMNCj4gPiBhc3Nv Y2lhdGVkIHdpdGggJ3NyJywgaXQgaGFzIHRvIGJlIGEgc2luZ2xlIGNvbnNpc3RlbnQgdHlwZSBv ZiBkYXRhLA0KPiA+IHNvIGl0IHdpbGwgYmUgaW4gb25lIG9mICdMYXRuJyBvciAnQ3lybCcuDQo+ IA0KPiBCdXQgdGhpcyBpcyBqdXN0IHByZWZpeCBtYXRjaGluZy4gIEZhbGxpbmcgYmFjayBmcm9t ICJzci1MYXRuLUlUIiB0bw0KPiAic3ItTGF0biIgdG8gInNyIiBkb2Vzbid0IHJlcXVpcmUgdXMg b3IgYW55b25lIGVsc2UgdG8gZGVmaW5lIGEgZGVmYXVsdA0KPiBzY3JpcHQgZm9yIFNlcmJpYW4u ICBBbmQgd2hlbiB3ZSBnZXQgdG8gInNyIiBhbmQgZmluYWxseSBmaW5kIGEgbWF0Y2gsDQo+IHdl IGhhdmUgd2hhdGV2ZXIgcmVzb3VyY2VzIHdlIGhhdmUuICBUaGV5IG1pZ2h0IGJlIGVpdGhlciBM YXRpbiBvcg0KPiBDeXJpbGxpYy4gIFRoZSBjaG9pY2Ugd29uJ3QgZGVwZW5kIG9uIHdoaWNoIHNj cmlwdCBzb21lb25lIGRlY2lkZWQgd2FzDQo+IHRoZSBkZWZhdWx0Lg0KPiANCj4gPiBTaW1pbGFy bHksIEFtZXJpY2FuIEVuZ2xpc2ggbWF5IGJlIHVzZWQgaW4gZGF0YSBhc3NvY2lhdGVkIHdpdGgg ZW4gZm9yDQo+ID4gbG9va3VwIHB1cnBvc2VzLiBBbnkgZGlzdGluY3Rpb25zIGFjY29yZGluZyB0 byBjb3VudHJ5IHdvdWxkIGJlIHN0b3JlZA0KPiA+IHNlcGFyYXRlbHkgaW4gYW4gJ2VuLUFVJywg J2VuLUNBJywgJ2VuLUlFJywgZXRjLiwgYW5kIGlmIGF2YWlsYWJsZSwNCj4gPiB3b3VsZCBiZSBm b3VuZCBpbiBhIGxvb2t1cC4gQnV0IGlmIHNvbWVvbmUgY2FtZSBpbiB3aXRoICdlbi1KUCcsIGFu ZA0KPiA+IHRoZXJlIHdhcyBubyBzZXBhcmF0ZSBkYXRhIHNvdXJjZSBmb3IgdGhhdCwgaXQgd291 bGQgZmFsbCBiYWNrIHRvIHRoZQ0KPiA+IGRhdGEgYXNzb2NpYXRlZCB3aXRoICdlbicsIHdoaWNo IHdvdWxkIGJlIEFtZXJpY2FuIEVuZ2xpc2guDQo+IA0KPiBOb3QgaWYgdGhlIGNvbnRlbnQgcHJv dmlkZXIgaXMgaW4gQXVzdHJhbGlhIG9yIENhbmFkYSBvciBJcmVsYW5kLiAgVGhlaXINCj4gZGF0 YSB3aWxsIGJlIGluIHRoZWlyIG93biBmbGF2b3Igb2YgRW5nbGlzaCwgd2hpY2ggaXMgd2hhdCB0 aGV5IHdvdWxkDQo+IGxvZ2ljYWxseSBjYWxsICJlbiIuDQo+IA0KPiA+IFRodXMsIEkgdGhpbmsg aXQgbWF5IGJlIHJlYXNvbmFibGUsIGluIHN1cHBvcnQgb2YgbG9va3VwIGZhbGxiYWNrDQo+ID4g c3RyYXRlZ2llcywgdG8gaGF2ZSBhIHRhYmxlIG9mIGRhdGEgZGVzaWduZWQgZm9yICJkZWZhdWx0 IiBsb29rdXANCj4gPiBmYWxsYmFjaywgc3RydWN0dXJlZCBhbG9uZyBzb21ldGhpbmcgbGlrZSB0 aGUgZm9sbG93aW5nIGxpbmVzOg0KPiA+DQo+ID4gZmFsbGJhY2sgfCBlbiB8IGVuLUxhdG4NCj4g PiBmYWxsYmFjayB8IHNyIHwgc3ItQ3lybA0KPiA+IGZhbGxiYWNrIHwgcHQgfCBwdC1CUiBwdC1M YXRuLUJSDQo+IA0KPiBJIHJlYWxseSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIHRoaXMuICBQZW9w bGUgd2lsbCBzZWUgaXQgYXMgYQ0KPiByZWNvbW1lbmRhdGlvbiBvciBhIERpa3RhdCB0aGF0IGVu ICJtZWFucyIgZW4tTGF0biwgb3IgKHdvcnNlKSB0aGF0IHNyDQo+ICJtZWFucyIgc3ItQ3lybC4N Cj4gDQo+IFdlJ3ZlIG5ldmVyIGdvdHRlbiBpbnZvbHZlZCB3aXRoIHNlY29uZC1ndWVzc2luZyB3 aGF0IHBlb3BsZSBtZWFuIHdoZW4NCj4gdGhleSB3cml0ZSBhIGNlcnRhaW4gbGFuZ3VhZ2UgdGFn LCBvciBjaG9vc2luZyBvbmUgc2NyaXB0IG9yIHJlZ2lvbiBhcw0KPiAicHJlZmVycmVkIiBvdmVy IGFub3RoZXIuICBJIHNlZSBubyByZWFzb24gdG8gc3RhcnQgZG9pbmcgc28gbm93Lg0KPiANCj4g LURvdWcgRXdlbGwNCj4gIEZ1bGxlcnRvbiwgQ2FsaWZvcm5pYQ0KPiAgaHR0cDovL3VzZXJzLmFk ZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxp c3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0 cnUNCg0K --===============1629761400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1629761400==-- From ltru-bounces@ietf.org Wed Mar 23 13:55:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19361; Wed, 23 Mar 2005 13:55:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEB6j-00076E-St; Wed, 23 Mar 2005 14:01:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAzH-0007AY-2K; Wed, 23 Mar 2005 13:53:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAzG-0007A6-PG for ltru@megatron.ietf.org; Wed, 23 Mar 2005 13:53:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19100 for ; Wed, 23 Mar 2005 13:53:36 -0500 (EST) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEB4a-0006zo-P9 for ltru@ietf.org; Wed, 23 Mar 2005 13:59:22 -0500 Received: from h-64-105-34-138.snvacaid.dynamic.covad.net ([64.105.34.138] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DEAyy-0000x2-00 for ltru@ietf.org; Wed, 23 Mar 2005 10:53:33 -0800 Message-ID: <008201c52fd9$b80a0400$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006201c52f73$bba93420$030aa8c0@DEWELL> Subject: Re: [Ltru] Registry in record-jar format Date: Wed, 23 Mar 2005 10:54:18 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, March 22, 2005 10:44 PM > Subject: [Ltru] Registry in record-jar format > > At least one person expressed some interest in seeing the draft / > proposed / sample registry in record-jar format, so here it is: > > http://users.adelphia.net/~dewell/lstreg-rj.txt > > This has no official sanction or consensus; it's just there so people > can visualize it (which I guess is true for the other one as well). ... Thanks for making this available. It's always helpful to be able to see just how a proposal might be realized. (co-chair hat off) I like this format better than the current one, for the following reasons: 1) it's much easier to read, and consequently less error-prone for whoever ends up doing the actual edits to the registry files 2) it's still machine-parseable 3) it would permit the initial registry content to be documented in an internet draft Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 14:20:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21929; Wed, 23 Mar 2005 14:20:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBUV-0007my-W4; Wed, 23 Mar 2005 14:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBNi-0001hA-OO; Wed, 23 Mar 2005 14:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBNh-0001gu-Ug for ltru@megatron.ietf.org; Wed, 23 Mar 2005 14:19:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21694 for ; Wed, 23 Mar 2005 14:19:04 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBTC-0007kC-Qt for ltru@ietf.org; Wed, 23 Mar 2005 14:24:49 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2NJIraN014833; Wed, 23 Mar 2005 14:18:54 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 23 Mar 2005 14:18:53 -0500 Date: Wed, 23 Mar 2005 14:18:53 -0500 From: John Cowan To: "L.Gillam" Subject: Re: [Ltru] Re: Preparations for smart matching Message-ID: <20050323191853.GE1564@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1A9@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A1A9@EVS-EC1-NODE1.surrey.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 L.Gillam scripsit: > The original point here was that "smart matching" would have to > do a bit more than "tag-dropping", fallback or, perhaps fall-forward as > seems to be being suggested. Association between 639-2 and 639-3 is just > that little bit more because of this. Using the zh-yue style makes this much easier on tag matchers, and only slightly harder on taggers. > Where -5 fishes the same alpha3 > pool, anybody deciding to incorporate this also would have further such > work to do because of associations. Which is why I hope it never does get used in RFC-style language tagging, other than the unavoidably grandfathered cases from 639-2. > I'm happy to make the draft available for expert comment - the ISO process > definitely allows for this. Thanks. Please post an URL, or if you are not allowed to do that, please send me a copy. > I don't believe you can actually *buy* the > drafts anywhere - I may be wrong, and perhaps ISO is missing a business > opportunity here! http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryString=639 claims that you can buy the DIS 639-3 (but not the WDs 639-4 or 639-5). > Accept but reduce dependency on, or keep using because of "legacy code"? Not legacy code so much as legacy tagging. There may be documents out there tagged "nai", worthless as that is for almost all purposes except completeness, so we can't just deprecate it wholesale -- the argument has been made that expecting people on the other side of the planet to discriminate between various North American Indian languages in their holdings is just unreasonable. -- John Cowan http://www.ccil.org/~cowan You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! `Tis a Jute.... (Finnegans Wake 16.5) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 15:15:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29793; Wed, 23 Mar 2005 15:15:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECM7-0001ID-7u; Wed, 23 Mar 2005 15:21:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECFO-0002qW-5x; Wed, 23 Mar 2005 15:14:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECFN-0002qR-Pz for ltru@megatron.ietf.org; Wed, 23 Mar 2005 15:14:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29559 for ; Wed, 23 Mar 2005 15:14:31 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECKt-0001FF-SL for ltru@ietf.org; Wed, 23 Mar 2005 15:20:17 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 12:14:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Registry in record-jar format Date: Wed, 23 Mar 2005 12:14:19 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82B68@irvmbxw01.quest.com> Thread-Topic: [Ltru] Registry in record-jar format Thread-Index: AcUv2dyHLne+fDziQfGIP4NXGWk+kgAAxtPQ From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 23 Mar 2005 20:14:20.0555 (UTC) FILETIME=[E5DEA5B0:01C52FE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable If we're going to consider different formats for the registry, might I = suggest that an even better format would be XML? XML can be structured in a way that would allow multiple separate = elements to be defined when multiple values are called for. Adding new = recommended prefixes, for example, could be done by adding = elements to the record. This would also allow for some other useful things. For example, the = registry could use the xml:lang attribute (ooh, self-referential objects = are so cool) to provide alternate language descriptions or native = language descriptions (since an XML file could use UTF-8 as the encoding = or at least NCRs). The registry could also use a URI (or rather, an IRI) = to reference the registration form itself (tying registration to the = registry). The DTD could also enforce a certain level of validity on the registry = and could itself be versioned to accommodate 3066ter and 639-3 as = necessary.=20 Finally, unlike a flat text file, an XML format would be extensible. = Future changes to the RFC could add fields to the registry without = breaking existing registry processors. (RJ format can do this too, of = course.) Note that XML files are text files, so the presence of an XML processor = itself is not required, especially if the registry uses NCRs for = non-ASCII values. Consider: Type: variant Subtag: hakka Description: Hakka Date: 1999-12-18 Recommended_Prefix: zh Versus: Hakka ..... = http://www.iana.org/assignments/lang-tags/zh-hakka= zh zh-Hant You can put all sorts of useful information=20 into an XML document. Of course, an XML (or any format) version of the registry can be made = from (say) the RJ format. We could pick one canonical format and = consider whether to render informative versions in other formats. XML = offers lots of flexibility for automating views of the data for that = matter. Just an idea........ Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: mercredi 23 mars 2005 10:54 > To: LTRU Working Group > Subject: Re: [Ltru] Registry in record-jar format >=20 > Hi - >=20 > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Tuesday, March 22, 2005 10:44 PM > > Subject: [Ltru] Registry in record-jar format > > >=20 > > At least one person expressed some interest in seeing the draft / > > proposed / sample registry in record-jar format, so here it is: > > > > http://users.adelphia.net/~dewell/lstreg-rj.txt > > > > This has no official sanction or consensus; it's just there so = people > > can visualize it (which I guess is true for the other one as well). > ... >=20 > Thanks for making this available. It's always helpful to be able to = see > just how a proposal might be realized. >=20 > (co-chair hat off) > I like this format better than the current one, for the following = reasons: > 1) it's much easier to read, and consequently less error-prone for > whoever ends up doing the actual edits to the registry files > 2) it's still machine-parseable > 3) it would permit the initial registry content to be documented in > an internet draft >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 15:27:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01209; Wed, 23 Mar 2005 15:27:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECXZ-0001ad-1t; Wed, 23 Mar 2005 15:33:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECRU-0004dy-If; Wed, 23 Mar 2005 15:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECRT-0004dr-3p for ltru@megatron.ietf.org; Wed, 23 Mar 2005 15:27:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01120 for ; Wed, 23 Mar 2005 15:27:01 -0500 (EST) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECX0-0001Yf-9S for ltru@ietf.org; Wed, 23 Mar 2005 15:32:46 -0500 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN8-94241d10854; Wed, 23 Mar 2005 15:26:49 -0500 Received: from DEBHOME (ACD7A505.ipt.aol.com [172.215.165.5]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2NKQcuP024162; Wed, 23 Mar 2005 15:26:38 -0500 Message-Id: <200503232026.j2NKQcuP024162@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'John Cowan'" , "'L.Gillam'" Subject: RE: [Ltru] Re: Preparations for smart matching Date: Wed, 23 Mar 2005 20:26:08 -0000 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: AcUv3UtyzvxiF6UNSluWuJazlGnuDQACTrBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050323191853.GE1564@skunk.reutershealth.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit John Cowan wrote: >>http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryStr ing=639 >>claims that you can buy the DIS 639-3 (but not the WDs 639-4 or 639-5). 639-4 is not in existence yet (quite strange given that it is supposed to provide the framework for 3,5 and 6) so no working draft is available. 639-5 has only just been posted (in the last 5 weeks) to members of the WG. I have a copy (one sent to JC) if any one wants it... I assume I am not going against any ISO rules. Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of John Cowan Sent: 23 March 2005 19:19 To: L.Gillam Cc: ltru@ietf.org Subject: Re: [Ltru] Re: Preparations for smart matching L.Gillam scripsit: > The original point here was that "smart matching" would have to > do a bit more than "tag-dropping", fallback or, perhaps fall-forward as > seems to be being suggested. Association between 639-2 and 639-3 is just > that little bit more because of this. Using the zh-yue style makes this much easier on tag matchers, and only slightly harder on taggers. > Where -5 fishes the same alpha3 > pool, anybody deciding to incorporate this also would have further such > work to do because of associations. Which is why I hope it never does get used in RFC-style language tagging, other than the unavoidably grandfathered cases from 639-2. > I'm happy to make the draft available for expert comment - the ISO process > definitely allows for this. Thanks. Please post an URL, or if you are not allowed to do that, please send me a copy. > I don't believe you can actually *buy* the > drafts anywhere - I may be wrong, and perhaps ISO is missing a business > opportunity here! http://www.iso.org/iso/en/CombinedQueryResult.CombinedQueryResult?queryStrin g=639 claims that you can buy the DIS 639-3 (but not the WDs 639-4 or 639-5). > Accept but reduce dependency on, or keep using because of "legacy code"? Not legacy code so much as legacy tagging. There may be documents out there tagged "nai", worthless as that is for almost all purposes except completeness, so we can't just deprecate it wholesale -- the argument has been made that expecting people on the other side of the planet to discriminate between various North American Indian languages in their holdings is just unreasonable. -- John Cowan http://www.ccil.org/~cowan You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! `Tis a Jute.... (Finnegans Wake 16.5) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 16:54:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22083; Wed, 23 Mar 2005 16:54:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDtj-0007vd-J3; Wed, 23 Mar 2005 17:00:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDCY-00033j-DD; Wed, 23 Mar 2005 16:15:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDCX-000333-3r for ltru@megatron.ietf.org; Wed, 23 Mar 2005 16:15:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06046 for ; Wed, 23 Mar 2005 16:15:38 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEDI3-00035o-Sd for ltru@ietf.org; Wed, 23 Mar 2005 16:21:25 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 23 Mar 2005 21:14:51 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 21:14:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Mar 2005 21:14:50 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A1B1@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Reading legacy data Thread-Index: AcUvtBc85/jE9lTlSCOjvu7KDFBr3gAAci1gAAH2fyAAC/LLYA== From: "L.Gillam" To: ltru X-OriginalArrivalTime: 23 Mar 2005 21:14:50.0454 (UTC) FILETIME=[59754760:01C52FED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] OT: Reading legacy data X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Geological interoperability may present a problem, and backups can be an issue in times of faults (earthquakes perhaps). Those who use non-standardized carving tools may pose difficulties for everybody = else.... on the bright side, I think I can do caveman impressions :-) > > Accept but reduce dependency on, or keep using because of=20 > "legacy code"? > I discovered yesterday, to my sheer horror, that an Oracle V10 client > could not > speak to an Oracle V8.1.5 server. But, an Oracle V8.1.5 server will > apparently > not work on a RedHat FC3 or RHEL 3 platform, and the platform it is > currrently > on cannot be hack-proofed for web accesses. Do Microsoft still support > Windows 95/98? There are ways to work around the problem, but as time > goes > by the work arounds become an artform - and I'm not a great=20 > fan of art. > :-( > >=20 > Hence all important documents should be carved into cave walls. >=20 > Misha _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 23 22:42:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29036; Wed, 23 Mar 2005 22:42:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEJKC-0002GN-DN; Wed, 23 Mar 2005 22:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEJDb-0003tS-H1; Wed, 23 Mar 2005 22:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEJDZ-0003tK-CG for ltru@megatron.ietf.org; Wed, 23 Mar 2005 22:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28969 for ; Wed, 23 Mar 2005 22:41:07 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEJJ9-0002F3-Nt for ltru@ietf.org; Wed, 23 Mar 2005 22:46:57 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 19:40:58 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 19:40:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Preparations for smart matching Date: Wed, 23 Mar 2005 19:40:57 -0800 Message-ID: Thread-Topic: [Ltru] Re: Preparations for smart matching thread-index: AcUv3VLdeFBRTn84RdSo8nbX+LGLmAARX1ww From: "Peter Constable" To: X-OriginalArrivalTime: 24 Mar 2005 03:40:58.0484 (UTC) FILETIME=[4AAE1B40:01C53023] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > Not legacy code so much as legacy tagging. There may be documents out > there > tagged "nai", worthless as that is for almost all purposes except > completeness, > so we can't just deprecate it wholesale -- the argument has been made that > expecting people on the other side of the planet to discriminate between > various North American Indian languages in their holdings is just > unreasonable. One additional point regarding this: there's a difference between an author tagging a resource and a cataloguer tagging a resource: the author will generally know the language the content was authored in; whether a cataloguer can recognize the language of an item to be catalogued is dependent on the cataloguer and the content and cannot be guaranteed. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 01:21:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13359; Thu, 24 Mar 2005 01:21:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DELoj-00078N-6E; Thu, 24 Mar 2005 01:27:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DELiC-0001Q6-Mr; Thu, 24 Mar 2005 01:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DELi6-0001NY-TQ for ltru@megatron.ietf.org; Thu, 24 Mar 2005 01:20:51 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13315 for ; Thu, 24 Mar 2005 01:20:49 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DELht-0002fW-Tu for ltru@lists.ietf.org; Thu, 24 Mar 2005 07:20:37 +0100 Received: from 62.80.58.38 ([62.80.58.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2005 07:20:37 +0100 Received: from nobody by 62.80.58.38 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Mar 2005 07:20:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 24 Mar 2005 07:16:27 +0100 Organization: Lines: 59 Message-ID: <42425B3B.12DA@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AB82B68@irvmbxw01.quest.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: 62.80.58.38 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Addison Phillips wrote: > If we're going to consider different formats for the > registry, might I suggest that an even better format would > be XML? would be nice to create I-Ds and later RfCs, see > This would also allow for some other useful things. Apparently you want a completely new DTD for this purpose. Does _any_ IANA registry use XML ? > provide alternate language descriptions or native language > descriptions (since an XML file could use UTF-8 as the > encoding or at least NCRs). The resulting plain text ASCII RfC and registry could be messy, from the POV of a reader. One or two literal Ӓ or u+04D2 in a paragraph are okay, but numerous of these beasts are ugly. > The registry could also use a URI (or rather, an IRI) to > reference the registration form itself (tying registration > to the registry). That's a good idea, add an URL as (optional) 7th column to the registry, pointing to the approval of the tag reviewer, e.g. http://www.iana.org/assignments/lang-tags/en-scouse In the record-jar part of a future I-D or RfC something like: %% Type: variant Subtag: scouse Description: Scouse Date: 2000-05-25 Recommended_Prefix: en URL: http://www.iana.org/assignments/lang-tags/en-scouse %% > The DTD could also enforce a certain level of validity on the > registry and could itself be versioned to accommodate 3066ter > and 639-3 as necessary. Is that a good idea ? Matching language tags shouldn't depend on XML parsers. It's also recursive, 3066bis is a definition of what we do in a xml:lang, and if that definition has its own XML DTD not mentioned in the document with the xml:lang then it's confusing. If we'd want DC we'd know where to find it. > XML offers lots of flexibility for automating views of the > data for that matter. True, but gawk is also a nice tool, it has no problem with the record-jar (or similar) format. But it's not exactly the best choice to parse XML. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 04:44:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20487; Thu, 24 Mar 2005 04:44:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEOyp-0004bN-Ku; Thu, 24 Mar 2005 04:50:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEOqw-0005mp-Ux; Thu, 24 Mar 2005 04:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEOqZ-0005mJ-Bs for ltru@megatron.ietf.org; Thu, 24 Mar 2005 04:41:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20385 for ; Thu, 24 Mar 2005 04:41:45 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEOwD-0004Xm-LT for ltru@ietf.org; Thu, 24 Mar 2005 04:47:38 -0500 Received: from lns-p19-1-idf-82-251-86-86.adsl.proxad.net ([82.251.86.86] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DEOqW-0005ca-PR for ltru@ietf.org; Thu, 24 Mar 2005 01:41:45 -0800 Message-Id: <6.1.2.0.2.20050324080839.0406a570@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 24 Mar 2005 10:41:35 +0100 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" In-Reply-To: <42425B3B.12DA@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AB82B68@irvmbxw01.quest.com> <42425B3B.12DA@xyzzy.claranet.de> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Just a minute, gentlemen! Could you please investigate first what will be the resulting use? The IANA is a reference source, for a "few" developers or politics to consult. What was documented by the RFC 3066 up to now was a more flexible manner to register, store and make accessible for free what ISO do with paid papers. The load resulting from RFC 3066 bis is more substantial since there are far more languages, possible subtags and resulting langtags to register and manage. If we consider the workload represented by registrations (proposition received from Michael Everson, registration, verification, possible errors and support) we are here in the range of a very large ccTLD with top quality services (we are only a few checking registered DNs). Also, before that I am not sure ietf-languages can cope with that workload (with a 15 days debate, etc.). Let remember that we have 7500 languages and 240 countries (rough figures), I suppose that the total amount of registrations may be in the range of 30-100.000. Plus private registration - over the years this may amount to millions if SNHNs start playing the way every indication show they will. The first question about this is: who will pay? Now, if you start talking of DTD, with several versions, and of XML presentations with additional data and linked URLs and IRIs, questions are: - who is going to maintain the entries? - there will be millions/billions of pages referencing the DTD, the urls, etc. which will lead to a IANA access 24/366. Some evaluations are needed about the resulting traffic and the CPU load before IANA can just discuss it. I am not sure, but we are replicating bigger than the DNS root here. One has to be aware that DoS and bug are very heavy on this kind of WHOIS is like systems (Iegitimate calls to the DNS root amount to 2.5% - 97.5% being more or less junk). I am not sure the IANA agreement with SRI or who ever else can stand the load. I note also that for such a standardized and hopefully stable formatted system, the format can certainly be prototyped in using XML but a more compact solution should to be considered. Most probably UDP supported. I do not know the INRIA, etc. project we will see documented. But I note that this is a paid access service. Resources have a cost. IANA is a "free" service because it is donated to the Internet community. I understand that Unicode/W3C want to use IANA "free" resources, but how much are these close paying membership structures ready to contribute to permit everyone to get this free service? Right now ccTLDs are discussing how much to pay ICANN for its IANA service. And want to keep it very very low. Since the more we would ask from IANA the more we would depend on ICANN, so the more our economies and people would depend on a foreign uncontrolled source. (this is a common concern by every ccTLD, that USA share: no one knows who will manage the IANA two years from now). We will certainly want to look in detail at this RFC 3066 ter service since our communities will most probably be large users of it. And we will certainly question its use and design to make sure we are requested to pay for the most appropriate solution. Several countries (and this is my own direct concern with AFRAC) consider how best to replicate and extend the IANA system for surety, security, stability, scalability, support, simplicity, sovereignty, innovation reasons. Economics, data consistency and operations considerations are also of the essence, since the granularity of these referencing systems will certainly extend down to the SNHNs. I do not know why but I feel we are considering a gas refinery where a straw would be enough to sip the wiskey in the -jar. jfc At 07:16 24/03/2005, Frank Alderman wrote: >Addison Phillips wrote: > > > If we're going to consider different formats for the > > registry, might I suggest that an even better format would > > be XML? > > would be nice >to create I-Ds and later RfCs, see > > > This would also allow for some other useful things. > >Apparently you want a completely new DTD for this purpose. >Does _any_ IANA registry use XML ? > > > provide alternate language descriptions or native language > > descriptions (since an XML file could use UTF-8 as the > > encoding or at least NCRs). > >The resulting plain text ASCII RfC and registry could be messy, >from the POV of a reader. One or two literal Ӓ or u+04D2 >in a paragraph are okay, but numerous of these beasts are ugly. > > > The registry could also use a URI (or rather, an IRI) to > > reference the registration form itself (tying registration > > to the registry). > >That's a good idea, add an URL as (optional) 7th column to the >registry, pointing to the approval of the tag reviewer, e.g. >http://www.iana.org/assignments/lang-tags/en-scouse > >In the record-jar part of a future I-D or RfC something like: > >%% >Type: variant >Subtag: scouse >Description: Scouse >Date: 2000-05-25 >Recommended_Prefix: en >URL: http://www.iana.org/assignments/lang-tags/en-scouse >%% > > > The DTD could also enforce a certain level of validity on the > > registry and could itself be versioned to accommodate 3066ter > > and 639-3 as necessary. > >Is that a good idea ? Matching language tags shouldn't depend >on XML parsers. It's also recursive, 3066bis is a definition >of what we do in a xml:lang, and if that definition has its own >XML DTD not mentioned in the document with the xml:lang then >it's confusing. If we'd want DC we'd know where to find it. > > > XML offers lots of flexibility for automating views of the > > data for that matter. > >True, but gawk is also a nice tool, it has no problem with the >record-jar (or similar) format. But it's not exactly the best >choice to parse XML. > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 06:15:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27049; Thu, 24 Mar 2005 06:15:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEQPO-00079b-Jr; Thu, 24 Mar 2005 06:21:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEQFC-0006vG-OQ; Thu, 24 Mar 2005 06:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEQEF-0006rr-3I for ltru@megatron.ietf.org; Thu, 24 Mar 2005 06:10:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26514 for ; Thu, 24 Mar 2005 06:10:16 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEQJu-0006yy-0a for ltru@ietf.org; Thu, 24 Mar 2005 06:16:10 -0500 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 24 Mar 2005 11:09:49 +0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 11:09:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Date: Thu, 24 Mar 2005 11:06:38 -0000 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A592E@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Thread-Index: AcUwVpQHHIFYt2WpQnuLHrbtFNz7AwACvjak From: "L.Gillam" To: ltru X-OriginalArrivalTime: 24 Mar 2005 11:09:49.0105 (UTC) FILETIME=[FE94C210:01C53061] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0283634614==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 This is a multi-part message in MIME format. --===============0283634614== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53061.FC4DC1CD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53061.FC4DC1CD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [snip] > The load resulting from RFC 3066 bis is more substantial since there = are > far more languages, possible subtags and resulting langtags to = register and > manage [snip] One might suggest that if a future ISO 639-4 provides for ISO 11179-3 / = ISO 12620 (in revision) conformant collections (XML-based), and = eventually perhaps ISO 3166 and 15924 could go the same way, an = XML-based RFC 3066 is a composition with additional documentation, and = the pages themselves form part of what one might suggest to be the = semantic web. Such an approach, based on technologies of the W3C itself, = seems to be quite sensible. The beauty of current technologies like XSL (T and FO) and database to = XML converters is that you can have quite a lot of formats. Profusion of = formats becomes problematic, and hence the consideration of metamodels = which allow for extensibility for specific purposes (see documents on = www.tc37sc4.org dealing with LMF for = example). Many computer programmers are more than capable of dealing = with format conversions. Selecting one, or more, poses no problems as = far as I can tell. I would, though, encourage the provision of = interchange routines alongside the formatted data. Theoretically, as yet = I see no problems. > - there will be millions/billions of pages referencing the DTD, the = urls, > etc. which will lead to a IANA access 24/366.=20 > Some evaluations are needed about the resulting traffic and the CPU = load before IANA can just discuss Why would it? I don't look at a dictionary every time I write a word, = then apply a spell check to that word and a grammar check to the = sentence so far. Moore's law applies to the technology. Around 5 = exabytes of new information are estimated to be created every year. A = billion pages isn't a lot - how many does Google currently claim to = handle? How many will it handle in 2 years? I suggest you investigate = the number of page impressions handled by certain existing web servers = technologies (Apache) and present a scientific argument about the = possible future limitations of the technology for handling the = application, rather than faulting the application. Stating that DoS = attacks should prevent people from undertaking these efforts is akin to = putting the cart before the horse.=20 =20 I do have a proposal . Following your scientific argument about the = possible future limitation of the technology, you approach the right = parties about fixing DoS problems. If, as you say, if only 2.5% are = valid requests, based on figures from where I know not, and you work = towards reducing the 97.5% by just another 2.5% you will double the = capacity at a stroke and remove the barriers to the valuable work being = undertaken here. How does that sound?=20 ------_=_NextPart_001_01C53061.FC4DC1CD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Ltru] is there some wiskey in the jar - [was: Registry in = record-jar format]=0A= =0A= =0A=
=0A=

[snip]

=0A=

> =0A= The load resulting from RFC 3066 bis is more substantial since there = are
> =0A= far more languages, possible subtags and resulting langtags to register =0A= and
> manage

=0A=

[snip]

=0A=

One =0A= might suggest that if a future ISO 639-4 provides for ISO 11179-3 / ISO = 12620 =0A= (in revision) conformant collections (XML-based), and eventually perhaps = ISO =0A= 3166 and 15924 could go the same way, an XML-based RFC 3066 is a = composition =0A= with additional documentation, and the pages themselves form part of = what one =0A= might suggest to be the semantic web. Such an approach, based on = technologies of =0A= the W3C itself, seems to be quite sensible.

=0A=

The =0A= beauty of current technologies like XSL (T and FO) and database to XML =0A= converters is that you can have quite a lot of formats. Profusion of = formats =0A= becomes problematic, and hence the consideration of metamodels which = allow for =0A= extensibility for specific purposes (see documents on www.tc37sc4.org dealing with LMF = for =0A= example). Many computer programmers are more than capable of dealing = with format =0A= conversions. Selecting one, or more, poses no problems as far as I can = tell. I =0A= would, though, encourage the provision of interchange routines alongside = the =0A= formatted data. Theoretically, as yet I see no = problems.

=0A=

> =0A= - there will be millions/billions of pages referencing the DTD, the =0A= urls,
> etc. which will lead to a IANA access 24/366. =0A=

=0A=

> =0A= Some evaluations are needed about the resulting traffic and the CPU load = before =0A= IANA can just discuss

=0A=
Why =0A= would it? I don’t look at a dictionary every time I write a word, = then apply a =0A= spell check to that word and a grammar check to the sentence so far. = Moore’s law =0A= applies to the technology. Around 5 exabytes of new information are = estimated to =0A= be created every year. A billion pages isn’t a lot – how = many does Google =0A= currently claim to handle? How many will it handle in 2 years? I suggest = you =0A= investigate the number of page impressions handled by certain existing = web =0A= servers technologies (Apache) and present a scientific argument about = the =0A= possible future limitations of the technology for handling the = application, =0A= rather than faulting the application. Stating that DoS attacks should = prevent =0A= people from undertaking these efforts is akin to putting the cart before = the =0A= horse.
=0A=
 
=0A=
I =0A= do have a proposal . Following your scientific argument about the = possible =0A= future limitation of the technology, you approach the right parties = about fixing =0A= DoS problems. If, as you say, if only 2.5% are valid = requests, based =0A= on figures from where I know not, and you work towards reducing the = 97.5% =0A= by just another 2.5% you will double the capacity at a stroke and remove = the =0A= barriers to the valuable work being undertaken here. How does that = sound? =0A=
=0A= =0A= =0A= ------_=_NextPart_001_01C53061.FC4DC1CD-- --===============0283634614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0283634614==-- From ltru-bounces@ietf.org Thu Mar 24 06:56:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01332; Thu, 24 Mar 2005 06:56:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DER2I-0008Nq-Vo; Thu, 24 Mar 2005 07:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEQva-0003hQ-Sv; Thu, 24 Mar 2005 06:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEQvZ-0003hC-UC for ltru@megatron.ietf.org; Thu, 24 Mar 2005 06:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01243 for ; Thu, 24 Mar 2005 06:55:03 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DER1D-0008LB-VC for ltru@ietf.org; Thu, 24 Mar 2005 07:00:57 -0500 Received: from Lugh (83-70-244-148.b-ras1.prp.dublin.eircom.net [83.70.244.148]) by postie2.hosting365.ie (Postfix) with ESMTP id 9FAA2237ADCE2 for ; Thu, 24 Mar 2005 11:54:53 +0000 (GMT) From: "Jon Hanna" To: Subject: RE: [Ltru] Re: Registry in record-jar format Date: Thu, 24 Mar 2005 11:54:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42425B3B.12DA@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUwOcSf0OSQS29wRGqczGqZn1lpRAALc2ug Message-Id: <20050324115453.9FAA2237ADCE2@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit > The resulting plain text ASCII RfC and registry could be messy, > from the POV of a reader. One or two literal Ӓ or u+04D2 > in a paragraph are okay, but numerous of these beasts are ugly. It would (and I'd hope eventually will) be much nicer if the RFC rules allowed for UTF-8 wouldn't it? Still, I'd imagine that the said XML section would be an appendix that anyone studying in earnest would view as XML, rather than as ASCII source formatted to fit the RFC line-width rules, so I don't foresee this being a major issue. Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 07:09:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02258; Thu, 24 Mar 2005 07:09:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DERFE-0000Km-IJ; Thu, 24 Mar 2005 07:15:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DER9J-0005RQ-Pg; Thu, 24 Mar 2005 07:09:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DER9I-0005RI-DA for ltru@megatron.ietf.org; Thu, 24 Mar 2005 07:09:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02251 for ; Thu, 24 Mar 2005 07:09:13 -0500 (EST) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEREx-0000IN-31 for ltru@ietf.org; Thu, 24 Mar 2005 07:15:08 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 24 Mar 2005 07:09:01 -0500 id 0055C1AA.4242ADDD.00000FDC Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: Registry in record-jar format Date: Thu, 24 Mar 2005 07:09:01 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0749C8EE@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <42425B3B.12DA@xyzzy.claranet.de> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit > Apparently you want a completely new DTD for this purpose. > Does _any_ IANA registry use XML ? Yes -- take a look at these: http://www.iana.org/assignments/xml-registry-index.html -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 08:34:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11298; Thu, 24 Mar 2005 08:34:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DESZJ-0003H9-DD; Thu, 24 Mar 2005 08:40:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DESSY-00088w-Jn; Thu, 24 Mar 2005 08:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DESSX-00088r-2e for ltru@megatron.ietf.org; Thu, 24 Mar 2005 08:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11244 for ; Thu, 24 Mar 2005 08:33:11 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DESYC-0003Dj-IJ for ltru@ietf.org; Thu, 24 Mar 2005 08:39:05 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 05:32:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Registry in record-jar format Date: Thu, 24 Mar 2005 05:32:55 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82E84@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUwOcSf0OSQS29wRGqczGqZn1lpRAALc2ugAANKvCA= From: "Addison Phillips" To: "Jon Hanna" , X-OriginalArrivalTime: 24 Mar 2005 13:32:55.0834 (UTC) FILETIME=[FCAB9FA0:01C53075] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable We can change the definition of a text-based version of the registry to = use UTF-8, although that imposes a certain burden on users that a string = ASCII regime does not. (Did I write that? I cannot believe I'm defending = an ASCII solution for this...) XML uses Unicode by definition, although we might choose to restrict the = registry file's actual encoding to ASCII for similar reasons. The question about lots of non-ASCII (JFC's comment) is a spurious one: = by rule it should be limited to the name of the described language or = language part in that language or to descriptive fields (both = informative). The normative data would still be restricted to ASCII. I agree that the initial registry need not be RFC text per-se. I do note = that there is no reason that the initial registry *values* couldn't be = listed in one format (say record-jar) and the normative registry itself = be in another (such as XML). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Jon Hanna > Sent: jeudi 24 mars 2005 03:55 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Registry in record-jar format >=20 > > The resulting plain text ASCII RfC and registry could be messy, > > from the POV of a reader. One or two literal Ӓ or u+04D2 > > in a paragraph are okay, but numerous of these beasts are ugly. >=20 > It would (and I'd hope eventually will) be much nicer if the RFC rules > allowed for UTF-8 wouldn't it? >=20 > Still, I'd imagine that the said XML section would be an appendix that > anyone studying in earnest would view as XML, rather than as ASCII = source > formatted to fit the RFC line-width rules, so I don't foresee this = being a > major issue. >=20 > Regards, > Jon Hanna > Work: > Play: > Chat: >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 08:55:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13275; Thu, 24 Mar 2005 08:55:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DESuH-0003za-AA; Thu, 24 Mar 2005 09:01:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DESnG-0002FH-60; Thu, 24 Mar 2005 08:54:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DESn9-0002F7-JF for ltru@megatron.ietf.org; Thu, 24 Mar 2005 08:54:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13170 for ; Thu, 24 Mar 2005 08:54:30 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DESsp-0003ua-7X for ltru@ietf.org; Thu, 24 Mar 2005 09:00:24 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2ODsJxp021936; Thu, 24 Mar 2005 08:54:20 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 24 Mar 2005 08:54:29 -0500 Date: Thu, 24 Mar 2005 08:54:29 -0500 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Message-ID: <20050324135428.GA16394@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AB82B68@irvmbxw01.quest.com> <42425B3B.12DA@xyzzy.claranet.de> <6.1.2.0.2.20050324080839.0406a570@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050324080839.0406a570@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f JFC (Jefsey) Morfin scripsit: > I suppose that the total > amount of registrations may be in the range of 30-100.000. The number of potential tags far exceeds that already. The number of useful tags is rather less. But in any case, the whole point of RFC 3066bis is to register only tag parts (and in 99% of cases directly tracking the various ISO standards). > Plus private > registration - over the years this may amount to millions if SNHNs start > playing the way every indication show they will. What are these "indications"? > I note also that for such a standardized and hopefully stable formatted > system, the format can certainly be prototyped in using XML but a more > compact solution should to be considered. Most probably UDP supported. Nobody supposes that the tag registry must or should be retrieved in real time as the DNS is. Caching, lots of private caching, is the order of the day, and it is already going on. > I do not know why but I feel we are considering a gas refinery where a > straw would be enough to sip the wiskey in the -jar. The straw in question is the strawman argument you are making. -- Do NOT stray from the path! John Cowan --Gandalf http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 09:57:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18847; Thu, 24 Mar 2005 09:57:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETrz-0005yB-Sp; Thu, 24 Mar 2005 10:03:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETlO-0001oW-Sf; Thu, 24 Mar 2005 09:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETlN-0001oR-2u for ltru@megatron.ietf.org; Thu, 24 Mar 2005 09:56:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18700 for ; Thu, 24 Mar 2005 09:56:43 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETr4-0005uw-2v for ltru@ietf.org; Thu, 24 Mar 2005 10:02:38 -0500 Received: from lns-p19-19-idf-82-65-128-79.adsl.proxad.net ([82.65.128.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DETl9-0002B2-NR; Thu, 24 Mar 2005 06:56:41 -0800 Message-Id: <6.1.2.0.2.20050324135452.040fa950@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 24 Mar 2005 15:56:04 +0100 To: "L.Gillam" , ltru From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A2121A592E@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A2121A592E@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0709097668==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad --===============0709097668== Content-Type: multipart/alternative; boundary="=====================_31897105==.ALT" --=====================_31897105==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA18700 Content-Transfer-Encoding: quoted-printable At 12:06 24/03/2005, L.Gillam wrote: > > The load resulting from RFC 3066 bis is more substantial since there = are > > far more languages, possible subtags and resulting langtags to regist= er and > > manage >[snip] > >One might suggest that if a future ISO 639-4 provides for ISO 11179-3 /=20 >ISO 12620 (in revision) conformant collections (XML-based), and eventual= ly=20 >perhaps ISO 3166 and 15924 could go the same way, an XML-based RFC 3066 = is=20 >a composition with additional documentation, and the pages themselves fo= rm=20 >part of what one might suggest to be the semantic web. Such an approach,= =20 >based on technologies of the W3C itself, seems to be quite sensible. > >The beauty of current technologies like XSL (T and FO) and database to X= ML=20 >converters is that you can have quite a lot of formats. Profusion of=20 >formats becomes problematic, and hence the consideration of metamodels=20 >which allow for extensibility for specific purposes (see documents on=20 >www.tc37sc4.org dealing with LMF for example).=20 >Many computer programmers are more than capable of dealing with format=20 >conversions. Selecting one, or more, poses no problems as far as I can=20 >tell. I would, though, encourage the provision of interchange routines=20 >alongside the formatted data. Theoretically, as yet I see no problems. Dear L.Gillam, I think you have yourself responded to your remark: "theoretically, as ye= t=20 you see no problems". I am not talking of theory, but of reality. From wh= at=20 you write about "many computer progammers" you probably are not a=20 programer. I suspect that having no problem in selecting "one, or more,=20 poses no problem" you are not a normalizer either. But the real problem I= =20 rise is not technical but financial: who is going to pay for all these=20 things. The other point I rise is also operational, because even if=20 theoretically possible, even if paid, there is the difficulty of deployin= g=20 it. As you may know for example, IPv6 which is the top priority deploymen= t=20 for the Internet for ... 13 years. > > - there will be millions/billions of pages referencing the DTD, the u= rls, > > etc. which will lead to a IANA access 24/366. > > Some evaluations are needed about the resulting traffic and the CPU=20 > load before IANA can just discuss >Why would it? I don't look at a dictionary every time I write a word, th= en=20 >apply a spell check to that word and a grammar check to the sentence so=20 >far. Moore's law applies to the technology. Happily, the law of Moore does not necessarily apply. BTW I am no sure th= at=20 you realise that quoting the law of Moore make you lingua franca centric.= =20 In your reasoning, the law of Reed applies (from each language to each=20 language). Happily, I don't think either necessarily apply. >Around 5 exabytes of new information are estimated to be created every=20 >year. A billion pages isn't a lot =96 how many does Google currently cla= im=20 >to handle? How many will it handle in 2 years? I suggest you investigate= =20 >the number of page impressions handled by certain existing web servers=20 >technologies (Apache) and present a scientific argument about the possib= le=20 >future limitations of the technology for handling the application, rathe= r=20 >than faulting the application. Stating that DoS attacks should prevent=20 >people from undertaking these efforts is akin to putting the cart before= =20 >the horse. I am afraid I do not understand the developped argument. I just ask that=20 before specifying something real, one gets a real picture of what it=20 implies and requires. > I do have a proposal . Following your scientific argument about the=20 > possible future limitation of the technology, you approach the right=20 > parties about fixing DoS problems. If, as you say, if only 2.5% are val= id=20 > requests, based on figures from where I know not, and you work towards=20 > reducing the 97.5% by just another 2.5% you will double the capacity at= a=20 > stroke and remove the barriers to the valuable work being undertaken=20 > here. How does that sound? That sound so fine that I suggest you get elected to the ICANN board to=20 explain them that :-) Or may be that you join the WG-DNSOPS=20 http://ietf.org/html.charters/dnsop-charter.html, or may be support the CRADA=20 http://www.icann.org/general/crada-report-summary-14mar03.htm, the results of which are well documented by Karl Auerbach (may be you kno= w=20 Karl?) http://www.cavebear.com/cbblog-archives/000007.html. Actually, I do not know what prompted to respond this. And I tried to=20 respond it as friendly possible to show you that reality is not so easy t= o=20 implement as writing or debating a Draft. But at the end of the day what=20 makes a difference is feasibility. I will just ask you (this matter has n= ot=20 been discussed): what it is the calendar you think realistic for the IANA= =20 database to be operational? Milestones for the work to be achieved would = be=20 of use. Having an RFC saying this is "how it should be done", may not be=20 enough to document the langtags of 7500 languages in 192 countries, with = a=20 15 days discussion period per language, represents how many days of=20 exchanges on ietf-languages@alvestrand.no ? So when will this WG plans the programers, users and other standardizers = be=20 reasonably able to use the IANA database in real operations? jfc >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru --=====================_31897105==.ALT Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA18700 Content-Transfer-Encoding: quoted-printable At 12:06 24/03/2005, L.Gillam wrote:
> The load resulting from RFC 3066 bis is more substantial since there are
> far more languages, possible subtags and resulting langtags to register and
> manage
[snip]

One might suggest that if a future ISO 639-4 provides for ISO 11179-3 / ISO 12620 (in revision) conformant collections (XML-based), and eventually perhaps ISO 3166 and 15924 could go the same way, an XML-based RFC 3066 is a composition with additional documentation, and the pages themselves form part of what one might suggest to be the semantic web. Such an approach, based on technologies of the W3C itself, seems to be quite sensible.

The beauty of current technologies like XSL (T and FO) and database to XML converters is that you can have quite a lot of formats. Profusion of formats becomes problematic, and hence the consideration of metamodels which allow for extensibility for specific purposes (see documents on www.tc37sc4.org dealing with LMF for example). Many computer programmers are more than capable of dealing with format conversions. Selecting one, or more, poses no problems as far as I can tell. I would, though, encourage the provision of interchange routines alongside the formatted data. Theoretically, as yet I see no problems.

Dear L.Gillam,
I think you have yourself responded to your remark: "theoretically, as yet you see no problems". I am not talking of theory, but of reality. From what you write about "many computer progammers" you probably are not a programer. I suspect that having no problem in selecting "one, or more, poses no problem" you are not a normalizer either. But the real problem I rise is not technical but financial: who is going to pay for all these things. The other point I rise is also operational, because even if theoretically possible, even if paid, there is the difficulty of deploying it. As you may know for example, IPv6 which is the top priority deployment for the Internet for ... 13 years.

> - there will be millions/billions of pages referencing the DTD, the urls,
> etc. which will lead to a IANA access 24/366.
> Some evaluations are needed about the resulting traffic and the CPU load before IANA can just discuss
Why would it? I don=92t look at a dictionary every time I write a word, then apply a spell check to that word and a grammar check to the sentence so far. Moore=92s law applies to the technology.

Happily, the law of Moore does not necessarily apply. BTW I am no sure that you realise that quoting the law of Moore make you lingua franca centric. In your reasoning, the law of Reed applies (from each language to each language). Happily, I don't think either necessarily apply.

Around 5 exabytes of new information are estimated to be created every year. A billion pages isn=92t a lot =96 how many does Google currently claim to handle? How many will it handle in 2 years? I suggest you investigate the number of page impressions handled by certain existing web servers technologies (Apache) and present a scientific argument about the possible future limitations of the technology for handling the application, rather than faulting the application. Stating that DoS attacks should prevent people from undertaking these efforts is akin to putting the cart before the horse.

I am afraid I do not understand the developped argument. I just ask that before specifying something real, one gets a real picture of what it implies and requires.

 I do have a proposal . Following your scientific argument about the possible future limitation of the technology, you approach the right parties about fixing DoS problems. If, as you say, if only 2.5% are valid requests, based on figures from where I know not, and you work towards reducing the 97.5% by just another 2.5% you will double the capacity at a stroke and remove the barriers to the valuable work being undertaken here. How does that sound?

That sound so fine that I suggest you get elected to the ICANN board to explain them that :-)
Or may be that you join the WG-DNSOPS http://ietf.org/html.charters/dnsop-charter.html,
or may be support the CRADA http://www.icann.org/general/crada-report-summary-14m= ar03.htm,
the results of which are well documented by Karl Auerbach (may be you know Karl?)
http://www.cavebear.com/cbblog-archives/000007.html.
Actually, I do not know what prompted to respond this. And I tried to respond it as friendly possible to show you that reality is not so easy to implement as writing or debating a Draft. But at the end of the day what makes a difference is feasibility. I will just ask you (this matter has not been discussed): what it is the calendar you think realistic for the IANA database to be operational? Milestones for the work to be achieved would be of use. Having an RFC saying this is "how it should be done", may not be enough to document the langtags of 7500 languages in 192 countries, with a 15 days discussion period per language, represents how many days of exchanges on ietf-languages@alvestrand.no ?

So when will this WG plans the programers, users and other standardizers be reasonably able to use the IANA database in real operations?
jfc



__________________________= _____________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=====================_31897105==.ALT-- --===============0709097668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0709097668==-- From ltru-bounces@ietf.org Thu Mar 24 10:00:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19044; Thu, 24 Mar 2005 10:00:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETuL-000619-9i; Thu, 24 Mar 2005 10:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETlU-0001pU-AV; Thu, 24 Mar 2005 09:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETlS-0001ow-CJ for ltru@megatron.ietf.org; Thu, 24 Mar 2005 09:56:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18716 for ; Thu, 24 Mar 2005 09:56:48 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETr8-0005v9-JO for ltru@ietf.org; Thu, 24 Mar 2005 10:02:43 -0500 Received: from lns-p19-19-idf-82-65-128-79.adsl.proxad.net ([82.65.128.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DETlO-0002B2-SB; Thu, 24 Mar 2005 06:56:47 -0800 Message-Id: <6.1.2.0.2.20050324145501.040b4eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 24 Mar 2005 15:25:12 +0100 To: "Addison Phillips" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Registry in record-jar format In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AB82E84@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AB82E84@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 14:32 24/03/2005, Addison Phillips wrote: >The question about lots of non-ASCII (JFC's comment) is a spurious one: by >rule it should be limited to the name of the described language or >language part in that language or to descriptive fields (both >informative). The normative data would still be restricted to ASCII. I am always happy to read constructive comments. Obviously ASCII fits the ASCII Internet. The question is will it fit the Multilingual Internet we all work on? I am just interested to know if what you consider spurious is "non-ASCII" or "lots". And if you think user's descriptive fields MUST or SHOULD be in ASCII (obviously only a MUST would go your way). Also, when you speak of normative data, do you speak of normative codes and numbers or of all the data in the norm, i.e. including French texts, (and happily sometimes, for the language norms Chinese, Russian, Arabic, etc. will be supported - again only a question of budget and international agreements we do not control)? ASCII will not even fully support French which is a normative language. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 10:01:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19172; Thu, 24 Mar 2005 10:01:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETvJ-00064W-CL; Thu, 24 Mar 2005 10:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETlW-0001pm-FC; Thu, 24 Mar 2005 09:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETlU-0001pY-QF for ltru@megatron.ietf.org; Thu, 24 Mar 2005 09:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18722 for ; Thu, 24 Mar 2005 09:56:51 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETrB-0005vJ-NQ for ltru@ietf.org; Thu, 24 Mar 2005 10:02:46 -0500 Received: from lns-p19-19-idf-82-65-128-79.adsl.proxad.net ([82.65.128.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DETlR-0002B2-Ty; Thu, 24 Mar 2005 06:56:51 -0800 Message-Id: <6.1.2.0.2.20050324152634.040b78a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 24 Mar 2005 15:50:13 +0100 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] In-Reply-To: <20050324135428.GA16394@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AB82B68@irvmbxw01.quest.com> <42425B3B.12DA@xyzzy.claranet.de> <6.1.2.0.2.20050324080839.0406a570@mail.jefsey.com> <20050324135428.GA16394@skunk.reutershealth.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 14:54 24/03/2005, John Cowan wrote: >JFC (Jefsey) Morfin scripsit: > > I suppose that the total > > amount of registrations may be in the range of 30-100.000. > >The number of potential tags far exceeds that already. The number of >useful tags is rather less. I rise a question, I do not dispute anything. Can you quantify/qualify what is useful? >But in any case, the whole point of >RFC 3066bis is to register only tag parts (and in 99% of cases directly >tracking the various ISO standards). So, what is the need for any registration? > > Plus private > > registration - over the years this may amount to millions if SNHNs start > > playing the way every indication show they will. > >What are these "indications" You are welcome to work on this yourself. You will certainly better document them than I could. > > I note also that for such a standardized and hopefully stable formatted > > system, the format can certainly be prototyped in using XML but a more > > compact solution should to be considered. Most probably UDP supported. > >Nobody supposes that the tag registry must or should be retrieved in >real time as the DNS is. Caching, lots of private caching, is the >order of the day, and it is already going on. I am extremely interested if you could document these IANA caching mechanisms. Distributed IANA is precisely what we (AFRAC) work on as a protoype Context Reference Center. > > I do not know why but I feel we are considering a gas refinery where a > > straw would be enough to sip the wiskey in the -jar. > >The straw in question is the strawman argument you are making. Oh! no problem: I am then a strawman for a few 30 years :-) jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 10:02:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19390; Thu, 24 Mar 2005 10:02:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETx0-00068Y-0G; Thu, 24 Mar 2005 10:08:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETpZ-0002GE-9n; Thu, 24 Mar 2005 10:01:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETpY-0002G9-4L for ltru@megatron.ietf.org; Thu, 24 Mar 2005 10:01:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19163 for ; Thu, 24 Mar 2005 10:01:02 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETvE-000646-9L for ltru@ietf.org; Thu, 24 Mar 2005 10:06:57 -0500 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 24 Mar 2005 15:00:44 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IDV000NB314U2@eupig1.dtc.lon.ime.reuters.com>; Thu, 24 Mar 2005 15:00:40 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 24 Mar 2005 15:00:44 +0000 Date: Thu, 24 Mar 2005 15:00:05 +0000 From: Misha Wolf Subject: RE: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] To: "JFC (Jefsey) Morfin" MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Thread-Index: AcUwVepNGWByQNCXQiynE1tduVSWcwAK+TSg content-class: urn:content-classes:message X-OriginalArrivalTime: 24 Mar 2005 15:00:44.0416 (UTC) FILETIME=[40FD7000:01C53082] X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin: =20 Let remember that we have 7500 languages and=20 240 countries (rough figures), I suppose that the total amount of=20 registrations may be in the range of 30-100.000. Plus private registration=20 - over the years this may amount to millions if SNHNs start playing the way=20 every indication show they will. I'm convinced that you live on a different planet from the rest of us. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 10:44:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25091; Thu, 24 Mar 2005 10:44:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUbZ-0007Xr-SS; Thu, 24 Mar 2005 10:50:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUT3-0008Bn-Gn; Thu, 24 Mar 2005 10:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUT2-0008Az-K6 for ltru@megatron.ietf.org; Thu, 24 Mar 2005 10:41:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24887 for ; Thu, 24 Mar 2005 10:41:50 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUYj-0007T8-Ba for ltru@ietf.org; Thu, 24 Mar 2005 10:47:46 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 07:41:40 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 24 Mar 2005 07:41:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Registry in record-jar format Date: Thu, 24 Mar 2005 07:41:42 -0800 Message-ID: Thread-Topic: [Ltru] Re: Registry in record-jar format thread-index: AcUwgkOD7NP3u4TNRC6A7jbmVDiYiQABRWdA From: "Peter Constable" To: X-OriginalArrivalTime: 24 Mar 2005 15:41:40.0635 (UTC) FILETIME=[F902B6B0:01C53087] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of JFC (Jefsey) Morfin > I am just interested to know if what you consider spurious is "non-ASCII" > or "lots". And if you think user's descriptive fields MUST or SHOULD be in > ASCII (obviously only a MUST would go your way). Also, when you speak of > normative data, do you speak of normative codes and numbers or of all the > data in the norm, i.e. including French texts, (and happily sometimes, for > the language norms Chinese, Russian, Arabic, etc. will be supported - > again > only a question of budget and international agreements we do not control)? Please do NOT consider adding names of languages, scripts, regions, etc. in multiple languages (the Chinese name for "Devanagari" etc.) to the registry. This should not be a localization-data repository. The last thing we need is to have the registry data file bloat to some huge size. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 10:57:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26367; Thu, 24 Mar 2005 10:57:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUnx-00081l-GV; Thu, 24 Mar 2005 11:03:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUgR-0001p7-9L; Thu, 24 Mar 2005 10:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUgQ-0001p2-3f for ltru@megatron.ietf.org; Thu, 24 Mar 2005 10:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26234 for ; Thu, 24 Mar 2005 10:55:40 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUm6-0007xL-SU for ltru@ietf.org; Thu, 24 Mar 2005 11:01:36 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 07:55:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Registry in record-jar format Date: Thu, 24 Mar 2005 07:55:28 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82F4D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUwgkOD7NP3u4TNRC6A7jbmVDiYiQABRWdAAABSWoA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 24 Mar 2005 15:55:29.0022 (UTC) FILETIME=[E6C489E0:01C53089] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable For the record, the suggestion was to replace or augment the current: 8. Native name of the language or variation (transcribed into ASCII): ... with the native name of the language or variation. In some cases = there may be several of these (witness zh-hakka, although one suspects = these are all represented by the same or at least a smaller set of = ideographs). There are also some regions that have naming problems in = ASCII (ISO 3166 shows the =C5land Islands surrounded by a sea of ASCII). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: jeudi 24 mars 2005 07:42 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Registry in record-jar format >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of JFC (Jefsey) Morfin >=20 > > I am just interested to know if what you consider spurious is > "non-ASCII" > > or "lots". And if you think user's descriptive fields MUST or SHOULD > be in > > ASCII (obviously only a MUST would go your way). Also, when you = speak > of > > normative data, do you speak of normative codes and numbers or of = all > the > > data in the norm, i.e. including French texts, (and happily = sometimes, > for > > the language norms Chinese, Russian, Arabic, etc. will be supported = - > > again > > only a question of budget and international agreements we do not > control)? >=20 > Please do NOT consider adding names of languages, scripts, regions, = etc. > in multiple languages (the Chinese name for "Devanagari" etc.) to the > registry. This should not be a localization-data repository. The last > thing we need is to have the registry data file bloat to some huge = size. >=20 >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 11:38:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01259; Thu, 24 Mar 2005 11:38:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVRD-000134-VA; Thu, 24 Mar 2005 11:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVK9-0008MJ-6C; Thu, 24 Mar 2005 11:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVK8-0008MC-9F for ltru@megatron.ietf.org; Thu, 24 Mar 2005 11:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01064 for ; Thu, 24 Mar 2005 11:36:41 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVPq-00010V-9P for ltru@ietf.org; Thu, 24 Mar 2005 11:42:38 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 08:36:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Registry in record-jar format Date: Thu, 24 Mar 2005 08:36:31 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AB82FD5@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUwgbTZGlHIkapdSgm8qobKtaTHwgACDi7g From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , X-OriginalArrivalTime: 24 Mar 2005 16:36:32.0553 (UTC) FILETIME=[A3258990:01C5308F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Normative data in 3066bis would be the subtags, subtag type identifiers, = ISO 8601 dates, canonical mappings, and recommended prefixes. = Non-normative fields would be descriptions and notes. These normative fields are restricted to ASCII because language tags are = or because ISO 8601 says so. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: jeudi 24 mars 2005 06:25 > To: Addison Phillips; ltru@ietf.org > Subject: RE: [Ltru] Re: Registry in record-jar format >=20 > At 14:32 24/03/2005, Addison Phillips wrote: > >The question about lots of non-ASCII (JFC's comment) is a spurious = one: > by > >rule it should be limited to the name of the described language or > >language part in that language or to descriptive fields (both > >informative). The normative data would still be restricted to ASCII. >=20 > I am always happy to read constructive comments. Obviously ASCII fits = the > ASCII Internet. The question is will it fit the Multilingual Internet = we > all work on? >=20 > I am just interested to know if what you consider spurious is = "non-ASCII" > or "lots". And if you think user's descriptive fields MUST or SHOULD = be in > ASCII (obviously only a MUST would go your way). Also, when you speak = of > normative data, do you speak of normative codes and numbers or of all = the > data in the norm, i.e. including French texts, (and happily sometimes, = for > the language norms Chinese, Russian, Arabic, etc. will be supported - > again > only a question of budget and international agreements we do not = control)? > ASCII will not even fully support French which is a normative = language. >=20 > jfc >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 11:42:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01714; Thu, 24 Mar 2005 11:42:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVVl-0001Dk-T3; Thu, 24 Mar 2005 11:48:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVOF-0000R6-Ty; Thu, 24 Mar 2005 11:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVOE-0000R1-QC for ltru@megatron.ietf.org; Thu, 24 Mar 2005 11:40:58 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01519 for ; Thu, 24 Mar 2005 11:40:56 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050324164026.INOK2192.mta9.adelphia.net@DEWELL> for ; Thu, 24 Mar 2005 11:40:26 -0500 Message-ID: <004f01c53090$2a710140$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050324094233.QKSF2124.mta7.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 08:40:17 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Also, before that I am not sure ietf-languages can cope with that > workload (with a 15 days debate, etc.). Let remember that we have 7500 > languages and 240 countries (rough figures), I suppose that the total > amount of registrations may be in the range of 30-100.000. This has been explained to Jefsey already, more than once, on the ietf-languages list. But for those who may be hearing this for the first time: 1. RFC 3066bis, like RFC 3066 and RFC 1766 before it, has what is called a "generative" mechanism. Language tags are generated from the combination of a primary language subtag and an optional region (country) subtag. That means if there are N language subtags and M region subtags, the number of possible tags based on these subtags is (N x M), but the number of things that need to be registered is only (N + M). So there is no need to register 100,000 of anything. RFC 3066bis introduces more types of subtags, but the arithmetic is still the same. 2. In the initial registry, subtags derived from code elements in ISO standards do not need to be "registered" one by one, using the same lengthy review process that is now needed to register special combinations under RFC 3066. They are included in the registry by acclamation, as it were. All we have to do -- we, this group, not IANA or ietf-languages -- is determine the rules for which code elements are admitted and which are not. So we don't even have to register (N + M) items as above. 3. RFC 3066bis in its present form does not support ISO 639-3 with its 7500+ additional languages. That is only a draft at this stage, not an approved standard, as we JUST got done saying. So any arithmetic involving 7500+ languages is misleading on its face. > Plus private registration - over the years this may amount to millions > if SNHNs start playing the way every indication show they will. The > first question about this is: who will pay? Private-use tags and subtags are private-use. They are not included in the registry. If anyone wants to create a private-use tag or subtag, they bear any costs of doing so. How could it be otherwise? > - there will be millions/billions of pages referencing the DTD, the > urls, etc. which will lead to a IANA access 24/366. Some evaluations > are needed about the resulting traffic and the CPU load before IANA > can just discuss it. I am not sure, but we are replicating bigger than > the DNS root here. You are not sure. That much is true. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 12:58:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09601; Thu, 24 Mar 2005 12:58:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEWgq-0003k4-Kr; Thu, 24 Mar 2005 13:04:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEWaP-00033X-5p; Thu, 24 Mar 2005 12:57:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEWaN-00033P-Hp for ltru@megatron.ietf.org; Thu, 24 Mar 2005 12:57:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09539 for ; Thu, 24 Mar 2005 12:57:32 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEWg1-0003hL-Pe for ltru@ietf.org; Thu, 24 Mar 2005 13:03:30 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2OHvLgM012328 for ; Thu, 24 Mar 2005 12:57:21 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2OHvL32038800 for ; Thu, 24 Mar 2005 12:57:21 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2OHvLRB001793 for ; Thu, 24 Mar 2005 12:57:21 -0500 Received: from markdavis (sig-9-48-119-153.mts.ibm.com [9.48.119.153]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2OHvKBR001733; Thu, 24 Mar 2005 12:57:20 -0500 Message-ID: <0b4401c5309a$eca9e060$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Peter Constable" , References: <634978A7DF025A40BFEF33EB191E13BC0AB82F4D@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Registry in record-jar format Date: Thu, 24 Mar 2005 09:57:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j2OHvLgM012328 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable If we did that, it should be an optional, additional field. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Peter Constable" ; Sent: Thursday, March 24, 2005 07:55 Subject: RE: [Ltru] Re: Registry in record-jar format For the record, the suggestion was to replace or augment the current: 8. Native name of the language or variation (transcribed into ASCII): ... with the native name of the language or variation. In some cases ther= e may be several of these (witness zh-hakka, although one suspects these ar= e all represented by the same or at least a smaller set of ideographs). The= re are also some regions that have naming problems in ASCII (ISO 3166 shows = the =C3=85land Islands surrounded by a sea of ASCII). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: jeudi 24 mars 2005 07:42 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Registry in record-jar format > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] > On > > Behalf Of JFC (Jefsey) Morfin > > > I am just interested to know if what you consider spurious is > "non-ASCII" > > or "lots". And if you think user's descriptive fields MUST or SHOULD > be in > > ASCII (obviously only a MUST would go your way). Also, when you speak > of > > normative data, do you speak of normative codes and numbers or of all > the > > data in the norm, i.e. including French texts, (and happily sometimes= , > for > > the language norms Chinese, Russian, Arabic, etc. will be supported - > > again > > only a question of budget and international agreements we do not > control)? > > Please do NOT consider adding names of languages, scripts, regions, etc. > in multiple languages (the Chinese name for "Devanagari" etc.) to the > registry. This should not be a localization-data repository. The last > thing we need is to have the registry data file bloat to some huge size. > > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 13:48:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14798; Thu, 24 Mar 2005 13:48:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEXT8-0005SP-Jd; Thu, 24 Mar 2005 13:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEXMI-0001SP-6z; Thu, 24 Mar 2005 13:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEXMH-0001SC-5B for ltru@megatron.ietf.org; Thu, 24 Mar 2005 13:47:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14665 for ; Thu, 24 Mar 2005 13:47:02 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEXRz-0005Qe-Gb for ltru@ietf.org; Thu, 24 Mar 2005 13:53:00 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 10:47:14 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 10:46:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Registry in record-jar format Date: Thu, 24 Mar 2005 10:46:56 -0800 Message-ID: Thread-Topic: [Ltru] Re: Registry in record-jar format thread-index: AcUwgkOD7NP3u4TNRC6A7jbmVDiYiQABRWdAAABSWoAABi7owA== From: "Peter Constable" To: X-OriginalArrivalTime: 24 Mar 2005 18:46:54.0226 (UTC) FILETIME=[D93A1F20:01C530A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable I wrote: > > Please do NOT consider adding names of languages, scripts, regions, etc. > > in multiple languages (the Chinese name for "Devanagari" etc.) to the > > registry. This should not be a localization-data repository. The last > > thing we need is to have the registry data file bloat to some huge size. to which Addison replied: > For the record, the suggestion was to replace or augment the current: >=20 > 8. Native name of the language or variation (transcribed into ASCII): >=20 > ... with the native name of the language or variation. I was responding to our not-always-helpful contributor JFC, who, because he believes we should be working toward "multilingualization" rather than "internationalization" (in quotes because I cannot guarantee that he uses that term to mean what anybody else means), appears very definitely to be wanting to be able to document the names of languages as expressed in every other language. He replied off-list to my comment above saying so. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 13:54:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15211; Thu, 24 Mar 2005 13:54:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEXYj-0005bV-JI; Thu, 24 Mar 2005 13:59:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEXPn-0001pH-W3; Thu, 24 Mar 2005 13:50:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEXPm-0001pC-PE for ltru@megatron.ietf.org; Thu, 24 Mar 2005 13:50:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14890 for ; Thu, 24 Mar 2005 13:50:39 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEXVV-0005WU-4s for ltru@ietf.org; Thu, 24 Mar 2005 13:56:38 -0500 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 24 Mar 2005 18:50:27 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IDV0086TDO0MS@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 24 Mar 2005 18:50:24 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 24 Mar 2005 18:50:27 +0000 Date: Thu, 24 Mar 2005 18:50:27 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: Registry in record-jar format To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUwgkOD7NP3u4TNRC6A7jbmVDiYiQABRWdAAABSWoAABi7owAAAOr+A content-class: urn:content-classes:message X-OriginalArrivalTime: 24 Mar 2005 18:50:27.0160 (UTC) FILETIME=[58254580:01C530A2] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable I suggest we=20 -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of=20 Sent: 24 March 2005 18:47 To: ltru@ietf.org Subject: RE: [Ltru] Re: Registry in record-jar format I wrote: > > Please do NOT consider adding names of languages, scripts, regions, etc. > > in multiple languages (the Chinese name for "Devanagari" etc.) to the > > registry. This should not be a localization-data repository. The last > > thing we need is to have the registry data file bloat to some huge size. to which Addison replied: > For the record, the suggestion was to replace or augment the current: >=20 > 8. Native name of the language or variation (transcribed into ASCII): >=20 > ... with the native name of the language or variation. I was responding to our not-always-helpful contributor JFC, who, because he believes we should be working toward "multilingualization" rather than "internationalization" (in quotes because I cannot guarantee that he uses that term to mean what anybody else means), appears very definitely to be wanting to be able to document the names of languages as expressed in every other language. He replied off-list to my comment above saying so. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 13:56:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15449; Thu, 24 Mar 2005 13:56:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEXag-0005hg-E0; Thu, 24 Mar 2005 14:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEXS7-0001x9-C7; Thu, 24 Mar 2005 13:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEXS6-0001x0-8B for ltru@megatron.ietf.org; Thu, 24 Mar 2005 13:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15073 for ; Thu, 24 Mar 2005 13:53:03 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEXXp-0005Zx-88 for ltru@ietf.org; Thu, 24 Mar 2005 13:59:01 -0500 Received: from uknsprd1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 24 Mar 2005 18:52:53 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IDV0048KDS59L@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 24 Mar 2005 18:52:53 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 24 Mar 2005 18:52:52 +0000 Date: Thu, 24 Mar 2005 18:52:52 +0000 From: Misha Wolf Subject: RE: [Ltru] OT: Registry in record-jar format To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF780360F523@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] OT: Registry in record-jar format Thread-Index: AcUwgkOD7NP3u4TNRC6A7jbmVDiYiQABRWdAAABSWoAABi7owAAAQRIg content-class: urn:content-classes:message X-OriginalArrivalTime: 24 Mar 2005 18:52:53.0082 (UTC) FILETIME=[AF1F33A0:01C530A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable [apologies for the last mail .. finger trouble] Peter Constable wrote: I was responding to our not-always-helpful contributor JFC, who, because he believes we should be working toward "multilingualization" rather than "internationalization" (in quotes because I cannot guarantee that he uses that term to mean what anybody else means), appears very definitely to be wanting to be able to document the names of languages as expressed in every other language. He replied off-list to my comment above saying so. Let's club together for a Web page where JFC can translate the names of millions (!) of languages into millions of languages. That should keep him off our backs for a week or two. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 21:14:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05764; Thu, 24 Mar 2005 21:14:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEeQZ-0004Xn-W2; Thu, 24 Mar 2005 21:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEeK9-0002Hr-D2; Thu, 24 Mar 2005 21:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEeK7-0002Hh-BN for ltru@megatron.ietf.org; Thu, 24 Mar 2005 21:13:19 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05630 for ; Thu, 24 Mar 2005 21:13:16 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEeJn-0000uj-IN for ltru@lists.ietf.org; Fri, 25 Mar 2005 03:13:01 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 03:12:59 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 03:12:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 03:11:48 +0100 Organization: Lines: 20 Message-ID: <42437364.746D@xyzzy.claranet.de> References: <42425B3B.12DA@xyzzy.claranet.de> <046F43A8D79C794FA4733814869CDF0749C8EE@dul1wnexmb01.vcorp.ad.vrsn.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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: >> Does _any_ IANA registry use XML ? > Yes -- take a look at these: > http://www.iana.org/assignments/xml-registry-index.html In that case some of us would probably love XML, and others (like me) still prefer record-jar or another 2822-style. For the latter it's also simple to split it into A..Z IANA pages with 7000+ languages. The DTD or schema could be an appendix in the registry draft. For Unicode-tags (language in their native script) it's better to translate XML into record-jar format, the other direction would be a pain. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 22:19:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12149; Thu, 24 Mar 2005 22:19:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEfRn-0006ZP-G3; Thu, 24 Mar 2005 22:25:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEfKn-0000tq-AO; Thu, 24 Mar 2005 22:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEfKm-0000tl-34 for ltru@megatron.ietf.org; Thu, 24 Mar 2005 22:18:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12105 for ; Thu, 24 Mar 2005 22:18:00 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEfQW-0006Vn-S5 for ltru@ietf.org; Thu, 24 Mar 2005 22:24:02 -0500 Received: from lns-p19-19-idf-82-65-128-79.adsl.proxad.net ([82.65.128.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DEfKY-0006Eb-1l; Thu, 24 Mar 2005 19:17:51 -0800 Message-Id: <6.1.2.0.2.20050325032516.0482ba00@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 25 Mar 2005 03:29:52 +0100 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format In-Reply-To: <42437364.746D@xyzzy.claranet.de> References: <42425B3B.12DA@xyzzy.claranet.de> <046F43A8D79C794FA4733814869CDF0749C8EE@dul1wnexmb01.vcorp.ad.vrsn.com> <42437364.746D@xyzzy.claranet.de> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 03:11 25/03/2005, Frank Ellermann wrote: >Scott Hollenbeck wrote: > > >> Does _any_ IANA registry use XML ? > > Yes -- take a look at these: > > http://www.iana.org/assignments/xml-registry-index.html > >In that case some of us would probably love XML, and others >(like me) still prefer record-jar or another 2822-style. Please read RFC 3688 limitations including Part 6 on IANA considerations. As one of those who will pay for that (ccTLDs) and will pay for mirrors (AFRAC), I thank those who have figures in mind to address my pending questions. I note that if the average load is one access per year per Internet user, the load of is 25 access per second. With root system ratio (which has been probably grown over time, but gives good examples of users behaviors) this represents 1000 accesses per seconds, hence picks (off DoS) of 10.000 and average piks of 3.000 (my guesstimate from comparable type of site - every correction/experience welcome). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 22:21:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12351; Thu, 24 Mar 2005 22:21:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEfTo-0006e4-Lf; Thu, 24 Mar 2005 22:27:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEfNv-00017y-EU; Thu, 24 Mar 2005 22:21:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEfNu-00017t-6i for ltru@megatron.ietf.org; Thu, 24 Mar 2005 22:21:18 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12338 for ; Thu, 24 Mar 2005 22:21:15 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEfNe-0005Uy-Tc for ltru@lists.ietf.org; Fri, 25 Mar 2005 04:21:02 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 04:21:02 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 04:21:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 04:10:46 +0100 Organization: Lines: 36 Message-ID: <42438136.537A@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AB82E84@irvmbxw01.quest.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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Did I write that? I cannot believe I'm defending an ASCII > solution for this... There's nothing wrong with ASCII, it works everywhere. > XML uses Unicode by definition, although we might choose to > restrict the registry file's actual encoding to ASCII for > similar reasons. Let's say that we don't want any "language name in its native script(s)" at the moment for 3066bis, it should be possible to add it later. IIRC Bruce wanted the official French names in the relevant standards, but IMHO that leads nowhere - national organizations are free to create their own official translations of the registry. > there is no reason that the initial registry *values* > couldn't be listed in one format (say record-jar) and the > normative registry itself be in another (such as XML). Both formats are important, for 3066bis we don't need to decide which form is "normative" and which is "derived", if we stick to ASCII. Only for more Unicode points XML is probably better. Doug now has scripts to create the format with six columns, on his system both XML and record-jar would be "derived" formats. I don't see a problem with this, let's discuss potential DTDs. Later you could add a DTD as appendix, and use the record-jar field names in the text, if that's the shortest and simplest way to define the semantics. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 23:09:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16442; Thu, 24 Mar 2005 23:09:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEgEF-00081h-CA; Thu, 24 Mar 2005 23:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEg7H-0005eC-3V; Thu, 24 Mar 2005 23:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEg77-0005e6-MW for ltru@megatron.ietf.org; Thu, 24 Mar 2005 23:08:01 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16411 for ; Thu, 24 Mar 2005 23:07:58 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEg6p-0000cB-2D for ltru@lists.ietf.org; Fri, 25 Mar 2005 05:07:43 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 05:07:43 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 05:07:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 05:03:50 +0100 Organization: Lines: 38 Message-ID: <42438DA6.30C8@xyzzy.claranet.de> References: <42425B3B.12DA@xyzzy.claranet.de> <046F43A8D79C794FA4733814869CDF0749C8EE@dul1wnexmb01.vcorp.ad.vrsn.com> <42437364.746D@xyzzy.claranet.de> <6.1.2.0.2.20050325032516.0482ba00@mail.jefsey.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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Please read RFC 3688 limitations including Part 6 on IANA > considerations. Thanks, the last time I looked into this was when MARID tried to get rid of some obscure XML-over-DNS ideas. In the case here I don't see a problem, the worst I'll ever try is to use the W3C validator with the registry, because Addison said that one advantage of XML is validation. For a DTD with a SYSTEM identifier that works, I've tested it with a SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" For a FPI I'd know where I could ask the W3C validator team to add it to their collection. "Registry validation" is a very special case, nothing we need to worry about. A DTD is not good enough to handle the finer points of the syntax like number of characters per subtag, and the W3C validator is not tuned to handle XML, but these are all Addison's problems. I'm happy with ABNF and record-jar / 2822. > As one of those who will pay for that (ccTLDs) and will pay > for mirrors (AFRAC), I thank those who have figures in mind > to address my pending questions. How you mirror IANA is your problem, but if you can handle the about 1 MB in 50,000 lines of a future 3066ter registry, then you can also handle about 2 MB in an equivalent XML format. You're IMHO not forced to squeeze this in a mobile device, and you're not limited by display resolutions for Unicode fonts. Or maybe you are, but then the size of a language tag registry is not your most pressing problem. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 24 23:41:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19151; Thu, 24 Mar 2005 23:41:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEgjO-0000Tc-No; Thu, 24 Mar 2005 23:47:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEgdV-00009C-I9; Thu, 24 Mar 2005 23:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEgdT-00008L-Q9 for ltru@megatron.ietf.org; Thu, 24 Mar 2005 23:41:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19144 for ; Thu, 24 Mar 2005 23:41:25 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEgjI-0000TG-6U for ltru@ietf.org; Thu, 24 Mar 2005 23:47:28 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 20:41:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Registry in record-jar format Date: Thu, 24 Mar 2005 20:41:16 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC29BE8@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUw8Gkc04OP0eiHS3SY1Z+IHBz2dgAA1vbg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 25 Mar 2005 04:41:17.0386 (UTC) FILETIME=[E2207AA0:01C530F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Well, one doesn't want to claim too much for any specific format. = Validation of the registry's structure would be limited by the limits of = what a DTD can reasonably do. I like XML because there are lots of tools for working with it and doing = useful things, but frankly you're correct that the Ur-format really = doesn't matter. All of these formats are essentially just permutations = of the same thing (absent that XML can do some structural backflips with = multiple entries that are harder in record-jar format). Size is also not a real limiting factor, especially once one factors in = the ability to transform from one format to another. I must admit that I think it a good idea, though, to choose one format = for the normative registry and make the others an informative mirror of = that. That answers the "where do I look" problem. I noticed yesterday, = for example, that IANA's new format web page doesn't link properly to = the language tag registration forms (the URI is mangled in the href), = making certain information difficult to access. If there is more than = one normative format and the registry copies ever get out of sync for = some (human error?) reason, it is useful to know which registry version = one is supposed to look at. Otherwise, despite earlier arguments, the format isn't that important to = me. Finishing the work is far more so. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 24 mars 2005 20:04 > To: ltru@ietf.org > Subject: [Ltru] Re: Registry in record-jar format >=20 > JFC (Jefsey) Morfin wrote: >=20 > > Please read RFC 3688 limitations including Part 6 on IANA > > considerations. >=20 > Thanks, the last time I looked into this was when MARID tried > to get rid of some obscure XML-over-DNS ideas. In the case > here I don't see a problem, the worst I'll ever try is to use > the W3C validator with the registry, because Addison said that > one advantage of XML is validation. >=20 > For a DTD with a SYSTEM identifier that works, I've tested it > with a SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" >=20 > For a FPI I'd know where I could ask the W3C validator team to > add it to their collection. >=20 > "Registry validation" is a very special case, nothing we need > to worry about. A DTD is not good enough to handle the finer > points of the syntax like number of characters per subtag, and > the W3C validator is not tuned to handle XML, but these are all > Addison's problems. I'm happy with ABNF and record-jar / 2822. >=20 > > As one of those who will pay for that (ccTLDs) and will pay > > for mirrors (AFRAC), I thank those who have figures in mind > > to address my pending questions. >=20 > How you mirror IANA is your problem, but if you can handle the > about 1 MB in 50,000 lines of a future 3066ter registry, then > you can also handle about 2 MB in an equivalent XML format. >=20 > You're IMHO not forced to squeeze this in a mobile device, and > you're not limited by display resolutions for Unicode fonts. > Or maybe you are, but then the size of a language tag registry > is not your most pressing problem. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 01:32:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26473; Fri, 25 Mar 2005 01:32:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEiTD-0003aa-33; Fri, 25 Mar 2005 01:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEhr2-0007As-DS; Fri, 25 Mar 2005 00:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEhr0-0007Ak-UB for ltru@megatron.ietf.org; Fri, 25 Mar 2005 00:59:31 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24543 for ; Fri, 25 Mar 2005 00:59:27 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325055859.IRHK5402.mta11.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 00:58:59 -0500 Message-ID: <008901c530ff$ba1d4000$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050321013121.MOXB2124.mta7.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 21:58:53 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Debbie Garside wrote: > RFC 3066bis seems intent on making > tags as small as possible (am I wrong? Just my perception) I do think this is overstating things a bit. There's a point of view that tags should be detailed, for accuracy, and another point of view that tags should be general, for compatibility and to prevent searches from missing them. I don't think either side is 100% right or wrong. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 01:32:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26498; Fri, 25 Mar 2005 01:32:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEiTF-0003aj-MW; Fri, 25 Mar 2005 01:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiGd-000158-By; Fri, 25 Mar 2005 01:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiGY-000150-ID for ltru@megatron.ietf.org; Fri, 25 Mar 2005 01:25:54 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25931 for ; Fri, 25 Mar 2005 01:25:53 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325062523.JFHW5402.mta11.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 01:25:23 -0500 Message-ID: <009701c53103$6c2eda80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050323071700.BRCV2128.mta1.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 22:25:21 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Great, thanks, but we still need the normal RfC (2)822 folding > for a proper I-D e.g. in line 4068 (107 characters). The idea > is to replace a space by : Good idea. I wasn't sure which approach to use for line continuation. I've gone ahead and adopted this one, without the tab, for the two lines that extended beyond 80 characters (language 'cu' and grandfathered 'zh-min-nan'). This has now been uploaded. >> This has no official sanction or consensus > > As soon as it's an I-D it's an "official draft registry". We're not at that point yet. There's been talk of making the registry into an I-D, but I thought the most recent idea was to publish the rules for initially populating it instead. (BTW, nobody has commented yet on my recipe for populating the language subtags, so I assume there's nothing dreadfully wrong with it. I'll do the other sections in similar fashion, perhaps this weekend.) > At the moment I'm more worried about the size of the future > registry for 7000+ languages, IANA is probably forced to split > it somehow on its Web pages. I'm not sure why that should be a problem. Yeah, the file would get bigger -- about 550,000 bytes bigger in record-jar format, or 340,000 bytes bigger in bar-delimited format, by my estimate -- but does that cause any real problems? You can now buy a 512 MB JumpDrive for 40 USD, or a 200 GB hard drive for 100 USD; surely a registry of 600,000 bytes isn't the greatest of our worries. I would think the inconvenience of dealing with multiple files and keeping them synchronized would be a greater concern. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 01:33:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26524; Fri, 25 Mar 2005 01:33:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEiTG-0003an-J8; Fri, 25 Mar 2005 01:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEhl6-0006g9-9I; Fri, 25 Mar 2005 00:53:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEhl3-0006g4-Cj for ltru@megatron.ietf.org; Fri, 25 Mar 2005 00:53:21 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24360 for ; Fri, 25 Mar 2005 00:53:18 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325055249.WVAF2192.mta9.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 00:52:49 -0500 Message-ID: <008001c530fe$ddd24aa0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325044220.GSSN2135.mta2.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 21:52:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA24360 Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Addison Phillips wrote: > For the record, the suggestion was to replace or augment the current: > > 8. Native name of the language or variation (transcribed into > ASCII): > > ... with the native name of the language or variation. In some cases > there may be several of these (witness zh-hakka, although one suspects > these are all represented by the same or at least a smaller set of > ideographs). There are also some regions that have naming problems in > ASCII (ISO 3166 shows the =C3=85land Islands surrounded by a sea of ASC= II). Mark Davis responded: > If we did that, it should be an optional, additional field. I agree. UN/LOCODE solves this problem by having two "name" fields, one in Latin-1 and another smashed to ASCII (i.e. each non-ASCII letter converted 1-to-1 to an ASCII letter, with no attempt to be linguistically correct). It seems to solve a problem they had. I would be concerned about an attempt to expand "native name" beyond Latin-1, though. Although Unicode-capable systems are commonplace now and we have the technology to display "Armenian" in Armenian and "Chinese" in Han, real people still have to be able to read this stuff. Not everyone using the registry will be capable of reading multiple scripts, and we shouldn't look like we're doing it just to show off. I'd just as soon give the =C3=85land Islands back their ring, give C=C3=B4= te d'Ivoire its circumflex and R=C3=A9union its acute, and pretty much leave= it at that. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 01:35:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26683; Fri, 25 Mar 2005 01:35:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEiW3-0003fw-0z; Fri, 25 Mar 2005 01:41:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiPm-00023a-SG; Fri, 25 Mar 2005 01:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiPl-00023V-3Y for ltru@megatron.ietf.org; Fri, 25 Mar 2005 01:35:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26655 for ; Fri, 25 Mar 2005 01:35:24 -0500 (EST) Received: from mta6.adelphia.net ([68.168.78.190]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEiVa-0003fL-JI for ltru@ietf.org; Fri, 25 Mar 2005 01:41:26 -0500 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325060619.IUMD5402.mta11.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 01:06:19 -0500 Message-ID: <008e01c53100$c07b6340$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050321044949.GEQD4900.mta8.adelphia.net@megatron.ietf.org> <003c01c52de1$f988a2a0$030aa8c0@DEWELL> <014f01c52e38$f1b9a950$38733009@sanjose.ibm.com> Subject: Re: Question: (was Re: [Ltru] Re: Populating the initial registry: Languages) Date: Thu, 24 Mar 2005 22:06:13 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Mark Davis wrote: > The safest and most robust policy is allow all codes that have ever > been permitted by the source standards. My reasons are that > (a) because of the instability of such sources, it was indeed a > reasonable tactic to take use the first defined code for a given > semantic, and that tactic was in widespread use, and > (b) because 3066 and 1766 did not take into account the instability of > the source standards, it was never clear which codes were in fact > valid at any point in time for use in 3066 or 1766, so there was no > guidance as to which code to use, or with what semantics. OK, so far we have Mark taking this stand, and Frank taking the stand that a cutoff date should be set, such as the publication of RFC 1766, such that language and country codes deprecated before that date would not be allowed in language tags. And I agree with Mark. Anyone else? This is only 3 voices out of at least 15 active participants in the group, which is not what anyone would call consensus. > However, because of the reuse of codes for unrelated entities by the > source standards, we do have to impose some order in those cases where > there is a conflict. For that, we have had in the drafts the use of a > cut-off date for deciding which semantic to use in case of a conflict, > such as with 'CS'. In that particular case there is sufficient > consensus to make that after the redefinition of CS to mean "Serbia > and Montenegro": a date of January 1 2005 would capture that > consensus. It would be safest not to put it at date of publication, > simply because that take the risk (probably small, but unfortunately > real) that the source standards would redefine a code after the draft > has been discussed and approved, but before publication. I wonder if we could solicit some sort of temporary moratorium from the MAs that they would refrain from doing this at least until we can get the RFCs out, presumably by the end of 2005. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 01:43:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27501; Fri, 25 Mar 2005 01:43:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEid2-0003vE-V8; Fri, 25 Mar 2005 01:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiWB-0002p1-OE; Fri, 25 Mar 2005 01:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiW9-0002ot-Tj for ltru@megatron.ietf.org; Fri, 25 Mar 2005 01:42:01 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27452 for ; Fri, 25 Mar 2005 01:42:00 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325064129.PTEG4618.mta13.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 01:41:29 -0500 Message-ID: <009c01c53105$ac1ce720$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 22:41:27 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> Are you aware that 'jw' was not documented as an error by >> ISO 639 RA/JAC until 2002? > > No, it wasn't clear whether this was a typo fixed 1988 or a > typo fixed 2001, or maybe an old typo fixed long ago but now > officially documented. It doesn't matter; the result is the same. > The in, iw, etc. cases are different, they were no typos. It still doesn't matter. If these codes were ever made available to users, they were probably used. > Actually it's not very important, do whatever you like, but > don't use it to justify FQ or RH later when we come to the > region codes. ;-) It's not a matter of whatever *I* like. Please don't go there. This is supposed to be a group effort. I sure wish more people would speak up on this so it wasn't just a matter of "what Frank wants" versus "what Doug wants." And yes, I will be consistent and describe the same approach for both language and country codes, at least until there is some rough consensus for doing otherwise. Right now it's just Frank and Doug bickering about it on the list. >> Frank, please write a counterproposal. I don't think it's >> accomplishing anything to continue saying "Or we could >> totally change the way country codes are handled" without a >> document that the WG can discuss. > > I've already done that using the worst case CS as an example > how it would work for a 3066bis-my-way introduced about 1989. > Addison added the 3066bis-your-way version for the same case. > > IMHO these examples were clear, in a 3066bis-your-way all > obsolete ISO 3166-1 codes are preserved using UN numbers for > some new regions, in a 3066-bis-my-way ISO 3166-1 is used as > is, if somebody wants a stable tag (guaranteed for centuries) > he's forced to use UN numbers instead of ISO 3166-1. All right, let's make it a more-or-less formal... QUESTION: Should the draft implement region-code stability: (a) by preserving all assigned ISO 3166 codes with their original meaning, except those that have already been reassigned, and using UN numeric codes in the case of future reassignments; (b) by allowing UN codes in parallel with ISO 3166 codes, as a preferred alternative, and deprecating the ISO codes; or (c) same as (b), but NOT deprecating the ISO codes? I won't bother writing a pro and con for this one. I think everyone interested will be able to judge for themselves. > Let's hope that "they" don't deprecate any country code while > we are desperately trying to find a compromise. We still want > compatibility with anything that was valid under 1766 / 3066. I couldn't agree more. See my earlier remark about a temporary moratorium. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 01:52:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28399; Fri, 25 Mar 2005 01:52:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEimE-0004Cp-V4; Fri, 25 Mar 2005 01:58:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEieB-0003kD-Vg; Fri, 25 Mar 2005 01:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEieA-0003k5-09 for ltru@megatron.ietf.org; Fri, 25 Mar 2005 01:50:18 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28267 for ; Fri, 25 Mar 2005 01:50:16 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325064945.MKZR7277.mta10.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 01:49:45 -0500 Message-ID: <00c301c53106$d3ce3ac0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050323181007.GEEB2135.mta4.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 22:49:43 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Getting back on track X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > 3. I remind that the Charter specifies that: "The RFC 3066 standard > for language tags has been widely adopted in various protocols and > text formats, including HTML, XML, and CLDR, as the best means of > identifying languages and language preferences.". So, I will only > quote your responses on CLDR and Unicode copyrigths in a waiver about > the support of CLDR. Up to the IESG to decide if they maintain their > Charter consideration on CLDR. All this says is that CLDR uses language tags. It does not say the LTRU effort has any dependency on CLDR, and certainly has nothing to do with the copyright status of CLDR or Unicode, or any IP issues at all really. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 02:04:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02947; Fri, 25 Mar 2005 02:04:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEixM-0004ZC-1e; Fri, 25 Mar 2005 02:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiq6-0004vv-EX; Fri, 25 Mar 2005 02:02:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiq5-0004vq-6p for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:02:37 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01457 for ; Fri, 25 Mar 2005 02:02:35 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325070205.JWNR5402.mta11.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 02:02:05 -0500 Message-ID: <00c801c53108$8bff7040$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050324094233.QKSF2124.mta7.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 23:02:02 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > If we're going to consider different formats for the registry, might I > suggest that an even better format would be XML? You might. Oh, all right, I'll do an XML version too and post it, so you guys can see that one too. XML has all the advantages and disadvantages that people have mentioned so far, and probably many more of both. XML is sort of like California: anything anyone can say about it is true. Actually I had wondered before about converting the registry to XML, but wasn't sure how it should be structured. (The eternal question: "Elements or attributes? Which will serve me best?") For this version, I'll use Addison's example blindly, but without any extra information (such as URLs) that isn't already in the existing registry. Don't hold your breath; I'll announce when it's ready. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 02:09:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08630; Fri, 25 Mar 2005 02:09:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEj32-0004gw-JR; Fri, 25 Mar 2005 02:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiwo-0005eM-JP; Fri, 25 Mar 2005 02:09:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEiwe-0005dn-Hd for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:09:24 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08044 for ; Fri, 25 Mar 2005 02:09:23 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325070853.QEFT4618.mta13.adelphia.net@DEWELL> for ; Fri, 25 Mar 2005 02:08:53 -0500 Message-ID: <00db01c53109$7cdaade0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050323071700.BRCV2128.mta1.adelphia.net@megatron.ietf.org> Date: Thu, 24 Mar 2005 23:08:45 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Preparations for smart matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Peter Constable wrote: >> The RFC 3066bis generative syntax is a superset of the RFC 3066 >> generative syntax. It allows things to be generated that cannot be >> generated under RFC 3066. > > This needs a little clarification: > > RFC 3066 has a weak syntax that permits lots of strings; it sanctions > a small set of those, requiring others to be registered explicitly. > > RFC3066bis has a stronger syntax that permits a much more restrictive > set of strings than does RFC 3066. On the other hand, it sanctions a > much larger portion of the strings its syntax permits, making the need > for registration (as well as the possibilities for registration) more > limited. All of this is true. The words "generative" and "generated" were central to what I wrote. Frank had written: > For existing RfC 3066 software en-Latn-US is gibberish. It was clear to me that he was talking about generative tags, not about the possibility of registering "en-Latn-US". Speaking only for myself, I'm not concerned about maintaining compatibility with parsers that couldn't handle "en-Latn-US" even if it were registered. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 02:21:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20300; Fri, 25 Mar 2005 02:21:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjEb-000532-KU; Fri, 25 Mar 2005 02:27:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEj75-0007EJ-Vl; Fri, 25 Mar 2005 02:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEj6m-0007Bi-VP for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:19:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18291 for ; Fri, 25 Mar 2005 02:19:51 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjCc-0004z7-9j for ltru@ietf.org; Fri, 25 Mar 2005 02:25:54 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 23:19:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Question: (was Re: [Ltru] Re: Populating the initial registry:Languages) Date: Thu, 24 Mar 2005 23:19:39 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC29C09@irvmbxw01.quest.com> Thread-Topic: Question: (was Re: [Ltru] Re: Populating the initial registry:Languages) Thread-Index: AcUxBN9D1SWqrykfSEGyL2y2b0TDWQABWzkg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 25 Mar 2005 07:19:40.0416 (UTC) FILETIME=[025FC800:01C5310B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0539603546==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 --===============0539603546== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaW1seSByZWNhbGwsIHBlcmhhcHMgbm90IGNvcnJlY3RseSwgdGhhdCBhIGZldyAzMTY2IGNv ZGVzIGZyb20gdGhlIGRpbSBwYXN0IGhhdmUgYmVlbiByZXVzZWQuIElzIHRoZSBSRkMgMTc2NiBk YXRlIEZyYW5rIGNpdGVzIG9mIHVzZSBpbiBleGNsdWRpbmcgbG9uZyBzdGFsZSBjb2RlcyB0aGF0 IGhhdmUgYmVlbiByZXVzZWQgKGkuZS4gZG9uJ3QgbWFrZSBjZXJ0YWluIHZhbHVlcyBjYW5vbmlj YWwsIGFsbG93IHNvbWUgbmV3ZXIgbWVhbmluZ3MgaW4pPyBPdGhlcndpc2UgSSB0ZW5kIHRvIGFn cmVlIHdpdGggTWFyay4NCg0KT2YgY291cnNlIHlvdSd2ZSBub3QgZ290IHRvIHJlZ2lvbnMgeWV0 OiB0aGlzIGlzIG9ubHkgbGFuZ3VhZ2UgY29kZXMuIE9uIGxhbmd1YWdlIGNvZGVzLCBJIHdvdWxk IHNheSB0YWtlIHRoZW0gYWxsLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5h dGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24g aXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFp bHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdl bGwNCj4gU2VudDogamV1ZGkgMjQgbWFycyAyMDA1IDIyOjA2DQo+IFRvOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uOiAod2FzIFJlOiBbTHRydV0gUmU6IFBvcHVs YXRpbmcgdGhlIGluaXRpYWwNCj4gcmVnaXN0cnk6TGFuZ3VhZ2VzKQ0KPiANCj4gTWFyayBEYXZp cyA8bWFyayBkb3QgZGF2aXMgYXQganRjc3YgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IFRoZSBz YWZlc3QgYW5kIG1vc3Qgcm9idXN0IHBvbGljeSBpcyBhbGxvdyBhbGwgY29kZXMgdGhhdCBoYXZl IGV2ZXINCj4gPiBiZWVuIHBlcm1pdHRlZCBieSB0aGUgc291cmNlIHN0YW5kYXJkcy4gTXkgcmVh c29ucyBhcmUgdGhhdA0KPiA+IChhKSBiZWNhdXNlIG9mIHRoZSBpbnN0YWJpbGl0eSBvZiBzdWNo IHNvdXJjZXMsIGl0IHdhcyBpbmRlZWQgYQ0KPiA+IHJlYXNvbmFibGUgdGFjdGljIHRvIHRha2Ug dXNlIHRoZSBmaXJzdCBkZWZpbmVkIGNvZGUgZm9yIGEgZ2l2ZW4NCj4gPiBzZW1hbnRpYywgYW5k IHRoYXQgdGFjdGljIHdhcyBpbiB3aWRlc3ByZWFkIHVzZSwgYW5kDQo+ID4gKGIpIGJlY2F1c2Ug MzA2NiBhbmQgMTc2NiBkaWQgbm90IHRha2UgaW50byBhY2NvdW50IHRoZSBpbnN0YWJpbGl0eSBv Zg0KPiA+IHRoZSBzb3VyY2Ugc3RhbmRhcmRzLCBpdCB3YXMgbmV2ZXIgY2xlYXIgd2hpY2ggY29k ZXMgd2VyZSBpbiBmYWN0DQo+ID4gdmFsaWQgYXQgYW55IHBvaW50IGluIHRpbWUgZm9yIHVzZSBp biAzMDY2IG9yIDE3NjYsIHNvIHRoZXJlIHdhcyBubw0KPiA+IGd1aWRhbmNlIGFzIHRvIHdoaWNo IGNvZGUgdG8gdXNlLCBvciB3aXRoIHdoYXQgc2VtYW50aWNzLg0KPiANCj4gT0ssIHNvIGZhciB3 ZSBoYXZlIE1hcmsgdGFraW5nIHRoaXMgc3RhbmQsIGFuZCBGcmFuayB0YWtpbmcgdGhlIHN0YW5k DQo+IHRoYXQgYSBjdXRvZmYgZGF0ZSBzaG91bGQgYmUgc2V0LCBzdWNoIGFzIHRoZSBwdWJsaWNh dGlvbiBvZiBSRkMgMTc2NiwNCj4gc3VjaCB0aGF0IGxhbmd1YWdlIGFuZCBjb3VudHJ5IGNvZGVz IGRlcHJlY2F0ZWQgYmVmb3JlIHRoYXQgZGF0ZSB3b3VsZA0KPiBub3QgYmUgYWxsb3dlZCBpbiBs YW5ndWFnZSB0YWdzLiAgQW5kIEkgYWdyZWUgd2l0aCBNYXJrLg0KPiANCj4gQW55b25lIGVsc2U/ ICBUaGlzIGlzIG9ubHkgMyB2b2ljZXMgb3V0IG9mIGF0IGxlYXN0IDE1IGFjdGl2ZQ0KPiBwYXJ0 aWNpcGFudHMgaW4gdGhlIGdyb3VwLCB3aGljaCBpcyBub3Qgd2hhdCBhbnlvbmUgd291bGQgY2Fs bA0KPiBjb25zZW5zdXMuDQo+IA0KPiA+IEhvd2V2ZXIsIGJlY2F1c2Ugb2YgdGhlIHJldXNlIG9m IGNvZGVzIGZvciB1bnJlbGF0ZWQgZW50aXRpZXMgYnkgdGhlDQo+ID4gc291cmNlIHN0YW5kYXJk cywgd2UgZG8gaGF2ZSB0byBpbXBvc2Ugc29tZSBvcmRlciBpbiB0aG9zZSBjYXNlcyB3aGVyZQ0K PiA+IHRoZXJlIGlzIGEgY29uZmxpY3QuIEZvciB0aGF0LCB3ZSBoYXZlIGhhZCBpbiB0aGUgZHJh ZnRzIHRoZSB1c2Ugb2YgYQ0KPiA+IGN1dC1vZmYgZGF0ZSBmb3IgZGVjaWRpbmcgd2hpY2ggc2Vt YW50aWMgdG8gdXNlIGluIGNhc2Ugb2YgYSBjb25mbGljdCwNCj4gPiBzdWNoIGFzIHdpdGggJ0NT Jy4gIEluIHRoYXQgcGFydGljdWxhciBjYXNlIHRoZXJlIGlzIHN1ZmZpY2llbnQNCj4gPiBjb25z ZW5zdXMgdG8gbWFrZSB0aGF0IGFmdGVyIHRoZSByZWRlZmluaXRpb24gb2YgQ1MgdG8gbWVhbiAi U2VyYmlhDQo+ID4gYW5kIE1vbnRlbmVncm8iOiBhIGRhdGUgb2YgSmFudWFyeSAxIDIwMDUgd291 bGQgY2FwdHVyZSB0aGF0DQo+ID4gY29uc2Vuc3VzLiBJdCB3b3VsZCBiZSBzYWZlc3Qgbm90IHRv IHB1dCBpdCBhdCBkYXRlIG9mIHB1YmxpY2F0aW9uLA0KPiA+IHNpbXBseSBiZWNhdXNlIHRoYXQg dGFrZSB0aGUgcmlzayAocHJvYmFibHkgc21hbGwsIGJ1dCB1bmZvcnR1bmF0ZWx5DQo+ID4gcmVh bCkgdGhhdCB0aGUgc291cmNlIHN0YW5kYXJkcyB3b3VsZCByZWRlZmluZSBhIGNvZGUgYWZ0ZXIg dGhlIGRyYWZ0DQo+ID4gaGFzIGJlZW4gZGlzY3Vzc2VkIGFuZCBhcHByb3ZlZCwgYnV0IGJlZm9y ZSBwdWJsaWNhdGlvbi4NCj4gDQo+IEkgd29uZGVyIGlmIHdlIGNvdWxkIHNvbGljaXQgc29tZSBz b3J0IG9mIHRlbXBvcmFyeSBtb3JhdG9yaXVtIGZyb20gdGhlDQo+IE1BcyB0aGF0IHRoZXkgd291 bGQgcmVmcmFpbiBmcm9tIGRvaW5nIHRoaXMgYXQgbGVhc3QgdW50aWwgd2UgY2FuIGdldA0KPiB0 aGUgUkZDcyBvdXQsIHByZXN1bWFibHkgYnkgdGhlIGVuZCBvZiAyMDA1Lg0KPiANCj4gLURvdWcg RXdlbGwNCj4gIEZ1bGxlcnRvbiwgQ2FsaWZvcm5pYQ0KPiAgaHR0cDovL3VzZXJzLmFkZWxwaGlh Lm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmll dGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============0539603546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0539603546==-- From ltru-bounces@ietf.org Fri Mar 25 02:24:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21211; Fri, 25 Mar 2005 02:24:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjHa-00058m-7A; Fri, 25 Mar 2005 02:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjAf-0007px-Mg; Fri, 25 Mar 2005 02:23:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjAW-0007oj-LX for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:23:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21027 for ; Fri, 25 Mar 2005 02:23:43 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjGM-00054k-Jb for ltru@ietf.org; Fri, 25 Mar 2005 02:29:47 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 23:23:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Question Date: Thu, 24 Mar 2005 23:23:34 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC29C0A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Question Thread-Index: AcUxBfNkeCYOmrajSxOBBTcxJmctNAABTIMg From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 25 Mar 2005 07:23:35.0245 (UTC) FILETIME=[8E57D7D0:01C5310B] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1237338981==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --===============1237338981== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBRVUVTVElPTjogIFNob3VsZCB0aGUgZHJhZnQgaW1wbGVtZW50IHJlZ2lvbi1jb2RlIHN0YWJp bGl0eTogKGEpIGJ5DQo+IHByZXNlcnZpbmcgYWxsIGFzc2lnbmVkIElTTyAzMTY2IGNvZGVzIHdp dGggdGhlaXIgb3JpZ2luYWwgbWVhbmluZywNCj4gZXhjZXB0IHRob3NlIHRoYXQgaGF2ZSBhbHJl YWR5IGJlZW4gcmVhc3NpZ25lZCwgYW5kIHVzaW5nIFVOIG51bWVyaWMNCj4gY29kZXMgaW4gdGhl IGNhc2Ugb2YgZnV0dXJlIHJlYXNzaWdubWVudHM7IChiKSBieSBhbGxvd2luZyBVTiBjb2RlcyBp bg0KPiBwYXJhbGxlbCB3aXRoIElTTyAzMTY2IGNvZGVzLCBhcyBhIHByZWZlcnJlZCBhbHRlcm5h dGl2ZSwgYW5kDQo+IGRlcHJlY2F0aW5nIHRoZSBJU08gY29kZXM7IG9yIChjKSBzYW1lIGFzIChi KSwgYnV0IE5PVCBkZXByZWNhdGluZyB0aGUNCj4gSVNPIGNvZGVzPw0KDQpJIHN1cHBvcnQgKGEp Lg0KDQpGcmFuayBoYXMgY29udmluY2VkIG1lIHRoYXQgSSB3b3VsZCBiZSBpbiBmYXZvciBvZiBh IGZvdXJ0aCBvcHRpb24gKGQpOiBzYW1lIGFzIChhKSBidXQgaW5jbHVkZSB0aGUgTS40OSBjb2Rl cyBpbiB0aGUgZGVzY3JpcHRpb24uDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0K R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVy bmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlv biBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcg W21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBEb3Vn IEV3ZWxsDQo+IFNlbnQ6IGpldWRpIDI0IG1hcnMgMjAwNSAyMjo0MQ0KPiBUbzogTFRSVSBXb3Jr aW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBSZTogUXVlc3Rpb24NCj4gDQo+IEZyYW5rIEVs bGVybWFubiA8bm9ib2R5IGF0IHh5enp5IGRvdCBjbGFyYW5ldCBkb3QgZGU+IHdyb3RlOg0KPiAN Cj4gPj4gQXJlIHlvdSBhd2FyZSB0aGF0ICdqdycgd2FzIG5vdCBkb2N1bWVudGVkIGFzIGFuIGVy cm9yIGJ5DQo+ID4+IElTTyA2MzkgUkEvSkFDIHVudGlsIDIwMDI/DQo+ID4NCj4gPiBObywgaXQg d2Fzbid0IGNsZWFyIHdoZXRoZXIgdGhpcyB3YXMgYSB0eXBvIGZpeGVkIDE5ODggb3IgYQ0KPiA+ IHR5cG8gZml4ZWQgMjAwMSwgb3IgbWF5YmUgYW4gb2xkIHR5cG8gZml4ZWQgbG9uZyBhZ28gYnV0 IG5vdw0KPiA+IG9mZmljaWFsbHkgZG9jdW1lbnRlZC4NCj4gDQo+IEl0IGRvZXNuJ3QgbWF0dGVy OyB0aGUgcmVzdWx0IGlzIHRoZSBzYW1lLg0KPiANCj4gPiBUaGUgaW4sIGl3LCBldGMuIGNhc2Vz IGFyZSBkaWZmZXJlbnQsIHRoZXkgd2VyZSBubyB0eXBvcy4NCj4gDQo+IEl0IHN0aWxsIGRvZXNu J3QgbWF0dGVyLiAgSWYgdGhlc2UgY29kZXMgd2VyZSBldmVyIG1hZGUgYXZhaWxhYmxlIHRvDQo+ IHVzZXJzLCB0aGV5IHdlcmUgcHJvYmFibHkgdXNlZC4NCj4gDQo+ID4gQWN0dWFsbHkgaXQncyBu b3QgdmVyeSBpbXBvcnRhbnQsIGRvIHdoYXRldmVyIHlvdSBsaWtlLCBidXQNCj4gPiBkb24ndCB1 c2UgaXQgdG8ganVzdGlmeSBGUSBvciBSSCBsYXRlciB3aGVuIHdlIGNvbWUgdG8gdGhlDQo+ID4g cmVnaW9uIGNvZGVzLiA7LSkNCj4gDQo+IEl0J3Mgbm90IGEgbWF0dGVyIG9mIHdoYXRldmVyICpJ KiBsaWtlLiAgUGxlYXNlIGRvbid0IGdvIHRoZXJlLiAgVGhpcyBpcw0KPiBzdXBwb3NlZCB0byBi ZSBhIGdyb3VwIGVmZm9ydC4gIEkgc3VyZSB3aXNoIG1vcmUgcGVvcGxlIHdvdWxkIHNwZWFrIHVw DQo+IG9uIHRoaXMgc28gaXQgd2Fzbid0IGp1c3QgYSBtYXR0ZXIgb2YgIndoYXQgRnJhbmsgd2Fu dHMiIHZlcnN1cyAid2hhdA0KPiBEb3VnIHdhbnRzLiINCj4gDQo+IEFuZCB5ZXMsIEkgd2lsbCBi ZSBjb25zaXN0ZW50IGFuZCBkZXNjcmliZSB0aGUgc2FtZSBhcHByb2FjaCBmb3IgYm90aA0KPiBs YW5ndWFnZSBhbmQgY291bnRyeSBjb2RlcywgYXQgbGVhc3QgdW50aWwgdGhlcmUgaXMgc29tZSBy b3VnaCBjb25zZW5zdXMNCj4gZm9yIGRvaW5nIG90aGVyd2lzZS4gIFJpZ2h0IG5vdyBpdCdzIGp1 c3QgRnJhbmsgYW5kIERvdWcgYmlja2VyaW5nIGFib3V0DQo+IGl0IG9uIHRoZSBsaXN0Lg0KPiAN Cj4gPj4gRnJhbmssIHBsZWFzZSB3cml0ZSBhIGNvdW50ZXJwcm9wb3NhbC4gIEkgZG9uJ3QgdGhp bmsgaXQncw0KPiA+PiBhY2NvbXBsaXNoaW5nIGFueXRoaW5nIHRvIGNvbnRpbnVlIHNheWluZyAi T3Igd2UgY291bGQNCj4gPj4gdG90YWxseSBjaGFuZ2UgdGhlIHdheSBjb3VudHJ5IGNvZGVzIGFy ZSBoYW5kbGVkIiB3aXRob3V0IGENCj4gPj4gZG9jdW1lbnQgdGhhdCB0aGUgV0cgY2FuIGRpc2N1 c3MuDQo+ID4NCj4gPiBJJ3ZlIGFscmVhZHkgZG9uZSB0aGF0IHVzaW5nIHRoZSB3b3JzdCBjYXNl IENTIGFzIGFuIGV4YW1wbGUNCj4gPiBob3cgaXQgd291bGQgd29yayBmb3IgYSAzMDY2YmlzLW15 LXdheSBpbnRyb2R1Y2VkIGFib3V0IDE5ODkuDQo+ID4gQWRkaXNvbiBhZGRlZCB0aGUgMzA2NmJp cy15b3VyLXdheSB2ZXJzaW9uIGZvciB0aGUgc2FtZSBjYXNlLg0KPiA+DQo+ID4gSU1ITyB0aGVz ZSBleGFtcGxlcyB3ZXJlIGNsZWFyLCBpbiBhIDMwNjZiaXMteW91ci13YXkgYWxsDQo+ID4gb2Jz b2xldGUgSVNPIDMxNjYtMSBjb2RlcyBhcmUgcHJlc2VydmVkIHVzaW5nIFVOIG51bWJlcnMgZm9y DQo+ID4gc29tZSBuZXcgcmVnaW9ucywgaW4gYSAzMDY2LWJpcy1teS13YXkgSVNPIDMxNjYtMSBp cyB1c2VkIGFzDQo+ID4gaXMsIGlmIHNvbWVib2R5IHdhbnRzIGEgc3RhYmxlIHRhZyAoZ3VhcmFu dGVlZCBmb3IgY2VudHVyaWVzKQ0KPiA+IGhlJ3MgZm9yY2VkIHRvIHVzZSBVTiBudW1iZXJzIGlu c3RlYWQgb2YgSVNPIDMxNjYtMS4NCj4gDQo+IEFsbCByaWdodCwgbGV0J3MgbWFrZSBpdCBhIG1v cmUtb3ItbGVzcyBmb3JtYWwuLi4NCj4gDQo+IFFVRVNUSU9OOiAgU2hvdWxkIHRoZSBkcmFmdCBp bXBsZW1lbnQgcmVnaW9uLWNvZGUgc3RhYmlsaXR5OiAoYSkgYnkNCj4gcHJlc2VydmluZyBhbGwg YXNzaWduZWQgSVNPIDMxNjYgY29kZXMgd2l0aCB0aGVpciBvcmlnaW5hbCBtZWFuaW5nLA0KPiBl eGNlcHQgdGhvc2UgdGhhdCBoYXZlIGFscmVhZHkgYmVlbiByZWFzc2lnbmVkLCBhbmQgdXNpbmcg VU4gbnVtZXJpYw0KPiBjb2RlcyBpbiB0aGUgY2FzZSBvZiBmdXR1cmUgcmVhc3NpZ25tZW50czsg KGIpIGJ5IGFsbG93aW5nIFVOIGNvZGVzIGluDQo+IHBhcmFsbGVsIHdpdGggSVNPIDMxNjYgY29k ZXMsIGFzIGEgcHJlZmVycmVkIGFsdGVybmF0aXZlLCBhbmQNCj4gZGVwcmVjYXRpbmcgdGhlIElT TyBjb2Rlczsgb3IgKGMpIHNhbWUgYXMgKGIpLCBidXQgTk9UIGRlcHJlY2F0aW5nIHRoZQ0KPiBJ U08gY29kZXM/DQo+IA0KPiBJIHdvbid0IGJvdGhlciB3cml0aW5nIGEgcHJvIGFuZCBjb24gZm9y IHRoaXMgb25lLiAgSSB0aGluayBldmVyeW9uZQ0KPiBpbnRlcmVzdGVkIHdpbGwgYmUgYWJsZSB0 byBqdWRnZSBmb3IgdGhlbXNlbHZlcy4NCj4gDQo+ID4gTGV0J3MgaG9wZSB0aGF0ICJ0aGV5IiBk b24ndCBkZXByZWNhdGUgYW55IGNvdW50cnkgY29kZSB3aGlsZQ0KPiA+IHdlIGFyZSBkZXNwZXJh dGVseSB0cnlpbmcgdG8gZmluZCBhIGNvbXByb21pc2UuICBXZSBzdGlsbCB3YW50DQo+ID4gY29t cGF0aWJpbGl0eSB3aXRoIGFueXRoaW5nIHRoYXQgd2FzIHZhbGlkIHVuZGVyIDE3NjYgLyAzMDY2 Lg0KPiANCj4gSSBjb3VsZG4ndCBhZ3JlZSBtb3JlLiAgU2VlIG15IGVhcmxpZXIgcmVtYXJrIGFi b3V0IGEgdGVtcG9yYXJ5DQo+IG1vcmF0b3JpdW0uDQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAgRnVs bGVydG9uLCBDYWxpZm9ybmlhDQo+ICBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwv DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============1237338981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1237338981==-- From ltru-bounces@ietf.org Fri Mar 25 02:28:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21574; Fri, 25 Mar 2005 02:28:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjL0-0005DM-9C; Fri, 25 Mar 2005 02:34:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjE8-0000Kd-1d; Fri, 25 Mar 2005 02:27:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjE0-0000Fs-6h for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:27:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21465 for ; Fri, 25 Mar 2005 02:27:18 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjJp-0005AN-9j for ltru@ietf.org; Fri, 25 Mar 2005 02:33:22 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1DEjDq-00026M-Ct; Fri, 25 Mar 2005 02:27:10 -0500 Date: Fri, 25 Mar 2005 02:27:10 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: Question Message-ID: <20050325072710.GA14412@ccil.org> References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org> <009c01c53105$ac1ce720$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009c01c53105$ac1ce720$030aa8c0@DEWELL> 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@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Here's my take on Doug Ewell's question. "Date A" means 1995-03-01, the publication date of RFC 1766. "Date B" means the publication date of the new BCP that replaces RFC 3066. These dates could be changed without affecting my judgments very much. > QUESTION: Should the draft implement region-code stability: (a) by > preserving all assigned ISO 3166 codes with their original meaning, ISO codes terminated before Date A and not reassigned have never been valid in 1766 or 3066 langtags, and should not be permitted. ISO codes terminated after Date A and not reassigned before Date B should be permitted and marked as deprecated, with the nearest equivalent documented in the registry. ISO codes in effect as of Date B, whether or not they were once assigned to a different meaning, should be permitted in their meaning as of Date B. > except those that have already been reassigned, and using UN numeric > codes in the case of future reassignments; UN codes that encode countries should only be allowed in the case of the reassignment of an ISO 3166-1 code after Date B. UN codes that encode regions of the world should be permitted. > (b) by allowing UN codes in parallel with ISO 3166 codes, as a preferred > alternative, and deprecating the ISO codes; or (c) same as (b), but > NOT deprecating the ISO codes? Having two codes for the same thing is always a bad idea and should not be allowed unless a code reassignment after Date A but before Date B makes it necessary. -- After fixing the Y2K bug in an application: John Cowan WELCOME TO cowan@ccil.org DATE: MONDAK, JANUARK 1, 1900 http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 02:35:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22272; Fri, 25 Mar 2005 02:35:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjRo-0005QN-IY; Fri, 25 Mar 2005 02:41:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjKA-0001Sv-Jy; Fri, 25 Mar 2005 02:33:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjK9-0001SU-4m for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:33:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22097 for ; Fri, 25 Mar 2005 02:33:39 -0500 (EST) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjPz-0005NQ-8D for ltru@ietf.org; Fri, 25 Mar 2005 02:39:43 -0500 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050325073327.ZDIB2192.mta9.adelphia.net@DEWELL>; Fri, 25 Mar 2005 02:33:27 -0500 Message-ID: <00e701c5310c$eb6a2da0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AC29C09@irvmbxw01.quest.com> Subject: Re: Question: (was Re: [Ltru] Re: Populating the initial registry:Languages) Date: Thu, 24 Mar 2005 23:33:19 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > I dimly recall, perhaps not correctly, that a few 3166 codes from the > dim past have been reused. Based on Clive Feather's page: AI originally meant French Afars and Issas, was removed in 1977, and reassigned to Anguilla sometime between 1982 and 1988. GE originally meant Gilbert and Ellice Islands, was removed in 1979, and reassigned to Georgia in 1992. SK originally meant Sikkim, was removed in 1975, and reassigned to Slovakia in 1993. And of course, the one we all know and love: CS originally meant Czechoslovakia, was removed in 1993, and reassigned to Serbia and Montenegro in 2003. > Is the RFC 1766 date Frank cites of use in excluding long stale codes > that have been reused (i.e. don't make certain values canonical, allow > some newer meanings in)? Otherwise I tend to agree with Mark. No codes that have been reused can possibly be used with their old meaning, by definition. We have to use them with their new meaning. CS was the lone exception, but that was changed last December. > Of course you've not got to regions yet: this is only language codes. > On language codes, I would say take them all. I think if we're going to use different criteria for language codes and country codes, we'd better have a really good, defensible reason for doing so. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 02:36:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22325; Fri, 25 Mar 2005 02:36:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjSH-0005Qb-0R; Fri, 25 Mar 2005 02:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjLV-0001dl-SW; Fri, 25 Mar 2005 02:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEjLU-0001dB-0C for ltru@megatron.ietf.org; Fri, 25 Mar 2005 02:35:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22227 for ; Fri, 25 Mar 2005 02:35:02 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjRK-0005P2-3U for ltru@ietf.org; Fri, 25 Mar 2005 02:41:06 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 23:34:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Question Date: Thu, 24 Mar 2005 23:34:53 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC29C11@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Question Thread-Index: AcUxDDxcn2L4tGhPRLi4VKdcX0B9gQAAKuuA From: "Addison Phillips" To: "John Cowan" , "Doug Ewell" X-OriginalArrivalTime: 25 Mar 2005 07:34:54.0492 (UTC) FILETIME=[2334B5C0:01C5310D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Ack. What John said, except add: UN M.49 codes for regions for which no ISO code has ever been assigned. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: jeudi 24 mars 2005 23:27 > To: Doug Ewell > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Question >=20 > Here's my take on Doug Ewell's question. "Date A" means 1995-03-01, > the publication date of RFC 1766. "Date B" means the publication date > of the new BCP that replaces RFC 3066. These dates could be changed > without affecting my judgments very much. >=20 > > QUESTION: Should the draft implement region-code stability: (a) by > > preserving all assigned ISO 3166 codes with their original meaning, >=20 > ISO codes terminated before Date A and not reassigned have never been > valid in 1766 or 3066 langtags, and should not be permitted. >=20 > ISO codes terminated after Date A and not reassigned before Date B > should be permitted and marked as deprecated, with the nearest = equivalent > documented in the registry. >=20 > ISO codes in effect as of Date B, whether or not they were once = assigned > to a different meaning, should be permitted in their meaning as of = Date B. >=20 > > except those that have already been reassigned, and using UN numeric > > codes in the case of future reassignments; >=20 > UN codes that encode countries should only be allowed in the case of > the reassignment of an ISO 3166-1 code after Date B. >=20 > UN codes that encode regions of the world should be permitted. >=20 > > (b) by allowing UN codes in parallel with ISO 3166 codes, as a = preferred > > alternative, and deprecating the ISO codes; or (c) same as (b), but > > NOT deprecating the ISO codes? >=20 > Having two codes for the same thing is always a bad idea and should = not > be allowed unless a code reassignment after Date A but before Date B > makes it necessary. >=20 > -- > After fixing the Y2K bug in an application: John Cowan > WELCOME TO cowan@ccil.org > DATE: MONDAK, JANUARK 1, 1900 = http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 03:34:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27838; Fri, 25 Mar 2005 03:34:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEkMl-0007ED-JC; Fri, 25 Mar 2005 03:40:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEkG2-0007yl-UV; Fri, 25 Mar 2005 03:33:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEkG0-0007yc-0P for ltru@megatron.ietf.org; Fri, 25 Mar 2005 03:33:28 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27760 for ; Fri, 25 Mar 2005 03:33:25 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEkFe-00021U-I6 for ltru@lists.ietf.org; Fri, 25 Mar 2005 09:33:06 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 09:33:06 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 09:33:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 09:30:53 +0100 Organization: Lines: 20 Message-ID: <4243CC3D.37B0@xyzzy.claranet.de> References: <20050323071700.BRCV2128.mta1.adelphia.net@megatron.ietf.org> <009701c53103$6c2eda80$030aa8c0@DEWELL> 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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Doug Ewell wrote: [huge files] > I'm not sure why that should be a problem. The IETF has a collection of I-Ds somewhere, it crashed my old browser. That's only a problem with *huge* (X)HTML files. If somebody wants to know what "yec" is in 3066ter it could be a pain to download the complete registry. > You can now buy a 512 MB JumpDrive for 40 USD, or a 200 GB > hard drive for 100 USD I'm not planning to buy a new hard drive only to read a IANA registry with language tags ;-) I trust that IANA will split it when necessary on its Web pages, and as you said it's no problem for a 3066bis without the future ISO 639-3 languages. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 04:14:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02163; Fri, 25 Mar 2005 04:14:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEkzz-00009z-DT; Fri, 25 Mar 2005 04:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEksj-0003xS-E5; Fri, 25 Mar 2005 04:13:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEksb-0003xA-Iz for ltru@megatron.ietf.org; Fri, 25 Mar 2005 04:13:22 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01995 for ; Fri, 25 Mar 2005 04:13:19 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEksH-0005YH-3N for ltru@lists.ietf.org; Fri, 25 Mar 2005 10:13:01 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 10:13:01 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 10:13:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 10:11:28 +0100 Organization: Lines: 23 Message-ID: <4243D5C0.33F@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AC29C09@irvmbxw01.quest.com> <00e701c5310c$eb6a2da0$030aa8c0@DEWELL> 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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I think if we're going to use different criteria for language > codes and country codes, we'd better have a really good, > defensible reason for doing so. That's rather simple: Compared with countries languages "live" much longer. ISO 639 promised that they'll never add a new alpha-2 code where an alpha-3 code already exists. They have no reason to ever reassign any alpha-2 or alpha-3 code. What they offer is by definition stable. OTOH ISO 3166-1 has only a very limited set of alpha-2 codes, and they try to use acronyms or other mnemonics. They are forced to reassign codes from time to time, and even if they'd guarantee a transition period of 50 years for deprecated codes what they offer is by definition _not_ stable. If we want to "freeze" ISO 3166-1 for stable codes we should at least not block future uses of old codes which were never used in RfC 3066 language tags, Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 07:16:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19631; Fri, 25 Mar 2005 07:16:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEnqC-0005V1-MK; Fri, 25 Mar 2005 07:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEnjm-0006V9-Mj; Fri, 25 Mar 2005 07:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEnjl-0006Uw-FM for ltru@megatron.ietf.org; Fri, 25 Mar 2005 07:16:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19599 for ; Fri, 25 Mar 2005 07:16:22 -0500 (EST) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEnpd-0005U9-83 for ltru@ietf.org; Fri, 25 Mar 2005 07:22:30 -0500 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 25 Mar 2005 07:16:15 -0500 id 002F003E.4244010F.00006313 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: Registry in record-jar format Date: Fri, 25 Mar 2005 07:16:14 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF0749C901@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <4243CC3D.37B0@xyzzy.claranet.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit > I'm not planning to buy a new hard drive only to read a IANA > registry with language tags ;-) I trust that IANA will split > it when necessary on its Web pages, and as you said it's no > problem for a 3066bis without the future ISO 639-3 languages. I wouldn't trust IANA to do anything without explicit instructions. Potential structural issues (and recommendations to address them) would be best described in an "IANA Considerations" section. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 07:59:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22943; Fri, 25 Mar 2005 07:59:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEoV4-0006p7-99; Fri, 25 Mar 2005 08:05:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEoOC-0001zz-RF; Fri, 25 Mar 2005 07:58:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEoOB-0001zt-R0 for ltru@megatron.ietf.org; Fri, 25 Mar 2005 07:58:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22847 for ; Fri, 25 Mar 2005 07:58:08 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEoU1-0006nW-Hs for ltru@ietf.org; Fri, 25 Mar 2005 08:04:15 -0500 Received: from lns-p19-19-idf-82-65-128-79.adsl.proxad.net ([82.65.128.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DEoO6-0001QZ-5b; Fri, 25 Mar 2005 04:58:06 -0800 Message-Id: <6.1.2.0.2.20050325113421.02838710@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 25 Mar 2005 13:58:00 +0100 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format In-Reply-To: <009701c53103$6c2eda80$030aa8c0@DEWELL> References: <20050323071700.BRCV2128.mta1.adelphia.net@megatron.ietf.org> <009701c53103$6c2eda80$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.4 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.4 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Doug, I extensively use my footer to evangelize about this WG's work (it informs people and leave them free to make their mind). I would appreciate (as well as anyone else maintaining a file on line of relevance to this work) to give the exact wording they wish I add for their file. At 07:25 /03/2005, Doug E well wrote: >(BTW, nobody has commented yet on my recipe for populating the language >subtags, so I assume there's nothing dreadfully wrong with it. I'll do >the other sections in similar fashion, perhaps this weekend.) Could you please make it a clean part that we could include in our Draft? > > At the moment I'm more worried about the size of the future > > registry for 7000+ languages, IANA is probably forced to split > > it somehow on its Web pages. > >I'm not sure why that should be a problem. Yeah, the file would get >bigger -- about 550,000 bytes bigger in record-jar format, or 340,000 >bytes bigger in bar-delimited format, by my estimate -- but does that >cause any real problems? You can now buy a 512 MB JumpDrive for 40 USD, >or a 200 GB hard drive for 100 USD; surely a registry of 600,000 bytes >isn't the greatest of our worries. I would think the inconvenience of >dealing with multiple files and keeping them synchronized would be a >greater concern. The problem as usual is the usage made of it, and the load imposed on IANA and private mirrors. I will take an example for you to understand people's behavior. There is a small DNS resolver for end users which has no permanent cache (its starts when you power-up). The first thing it does when you want to use an URL is to call _all_ the root servers (13 calls), while average usage may result in one call over may be tens of thousands of calls. If for any reason someone finds useful or funny or money making to call the file it will result huge traffic and CPU load. Another point we try to consider is the developing countries and islands problems. ADSL US or European or Korean traffic costs nothing. But 600,0000 at real 500 characters per second or less is 1200 seconds. When you know that in some countries one hour of internet equals one day work salary, you see the digital divide this represents for some of the really most involved searchers. The real issue is the CRCD (context reference compact disk). This is the CD any ISP, Gov, Telco, will have to produce to include all these information everyone needs and which are so costly sold by ISO, ITU, terminology, programs, standardization organization or not distributed by searchers however funded by Gov or Intl budget. And the format/program to get it out the CRCD towards real life applications (mail, browsers, blogs, firewalls, etc.) trough appropriate OPES. We try to find money to sponsor a "data in the air" program. All over the world Teletex broadcasts 600 bps per second on TV. Some are extensively used, some are not. This means that a free daily datajournal of 3 Meg maximum is available to everyone (with FEC and with cycles for vital information updates - warnings, available beds in hospitals, missing children, catastrophe maps [TV is usually the first media which is restored and its foot path is better than mobiles and wi-fi], etc. etc.). In this we think we could broadcast daily updated news and weekly information. We cannot reasonably do a longer cycle, even with small solar batteries, due to the possible failures.This means the we can reasonably think of a 10 Meg "disk in the air" system (a DIA system can cost as low as $ 200, with a few USB ports). Permitting people to exchange in different languages over real time information is of the essence for international assistance for example. So languages, terminology, etc. are an important elements. But at the same time we need to qualify that information, to keep it as dense as possible, to "culturalize it" to that end (because a DoS costs too much - and this is why IP is not a proper vehicle, and IPSec is costly). This is where you find that ISO 3166 is of importance but it does not address the diaspora, the immigration, de cultural, the corporate, the reader/viewers classes, etc. This is where you understand that Governments on_the_network are also perceived through their e-regalian embodiment of services - and possible interference with CRCs. FYI our DIA effort will be dedicated to IEMS a small team of a WU shop who had started an inter-mail systems bridge. Mexico City known a big earth break and for hours all the international assistance coordination went though one of their customer's mail system to their ITT mailbox. No one really praised them, but many lifes and sufferances were spared that day because of their small async 300 bps service. jfc ====================================================== Standardizing Tags for the Identification of Languages should not be a way to standardize languages and to unify the world under a dominant culture. ====================================================== For your convenience: RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066 Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ====================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ====================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ====================================================== It seems that what works for countries and ISO 3166 since 1978, should apply to languages and to ISO 693. ====================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 08:07:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24093; Fri, 25 Mar 2005 08:07:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEocr-0007Cx-KY; Fri, 25 Mar 2005 08:13:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEoSo-0002dl-V5; Fri, 25 Mar 2005 08:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEoSn-0002dU-NG for ltru@megatron.ietf.org; Fri, 25 Mar 2005 08:02:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23566 for ; Fri, 25 Mar 2005 08:02:56 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEoYg-00070O-M0 for ltru@ietf.org; Fri, 25 Mar 2005 08:09:03 -0500 Received: from lns-p19-19-idf-82-65-128-79.adsl.proxad.net ([82.65.128.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DEoSl-0003KN-VZ for ltru@ietf.org; Fri, 25 Mar 2005 05:02:56 -0800 Message-Id: <6.1.2.0.2.20050325140226.03d7f760@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 25 Mar 2005 14:02:54 +0100 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Question Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b On 08:23 25/03/2005, Addison Phillips said: >content-class: urn:content-classes:message >Content-Type: text/plain; > charset="utf-8" > > > QUESTION: Should the draft implement region-code stability: (a) by > > preserving all assigned ISO 3166 codes with their original meaning, > > except those that have already been reassigned, and using UN numeric > > codes in the case of future reassignments; (b) by allowing UN codes in > > parallel with ISO 3166 codes, as a preferred alternative, and > > deprecating the ISO codes; or (c) same as (b), but NOT deprecating the > > ISO codes? > >I support (a). >Frank has convinced me that I would be in favor of a fourth option (d): >same as (a) but include the M.49 codes in the description. This rises the question of the update cycle of the data of reference. You can use words of the XVIIth century or talk of a network in the meaning of 1960.Perfect language, you will be understood by no one. This is a general question for the IETF (after how long a release is not supposed to be supported). Retro compatibility is offered for a long nowhere. Try to use your 1930 telephone set, I am not sure it will work. Try to publish an Internet 1990 terminology. Try to use the root servers file of 1995, it will may be still work partly. Try to use DOS on your PC, it works very well, but you are missing a lot of things. We all use anti-virus which are updated once or twice a week or every day..... Either we are on the Internet or on the Eternet. Internet is 22 years old (Jan 1st, 1983). It seems reasonable to consider that every Internet related system should survive 10 years. Then, that it is to the application to consider how to handle the data. Is XML 10 years old, will it be around in 10 years time? By the same token it seems reasonable (to avoid date format problem and help stability) that standard changes should not occur twice yearly, so a version can be indicated by its year (archeological retro compatibility being supported). This permits to stay compatible for another 30.000 years in using a double byte. Operationally wise, it is likely that ISP will convert progressively to SNHN management assistance (we see that through the evolution of the market and the responses we receive to the CRCD program). It will not be to morrow, but we can presume that in a decade the whole network will be an NGN system where everyone userbox will be maintained for all the "information society" related systems as are our anti-virus today. The Y2K shown us that the world can survive this kind of problem. There is obviously a need for OS designers to incorporate a universal tag as a file header with the date of the file, its MD4, its langtag, possibly its handle. Objection to a decade obsolecense cycle? I note that this exactly conforms to the RFC 1766 date (1995). I therefore support the consensus on this particular case and propose to make it a general suggestion for the Internet standard process (which is only a BCP, ie a COULD/SHOULD, not a MUST). This establishes a rule which probably solves most of the issues risen in the charter on compatibility in time. It addresses the CS issue. It leaves open the SU question. jfc ====================================================== Standardizing Tags for the Identification of Languages should not be a way to standardize languages and to unify the world under a dominant culture. ====================================================== For your convenience: RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066 Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Charter: http://ietf.org/html.charters/ltru-charter.html gmane: http://dir.gmane.org/gmane.ietf.ltru If you were Bcced for information and not familliar with the IETF process: http://www.ietf.org/rfc/rfc2026.txt http://www.ietf.org/rfc/rfc2418.txt http://www.ietf.org/rfc/rfc3934.txt http://www.ietf.org/rfc/rfc3669.txt http://www.ietf.org/rfc/rfc3160.txt http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt ====================================================== Jon Postel (RFC 1591): "The IANA is not in the business of deciding what is and what is not a country. The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list." ====================================================== Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." ====================================================== It seems that what works for countries and ISO 3166 since 1978, should apply to languages and to ISO 693. ====================================================== _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 10:46:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09023; Fri, 25 Mar 2005 10:46:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEr6n-0003Qk-Je; Fri, 25 Mar 2005 10:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEr02-0004Vm-JE; Fri, 25 Mar 2005 10:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEr01-0004VP-4E for ltru@megatron.ietf.org; Fri, 25 Mar 2005 10:45:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08819 for ; Fri, 25 Mar 2005 10:45:22 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEr5u-0003Ob-G1 for ltru@ietf.org; Fri, 25 Mar 2005 10:51:31 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Mar 2005 07:45:13 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 25 Mar 2005 07:45:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Question Date: Fri, 25 Mar 2005 07:45:13 -0800 Message-ID: Thread-Topic: [Ltru] Re: Question thread-index: AcUxDDQW+TYB084IQPaY3J4U7uNqLwARSKhQ From: "Peter Constable" To: X-OriginalArrivalTime: 25 Mar 2005 15:45:13.0348 (UTC) FILETIME=[A235E440:01C53151] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > Here's my take on Doug Ewell's question.... Not having had a chance to review the question in detail, I can't formulate a completely independent opinion. But John's assessment and proposal sounds good to me. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 11:28:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14797; Fri, 25 Mar 2005 11:28:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DErm8-00057b-1a; Fri, 25 Mar 2005 11:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DErfb-0003DN-4s; Fri, 25 Mar 2005 11:28:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DErfZ-0003Cr-Dc for ltru@megatron.ietf.org; Fri, 25 Mar 2005 11:28:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14607 for ; Fri, 25 Mar 2005 11:28:18 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DErlT-00053v-KI for ltru@ietf.org; Fri, 25 Mar 2005 11:34:27 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2PGS3Oh031652 for ; Fri, 25 Mar 2005 11:28:03 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2PGS38B250978 for ; Fri, 25 Mar 2005 11:28:03 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2PGS2gp004039 for ; Fri, 25 Mar 2005 11:28:03 -0500 Received: from markdavis (sig-9-48-118-49.mts.ibm.com [9.48.118.49]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2PGS2rh004019; Fri, 25 Mar 2005 11:28:02 -0500 Message-ID: <0e2d01c53157$9d2c0230$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "John Cowan" References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org><009c01c53105$ac1ce720$030aa8c0@DEWELL> <20050325072710.GA14412@ccil.org> Subject: Re: [Ltru] Re: Question Date: Fri, 25 Mar 2005 08:21:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j2PGS3Oh031652 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable I feel like this conversation is going off in the weeds. For backwards compatibility, the goal should be at least: (z) Every generated language tag that was valid under 1766 or 3066 remain= s valid, with the same semantic. The only exceptions are cases where the co= de changed to mean an unrelated entity (eg CS). Your principle violates that. > ISO codes terminated before Date A and not reassigned have never been > valid in 1766 or 3066 langtags, and should not be permitted. This is precisely the problem. They *are* permitted. According to http://www.ietf.org/rfc/rfc1766.txt, all and only the codes in [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology (principles and coordination). [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15.are valid. Note that *nowhere* in 1766 does it say that a code later deprecated in ISO 639 or 3166 is not valid, nor does it even say that earlier deprecated codes are invalid.=E2=80=8EMark----- Original Message -----=20 From: "John Cowan" To: "Doug Ewell" Cc: Sent: Thursday, March 24, 2005 23:27 Subject: Re: [Ltru] Re: Question > Here's my take on Doug Ewell's question. "Date A" means 1995-03-01, > the publication date of RFC 1766. "Date B" means the publication date > of the new BCP that replaces RFC 3066. These dates could be changed > without affecting my judgments very much. > > > QUESTION: Should the draft implement region-code stability: (a) by > > preserving all assigned ISO 3166 codes with their original meaning, > > ISO codes terminated before Date A and not reassigned have never been > valid in 1766 or 3066 langtags, and should not be permitted. > > ISO codes terminated after Date A and not reassigned before Date B > should be permitted and marked as deprecated, with the nearest equivale= nt > documented in the registry. > > ISO codes in effect as of Date B, whether or not they were once assigne= d > to a different meaning, should be permitted in their meaning as of Date= B. > > > except those that have already been reassigned, and using UN numeric > > codes in the case of future reassignments; > > UN codes that encode countries should only be allowed in the case of > the reassignment of an ISO 3166-1 code after Date B. > > UN codes that encode regions of the world should be permitted. > > > (b) by allowing UN codes in parallel with ISO 3166 codes, as a prefer= red > > alternative, and deprecating the ISO codes; or (c) same as (b), but > > NOT deprecating the ISO codes? > > Having two codes for the same thing is always a bad idea and should not > be allowed unless a code reassignment after Date A but before Date B > makes it necessary. > > --=20 > After fixing the Y2K bug in an application: John Cowan > WELCOME TO cowan@ccil.org > DATE: MONDAK, JANUARK 1, 1900 http://www.ccil.org/~co= wan > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 12:15:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18806; Fri, 25 Mar 2005 12:15:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsV4-0006af-U2; Fri, 25 Mar 2005 12:21:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsOM-0002sD-JN; Fri, 25 Mar 2005 12:14:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsOL-0002s3-LY for ltru@megatron.ietf.org; Fri, 25 Mar 2005 12:14:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18729 for ; Fri, 25 Mar 2005 12:14:34 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEsUF-0006Xl-E2 for ltru@ietf.org; Fri, 25 Mar 2005 12:20:44 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2PHEFw0027544; Fri, 25 Mar 2005 09:14:15 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77GF62>; Fri, 25 Mar 2005 09:14:16 -0800 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: Registry in record-jar format Date: Fri, 25 Mar 2005 09:14:15 -0800 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi, Please don't mis-use XML attributes to be the equivalent of 'attributes' in the object-oriented sense. They aren't and the protocol specs I've seen that used them caused nightmares when trying to morph them into proper hierarchical elements. And bear in mind what Scott Hollenbeck just reminded us about, to whit, _nothing_ is up to IANA to figure out. This WG has to specify complete processes and formats for use by IANA in our 'IANA Considerations' section. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Doug Ewell Sent: Friday, March 25, 2005 2:02 AM To: LTRU Working Group Subject: [Ltru] Re: Registry in record-jar format Addison Phillips wrote: > If we're going to consider different formats for the registry, might I > suggest that an even better format would be XML? You might. Oh, all right, I'll do an XML version too and post it, so you guys can see that one too. XML has all the advantages and disadvantages that people have mentioned so far, and probably many more of both. XML is sort of like California: anything anyone can say about it is true. Actually I had wondered before about converting the registry to XML, but wasn't sure how it should be structured. (The eternal question: "Elements or attributes? Which will serve me best?") For this version, I'll use Addison's example blindly, but without any extra information (such as URLs) that isn't already in the existing registry. Don't hold your breath; I'll announce when it's ready. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 12:52:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22928; Fri, 25 Mar 2005 12:52:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEt4w-0007sd-RI; Fri, 25 Mar 2005 12:58:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsyj-0000aG-Tk; Fri, 25 Mar 2005 12:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEsyj-0000aB-Ca for ltru@megatron.ietf.org; Fri, 25 Mar 2005 12:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22915 for ; Fri, 25 Mar 2005 12:52:10 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEt4d-0007sC-MI for ltru@ietf.org; Fri, 25 Mar 2005 12:58:21 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Mar 2005 09:52:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry in record-jar format Date: Fri, 25 Mar 2005 09:52:01 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC29DB2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUxXju5KAPkb8orQVuwZIPyEzvxCwAA9oxQ From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 25 Mar 2005 17:52:01.0438 (UTC) FILETIME=[58FC4BE0:01C53163] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1374564994==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --===============1374564994== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSByZWFsIFhNTCBEVEQgd291bGQgaGF2ZSB0byBiZSBjYXJlZnVsbHkgZGVzaWduZWQuIE15IGV4 YW1wbGUgaW4gdGhlIGVtYWlsIHdhcyB2ZXJ5IG11Y2ggYSBiYWNrLW9mLXRoZS1lbnZlbG9wZSBl eGFtcGxlLg0KDQpJIGFncmVlIHRoYXQgZXZlcnl0aGluZyBoYXMgdG8gYmUgaW4gdGhlIFJGQyBn b3Zlcm5pbmcgdGhlIHJlZ2lzdHJ5LiBJZiB0aGVyZSBhcmUgdG8gYmUgbXVsdGlwbGUgZm9ybWF0 cywgdGhlbiB0aGV5IGFsbCBoYXZlIHRvIGJlIGRvY3VtZW50ZWQsIGFsb25nIHdpdGggdGhlaXIg cHJvZHVjdGlvbiBtZXRob2RzLCBmb3IgSUFOQSBhbmQgb3RoZXJzLg0KDQpUaGUga2V5IGlzIGdl dHRpbmcgY29uc2Vuc3VzIG9uIHdoYXQgdG8gZG8uDQoNClJpZ2h0IG5vdyBJIHRoaW5rIHRoZSBv cHRpb25zIGFyZToNCg0KMS4gQ2hhbmdlIHRvIHJlY29yZC1qYXIgZm9ybWF0Lg0KMi4gQ2hhbmdl IHRvIGFuIFhNTCBmb3JtYXQuIEEgcHJvcGVyIERURCBuZWVkcyB0byBiZSBkZXNpZ25lZCBpbiB0 aGlzIGNhc2UuDQozLiBOZWl0aGVyLg0KNC4gQm90aCAocmVjb3JkLWphciBpcyBub3JtYXRpdmUp DQo1LiBCb3RoIChYTUwgaXMgbm9ybWF0aXZlKQ0KDQpSaWdodCB0aGlzIHNlY29uZCBJIHN1cHBv cnQgKDIpLCBidXQgd291bGQgYmUgKGFsbW9zdCkgYXMgaGFwcHkgd2l0aCAoMSkuDQoNCkFkZGlz b24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0 IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBH cm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4g YXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBs dHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0 Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBNY0RvbmFsZCwgSXJhDQo+IFNlbnQ6IHZlbmRyZWRpIDI1 IG1hcnMgMjAwNSAwOToxNA0KPiBUbzogJ0RvdWcgRXdlbGwnOyBMVFJVIFdvcmtpbmcgR3JvdXAN Cj4gU3ViamVjdDogUkU6IFtMdHJ1XSBSZTogUmVnaXN0cnkgaW4gcmVjb3JkLWphciBmb3JtYXQN Cj4gDQo+IEhpLA0KPiANCj4gUGxlYXNlIGRvbid0IG1pcy11c2UgWE1MIGF0dHJpYnV0ZXMgdG8g YmUgdGhlIGVxdWl2YWxlbnQgb2YNCj4gJ2F0dHJpYnV0ZXMnIGluIHRoZSBvYmplY3Qtb3JpZW50 ZWQgc2Vuc2UuICBUaGV5IGFyZW4ndCBhbmQNCj4gdGhlIHByb3RvY29sIHNwZWNzIEkndmUgc2Vl biB0aGF0IHVzZWQgdGhlbSBjYXVzZWQgbmlnaHRtYXJlcw0KPiB3aGVuIHRyeWluZyB0byBtb3Jw aCB0aGVtIGludG8gcHJvcGVyIGhpZXJhcmNoaWNhbCBlbGVtZW50cy4NCj4gDQo+IEFuZCBiZWFy IGluIG1pbmQgd2hhdCBTY290dCBIb2xsZW5iZWNrIGp1c3QgcmVtaW5kZWQgdXMgYWJvdXQsDQo+ IHRvIHdoaXQsIF9ub3RoaW5nXyBpcyB1cCB0byBJQU5BIHRvIGZpZ3VyZSBvdXQuICBUaGlzIFdH IGhhcw0KPiB0byBzcGVjaWZ5IGNvbXBsZXRlIHByb2Nlc3NlcyBhbmQgZm9ybWF0cyBmb3IgdXNl IGJ5IElBTkEgaW4NCj4gb3VyICdJQU5BIENvbnNpZGVyYXRpb25zJyBzZWN0aW9uLg0KPiANCj4g Q2hlZXJzLA0KPiAtIElyYQ0KPiANCj4gSXJhIE1jRG9uYWxkIChNdXNpY2lhbiAvIFNvZnR3YXJl IEFyY2hpdGVjdCkNCj4gQmx1ZSBSb29mIE11c2ljIC8gSGlnaCBOb3J0aCBJbmMNCj4gUE8gQm94 IDIyMSAgR3JhbmQgTWFyYWlzLCBNSSAgNDk4MzkNCj4gcGhvbmU6ICsxLTkwNi00OTQtMjQzNA0K PiBlbWFpbDogaW1jZG9uYWxkQHNoYXJwbGFicy5jb20NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0 cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ11Pbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBT ZW50OiBGcmlkYXksIE1hcmNoIDI1LCAyMDA1IDI6MDIgQU0NCj4gVG86IExUUlUgV29ya2luZyBH cm91cA0KPiBTdWJqZWN0OiBbTHRydV0gUmU6IFJlZ2lzdHJ5IGluIHJlY29yZC1qYXIgZm9ybWF0 DQo+IA0KPiANCj4gQWRkaXNvbiBQaGlsbGlwcyA8YWRkaXNvbiBkb3QgcGhpbGxpcHMgYXQgcXVl c3QgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IElmIHdlJ3JlIGdvaW5nIHRvIGNvbnNpZGVyIGRp ZmZlcmVudCBmb3JtYXRzIGZvciB0aGUgcmVnaXN0cnksIG1pZ2h0IEkNCj4gPiBzdWdnZXN0IHRo YXQgYW4gZXZlbiBiZXR0ZXIgZm9ybWF0IHdvdWxkIGJlIFhNTD8NCj4gDQo+IFlvdSBtaWdodC4N Cj4gDQo+IE9oLCBhbGwgcmlnaHQsIEknbGwgZG8gYW4gWE1MIHZlcnNpb24gdG9vIGFuZCBwb3N0 IGl0LCBzbyB5b3UgZ3V5cyBjYW4NCj4gc2VlIHRoYXQgb25lIHRvby4NCj4gDQo+IFhNTCBoYXMg YWxsIHRoZSBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIHRoYXQgcGVvcGxlIGhhdmUgbWVu dGlvbmVkDQo+IHNvIGZhciwgYW5kIHByb2JhYmx5IG1hbnkgbW9yZSBvZiBib3RoLiAgWE1MIGlz IHNvcnQgb2YgbGlrZSBDYWxpZm9ybmlhOg0KPiBhbnl0aGluZyBhbnlvbmUgY2FuIHNheSBhYm91 dCBpdCBpcyB0cnVlLg0KPiANCj4gQWN0dWFsbHkgSSBoYWQgd29uZGVyZWQgYmVmb3JlIGFib3V0 IGNvbnZlcnRpbmcgdGhlIHJlZ2lzdHJ5IHRvIFhNTCwgYnV0DQo+IHdhc24ndCBzdXJlIGhvdyBp dCBzaG91bGQgYmUgc3RydWN0dXJlZC4gIChUaGUgZXRlcm5hbCBxdWVzdGlvbjoNCj4gIkVsZW1l bnRzIG9yIGF0dHJpYnV0ZXM/ICBXaGljaCB3aWxsIHNlcnZlIG1lIGJlc3Q/IikgIEZvciB0aGlz IHZlcnNpb24sDQo+IEknbGwgdXNlIEFkZGlzb24ncyBleGFtcGxlIGJsaW5kbHksIGJ1dCB3aXRo b3V0IGFueSBleHRyYSBpbmZvcm1hdGlvbg0KPiAoc3VjaCBhcyBVUkxzKSB0aGF0IGlzbid0IGFs cmVhZHkgaW4gdGhlIGV4aXN0aW5nIHJlZ2lzdHJ5LiAgRG9uJ3QgaG9sZA0KPiB5b3VyIGJyZWF0 aDsgSSdsbCBhbm5vdW5jZSB3aGVuIGl0J3MgcmVhZHkuDQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAg RnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ICBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdl bGwvDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5n IGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============1374564994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1374564994==-- From ltru-bounces@ietf.org Fri Mar 25 13:38:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28422; Fri, 25 Mar 2005 13:38:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEtnb-00013h-9q; Fri, 25 Mar 2005 13:44:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEthM-0008G3-NL; Fri, 25 Mar 2005 13:38:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEthI-0008Ft-UG for ltru@megatron.ietf.org; Fri, 25 Mar 2005 13:38:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28397 for ; Fri, 25 Mar 2005 13:38:13 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEtn9-00013H-Ne for ltru@ietf.org; Fri, 25 Mar 2005 13:44:24 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2PIbq6U001412; Fri, 25 Mar 2005 10:37:56 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77GGW8>; Fri, 25 Mar 2005 10:37:53 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , LTRU Working Group Subject: RE: [Ltru] Re: Registry in record-jar format [choice of formats] Date: Fri, 25 Mar 2005 10:37:52 -0800 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: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Hi, I'm most happy with option 1 (or option 4). Because I'm convinced that record-jar format will be much easier to extract information from when NOT using XML parsers and XML-aware tools. I suppose filters using 'awk' or whatever might level that difference. But personally I write C utilities when I want to extract items from IANA registries. Hand-parsing XML is needless busywork, IMHO. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Addison Phillips Sent: Friday, March 25, 2005 12:52 PM To: LTRU Working Group Subject: RE: [Ltru] Re: Registry in record-jar format A real XML DTD would have to be carefully designed. My example in the email was very much a back-of-the-envelope example. I agree that everything has to be in the RFC governing the registry. If there are to be multiple formats, then they all have to be documented, along with their production methods, for IANA and others. The key is getting consensus on what to do. Right now I think the options are: 1. Change to record-jar format. 2. Change to an XML format. A proper DTD needs to be designed in this case. 3. Neither. 4. Both (record-jar is normative) 5. Both (XML is normative) Right this second I support (2), but would be (almost) as happy with (1). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of McDonald, Ira > Sent: vendredi 25 mars 2005 09:14 > To: 'Doug Ewell'; LTRU Working Group > Subject: RE: [Ltru] Re: Registry in record-jar format > > Hi, > > Please don't mis-use XML attributes to be the equivalent of > 'attributes' in the object-oriented sense. They aren't and > the protocol specs I've seen that used them caused nightmares > when trying to morph them into proper hierarchical elements. > > And bear in mind what Scott Hollenbeck just reminded us about, > to whit, _nothing_ is up to IANA to figure out. This WG has > to specify complete processes and formats for use by IANA in > our 'IANA Considerations' section. > > 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Doug Ewell > Sent: Friday, March 25, 2005 2:02 AM > To: LTRU Working Group > Subject: [Ltru] Re: Registry in record-jar format > > > Addison Phillips wrote: > > > If we're going to consider different formats for the registry, might I > > suggest that an even better format would be XML? > > You might. > > Oh, all right, I'll do an XML version too and post it, so you guys can > see that one too. > > XML has all the advantages and disadvantages that people have mentioned > so far, and probably many more of both. XML is sort of like California: > anything anyone can say about it is true. > > Actually I had wondered before about converting the registry to XML, but > wasn't sure how it should be structured. (The eternal question: > "Elements or attributes? Which will serve me best?") For this version, > I'll use Addison's example blindly, but without any extra information > (such as URLs) that isn't already in the existing registry. Don't hold > your breath; I'll announce when it's ready. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 14:42:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03535; Fri, 25 Mar 2005 14:42:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEunC-0002oX-Fw; Fri, 25 Mar 2005 14:48:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEufo-0007pL-1q; Fri, 25 Mar 2005 14:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEufm-0007pG-Ev for ltru@megatron.ietf.org; Fri, 25 Mar 2005 14:40:46 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03458 for ; Fri, 25 Mar 2005 14:40:44 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEueT-00064G-Hx for ltru@lists.ietf.org; Fri, 25 Mar 2005 20:39:25 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 20:39:25 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 20:39:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 20:32:58 +0100 Organization: Lines: 59 Message-ID: <4244676A.6FAD@xyzzy.claranet.de> References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org><009c01c53105$ac1ce720$030aa8c0@DEWELL> <20050325072710.GA14412@ccil.org> <0e2d01c53157$9d2c0230$727d3009@sanjose.ibm.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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Mark Davis wrote: > This is precisely the problem. They *are* permitted. The obsolete RfC 1766 said: | ISO 639 defines a registration authority for additions to and | changes in the list of languages in ISO 639. This authority | is: [...] ...not an obscure reference in an obsolete RfC. Same idea for ISO 3166-1. The actual RfC 3066 states: | All 2-letter subtags are interpreted as ISO 3166 alpha-2 | country codes from [ISO 3166], or subsequently assigned by | the ISO 3166 maintenance agency or governing standardization | bodies, denoting the area to which this language variant | relates. Later 3066 speculates about the chances of an ISO 639-1:2000 published in 2001, and forbids the user assigned codes AA, ZZ, QM-QZ, and XA-XZ, they were allowed in RfC 1766. SNAFU. It's the purpose of 3066bis to cleanup this mess, not to preserve it. Apparently nobody has a copy of ISO 3166:1988. Doug is forced to guess using private Web pages what this old stuff is about. We found RH, BQ, FQ, and NQ, these codes are irrelevant and disgusting. Nobody recognizes these codes, and nobody needs any ?Q for fantastic languages in the Antarctic. > *nowhere* in 1766 does it say that a code later deprecated in > ISO 639 or 3166 is not valid "additions to and changes in the list". Country codes like NH, BQ, FQ, and NQ are shown as _unassigned_ on the 3166-1 page. Maybe _deprecated_ in ISO 639 is a different issue, but 3166-1 has a clear list of states: officially assigned - examples: AQ, AX, CS user assigned - examples: AA. QQ, XX exceptionally reserved - examples: AC, EU, IM transitionally reserved - examples: BU, NT, SF indeterminately reserved - examples: DY. FL, RH not used at present stage - examples: AP, BX, EF unassigned - examples: BQ, DD, NH "Transitionally reserved" is roughly the same as "deprecated". "Not used at present stage" is plain nonsense not related to any country codes. "Unassigned" is "free / available". "Exceptioally reserved" are the missing ccTLDs and some others. "Indeterminately reserved" is apparently used for car-plates. BTW, Doug has RH as Southern Rhodesia, the ISO 3166-1 Web page has RH as Haiti (indeterminately reserved). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 15:24:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08272; Fri, 25 Mar 2005 15:24:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEvRq-0003y8-Bg; Fri, 25 Mar 2005 15:30:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEvLJ-0005Fu-B5; Fri, 25 Mar 2005 15:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEvLG-0005Fp-Sw for ltru@megatron.ietf.org; Fri, 25 Mar 2005 15:23:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08235 for ; Fri, 25 Mar 2005 15:23:36 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEvRD-0003vu-EV for ltru@ietf.org; Fri, 25 Mar 2005 15:29:47 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2PKNTQS029540 for ; Fri, 25 Mar 2005 15:23:29 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2PKNOgv057786 for ; Fri, 25 Mar 2005 15:23:29 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2PKNOs5022296 for ; Fri, 25 Mar 2005 15:23:24 -0500 Received: from markdavis (sig-9-48-118-49.mts.ibm.com [9.48.118.49]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2PKNNgq022259; Fri, 25 Mar 2005 15:23:23 -0500 Message-ID: <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org><009c01c53105$ac1ce720$030aa8c0@DEWELL><20050325072710.GA14412@ccil.org><0e2d01c53157$9d2c0230$727d3009@sanjose.ibm.com> <4244676A.6FAD@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Question Date: Fri, 25 Mar 2005 12:23:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j2PKNTQS029540 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable People presumed that 3066 was backwards compatible with 1766, and data wa= s generated on that basis. The cost of supporting full backwards compatibil= ity with 1766 and 3066 (for all but the ISO codes that were reused) is extrem= ely low, just a few additional codes. We then don't disturb the stability of tags that were generated in good faith, using codes that at some point in time qualified as 'assigned' in the base standards. On that basis, I think it's a no-brainer. You are the only one I hear saying that we don't care about backward compability with codes that were valid under 1766 and 3066. Anyone else w= ant to speak up for non-backwards compatibility? =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Friday, March 25, 2005 11:32 Subject: [Ltru] Re: Question > Mark Davis wrote: > > > This is precisely the problem. They *are* permitted. > > The obsolete RfC 1766 said: > > | ISO 639 defines a registration authority for additions to and > | changes in the list of languages in ISO 639. This authority > | is: > [...] > > ...not an obscure reference in an obsolete RfC. Same idea for > ISO 3166-1. The actual RfC 3066 states: > > | All 2-letter subtags are interpreted as ISO 3166 alpha-2 > | country codes from [ISO 3166], or subsequently assigned by > | the ISO 3166 maintenance agency or governing standardization > | bodies, denoting the area to which this language variant > | relates. > > Later 3066 speculates about the chances of an ISO 639-1:2000 > published in 2001, and forbids the user assigned codes AA, ZZ, > QM-QZ, and XA-XZ, they were allowed in RfC 1766. > > SNAFU. It's the purpose of 3066bis to cleanup this mess, not > to preserve it. Apparently nobody has a copy of ISO 3166:1988. > Doug is forced to guess using private Web pages what this old > stuff is about. We found RH, BQ, FQ, and NQ, these codes are > irrelevant and disgusting. Nobody recognizes these codes, and > nobody needs any ?Q for fantastic languages in the Antarctic. > > > *nowhere* in 1766 does it say that a code later deprecated in > > ISO 639 or 3166 is not valid > > "additions to and changes in the list". Country codes like NH, > BQ, FQ, and NQ are shown as _unassigned_ on the 3166-1 page. > Maybe _deprecated_ in ISO 639 is a different issue, but 3166-1 > has a clear list of states: > > officially assigned - examples: AQ, AX, CS > user assigned - examples: AA. QQ, XX > exceptionally reserved - examples: AC, EU, IM > transitionally reserved - examples: BU, NT, SF > indeterminately reserved - examples: DY. FL, RH > not used at present stage - examples: AP, BX, EF > unassigned - examples: BQ, DD, NH > > "Transitionally reserved" is roughly the same as "deprecated". > "Not used at present stage" is plain nonsense not related to > any country codes. "Unassigned" is "free / available". > > "Exceptioally reserved" are the missing ccTLDs and some others. > "Indeterminately reserved" is apparently used for car-plates. > > BTW, Doug has RH as Southern Rhodesia, the ISO 3166-1 Web page > has RH as Haiti (indeterminately reserved). > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 16:31:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18806; Fri, 25 Mar 2005 16:31:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwIt-0006O7-W1; Fri, 25 Mar 2005 16:25:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwBR-0005ul-SS; Fri, 25 Mar 2005 16:17:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwBQ-0005ug-92 for ltru@megatron.ietf.org; Fri, 25 Mar 2005 16:17:32 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18274 for ; Fri, 25 Mar 2005 16:17:29 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DEwAV-0000Cb-Kv for ltru@lists.ietf.org; Fri, 25 Mar 2005 22:16:35 +0100 Received: from d252094.dialin.hansenet.de ([80.171.252.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 22:16:35 +0100 Received: from nobody by d252094.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2005 22:16:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 25 Mar 2005 22:15:27 +0100 Organization: Lines: 11 Message-ID: <42447F6F.1C56@xyzzy.claranet.de> References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org><009c01c53105$ac1ce720$030aa8c0@DEWELL><20050325072710.GA14412@ccil.org><0e2d01c53157$9d2c0230$727d3009@sanjose.ibm.com> <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.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: d252094.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Mark Davis wrote: > People presumed that 3066 was backwards compatible with 1766, > and data was generated on that basis. You're talking about country codes valid 1995 (RfC 1766 and later). I'm talking about country codes invalid 1994 (before RfC 1766), "unassigned" and similar cases like RH, NH, FQ, DD. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 16:41:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19747; Fri, 25 Mar 2005 16:41:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwep-0007OA-3C; Fri, 25 Mar 2005 16:47:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwXP-0000UU-0f; Fri, 25 Mar 2005 16:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwXK-0000UP-U5 for ltru@megatron.ietf.org; Fri, 25 Mar 2005 16:40:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19617 for ; Fri, 25 Mar 2005 16:40:08 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwdH-0007MY-LT for ltru@ietf.org; Fri, 25 Mar 2005 16:46:20 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1DEwXC-0002ZT-7N; Fri, 25 Mar 2005 16:40:02 -0500 Date: Fri, 25 Mar 2005 16:40:02 -0500 To: Mark Davis Subject: Re: [Ltru] Re: Question Message-ID: <20050325214002.GB14412@ccil.org> References: <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f9901c53178$7de93840$727d3009@sanjose.ibm.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@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Mark Davis scripsit: > You are the only one I hear saying that we don't care about backward > compability with codes that were valid under 1766 and 3066. Anyone else want > to speak up for non-backwards compatibility? I deny that 3166 codes obsoleted before 1995-03-01 were ever valid in 1766 or 3066, so I agree with your statement de dicto, but I disagree with it de re. I believe that Addison agrees. -- 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.reutershealth.com --gadicath http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 17:37:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23708; Fri, 25 Mar 2005 17:37:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DExWW-0000u0-RB; Fri, 25 Mar 2005 17:43:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DExPB-0000S9-2Q; Fri, 25 Mar 2005 17:35:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DExP9-0000Rz-K7 for ltru@megatron.ietf.org; Fri, 25 Mar 2005 17:35:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23594 for ; Fri, 25 Mar 2005 17:35:44 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DExV6-0000oc-8U for ltru@ietf.org; Fri, 25 Mar 2005 17:41:57 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Mar 2005 14:35:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Question Date: Fri, 25 Mar 2005 14:35:26 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC29F63@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Question Thread-Index: AcUxg2zhboKO+6ntRH6mRNJ3D1cizgAB37wg From: "Addison Phillips" To: "John Cowan" , "Mark Davis" X-OriginalArrivalTime: 25 Mar 2005 22:35:27.0177 (UTC) FILETIME=[F1322390:01C5318A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable +1 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: vendredi 25 mars 2005 13:40 > To: Mark Davis > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Question >=20 > Mark Davis scripsit: >=20 > > You are the only one I hear saying that we don't care about backward > > compability with codes that were valid under 1766 and 3066. Anyone = else > want > > to speak up for non-backwards compatibility? >=20 > I deny that 3166 codes obsoleted before 1995-03-01 were ever valid in > 1766 or 3066, so I agree with your statement de dicto, but I disagree > with it de re. I believe that Addison agrees. >=20 > -- > 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.reutershealth.com > --gadicath = http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 17:51:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24875; Fri, 25 Mar 2005 17:51:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DExkK-0001QB-3H; Fri, 25 Mar 2005 17:57:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DExd4-0002Ua-O7; Fri, 25 Mar 2005 17:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DExd3-0002T8-89 for ltru@megatron.ietf.org; Fri, 25 Mar 2005 17:50:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24661 for ; Fri, 25 Mar 2005 17:50:06 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DExj1-0001KO-CA for ltru@ietf.org; Fri, 25 Mar 2005 17:56:19 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2PMnxlF008900 for ; Fri, 25 Mar 2005 17:49:59 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2PMnxgv067774 for ; Fri, 25 Mar 2005 17:49:59 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2PMnxos008974 for ; Fri, 25 Mar 2005 17:49:59 -0500 Received: from markdavis (sig-9-48-118-49.mts.ibm.com [9.48.118.49]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2PMnwgd008924; Fri, 25 Mar 2005 17:49:58 -0500 Message-ID: <0fdd01c5318c$f82628c0$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" References: <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> <20050325214002.GB14412@ccil.org> Subject: Re: [Ltru] Re: Question Date: Fri, 25 Mar 2005 14:49:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j2PMnxlF008900 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Joe Blow was deciding whether his code should allow "en-BU" as a valid co= de according to 1766. He looks at the text and finds: In the first subtag: - All 2-letter codes are interpreted as ISO 3166 alpha-2 country codes denoting the area in which the language is used.In the references, he sees: [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15. So he looks at ISO 3166:1988. There he finds that BU was perfectly valid. And since 'en' was also, and the rest of the syntax was fine, it must be = a valid language tag. That is a perfectly reasonable interpretation on Joe'= s part. Part of the problem, of course, *was* that 1766 and 3066 were not v= ery specific as to validity and stability. That is part of the reason that we are being very careful about this in 3066bis! Now, if we were talking about a large percentage of the codespace here, I might agree that it is worth sacrificing backwards compatibility for thes= e codes. But since there are only a few, let's just include the darned thin= gs for backwards compatibility and move on to do something more productive. =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: "Mark Davis" Cc: Sent: Friday, March 25, 2005 13:40 Subject: Re: [Ltru] Re: Question > Mark Davis scripsit: > > > You are the only one I hear saying that we don't care about backward > > compability with codes that were valid under 1766 and 3066. Anyone el= se want > > to speak up for non-backwards compatibility? > > I deny that 3166 codes obsoleted before 1995-03-01 were ever valid in > 1766 or 3066, so I agree with your statement de dicto, but I disagree > with it de re. I believe that Addison agrees. > > --=20 > 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.reutershealth.com > --gadicath http://www.ccil.org/~co= wan > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 18:24:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28968; Fri, 25 Mar 2005 18:24:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyFr-0002Wn-OW; Fri, 25 Mar 2005 18:30:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEy8W-0007Pb-V5; Fri, 25 Mar 2005 18:22:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEy8W-0007PW-0p for ltru@megatron.ietf.org; Fri, 25 Mar 2005 18:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28873 for ; Fri, 25 Mar 2005 18:22:37 -0500 (EST) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyET-0002UI-IR for ltru@ietf.org; Fri, 25 Mar 2005 18:28:50 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1DEy8L-0000GH-Pr; Fri, 25 Mar 2005 18:22:29 -0500 Date: Fri, 25 Mar 2005 18:22:29 -0500 To: Mark Davis Subject: Re: [Ltru] Re: Question Message-ID: <20050325232229.GF14412@ccil.org> References: <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> <20050325214002.GB14412@ccil.org> <0fdd01c5318c$f82628c0$727d3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0fdd01c5318c$f82628c0$727d3009@sanjose.ibm.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Mark Davis scripsit: > So he looks at ISO 3166:1988. There he finds that BU was perfectly valid. Does he not also find a statement that the code list in ISO 3166:1988 is subject to revision by the 3166/MA? That's a serious question; I have never seen a copy of 3166:1988. Jesuitical it may be, but it seems to me that discontinued 3166 codes are not part of 3166. > Now, if we were talking about a large percentage of the codespace here, I > might agree that it is worth sacrificing backwards compatibility for these > codes. But since there are only a few, let's just include the darned things > for backwards compatibility and move on to do something more productive. The reason it matters is that there's a good chance some of those codes will be used again someday, in which case it's going to be awfully lame to say "Well, that code was used for the French claims to Antarctica half a century or more ago, so you can't have it." That's taking stability to an insane level, particularly as there are no sensible xx-FQ language tags and never will be. -- 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 18:24:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29051; Fri, 25 Mar 2005 18:24:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyGR-0002ay-JQ; Fri, 25 Mar 2005 18:30:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEy8A-0007LA-PE; Fri, 25 Mar 2005 18:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEy88-0007L5-UB for ltru@megatron.ietf.org; Fri, 25 Mar 2005 18:22:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28766 for ; Fri, 25 Mar 2005 18:22:13 -0500 (EST) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEyE7-0002U1-A3 for ltru@ietf.org; Fri, 25 Mar 2005 18:28:27 -0500 Received: from snv-lobby-rtr.corp.yahoo.com (HELO xencraft.com) (216.145.49.17) by smtp04.mrf.mail.rcn.net with ESMTP; 25 Mar 2005 18:22:11 -0500 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.8.1]); Fri, 25 Mar 2005 15:22:10 -0800 Message-ID: <42449D22.912D2F78@i18nguy.com> Date: Fri, 25 Mar 2005 15:22:10 -0800 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Question References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org><009c01c53105$ac1ce720$030aa8c0@DEWELL><20050325072710.GA14412@ccil.org><0e2d01c53157$9d2c0230$727d3009@sanjose.ibm.com> <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit The question of speaking up for no-BC is a bit loaded when asked in that way. I would not mind forgoing backward compatibility if there were compensating benefits. I would need to believe that the benefits were real, and also that there weren't a number of hidden dangers that might be more problematic than dealing with the cost of legacy. But given the ambiguities in the legacy of language tags, and its different usages by different technologies, I can certainly see creating a new scheme. In fact would want it to look different so it didnt suffer the confusion and baggage of the current system. I said this a few years ago as well when we discussed solving the problems I raised in the locales paper for the Unicode conference. I would still welcome a new approach. I don't see however, that we have a way to articulate a clean solution. The problem I see is not in architecting the scheme for tagging, but determining what a language is, in a useful way for software developers, so that they can understand which language tag to use, and not an identification which only linguists recognize or criteria which are not clearly expressed. So yes, forget compatibility if I can have a scheme that works. On the other hand, if we maintain compatibility and make the current system more complex and no more usable, I don't need that either. I would welcome a clear set of rules for choosing a tag for content, and rules for finding content with known tags. tex Mark Davis wrote: > > People presumed that 3066 was backwards compatible with 1766, and data was > generated on that basis. The cost of supporting full backwards compatibility > with 1766 and 3066 (for all but the ISO codes that were reused) is extremely > low, just a few additional codes. We then don't disturb the stability of > tags that were generated in good faith, using codes that at some point in > time qualified as 'assigned' in the base standards. > > On that basis, I think it's a no-brainer. > > You are the only one I hear saying that we don't care about backward > compability with codes that were valid under 1766 and 3066. Anyone else want > to speak up for non-backwards compatibility? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 20:08:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08522; Fri, 25 Mar 2005 20:08:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEzsp-0006Rn-Em; Fri, 25 Mar 2005 20:14:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEzl8-0007Z2-I4; Fri, 25 Mar 2005 20:06:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEzl7-0007Ys-Ff for ltru@megatron.ietf.org; Fri, 25 Mar 2005 20:06:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08384 for ; Fri, 25 Mar 2005 20:06:28 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEzr1-0006QC-Hs for ltru@ietf.org; Fri, 25 Mar 2005 20:12:43 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2Q16MLP021680 for ; Fri, 25 Mar 2005 20:06:22 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2Q16Igv076006 for ; Fri, 25 Mar 2005 20:06:22 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2Q16IYe018716 for ; Fri, 25 Mar 2005 20:06:18 -0500 Received: from markdavis (sig-9-48-118-49.mts.ibm.com [9.48.118.49]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2Q16HJ9018687; Fri, 25 Mar 2005 20:06:18 -0500 Message-ID: <104a01c531a0$037b7c80$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" References: <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> <20050325214002.GB14412@ccil.org> <0fdd01c5318c$f82628c0$727d3009@sanjose.ibm.com> <20050325232229.GF14412@ccil.org> Subject: Re: [Ltru] Re: Question Date: Fri, 25 Mar 2005 17:06:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j2Q16MLP021680 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Look, we regularly get beaten up by various IETF people for the backwards compatibility of the Unicode Standard. I hate to see IETF take a much mor= e lackadaisical approach to language tags. I'm ok with excluding codes that= no reasonable person would believe is was valid at some time according to th= e text of 1766 and 3066. And if we start down the road of judging each individual case according t= o whether we think it was "lame" or not, we will just tie ourselves up in knots. We have a bright line; let's use it. We should simply not break backward compatibility, when the only benefit is having a very small numb= er of additional codes. =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: "Mark Davis" Cc: Sent: Friday, March 25, 2005 15:22 Subject: Re: [Ltru] Re: Question > Mark Davis scripsit: > > > So he looks at ISO 3166:1988. There he finds that BU was perfectly valid. > > Does he not also find a statement that the code list in ISO 3166:1988 > is subject to revision by the 3166/MA? That's a serious question; > I have never seen a copy of 3166:1988. > > Jesuitical it may be, but it seems to me that discontinued 3166 codes > are not part of 3166. > > > Now, if we were talking about a large percentage of the codespace her= e, I > > might agree that it is worth sacrificing backwards compatibility for these > > codes. But since there are only a few, let's just include the darned things > > for backwards compatibility and move on to do something more producti= ve. > > The reason it matters is that there's a good chance some of those codes > will be used again someday, in which case it's going to be awfully lame > to say "Well, that code was used for the French claims to Antarctica ha= lf > a century or more ago, so you can't have it." That's taking stability > to an insane level, particularly as there are no sensible xx-FQ languag= e > tags and never will be. > > --=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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 25 22:00:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19480; Fri, 25 Mar 2005 22:00:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF1dZ-0001wa-8b; Fri, 25 Mar 2005 22:06:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF1W5-0000Ja-Lt; Fri, 25 Mar 2005 21:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF1W4-0000J3-7O for ltru@megatron.ietf.org; Fri, 25 Mar 2005 21:59:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19187 for ; Fri, 25 Mar 2005 21:59:09 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF1c3-0001qR-Dv for ltru@ietf.org; Fri, 25 Mar 2005 22:05:24 -0500 Received: from lns-p19-1-idf-82-251-133-194.adsl.proxad.net ([82.251.133.194] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DF1Vz-0005LI-9w; Fri, 25 Mar 2005 18:59:07 -0800 Message-Id: <6.1.2.0.2.20050326033958.04242d70@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 26 Mar 2005 03:40:35 +0100 To: "McDonald, Ira" , "'Addison Phillips'" , LTRU Working Group From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Registry in record-jar format [choice of formats] In-Reply-To: References: Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab At 19:37 25/03/2005, McDonald, Ira wrote: >Hi, > >I'm most happy with option 1 (or option 4). > >Because I'm convinced that record-jar format will >be much easier to extract information from when NOT >using XML parsers and XML-aware tools. > >I suppose filters using 'awk' or whatever might level >that difference. But personally I write C utilities >when I want to extract items from IANA registries. >Hand-parsing XML is needless busywork, IMHO. idem. Full agreement. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 06:41:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17344; Sat, 26 Mar 2005 06:41:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF9lK-00022o-46; Sat, 26 Mar 2005 06:47:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF9eA-0006EJ-1z; Sat, 26 Mar 2005 06:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF9e8-0006D5-Kt for ltru@megatron.ietf.org; Sat, 26 Mar 2005 06:40:04 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17279 for ; Sat, 26 Mar 2005 06:40:01 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DF9dd-0004t7-93 for ltru@lists.ietf.org; Sat, 26 Mar 2005 12:39:33 +0100 Received: from du-001-124.access.de.clara.net ([212.82.227.124]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Mar 2005 12:39:33 +0100 Received: from nobody by du-001-124.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Mar 2005 12:39:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 26 Mar 2005 12:38:33 +0100 Organization: Lines: 22 Message-ID: <424549B9.51EB@xyzzy.claranet.de> References: <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> <20050325214002.GB14412@ccil.org> <0fdd01c5318c$f82628c0$727d3009@sanjose.ibm.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-124.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gil-ltru@m.gmane.org X-MailScanner-To: ltru@lists.ietf.org Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Mark Davis wrote: > Joe Blow was deciding whether his code should allow "en-BU" That's a sad story, like Jane Blog's adventure in cyberspace: Seeing RH on a car in Haiti she checks the ISO 3166-1 Web page and finds something about "RH Haiti" as expected, So she tags a Creole text with fr-RH, and later she's surprised when her job application is returned by the ZW embassy. > let's just include the darned things for backwards > compatibility and move on to do something more productive. The most serious problem with the actual draft is, that it forces us to choose between an erroneous concept of backwards compatibility and compatibility with future country codes for the known list of "invalid" country codes. At least for the decade 1995 - 2005 we can get one unambiguous idea of "valid". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 10:58:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07270; Sat, 26 Mar 2005 10:58:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFDmV-0002ER-Dr; Sat, 26 Mar 2005 11:04:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFDeu-00054K-Nx; Sat, 26 Mar 2005 10:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFDet-00053o-HZ for ltru@megatron.ietf.org; Sat, 26 Mar 2005 10:57:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07158 for ; Sat, 26 Mar 2005 10:57:05 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFDkz-0002CW-PH for ltru@ietf.org; Sat, 26 Mar 2005 11:03:27 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFDep-000502-Jp; Sat, 26 Mar 2005 07:57:04 -0800 Message-Id: <6.1.2.0.2.20050326141650.032d8b80@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 26 Mar 2005 14:27:35 +0100 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Question In-Reply-To: <424549B9.51EB@xyzzy.claranet.de> References: <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> <20050325214002.GB14412@ccil.org> <0fdd01c5318c$f82628c0$727d3009@sanjose.ibm.com> <424549B9.51EB@xyzzy.claranet.de> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 At 12:38 26/03/2005, Frank Ellermann wrote: >Mark Davis wrote: > > > Joe Blow was deciding whether his code should allow "en-BU" > >That's a sad story, like Jane Blog's adventure in cyberspace: > >Seeing RH on a car in Haiti she checks the ISO 3166-1 Web >page and finds something about "RH Haiti" as expected, So >she tags a Creole text with fr-RH, and later she's surprised >when her job application is returned by the ZW embassy. > > > let's just include the darned things for backwards > > compatibility and move on to do something more productive. > >The most serious problem with the actual draft is, that it >forces us to choose between an erroneous concept of backwards >compatibility and compatibility with future country codes for >the known list of "invalid" country codes. At least for the >decade 1995 - 2005 we can get one unambiguous idea of "valid". I do not understand this problem. Are versioning and conflicts not supported by CVS for example? UDC just choses to update its change on Jan 1st every year as did Internet when created. Every military publication in the world, every legal texts, every commercial catalog, etc. has the same problem. if AI was valid until 31/12/77 there are three entries in the tables: AI77 262 AI 660 DJ 262 = 18 bytes 262 Djibouti 660 Anguilla = 22 bytes The application will use the date of the file to know the proper value of "AI". This covers years -32.000 to + 32,000 . The requirement is only that a datetag is provided or obtained from the file directory. jfc J-F C. MORFIN UTEL, President _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 11:25:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09140; Sat, 26 Mar 2005 11:25:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFECX-00034z-GG; Sat, 26 Mar 2005 11:31:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFE62-00006F-AA; Sat, 26 Mar 2005 11:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFE60-00005q-CL for ltru@megatron.ietf.org; Sat, 26 Mar 2005 11:25:08 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09037 for ; Sat, 26 Mar 2005 11:25:05 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050326162436.SJHK5402.mta11.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 11:24:36 -0500 Message-ID: <008d01c53220$4689b7a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 08:24:24 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> You can now buy a 512 MB JumpDrive for 40 USD, or a 200 GB >> hard drive for 100 USD > > I'm not planning to buy a new hard drive only to read a IANA > registry with language tags ;-) I said the registry would grow by 600,000 bytes. I don't think that's quite big enough to require you to buy a new hard drive. My point was that 600,000 bytes isn't all that much in comparison to the things we store and pass around nowadays. That's less than half a floppy disk, and everyone knows we don't use floppies any more because they're considered too small to hold anything useful. > I trust that IANA will split > it when necessary on its Web pages, and as you said it's no > problem for a 3066bis without the future ISO 639-3 languages. Whether the registry gets split into pieces is, I suppose, IANA's business. I would have thought the extra hassle of downloading and maintaining multiple files would militate against this. And it's still a non-issue until ISO 639-3 codes become available as extended-language subtags, which won't happen until (a) ISO 639-3 is published and (b) the registry RFC we are working on is updated to accommodate them. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 11:39:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10354; Sat, 26 Mar 2005 11:39:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFEPh-0003XF-Lv; Sat, 26 Mar 2005 11:45:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFEIQ-00022l-1p; Sat, 26 Mar 2005 11:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFEIO-00022A-6G for ltru@megatron.ietf.org; Sat, 26 Mar 2005 11:37:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10235 for ; Sat, 26 Mar 2005 11:37:54 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFEOU-0003TH-SK for ltru@ietf.org; Sat, 26 Mar 2005 11:44:16 -0500 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sat, 26 Mar 2005 16:37:44 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IDY00179WUR2F@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sat, 26 Mar 2005 16:37:39 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sat, 26 Mar 2005 16:37:43 +0000 Date: Sat, 26 Mar 2005 16:37:42 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: Registry in record-jar format To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcUyIIu0ND+CeVviRuO3Z4+K4dqO7QAARJew content-class: urn:content-classes:message X-OriginalArrivalTime: 26 Mar 2005 16:37:43.0600 (UTC) FILETIME=[2251F300:01C53222] X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Doug Ewell wrote: =20 My point was that 600,000 bytes isn't all that much in comparison to the things we store and pass around nowadays. That's less than half a floppy disk, and everyone knows we don't use floppies any more because they're considered too small to hold anything useful. Do you have in mind an 8 inch or a 5.25 inch floppy disk? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 12:15:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13029; Sat, 26 Mar 2005 12:15:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFEyu-0004iN-NO; Sat, 26 Mar 2005 12:21:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFEs5-0007Lb-QK; Sat, 26 Mar 2005 12:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFEs4-0007LT-Sq for ltru@megatron.ietf.org; Sat, 26 Mar 2005 12:14:48 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12992 for ; Sat, 26 Mar 2005 12:14:46 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050326171417.VQRG4618.mta13.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 12:14:17 -0500 Message-ID: <000801c53227$3ba04640$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 09:14:12 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > I extensively use my footer to evangelize about this WG's work (it > informs people and leave them free to make their mind). I would > appreciate (as well as anyone else maintaining a file on line of > relevance to this work) to give the exact wording they wish I add for > their file. "Extensive" is the word, all right. I have other words for it as well. Your signature block: * is 33 lines and almost 2000 characters long, far beyond the accepted limits for Internet mail; * implies that we are trying "to standardize languages and to unify the world under a dominant culture," which is not only demonstrably inaccurate but highly offensive as well; * includes a Jon Postel quote, the relevance of which is puzzling at best, since region subtags *are* based on ISO 3166 codes, at least as much so as ccTLDs; * includes a Brian Carpenter quote, also with dubious relevance, since ccTLDs and regions in language tags are not "the same problem," and do not therefore require the same solution, especially in the context of "protocol functionality"; * makes a comparison between ISO 3166 and ISO "693" [sic] which is puzzling and obscure even without the lingering typo. Instead of adding even more wording, I would suggest a simple signature block of no more than four lines (some say six is acceptable), with your name, e-mail address, affiliation, maybe a single short quote, and probably a link to the LTRU archive so interested people can visit, join, and make their own judgments. They don't need "evangelizing." Now, back on topic. >> (BTW, nobody has commented yet on my recipe for populating the >> language subtags, so I assume there's nothing dreadfully wrong with >> it. I'll do the other sections in similar fashion, perhaps this >> weekend.) > > Could you please make it a clean part that we could include in our > Draft? I'm working on it. Easter weekend activities may prevent me from posting additional installments in the next few days, but it is on its way. I think the current theory is indeed to put the description in the draft, rather than relying on the pre-built registry. > The problem as usual is the usage made of it, and the load imposed on > IANA and private mirrors... > > Another point we try to consider is the developing countries and > islands problems. ADSL US or European or Korean traffic costs nothing. > But 600,0000 at real 500 characters per second or less is 1200 > seconds. When you know that in some countries one hour of internet > equals one day work salary, you see the digital divide this represents > for some of the really most involved searchers. Happily, nobody will be required to download a fresh copy of the registry every time they wish to read or write a language tag. Section 4, "Security Considerations," says: "Although the specification of valid subtags for an extension MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks." This applies to cost-of-access concerns as well as security concerns. > Permitting people to exchange in different languages over real time > information is of the essence for international assistance for > example. So languages, terminology, etc. are an important elements. > But at the same time we need to qualify that information, to keep it > as dense as possible, to "culturalize it" to that end (because a DoS > costs too much - and this is why IP is not a proper vehicle, and > IPSec is costly). This is where you find that ISO 3166 is of > importance but it does not address the diaspora, the immigration, de > cultural, the corporate, the reader/viewers classes, etc. This is > where you understand that Governments on_the_network are also > perceived through their e-regalian embodiment of services - and > possible interference with CRCs. I don't see what 90% of this has to do with language tags -- surprise -- but I would suggest that ISO 3166-based region subtags used to indicate "language variations used in a specific region, geographic, or political area" apply equally well to a diaspora or to other types of immigrants. That is, if you were a Frenchman living in Canada, your language variety might well be "fr-FR" rather than "fr-CA", and in some cases it might be important to tag that distinction. Newer versions of Windows include a "region" setting in Control Panel, distinct from the traditional "language variant/locale" setting that has always been there. The idea is that (assuming the above scenario) you could set your language and other locale preferences to "French as used in France," but still specify that you are physically in Canada for applications where that matters. > FYI our DIA effort will be dedicated to IEMS a small team of a WU shop > who had started an inter-mail systems bridge. Mexico City known a big > earth break and for hours all the international assistance > coordination went though one of their customer's mail system to their > ITT mailbox. No one really praised them, but many lifes and > sufferances were spared that day because of their small async 300 bps > service. Their efforts are much appreciated. Please reassure them that they will not be required to perform a 20-minute download to tag their text. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 12:23:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13676; Sat, 26 Mar 2005 12:23:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFF6u-0004xh-7n; Sat, 26 Mar 2005 12:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFF0T-0008UN-F9; Sat, 26 Mar 2005 12:23:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFF0S-0008TV-8D for ltru@megatron.ietf.org; Sat, 26 Mar 2005 12:23:28 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13637 for ; Sat, 26 Mar 2005 12:23:25 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050326172256.VYZM4618.mta13.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 12:22:56 -0500 Message-ID: <001301c53228$6fc9bd60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 09:22:49 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Shelf life of data (was: Re: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Retro compatibility is offered for a long nowhere. Try to use your > 1930 telephone set, I am not sure it will work. Try to publish an > Internet 1990 terminology. Try to use the root servers file of 1995, > it will may be still work partly. Try to use DOS on your PC, it works > very well, but you are missing a lot of things. People have been quoting RFC 822, which is 23 years old, on this list. Even though it has been updated by RFC 2822, obviously many of the basic philosophies and terminology still apply. > Objection to a decade obsolecense cycle? It's much too general to apply blindly. Some standards and technologies are obsolete within a year or two; others are good for decades. ASCII is 42 years old (or 38, depending on what you mean by "ASCII"), and yet many people still consider it the lowest common denominator necessary to ensure reliable communications. There's nothing magic about 10 years. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 16:13:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00872; Sat, 26 Mar 2005 16:13:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFIgw-0003w0-Ii; Sat, 26 Mar 2005 16:19:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFIZa-0002mQ-De; Sat, 26 Mar 2005 16:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFIZY-0002m3-2J for ltru@megatron.ietf.org; Sat, 26 Mar 2005 16:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00728 for ; Sat, 26 Mar 2005 16:11:51 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFIfe-0003r7-St for ltru@ietf.org; Sat, 26 Mar 2005 16:18:15 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFIZK-0007uE-ME; Sat, 26 Mar 2005 13:11:43 -0800 Message-Id: <6.1.2.0.2.20050326210800.043a07e0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 26 Mar 2005 22:06:26 +0100 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format In-Reply-To: <000801c53227$3ba04640$030aa8c0@DEWELL> References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> <000801c53227$3ba04640$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Dear Doug, I will certainly be polite and address all your points, but I hope that at the end of the day you will read and accept what I say in responding your first part. We are both accustomed to the political aspects and tricks of normalization. On 18:14 26/03/2005, Doug Ewell said: >JFC (Jefsey) Morfin wrote: > > > I extensively use my footer to evangelize about this WG's work (it > > informs people and leave them free to make their mind). I would > > appreciate (as well as anyone else maintaining a file on line of > > relevance to this work) to give the exact wording they wish I add for > > their file. > >"Extensive" is the word, all right. I have other words for it as well. "Of or relating to the cultivation of vast areas of land with a minimum of labor or expense". Yes. >Your signature block: >* is 33 lines and almost 2000 characters long, far beyond the accepted >limits for Internet mail; Reference? 1869 bytes isn't all that much in comparison to the things we store and pass around nowadays. >* implies that we are trying "to standardize languages and to unify the >world under a dominant culture," which is not only demonstrably >inaccurate but highly offensive as well; It implies nothing. It is a very lenient form of the comments I hear all the day long about this work. I am not sure why you oppose it? >* includes a Jon Postel quote, the relevance of which is puzzling at >best, since region subtags *are* based on ISO 3166 codes, at least as >much so as ccTLDs; So, I do not see why it is puzzling? >* includes a Brian Carpenter quote, also with dubious relevance, since >ccTLDs and regions in language tags are not "the same problem," and do >not therefore require the same solution, especially in the context of >"protocol functionality"; IMHO this is inaccurate and highly offensive as well, if you accept to think about what you say implies. >* makes a comparison between ISO 3166 and ISO "693" [sic] which is >puzzling and obscure even without the lingering typo. Thank you for correcting the typo. This remark is puzzling and obscure to me. >Instead of adding even more wording, I would suggest a simple signature >block of no more than four lines (some say six is acceptable), with your >name, e-mail address, affiliation, maybe a single short quote, and >probably a link to the LTRU archive so interested people can visit, >join, and make their own judgments. They don't need "evangelizing." Thank you, dad, for your advise. We really live in two worlds appart :-) >Now, back on topic. > > >> (BTW, nobody has commented yet on my recipe for populating the > >> language subtags, so I assume there's nothing dreadfully wrong with > >> it. I'll do the other sections in similar fashion, perhaps this > >> weekend.) > > > > Could you please make it a clean part that we could include in our > > Draft? > >I'm working on it. Easter weekend activities may prevent me from osting >additional installments in the next few days, but it is on its way. Yes. Thank you. Same for me. I may have an extra week delay, because a lot of printing I ordered for our work is delayed: the printing shop closed for the Easter WE .... >I think the current theory is indeed to put the description in the draft, >rather than relying on the pre-built registry. IMHO it would be better in a second RFC. To preserve the weight of the main RFC (when quoted, printed). To permit to update that RFC separately. > > The problem as usual is the usage made of it, and the load imposed on > > IANA and private mirrors... > > > > Another point we try to consider is the developing countries and > > islands problems. ADSL US or European or Korean traffic costs nothing. > > But 600,0000 at real 500 characters per second or less is 1200 > > seconds. When you know that in some countries one hour of internet > > equals one day work salary, you see the digital divide this represents > > for some of the really most involved searchers. > >Happily, nobody will be required to download a fresh copy of the >registry every time they wish to read or write a language tag. Section >4, "Security Considerations," says: > >"Although the specification of valid subtags for an extension MUST be >available over the Internet, implementations SHOULD NOT mechanically >depend on it being always accessible, to prevent denial-of-service >attacks." > >This applies to cost-of-access concerns as well as security concerns. I am afraid you missed the concern. SHOULD NOT is not a MUST NOT. You should understand that the format will make a lot of difference. If the presentation is in XML the unnecessary usage will probably be 10 times larger. There is a good example: the http://ref-editor.org In 1200 days there have been 1.800.000, ie 1500 accesses a day. What is far lower. But you understand that 600.000 bytes are not the 3 to 10 000 bytes of an RFC. This Draft must define all that in detail in IANA considerations. The solution requested must be workable. I know that our Chairs do not want Doug Barton to share in this WG, but we would certainly need to have precise inputs. I want also to underline that the figure I quote are not for "every time", but very conservative (1 a year) as you call for. > > Permitting people to exchange in different languages over real time > > information is of the essence for international assistance for > > example. So languages, terminology, etc. are an important elements. > > But at the same time we need to qualify that information, to keep it > > as dense as possible, to "culturalize it" to that end (because a DoS > > costs too much - and this is why IP is not a proper vehicle, and > > IPSec is costly). This is where you find that ISO 3166 is of > > importance but it does not address the diaspora, the immigration, de > > cultural, the corporate, the reader/viewers classes, etc. This is > > where you understand that Governments on_the_network are also > > perceived through their e-regalian embodiment of services - and > > possible interference with CRCs. > >I don't see what 90% of this has to do with language tags -- surprise -- >but I would suggest that ISO 3166-based region subtags used to indicate >"language variations used in a specific region, geographic, or political >area" apply equally well to a diaspora or to other types of immigrants. >That is, if you were a Frenchman living in Canada, your language variety >might well be "fr-FR" rather than "fr-CA", and in some cases it might be >important to tag that distinction. > >Newer versions of Windows include a "region" setting in Control Panel, >distinct from the traditional "language variant/locale" setting that has >always been there. The idea is that (assuming the above scenario) you >could set your language and other locale preferences to "French as used >in France," but still specify that you are physically in Canada for >applications where that matters. Thank you for the 10% (in standardization, there are not such a way as %, if there is a need it must be supported 100% or not). What you quote about Microsoft is interesting. But it looks like a way to tune an obligation imposed elsewhere? (if you speak French and are in Canada you are supposed to speak fr-CA?). But this is a good point. I recall you that my lang5tag proposition is not only in line with every dictionary, but also with Word and with the "preferences" quoted in the Charter. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 16:13:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00924; Sat, 26 Mar 2005 16:13:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFIhM-0003wM-7K; Sat, 26 Mar 2005 16:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFIZa-0002mM-8x; Sat, 26 Mar 2005 16:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFIZY-0002lx-2L for ltru@megatron.ietf.org; Sat, 26 Mar 2005 16:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00730 for ; Sat, 26 Mar 2005 16:11:51 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFIfe-0003r9-Sx for ltru@ietf.org; Sat, 26 Mar 2005 16:18:16 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFIZM-0007uE-8k; Sat, 26 Mar 2005 13:11:44 -0800 Message-Id: <6.1.2.0.2.20050326220722.03a5bad0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 26 Mar 2005 22:11:12 +0100 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Shelf life of data (was: Re: Question) In-Reply-To: <001301c53228$6fc9bd60$030aa8c0@DEWELL> References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <001301c53228$6fc9bd60$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d At 18:22 26/03/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > Retro compatibility is offered for a long nowhere. Try to use your > > 1930 telephone set, I am not sure it will work. Try to publish an > > Internet 1990 terminology. Try to use the root servers file of 1995, > > it will may be still work partly. Try to use DOS on your PC, it works > > very well, but you are missing a lot of things. > >People have been quoting RFC 822, which is 23 years old, on this list. >Even though it has been updated by RFC 2822, obviously many of the basic >philosophies and terminology still apply. I do not fully understand how the point applies here. What we decided in 1984 and which still makes the today namespace was in line with fundamental principles (root name concept). It will certainly last for ever as intrisic to a name space. > > Objection to a decade obsolecense cycle? > >It's much too general to apply blindly. Some standards and technologies >are obsolete within a year or two; others are good for decades. ASCII >is 42 years old (or 38, depending on what you mean by "ASCII"), and yet >many people still consider it the lowest common denominator necessary to >ensure reliable communications. > >There's nothing magic about 10 years. Nothing. In real life you need to take decisions. When you need something to be applied, you need a good mnemonic. It also turns out from experience that a decade seems to be the absolecense cycle of the technology itself. Take care. Happy Easter. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 18:21:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12308; Sat, 26 Mar 2005 18:21:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFKhP-0008Ht-VS; Sat, 26 Mar 2005 18:28:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFKYg-0002oF-OB; Sat, 26 Mar 2005 18:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFKYf-0002nw-M2 for ltru@megatron.ietf.org; Sat, 26 Mar 2005 18:19:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12130 for ; Sat, 26 Mar 2005 18:19:07 -0500 (EST) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFKeo-0008Co-Of for ltru@ietf.org; Sat, 26 Mar 2005 18:25:33 -0500 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050326231853.KZHS7277.mta10.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 18:18:53 -0500 Message-ID: <002601c5325a$2a79d4c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <001301c53228$6fc9bd60$030aa8c0@DEWELL> <6.1.2.0.2.20050326220722.03a5bad0@mail.jefsey.com> Subject: Re: [Ltru] Shelf life of data (was: Re: Question) Date: Sat, 26 Mar 2005 15:18:47 -0800 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-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> People have been quoting RFC 822, which is 23 years old, on this >> list. Even though it has been updated by RFC 2822, obviously many of >> the basic philosophies and terminology still apply. > > I do not fully understand how the point applies here. What we decided > in 1984 and which still makes the today namespace was in line with > fundamental principles (root name concept). It will certainly last for > ever as intrisic to a name space. Your point was that a good many things from the past no longer function, or function only partly, in today's world. My point was that some things from the past still function just fine. We are both right. >> There's nothing magic about 10 years. > > Nothing. In real life you need to take decisions. When you need > something to be applied, you need a good mnemonic. It also turns out > from experience that a decade seems to be the absolecense cycle of the > technology itself. It depends on the technology. Some technologies, like laser video disks, take much less than a decade to become obsolescent. Some last much, much longer. Ten years is not carved in stone. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 19:18:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16846; Sat, 26 Mar 2005 19:18:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFLZz-0001ps-C6; Sat, 26 Mar 2005 19:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFLTm-0003fa-4e; Sat, 26 Mar 2005 19:18:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFLTk-0003eY-Ki for ltru@megatron.ietf.org; Sat, 26 Mar 2005 19:18:08 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16840 for ; Sat, 26 Mar 2005 19:18:05 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327001736.MTOT7277.mta10.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 19:17:36 -0500 Message-ID: <004301c53262$5aa258e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> <000801c53227$3ba04640$030aa8c0@DEWELL> <6.1.2.0.2.20050326210800.043a07e0@mail.jefsey.com> Subject: Re: [Ltru] Re: Registry in record-jar format Date: Sat, 26 Mar 2005 16:17:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA16840 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin wrote: >> I think the current theory is indeed to put the description in the >> draft, rather than relying on the pre-built registry. > > IMHO it would be better in a second RFC. To preserve the weight of the > main RFC (when quoted, printed). To permit to update that RFC > separately. The registry will need to be updated whenever a new code element is added to ISO 639, 3166, or 15924, or whenever the Language Subtag Reviewer approves the registration of a variant subtag. By my estimate, this is anywhere from 3 to 12 times a year. I don't think an RFC is the right vehicle for something as dynamic as that. > I am afraid you missed the concern. SHOULD NOT is not a MUST NOT. You > should understand that the format will make a lot of difference. If > the presentation is in XML the unnecessary usage will probably be 10 > times larger. There is a good example: the http://ref-editor.org In > 1200 days there have been 1.800.000, ie 1500 accesses a day. What is > far lower. But you understand that 600.000 bytes are not the 3 to > 10 000 bytes of an RFC. I am not necessarily arguing in favor of the XML format, which is clearly more bulky than the others being considered. Nobody, least of all the W3C, claims that XML is a terse and compact format. However, we are talking about ISO 639-3 code elements used as extended-language subtags, and it does need to be noted that there are more than 7,000 of these and there is NO plain-text format that can express them all without chewing up quite a few bytes. I created a text file from the tables in a draft version of 639-3, in about as compact a format as you can imagine: # Reference name|ID|Scope|Part 2|Status|Macro| !O!ung|oun|I|||| !X=C3=B3=C3=B5|nmn|I|||| //Ani|hnh|I|||| //Gana|gnk|I|||| //Xegwi|xeg|I|||| /Gwi|gwj|I|||| /Xam|xam|I|||| etc. and even this file, with 7,617 records (479 of which are already in 639-1 or 639-2 and thus won't need to be added to the registry), is more than 161,000 bytes. There's no getting around it; no matter how you slice it up, no matter what format is chosen, a registry with seven thousand languages is a large registry. > I want also to underline that the figure I quote are not for "every > time", but very conservative (1 a year) as you call for. You are correct, and I did miss that. I suppose a valid question might be, how often does an application need to update its copy of the registry if it attempts to be "conformant" with RFC 3066bis (however that is defined)? Currently we have applications that claim to support RFC 3066, but don't necessarily support all registered tags, such as "bs-Latn" which was registered just last month. (For that matter, even the IANA pages don't list any of the tags they have registered since mid-2004.) As you mentioned, anti-virus software requires virus definition files to be updated frequently for maximum effectiveness. This is not the same as requiring frequent updates in order for the software to work at all. I wonder what the situation is with other applications that rely on data from IANA registries. Are they considered non-conformant if they don't have the latest version, or just behind the times? Maybe there should be a way to provide incremental updates to the registry, so that the addition of one or two new subtags does not require the whole registry to be replaced. This is probably application-specific, and out of our scope. > What you quote about Microsoft is interesting. But it looks like a way > to tune an obligation imposed elsewhere? (if you speak French and are > in Canada you are supposed to speak fr-CA?). No, that's the exact opposite of my point. If you are from France and travel to Canada, you probably still speak fr-FR, not fr-CA. And you may want locale settings, sduch as spelling dictionaries and sort order, appropriate for France as well. Microsoft's approach allows you to specify that your physical location is Canada, but you want the settings for France for language and other things. (This is not to say only Microsoft has addressed this issue; I'm sure other vendors have as well.) You had stated that "ISO 3166 is of importance but it does not address the diaspora, the immigration, de cultural, the corporate, the reader/viewers classes, etc." I wanted to show that ISO 3166 codes in language tags are orthogonal to the existence of a diaspora or other immigrants. People speak whatever language or variant they speak, regardless of their physical location. > But this is a good point. I recall you that my lang5tag proposition is > not only in line with every dictionary, but also with Word and with > the "preferences" quoted in the Charter. We'll see what your draft says. Being "in line with" Microsoft Word is not a goal of the current draft, though. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 20:03:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19550; Sat, 26 Mar 2005 20:03:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFMIH-0003Jg-4A; Sat, 26 Mar 2005 20:10:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFMAB-00037F-Ih; Sat, 26 Mar 2005 20:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFMAA-00035T-4K for ltru@megatron.ietf.org; Sat, 26 Mar 2005 20:01:58 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19367 for ; Sat, 26 Mar 2005 20:01:52 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327010119.JWPQ4618.mta13.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 20:01:19 -0500 Message-ID: <004c01c53268$77e7e180$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 17:01:10 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Cutoff date for ISO codes (was: Re: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Mark brings up an interesting point that I hadn't examined carefully before, and which is actually leading me to change my mind and start supporting a "Date A." First we need to separate the question of "what goal we want to accomplish in allowing or disallowing certain codes" from the question of "how do we achieve that goal." I think most people would agree that we want to maintain compatibility with all previous RFC 1766 and 3066 tags. Specifically, there should be no tag that was valid under the rules of RFC 1766 or 3066 that is no longer valid under RFC 3066bis. Then the question becomes, what *were* the rules of RFC 1766 and 3066? RFC 1766 says: "All 2-letter tags are interpreted according to ISO standard 639, 'Code for the representation of names of languages' [ISO 639]." The reference in square brackets is to ISO 639:1988. The text mentions that a Registration Authority exists, and gives its address and telephone number, but does not make any provision for adopting the RA's changes. It does list six codes that "have been added in 1989," including three that "replaced" other codes, but says nothing about whether the "replaced" codes were still allowable in tags, or whether new codes subsequently approved by the RA would also be allowable. RFC 3066 corrected this omission as follows: "All 2-letter subtags are interpreted according to assignments found in ISO standard 639, 'Code for the representation of names of languages' [ISO 639], or assignments subsequently made by the ISO 639 part 1 maintenance agency or governing standardization bodies." Again the reference is to ISO 639:1988, but this time it is clearly stated that added and changed codes can also be used in language tags. Again, no mention is made of whether old codes were still allowable, but it would be awkward to conclude that a code change should require all existing data using the old code to be retagged. The situation is the same for ISO 3166. RFC 1766 cites the 1988 version of ISO 3166, and only allows for codes in that version, whereas RFC 3066 expressly allows codes "subsequently assigned by the ISO 3166 maintenance agency or governing standardization bodies." A strict interpretation of all this would be that the codes allowed by RFC 1766 and 3066 are those listed in the 1988 versions of ISO 639 and 3166, plus the six codes listed in RFC 1766 as having been "added in 1989," PLUS all codes added to either standard since 2001, when RFC 3066 with its allowance for "assignments subsequently made" was published. A more realistic interpretation, which probably captures the true situation, would be that the set of allowable codes consists of all codes in ISO 639:1988 and ISO 3166:1988, plus all codes assigned since those standards were published -- 1988, not 1995 or 2001. This covers not only the six language codes explicitly listed in RFC 1766, but also the assumption that was probably always made since the release of RFC 1766, and finally codified in RFC 3066: that updates were allowed. What does this mean for the registry? ISO 639:1988 was the original version of that standard, so this "looser interpretation" doesn't remove any language subtags. ISO 3166:1988 was the third edition of that standard (originally published in 1974). Restricting the region subtags to those published in the 1988 version or later would exclude the following 15 code elements: BQ British Antarctic Territory CT Canton and Enderbury Islands DY Benin (Dahomey) FQ French Southern and Antarctic Territories HV Burkina Faso (Upper Volta) JT Johnston Island MI Midway Islands NH Vanuatu (New Hebrides) NQ Dronning Maud Land PC Pacific Islands Trust Territory PU U.S. Miscellaneous Pacific Islands PZ Panama Canal Zone RH Zimbabwe (Southern Rhodesia) VD North Vietnam WK Wake Island but would NOT exclude the following 9 code elements, which were withdrawn after 1988: BU Myanmar (Burma) DD East Germany FX Metropolitan France NT Neutral Zone SU Union of Soviet Socialist Republics TP Timor-Leste (East Timor, originally Portuguese Timor) YD People's Democratic Republic of Yemen YU Serbia and Montenegro (Yugoslavia) ZR Congo, The Democratic Republic of the (Zaire) Does this make sense? If the goal is to make sure all RFC 1766 and 3066 language tags are still valid, and if we can agree that codes withdrawn before 1988 were never valid in tags, then we can disallow these codes in RFC 3066bis as well. We can "give back" the 15 codes to ISO 3166/MA, so to speak, so that if they are reassigned it doesn't hurt us. Note that we haven't done any one-by-one "cherry-picking" as to whether a given code is useless or lame or anything. For example, "ar-NT" is still just as pointless a tag as ever, but we don't use that as a reason to disallow it. In John Cowan's terms, then, "Date A" would be 1988-01-01. (Actually, it doesn't matter what date in 1988 is chosen, since no codes were withdrawn during that year.) And "Date B" would be either 2005-01-01, or the date of each new draft, or the date of final publication, or whatever. It won't matter if we can get the MAs to play nice and not reassign any codes until then. I propose this solution, and politely request WG feedback. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 20:25:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20839; Sat, 26 Mar 2005 20:25:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFMcp-0003yb-CQ; Sat, 26 Mar 2005 20:31:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFMTb-0007II-VV; Sat, 26 Mar 2005 20:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFMTb-0007ID-7d for ltru@megatron.ietf.org; Sat, 26 Mar 2005 20:22:03 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20409 for ; Sat, 26 Mar 2005 20:22:01 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327012131.OMKV7277.mta10.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 20:21:31 -0500 Message-ID: <004f01c5326b$49318a00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050326170237.JMJV2140.mta3.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 17:21:20 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Misha Wolf wrote: > > My point was that 600,000 bytes isn't all that much in comparison to > the things we store and pass around nowadays. That's less than half a > floppy disk, and everyone knows we don't use floppies any more because > they're considered too small to hold anything useful. > > > Do you have in mind an 8 inch or a 5.25 inch floppy disk? I have in mind either a 5.25-inch or a 3.5-inch high-density diskette, either of which can hold at least 1.2 MB. I haven't seen a computer built in the last 25 years that used an 8-inch diskette. We had some in the college bookstore warehouse where I worked in the '80s; we considered them museum pieces even then. The 5.25-inch HD diskette has been available since 1984, and the 3.5-inch HD since 1987. Very few PCs sold since the mid-'90s support only the low-density (720K) diskettes, which would still be large enough to hold a 600K registry. 5.25-inch drives are getting quite hard to find by now. I shouldn't have brought this up. The registry won't be anywhere near this big unless and until the draft makes a concrete provision to support ISO 639-3 codes. Right now it defines a placeholder for them, but does not specify anything else about them (e.g. when are they used as primary language subtags and when as extlang subtags). -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 20:46:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22220; Sat, 26 Mar 2005 20:46:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFMxL-0004ZP-HW; Sat, 26 Mar 2005 20:52:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFMqR-0002lS-GM; Sat, 26 Mar 2005 20:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFMqP-0002l0-Bc for ltru@megatron.ietf.org; Sat, 26 Mar 2005 20:45:37 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22198 for ; Sat, 26 Mar 2005 20:45:35 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327014505.PDAM7277.mta10.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 20:45:05 -0500 Message-ID: <005401c5326e$971d5340$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050326155923.OBLW2135.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 17:44:59 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Language tag humor (was: Re: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Tex Texin wrote: > The question of speaking up for no-BC is a bit loaded when asked in > that way. I was scratching my head and searching frantically for a country code 'BC', so I could figure out where someone was speaking Norwegian, until I realized that "no-BC" meant "no backward compatibility." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:02:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23050; Sat, 26 Mar 2005 21:02:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFNCY-00054R-3U; Sat, 26 Mar 2005 21:08:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFN4K-0005Kv-Mg; Sat, 26 Mar 2005 21:00:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFN4J-0005Jw-Gk for ltru@megatron.ietf.org; Sat, 26 Mar 2005 20:59:59 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22962 for ; Sat, 26 Mar 2005 20:59:57 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327015928.FTGI2192.mta9.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 20:59:28 -0500 Message-ID: <005901c53270$98510660$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325214229.NHDO2135.mta4.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 17:59:21 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Later 3066 speculates about the chances of an ISO 639-1:2000 > published in 2001, and forbids the user assigned codes AA, ZZ, > QM-QZ, and XA-XZ, they were allowed in RfC 1766. Because they were allowed in RFC 1766, and because they may be useful, they should be allowed in RFC 3066bis. > SNAFU. It's the purpose of 3066bis to cleanup this mess, not > to preserve it. Apparently nobody has a copy of ISO 3166:1988. > Doug is forced to guess using private Web pages what this old > stuff is about. I have to use Clive Feather's page anyway because I don't have a copy of ISO 3166-3 that says when this code and that code were withdrawn. Once again: Anyone got a copy of ISO 3166-3? > We found RH, BQ, FQ, and NQ, these codes are > irrelevant and disgusting. Nobody recognizes these codes, and > nobody needs any ?Q for fantastic languages in the Antarctic. See my other post, which proposes to exclude these codes because they were not valid under earlier RFCs, not because they are "irrelevant and disgusting." The latter is subjective and arbitrary. (It is funny, though.) >> *nowhere* in 1766 does it say that a code later deprecated in >> ISO 639 or 3166 is not valid > > "additions to and changes in the list". Country codes like NH, > BQ, FQ, and NQ are shown as _unassigned_ on the 3166-1 page. > Maybe _deprecated_ in ISO 639 is a different issue, but 3166-1 > has a clear list of states: > > officially assigned - examples: AQ, AX, CS > user assigned - examples: AA. QQ, XX > exceptionally reserved - examples: AC, EU, IM > transitionally reserved - examples: BU, NT, SF > indeterminately reserved - examples: DY. FL, RH > not used at present stage - examples: AP, BX, EF > unassigned - examples: BQ, DD, NH "Why they are reserved" is not important. Either a code is currently assigned, or it was formerly assigned, or it is private-use ("user-assigned"). Distinctions between the different types of "reserved" are of interest only to the MA. > BTW, Doug has RH as Southern Rhodesia, the ISO 3166-1 Web page > has RH as Haiti (indeterminately reserved). RH for Haiti would probably be a car code for "Republic of Haiti." "Indeterminately reserved" is not a category I have any faith or confidence in, not since ISO 3166/MA indeterminately reserved ROU (Republic of Uruguay) and then assigned it to Romania because the old code, ROM, might be construed as referring to a disparaged ethnic group. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:23:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24254; Sat, 26 Mar 2005 21:23:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFNWq-0005lP-H8; Sat, 26 Mar 2005 21:29:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNOB-00018U-8g; Sat, 26 Mar 2005 21:20:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNO9-00018I-R0 for ltru@megatron.ietf.org; Sat, 26 Mar 2005 21:20:29 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24143 for ; Sat, 26 Mar 2005 21:20:28 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327021958.GOEA2192.mta9.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 21:19:58 -0500 Message-ID: <006a01c53273$72379400$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050326155923.OBLW2135.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 26 Mar 2005 18:19:45 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Mark Davis wrote: > Look, we regularly get beaten up by various IETF people for the > backwards compatibility of the Unicode Standard. I hate to see IETF > take a much more lackadaisical approach to language tags. I'm ok with > excluding codes that no reasonable person would believe is was valid > at some time according to the text of 1766 and 3066. I agree that we should not be lackadaisical. I do feel that the text of 1766 and 3066 excludes pre-1988 codes. > And if we start down the road of judging each individual case > according to whether we think it was "lame" or not, we will just tie > ourselves up in knots. We have a bright line; let's use it. We should > simply not break backward compatibility, when the only benefit is > having a very small number of additional codes. Frank's concern, echoed by John in his comment about "lame," is not so much that we lose a few codes, but that ISO 3166/MA will pull an ISO 3166/MA and reassign one of the codes, and the country to whom it was reassigned will be forced to accept a UN M.49 code in language tags, because we've reserved the subtag in perpetuity for "French Unrecognized Antarctic Claims." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:37:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25185; Sat, 26 Mar 2005 21:37:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFNkT-0006BR-QY; Sat, 26 Mar 2005 21:43:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNd5-0003Y4-11; Sat, 26 Mar 2005 21:35:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNd4-0003Xx-0A for ltru@megatron.ietf.org; Sat, 26 Mar 2005 21:35:54 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25080 for ; Sat, 26 Mar 2005 21:35:52 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327023522.QQAY7277.mta10.adelphia.net@DEWELL> for ; Sat, 26 Mar 2005 21:35:22 -0500 Message-ID: <009a01c53275$99c1bb20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 26 Mar 2005 18:35:11 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] XML registries now available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit I've uploaded a couple of XML versions of the registry, again just so everyone can visualize what they would look like. One is in Addison's original "back of the envelope" format, at http://users.adelphia.net/~dewell/lstreg-addison.xml: Afar while the other uses XML elements exclusively instead of attributes, which may or may not have been what Ira McDonald had in mind, at http://users.adelphia.net/~dewell/lstreg-ira.xml: language aa Afar 2004-07-06 These are only up for illustration, not for advocacy. Personally I liked the old vertical-bar format, but if the group would prefer to see a change, that's fine. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:39:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25371; Sat, 26 Mar 2005 21:39:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFNmK-0006EX-18; Sat, 26 Mar 2005 21:45:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNfE-00040W-1o; Sat, 26 Mar 2005 21:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNfC-00040E-8y for ltru@megatron.ietf.org; Sat, 26 Mar 2005 21:38:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25320 for ; Sat, 26 Mar 2005 21:38:04 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFNlN-0006Ck-0n for ltru@ietf.org; Sat, 26 Mar 2005 21:44:31 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2R2bmF7006810; Sat, 26 Mar 2005 21:37:48 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 26 Mar 2005 21:37:46 -0500 Date: Sat, 26 Mar 2005 21:37:46 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Cutoff date for ISO codes (was: Re: Question) Message-ID: <20050327023746.GB24325@skunk.reutershealth.com> References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <004c01c53268$77e7e180$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01c53268$77e7e180$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Doug Ewell scripsit: > In John Cowan's terms, then, "Date A" would be 1988-01-01. (Actually, > it doesn't matter what date in 1988 is chosen, since no codes were > withdrawn during that year.) And "Date B" would be either 2005-01-01, > or the date of each new draft, or the date of final publication, or > whatever. It won't matter if we can get the MAs to play nice and not > reassign any codes until then. This version of my solution is also fine with me. -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan http://www.ccil.org/~cowan http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:58:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26359; Sat, 26 Mar 2005 21:58:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFO4t-0006qF-Fl; Sat, 26 Mar 2005 22:04:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNxQ-000743-Mc; Sat, 26 Mar 2005 21:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNxO-00073V-Sg for ltru@megatron.ietf.org; Sat, 26 Mar 2005 21:56:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26226 for ; Sat, 26 Mar 2005 21:56:53 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFO3b-0006lX-SZ for ltru@ietf.org; Sat, 26 Mar 2005 22:03:20 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFNxG-0007ZV-0v; Sat, 26 Mar 2005 18:56:46 -0800 Message-Id: <6.1.2.0.2.20050327035629.043a0db0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 27 Mar 2005 04:47:54 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format In-Reply-To: <004301c53262$5aa258e0$030aa8c0@DEWELL> References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> <000801c53227$3ba04640$030aa8c0@DEWELL> <6.1.2.0.2.20050326210800.043a07e0@mail.jefsey.com> <004301c53262$5aa258e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA26226 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable At 03:17 27/03/2005, Doug Ewell wrote: >The registry will need to be updated whenever a new code element is >added to ISO 639, 3166, or 15924, or whenever the Language Subtag >Reviewer approves the registration of a variant subtag. By my estimate, >this is anywhere from 3 to 12 times a year. I don't think an RFC is the >right vehicle for something as dynamic as that. What I mean is that: - if you put the data in the BCP 047, it would become obsolete when there= =20 would be an ISO update. - if you put them in a separate RFC, the IANA will load them. At the firs= t=20 change, you update the IANA according to the BCP047 procedure (new=20 document) and obsolete the data RFC. >However, we are talking about ISO 639-3 code elements used as >extended-language subtags, and it does need to be noted that there are >more than 7,000 of these and there is NO plain-text format that can >express them all without chewing up quite a few bytes. I created a text >file from the tables in a draft version of 639-3, in about as compact a >format as you can imagine: > ># Reference name|ID|Scope|Part 2|Status|Macro| >!O!ung|oun|I|||| >!X=C3=B3=C3=B5|nmn|I|||| >//Ani|hnh|I|||| >//Gana|gnk|I|||| >//Xegwi|xeg|I|||| >/Gwi|gwj|I|||| >/Xam|xam|I|||| >etc. > >and even this file, with 7,617 records (479 of which are already in >639-1 or 639-2 and thus won't need to be added to the registry), is more >than 161,000 bytes. There's no getting around it; no matter how you >slice it up, no matter what format is chosen, a registry with seven >thousand languages is a large registry. We fully agree. I rose the question of the load when we started discussin= g=20 XML. IMHO, but this may be subjective, this is why I asked, the least=20 directly usable is the format, the least there will be chances that someo= ne=20 builds an application calling the IANA. I will be frank IMHO the IANA registryis has only a political and and a=20 central exposure interes: it would be better just to document where to fi= nd=20 the data supported by their referent. We have the experience of the DNS=20 database: the IANA delays/moods in getting the DNS root updated are the=20 main problem of TLD Managers. Also, be sure that if you start building a=20 formal system, imposing constraints, usage will just partly move away fro= m=20 it. Like for the DNS, with alt-roots and PADs. NB. I keep refering to the DNS because (I quoted the STD 013) it could be= =20 the proper vehicle to support the data and permit immediate access by=20 applications. I do not know if I will be able to present/discuss our draft as we planne= d=20 due to the Easter delay, so let me introduce the idea and it can be=20 discussed before the draft (at this stage it is just a concept, but I hav= e=20 the tools and the possibly useful plug-in). 1. there are four descriptive subtags (language, script, culture, style) 2. there is an authoritative subtag (referent). Let assume that the referent is designated by his domain=20 name. "style.culture.language.script.referent" can be a domain name wher= e=20 an information is stored (exists or not, to start with) in an RR. Exemple= :=20 "casual.fra.fr.latn.jefsey.com" will be where to find my description of t= he=20 way I understand casual French of France. I can certainly have a CNAME wi= th=20 "casual.fr.fr.latn.jefsey.com". The reason why I put the script first is that "latn.jefsey.com" can be=20 transformed by a plug-in (currently used by scores of millions of users)=20 into ".langtag" in Latin character. The call is then casual.fr.fr.langtag= ,=20 with a RX being responded to the application documenting the registration= =20 (it can simply be the Handle of the documentation - permanent document=20 addressing system used by the LOC and many others). It just calls for a db.file description to immediately support 7500=20 languages and 20000 dialects and all what you want. 15.000.000 tags are n= o=20 big deal vs. hundreds of million of domain names supported by nearly one=20 million of nameservers. And it costs nothing. > > I want also to underline that the figure I quote are not for "every > > time", but very conservative (1 a year) as you call for. > >You are correct, and I did miss that. > >I suppose a valid question might be, how often does an application need >to update its copy of the registry if it attempts to be "conformant" >with RFC 3066bis (however that is defined)? Currently we have >applications that claim to support RFC 3066, but don't necessarily >support all registered tags, such as "bs-Latn" which was registered just >last month. (For that matter, even the IANA pages don't list any of the >tags they have registered since mid-2004.) > >As you mentioned, anti-virus software requires virus definition files to >be updated frequently for maximum effectiveness. This is not the same >as requiring frequent updates in order for the software to work at all. >I wonder what the situation is with other applications that rely on data >from IANA registries. Are they considered non-conformant if they don't >have the latest version, or just behind the times? > >Maybe there should be a way to provide incremental updates to the >registry, so that the addition of one or two new subtags does not >require the whole registry to be replaced. This is probably >application-specific, and out of our scope. > > > What you quote about Microsoft is interesting. But it looks like a wa= y > > to tune an obligation imposed elsewhere? (if you speak French and are > > in Canada you are supposed to speak fr-CA?). > >No, that's the exact opposite of my point. We are in agreement. My Franglish probably the problem. I meant you are=20 supposed to use a Canadian locale, but Microft allows you to evade from = it. How do you support Tamils? > > But this is a good point. I recall you that my lang5tag proposition i= s > > not only in line with every dictionary, but also with Word and with > > the "preferences" quoted in the Charter. > >We'll see what your draft says. Being "in line with" Microsoft Word is >not a goal of the current draft, though. You are right. I only assume that Word is probably in line with the users= =20 otherwise they would use something else. So being level with Words and=20 Dictionaries (which usually document a word in giving the style, the=20 reference and possibly the date) gives chances to be level wit the real = needs. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:58:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26377; Sat, 26 Mar 2005 21:58:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFO4t-0006qE-Fd; Sat, 26 Mar 2005 22:04:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNxU-00074T-7L; Sat, 26 Mar 2005 21:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNxP-00073i-Rq for ltru@megatron.ietf.org; Sat, 26 Mar 2005 21:56:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26230 for ; Sat, 26 Mar 2005 21:56:53 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFO3b-0006lW-SV for ltru@ietf.org; Sat, 26 Mar 2005 22:03:21 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFNxE-0007ZV-Uv; Sat, 26 Mar 2005 18:56:45 -0800 Message-Id: <6.1.2.0.2.20050327032746.044072d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 27 Mar 2005 04:56:42 +0200 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Shelf life of data (was: Re: Question) In-Reply-To: <002601c5325a$2a79d4c0$030aa8c0@DEWELL> References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <001301c53228$6fc9bd60$030aa8c0@DEWELL> <6.1.2.0.2.20050326220722.03a5bad0@mail.jefsey.com> <002601c5325a$2a79d4c0$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On 01:18 27/03/2005, Doug Ewell said: > > It also turns out from experience that a decade seems to be the > absolecense cycle of the > > technology itself. > >It depends on the technology. :-) we are IETF. I meant international network technology. Since 1977: Tymnet, OSI, Internet, coming NGN. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 21:59:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26459; Sat, 26 Mar 2005 21:59:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFO5l-0006tk-AM; Sat, 26 Mar 2005 22:05:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNxU-00074P-2b; Sat, 26 Mar 2005 21:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFNxP-00073d-O9 for ltru@megatron.ietf.org; Sat, 26 Mar 2005 21:56:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26231 for ; Sat, 26 Mar 2005 21:56:53 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFO3b-0006la-Sd for ltru@ietf.org; Sat, 26 Mar 2005 22:03:21 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFNxH-0007ZV-E3; Sat, 26 Mar 2005 18:56:47 -0800 Message-Id: <6.1.2.0.2.20050327044253.03a10c40@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 27 Mar 2005 04:46:44 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] XML registries now available In-Reply-To: <009a01c53275$99c1bb20$030aa8c0@DEWELL> References: <009a01c53275$99c1bb20$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 At 05:35 27/03/2005, Doug Ewell wrote: >These are only up for illustration, not for advocacy. Personally I >liked the old vertical-bar format, but if the group would prefer to see >a change, that's fine. I favor vertical bar: simple, visual, secure. IMHO the only advantage of XML is to be easily ported to ASN.1 (easy maintenance in case of changes). However I agree with Ira, the programing is much simpler and secure with vertical bars. It is also Excell compatible. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 26 22:12:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27340; Sat, 26 Mar 2005 22:12:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFOIw-0007LD-Qs; Sat, 26 Mar 2005 22:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFOBS-0001AW-8G; Sat, 26 Mar 2005 22:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFOBQ-00019y-2W for ltru@megatron.ietf.org; Sat, 26 Mar 2005 22:11:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27294 for ; Sat, 26 Mar 2005 22:11:22 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFOHc-0007HP-Ao for ltru@ietf.org; Sat, 26 Mar 2005 22:17:49 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2R3BCtV006935 for ; Sat, 26 Mar 2005 22:11:13 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 26 Mar 2005 22:11:16 -0500 Date: Sat, 26 Mar 2005 22:11:15 -0500 From: John Cowan To: ltru@ietf.org Message-ID: <20050327031115.GE24325@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AB823BF@irvmbxw01.quest.com> <03ee01c52f25$bb24e560$727d3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03ee01c52f25$bb24e560$727d3009@sanjose.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ltru] Proposal for a third matching algorithm (was: Preparations for smart matching) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Mark Davis scripsit: > 1. Matching. Use of 'sr' says that you want to match Serbian of > whatever form: doesn't depend on the country, doesn't depend on the script. > Use of, say, 'sr-Latn-IT' means that you want Serbian, but limited to > Latin script, and as used in Italy. If I want to have a document query, then > I could use one of the above to restrict the documents that match my query. > I could get back 1000 documents or none, according to what database of > documents I am searching and how restrictive my query is. Something I didn't really understand about RFC 2616 matching until now is that if a server has content tagged en-gb and en-us, but none tagged just en, then it's conformant for the server to return either one in a request for en without telling you about the other in any way. > 2. Lookup. When you lookup language data, for example, for display on a web > page, it is a different process. You typically don't have the choice of > displaying nothing if there is not an exact match. Instead, you fall back. > If you don't have data exactly matching 'sr-Latn-IT', you fallback to data > for 'sr-Latn'. If you don't have that either, you fallback to data for 'sr'. > Now, whatever data contents someone has associated with 'sr', it has to be a > single consistent type of data, so it will be in one of 'Latn' or 'Cyrl'. This algorithm should be added to the matching draft. I also have a third algorithm to propose, which I have not worked out in full detail. It accepts a language pattern to match against and a set of documents to be matched, each with a language tag. 1) The language pattern and the language tags are pre-normalized by mapping grandfathered and obsolete tags into modern equivalents. 2) The language pattern and the language tags are normalized into quadruples of the form (language, script, country, variant), where extended language is considered part of language and x-private-codes are considered part of the language if they are initial and part of the language if not initial. Missing components are set to "*". An "*" pattern becomes the quadruple ("*", "*", "*", "*"). 3) Each document is assigned a figure of merit such that higher values indicate better matches and lower values indicate worse ones. a) If the language matches, add 8 to the figure of merit. b) If the script matches, add 4 to the figure of merit. c) If the region matches, add 2 to the figure of merit. d) If the variant matches, add 1 to the figure of merit. Elements of the quadruples are considered to match if they are the same or if one of them is "*". 4) 15 is a perfect match, 0 is no match at all. Any match less than 8 is almost certainly not worth considering. This algorithm may have bugs, and is certainly not expressed in the necessary detail. I invite people to fiddle with it. -- Is not a patron, my Lord [Chesterfield], John Cowan one who looks with unconcern on a man http://www.ccil.org/~cowan struggling for life in the water, and when http://www.reutershealth.com he has reached ground encumbers him with help? jcowan@reutershealth.com --Samuel Johnson _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 00:15:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06167; Sun, 27 Mar 2005 00:15:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFQDp-0002xU-0f; Sun, 27 Mar 2005 00:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFQ7M-0007xI-2g; Sun, 27 Mar 2005 00:15:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFQ7K-0007wr-GB for ltru@megatron.ietf.org; Sun, 27 Mar 2005 00:15:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06152 for ; Sun, 27 Mar 2005 00:15:15 -0500 (EST) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFQDY-0002x5-L3 for ltru@ietf.org; Sun, 27 Mar 2005 00:21:45 -0500 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050327051502.OBKZ5402.mta11.adelphia.net@DEWELL> for ; Sun, 27 Mar 2005 00:15:02 -0500 Message-ID: <00af01c5328b$e49a7d60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> <000801c53227$3ba04640$030aa8c0@DEWELL> <6.1.2.0.2.20050326210800.043a07e0@mail.jefsey.com> <004301c53262$5aa258e0$030aa8c0@DEWELL> <6.1.2.0.2.20050327035629.043a0db0@mail.jefsey.com> Date: Sat, 26 Mar 2005 21:14:45 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > What I mean is that: > - if you put the data in the BCP 047, it would become obsolete when > there would be an ISO update. Of course. I don't know anyone who wants to do that. > - if you put them in a separate RFC, the IANA will load them. At the > first change, you update the IANA according to the BCP047 procedure > (new document) and obsolete the data RFC. I don't think there should be a data RFC in the first place. > I will be frank IMHO the IANA registryis has only a political and and > a central exposure interes: it would be better just to document where > to find the data supported by their referent. I strongly disagree. Nobody should have to go through all the tedious and error-prone steps to derive the registry from all the various source standards. Take another look at http://users.adelphia.net/~dewell/init-registry.html, and bear in mind that's just the language subtags. The region subtags will be worse. I don't believe that any of us who support the creation of a registry do so on the basis of any political agenda or desire for "exposure," if that is what you mean. I certainly do not have those goals. > We have the experience of the DNS database: the IANA delays/moods in > getting the DNS root updated are the main problem of TLD Managers. I have to admit, I am worried about whether the subtag registry will get updated in a timely manner, if the existing whole-tag registry hasn't been updated since mid-2004 even though nine tags have been registered since then. > Also, be sure that if you start building a formal system, imposing > constraints, usage will just partly move away from it. Like for the > DNS, with alt-roots and PADs. The "system" we are "building" is just a significant update to the RFC 1766/3066 system that already exists. And yes, some people have abused it. Not to pick on Microsoft, because everyone else does, but the .NET Framework has a class called CultureInfo, which has a property called Name, which is a string that supposedly "follows the RFC 1766 standard." Only it doesn't; it extends it in certain ways, by assigning names like "zh-CHS" and "zh-CHT" for Simplified and Traditional Chinese, and using the 3-letter "div" instead of "dv" for Divehi, and by using the non-existent country code 'SP' for Serbia and Montenegro, and by using language-region-script codes like "az-AZ-Cyrl" which aren't registered under either RFC 1766 or 3066. (I wish, oh how I wish, that 'SP' really were the country code that ISO 3166/MA had chosen to replace 'YU'. But it isn't.) So sure, somebody is bound to abuse RFC 3066bis. I don't think that's a convincing argument not to build it. > I do not know if I will be able to present/discuss our draft as we > planned due to the Easter delay, so let me introduce the idea and it > can be discussed before the draft (at this stage it is just a concept, > but I have the tools and the possibly useful plug-in). > 1. there are four descriptive subtags (language, script, culture, > style) > 2. there is an authoritative subtag (referent). > > Let assume that the referent is designated by his domain name. > "style.culture.language.script.referent" can be a domain name where an > information is stored (exists or not, to start with) in an RR. > Exemple: "casual.fra.fr.latn.jefsey.com" will be where to find my > description of the way I understand casual French of France. I can > certainly have a CNAME with "casual.fr.fr.latn.jefsey.com". Others can discuss this now if they choose to. I will wait for the draft. >>> What you quote about Microsoft is interesting. But it looks like a >>> way to tune an obligation imposed elsewhere? (if you speak French >>> and are in Canada you are supposed to speak fr-CA?). >> >> No, that's the exact opposite of my point. > > We are in agreement. My Franglish probably the problem. I meant you > are supposed to use a Canadian locale, but Microft allows you to evade > from it. I still don't understand. Microsoft lets you use a France locale, and simultaneously say, "but I am physically in Canada." Maybe we should just drop this. > How do you support Tamils? Very well, thank you. No, seriously, there must be an inner meaning to this that I don't understand. You can write "ta" for Tamil, or "ta-IN" for Tamil as used specifically in India, or "ta-LK" for Tamil in Sri Lanka, etc. etc. You can do that today, with RFC 3066. Under RFC 3066bis you could also use the script subtag 'Taml', or a different one if another script is being used to write Tamil (I don't know if that happens). >> We'll see what your draft says. Being "in line with" Microsoft Word >> is not a goal of the current draft, though. > > You are right. I only assume that Word is probably in line with the > users otherwise they would use something else. So being level with > Words and Dictionaries (which usually document a word in giving the > style, the reference and possibly the date) gives chances to be level > wit the real needs. Sorry, you lost me. I use Word, at home because I think it's good software, and at work because I have to. As for dictionaries, I have one of those huge Random House unabridged dictionaries and enjoy being able to look up etymologies, origins, and dates of first usage. But I don't recall it classifying every word as to "style," except for obvious non-standard words like "ain't," and I certainly wouldn't consider that to be a "real need" in the sense that I would need that information from the dictionary in order to form a sentence. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 01:13:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08568; Sun, 27 Mar 2005 01:13:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFR8M-0004YD-U8; Sun, 27 Mar 2005 01:20:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFR0R-0001rI-Nm; Sun, 27 Mar 2005 01:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFR0P-0001rA-PJ for ltru@megatron.ietf.org; Sun, 27 Mar 2005 01:12:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08511 for ; Sun, 27 Mar 2005 01:12:13 -0500 (EST) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFR6d-0004X1-JK for ltru@ietf.org; Sun, 27 Mar 2005 01:18:40 -0500 Received: from c-24-6-55-132.client.comcast.net (HELO [192.168.1.100]) (24.6.55.132) by smtp04.mrf.mail.rcn.net with ESMTP; 27 Mar 2005 01:12:11 -0500 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.8.1]); Sat, 26 Mar 2005 22:12:06 -0800 Message-ID: <42464EB1.53E3C1CB@i18nguy.com> Date: Sat, 26 Mar 2005 22:12:01 -0800 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Language tag humor (was: Re: Question) References: <20050326155923.OBLW2135.mta2.adelphia.net@megatron.ietf.org> <005401c5326e$971d5340$030aa8c0@DEWELL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Actually it refers to a special Norwegian form of backward compatibility. ;-) My bad for abbreviating. Sorry. I thought this list was already using BC for backward compatibility, but its possible it was being used regularly in another list I am on and not this one. But I should have anticipated the hyphenated no- form would look more like a lang tag than an abbreviation. tex Doug Ewell wrote: > > Tex Texin wrote: > > > The question of speaking up for no-BC is a bit loaded when asked in > > that way. > > I was scratching my head and searching frantically for a country code > 'BC', so I could figure out where someone was speaking Norwegian, until > I realized that "no-BC" meant "no backward compatibility." > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- ------------------------------------------------------------- Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com Xen Master http://www.i18nGuy.com XenCraft http://www.XenCraft.com Making e-Business Work Around the World ------------------------------------------------------------- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 11:27:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12806; Sun, 27 Mar 2005 11:27:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFahh-00031U-A2; Sun, 27 Mar 2005 11:33:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFaa7-00064D-OB; Sun, 27 Mar 2005 11:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFaa6-000648-DE for ltru@megatron.ietf.org; Sun, 27 Mar 2005 11:25:42 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12771 for ; Sun, 27 Mar 2005 11:25:39 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFaZD-0002Et-7F for ltru@lists.ietf.org; Sun, 27 Mar 2005 18:24:47 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 18:24:47 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 18:24:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 18:23:46 +0200 Organization: Lines: 22 Message-ID: <4246DE12.7531@xyzzy.claranet.de> References: <009a01c53275$99c1bb20$030aa8c0@DEWELL> 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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: XML registries now available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > http://users.adelphia.net/~dewell/lstreg-addison.xml [...] > http://users.adelphia.net/~dewell/lstreg-ira.xml Both nice, I can't judge the pro and con between these formats. To get a simple parser in any language very fast record-jar or similar is apparently good enough. The XML formats would allow Unicode for 3066ter ideas like "language name in its native script(s)" or only a Latin-1 "French name". > These are only up for illustration, not for advocacy. > Personally I liked the old vertical-bar format It's fine, but unusable in an I-D or RfC. Therefore I'd opt for record-jar or a variant with empty lines instead of "%%", plus the normal MIME folding for too long lines. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 11:44:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13718; Sun, 27 Mar 2005 11:44:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFayP-0003WD-7D; Sun, 27 Mar 2005 11:50:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFarg-0000nt-GS; Sun, 27 Mar 2005 11:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFare-0000no-3A for ltru@megatron.ietf.org; Sun, 27 Mar 2005 11:43:50 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13707 for ; Sun, 27 Mar 2005 11:43:47 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFaqu-0003sW-4E for ltru@lists.ietf.org; Sun, 27 Mar 2005 18:43:04 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 18:43:04 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 18:43:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 18:42:31 +0200 Organization: Lines: 21 Message-ID: <4246E277.2C4C@xyzzy.claranet.de> References: <20050325214229.NHDO2135.mta4.adelphia.net@megatron.ietf.org> <005901c53270$98510660$030aa8c0@DEWELL> 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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] 3166-1 state machie (was: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Doug Ewell wrote: > "Why they are reserved" is not important. Either a code is > currently assigned, or it was formerly assigned, or it is > private-use ("user-assigned"). Distinctions between the > different types of "reserved" are of interest only to the MA. I'm not sure, if "transitionally reserved" is essentially the same as "deprecated", this could be relevant, and if all these other "reservations" hide what we're interested in here, i.e. "deprecated" vs. "unassigned", it could be also relevant. And for Mark's "Joe Blow" or my "Jane Blog" anything on the 3166-1 web pages could be (ab)used. Especially before 3066bis. If we don't have a copy of ISO 3166:1988, then Joe and Jane also have no copy, that's why they (ab)use ccTLDs or reserved codes. Until the future 3066bis registry helps to catch such errors. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 11:53:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14138; Sun, 27 Mar 2005 11:53:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFb72-0003ls-9T; Sun, 27 Mar 2005 11:59:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFb0O-0002PD-2M; Sun, 27 Mar 2005 11:52:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFb0M-0002P5-1b for ltru@megatron.ietf.org; Sun, 27 Mar 2005 11:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14124 for ; Sun, 27 Mar 2005 11:52:47 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFb6g-0003le-Jm for ltru@ietf.org; Sun, 27 Mar 2005 11:59:23 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2RGqV5V023185; Sun, 27 Mar 2005 08:52:31 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77GYAN>; Sun, 27 Mar 2005 08:52:32 -0800 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] XML registries now available Date: Sun, 27 Mar 2005 08:52:22 -0800 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: 31247fb3be228bb596db9127becad0bc X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Doug, Yes, using only XML elements was exactly what I had in mind. Mixing XML attributes with XML elements to contain the data has no practical advantages and makes the XML much harder to parse. Looking forward in this thread, Frank's right, you can't put XML with non-ASCII characters in an RFC. Period. It's IESG policy we're not going to change for our RFC. That specifically means also not using so-called upper-half ISO 8859-1 (Latin-1) characters. They are NOT permitted in RFCs. So if Aland needs it's ring in the registry, we still need some more mechanism. Proposal - since it only affects one field (native name of language in UTF-8), what about having a parallel list (a second Informative registry file) that has the pairs of transcribed ASCII name and native language name? Using XML seems to be considered here mainly as a codespace solution for non-ASCII names (which is NOT a good reason for using XML). Cheers, - Ira PS - That second file would be Informative (even in the IANA Registry) so that this WG list doesn't become a poor man's ISO Registration/Maintenance Authority - it's best effort. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Doug Ewell Sent: Saturday, March 26, 2005 9:35 PM To: LTRU Working Group Subject: [Ltru] XML registries now available I've uploaded a couple of XML versions of the registry, again just so everyone can visualize what they would look like. One is in Addison's original "back of the envelope" format, at http://users.adelphia.net/~dewell/lstreg-addison.xml: Afar while the other uses XML elements exclusively instead of attributes, which may or may not have been what Ira McDonald had in mind, at http://users.adelphia.net/~dewell/lstreg-ira.xml: language aa Afar 2004-07-06 These are only up for illustration, not for advocacy. Personally I liked the old vertical-bar format, but if the group would prefer to see a change, that's fine. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 12:23:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16183; Sun, 27 Mar 2005 12:23:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFba0-0004im-Ds; Sun, 27 Mar 2005 12:29:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFbSf-0007uM-8M; Sun, 27 Mar 2005 12:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFbSe-0007uH-4X for ltru@megatron.ietf.org; Sun, 27 Mar 2005 12:22:04 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16088 for ; Sun, 27 Mar 2005 12:22:01 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFbRm-0006xX-E8 for ltru@lists.ietf.org; Sun, 27 Mar 2005 19:21:10 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 19:21:10 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 19:21:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 19:20:26 +0200 Organization: Lines: 38 Message-ID: <4246EB5A.6FF1@xyzzy.claranet.de> References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org> <008d01c53220$4689b7a0$030aa8c0@DEWELL> 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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> I'm not planning to buy a new hard drive only to read a IANA >> registry with language tags ;-) > I said the registry would grow by 600,000 bytes. I don't > think that's quite big enough to require you to buy a new > hard drive. Sure, I was joking. It would be serious if you were talking about 50 MB. Or maybe about cell phones / PDAs / etc. > Whether the registry gets split into pieces is, I suppose, > IANA's business. Scott said that we should assume the worst, or at leaast that was my interpretation. One way to organize this could be a "one tage = one file" subdirectory (+ ZIP or similar), for an example see the xml2rfc subdirectories: There are similar subdirectories for fresh I-Ds, other formats, other popular references, etc. One example you could need in a future "draft registry" with xml2rfc is: > it's still a non-issue until ISO 639-3 codes become available > as extended-language subtags, which won't happen until (a) > ISO 639-3 is published and (b) the registry RFC we are > working on is updated to accommodate them. Sure, but IANA and many users won't be happy if we change the format of their langtag registry more than once in this decade. Yes, I know when RfC 3066 was published. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 13:09:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20577; Sun, 27 Mar 2005 13:09:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFcJJ-0006W6-V3; Sun, 27 Mar 2005 13:16:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFcC6-0008J7-3c; Sun, 27 Mar 2005 13:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFcC4-0008Ic-Ca for ltru@megatron.ietf.org; Sun, 27 Mar 2005 13:09:00 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20176 for ; Sun, 27 Mar 2005 13:08:56 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFcB0-0002X8-77 for ltru@lists.ietf.org; Sun, 27 Mar 2005 20:07:54 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 20:07:54 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 20:07:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 20:05:40 +0200 Organization: Lines: 55 Message-ID: <4246F5F4.2282@xyzzy.claranet.de> References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <001301c53228$6fc9bd60$030aa8c0@DEWELL> 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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Shelf life of data X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Doug Ewell wrote: > There's nothing magic about 10 years. For our purposes the last 10 years would allow us to get rid of the A-list country codes (after 1988, before RfC 1766): BU, DD, FX, NT, SU, TP, YD, YU, ZR. If the next registry draft allows to use ISO 3166-3 as a source for canonical values, we could fix DDDE and YDYE (no canonical value for DD and YD at the moment). We would still have the odd situation, that tags for DD and YD are possible, but tags for the old DE and YE are impossible - these country codes are now implicitly the new DE (incl. DD) and the new YE (incl. YD). To fix this oddity we could add a "union rule": | If two or more regions form a union, and if that union | inherits the country code of one of its former parts, then | the former UN number of this region is added as deprecated | subtag with a corresponding canonical value. Example - I'm too lazy to check the UN numers and invent them here, before the union of YD+YE and DD+DE resp.: YD 101 YE 102 DD 201 DE 202 After the unions: 102 YE # deprecated YD 101 YE # deprecated (3166-3 YDYE) YE 100 # see also 102 202 DE # deprecated DD 201 DE # deprecated (3166-3 DDDE) DE 200 # see also 202 At the moment the consensus is apparently some "frozen 3166-1" concept, and not my "whatever 3166-1 says is fine but unstable" idea. In that case we'd need better rules for "unions" (and probably also for "splits") when the new region inherits an old country code. Otherwise we'd implicitly "lose" regions as shown above. You're all very sure that my proposal to use UN numbers for stability isn't okay ? All these weird cases of "unions", "splits", "lost regions", etc. don't exist for UN numbers. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 13:36:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23297; Sun, 27 Mar 2005 13:36:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFcjU-0007We-Th; Sun, 27 Mar 2005 13:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFcd1-0004UO-WD; Sun, 27 Mar 2005 13:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFcd0-0004UJ-Ko for ltru@megatron.ietf.org; Sun, 27 Mar 2005 13:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23270 for ; Sun, 27 Mar 2005 13:36:45 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFcjJ-0007WS-3l for ltru@ietf.org; Sun, 27 Mar 2005 13:43:22 -0500 Received: from Lugh (83-70-239-110.b-ras1.prp.dublin.eircom.net [83.70.239.110]) by postie2.hosting365.ie (Postfix) with ESMTP id A64EE24C1FD9A for ; Sun, 27 Mar 2005 19:36:44 +0100 (IST) From: "Jon Hanna" To: Subject: RE: [Ltru] Re: Registry in record-jar format Date: Sun, 27 Mar 2005 19:36:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4246EB5A.6FF1@xyzzy.claranet.de> Thread-Index: AcUy8aSa40cr6nVCTvWlDTAlFQtGSwACkQcw Message-Id: <20050327183644.A64EE24C1FD9A@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit What is the "dumbest" device we're likely to want to have a cache of the registry? This clearly isn't an elevator-control matter, but how much smarter than that would something have to be before having a access to the registry is useful, and hence before the size of the cache becomes a significant matter? Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 13:56:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24966; Sun, 27 Mar 2005 13:56:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFd2j-0008DV-JR; Sun, 27 Mar 2005 14:03:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFcvf-0008MS-VE; Sun, 27 Mar 2005 13:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFcve-0008MN-8E for ltru@megatron.ietf.org; Sun, 27 Mar 2005 13:56:06 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24885 for ; Sun, 27 Mar 2005 13:56:04 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFcue-0005zi-OG for ltru@lists.ietf.org; Sun, 27 Mar 2005 20:55:04 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 20:55:04 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 20:55:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 20:48:15 +0200 Organization: Lines: 23 Message-ID: <4246FFEF.543A@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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: XML registries now available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > Looking forward in this thread, Frank's right, you can't > put XML with non-ASCII characters in an RFC. Period. Wait a moment, that's the interesting point about XML, you can use us-ascii in the document with character references like å - the W3C now prefers hex. (C048), but that's a "no-BC" idea for (X)HTML. You can also define symbolic character references on the fly like or "include" these symbolic definitions found in another public DTD / ENT file. > Using XML seems to be considered here mainly as a codespace > solution for non-ASCII names (which is NOT a good reason for > using XML). For the very simple structure needed here it's the only pro-XML argument I can think of. We both don't want XML, but apparently for different reasons. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 14:02:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25313; Sun, 27 Mar 2005 14:02:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFd7i-0008LQ-Lb; Sun, 27 Mar 2005 14:08:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFczy-0000ba-L3; Sun, 27 Mar 2005 14:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFczx-0000bV-EK for ltru@megatron.ietf.org; Sun, 27 Mar 2005 14:00:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25225 for ; Sun, 27 Mar 2005 14:00:32 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFd6J-0008JO-8x for ltru@ietf.org; Sun, 27 Mar 2005 14:07:07 -0500 Received: from Lugh (83-70-239-110.b-ras1.prp.dublin.eircom.net [83.70.239.110]) by postie2.hosting365.ie (Postfix) with ESMTP id B486F24C3DCE4 for ; Sun, 27 Mar 2005 20:00:31 +0100 (IST) From: "Jon Hanna" To: Subject: RE: [Ltru] Re: XML registries now available Date: Sun, 27 Mar 2005 20:00:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4246FFEF.543A@xyzzy.claranet.de> Thread-Index: AcUy/rzE5GvjtYanQgeXAHPOXCrcZAAAGaMw Message-Id: <20050327190031.B486F24C3DCE4@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > Wait a moment, that's the interesting point about XML, you can > use us-ascii in the document with character references like > å - the W3C now prefers hex. (C048), but that's a "no-BC" > idea for (X)HTML. In practice only for HTML, with XHTML if that's causing you BC problems so will a whole lot else. Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 14:13:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26368; Sun, 27 Mar 2005 14:13:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdJE-0000KK-3M; Sun, 27 Mar 2005 14:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdCC-0002qj-IG; Sun, 27 Mar 2005 14:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdCB-0002qe-6i for ltru@megatron.ietf.org; Sun, 27 Mar 2005 14:13:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26293 for ; Sun, 27 Mar 2005 14:13:09 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdIV-0000JX-U5 for ltru@ietf.org; Sun, 27 Mar 2005 14:19:45 -0500 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sun, 27 Mar 2005 19:12:57 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IE000CIRYPGDM@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sun, 27 Mar 2005 19:12:53 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Sun, 27 Mar 2005 20:04:38 +0100 Date: Sun, 27 Mar 2005 20:04:37 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: XML registries now available To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: XML registries now available Thread-Index: AcUy/ubOqtmyDfOwRbid2YINE3vzVQAANsvw content-class: urn:content-classes:message X-OriginalArrivalTime: 27 Mar 2005 19:04:38.0146 (UTC) FILETIME=[D29CAE20:01C532FF] X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Why are we talking about XML in an RFC. Surely the registry wouldn't be *in* an RFC? HTML 4.01 allows hex NCRs [1], as does XHTML. [1] http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.3 Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 14:24:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27005; Sun, 27 Mar 2005 14:24:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdT8-0000gk-2N; Sun, 27 Mar 2005 14:30:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdLu-0004dF-PV; Sun, 27 Mar 2005 14:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdLt-0004d0-Rb for ltru@megatron.ietf.org; Sun, 27 Mar 2005 14:23:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26882 for ; Sun, 27 Mar 2005 14:23:12 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdSE-0000aq-OA for ltru@ietf.org; Sun, 27 Mar 2005 14:29:47 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2RJN1uh011981; Sun, 27 Mar 2005 14:23:02 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 27 Mar 2005 14:23:08 -0500 Date: Sun, 27 Mar 2005 14:23:08 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: XML registries now available Message-ID: <20050327192308.GM24325@skunk.reutershealth.com> References: <009a01c53275$99c1bb20$030aa8c0@DEWELL> <4246DE12.7531@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4246DE12.7531@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Frank Ellermann scripsit: > It's fine, but unusable in an I-D or RfC. Therefore I'd opt > for record-jar or a variant with empty lines instead of "%%", > plus the normal MIME folding for too long lines. Empty lines easily get lost in RFC format if they appear at the top or bottom of a page; the "%%" delimiter is not subject to that problem. -- We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum jcowan@reutershealth.com www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 14:37:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28422; Sun, 27 Mar 2005 14:37:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdfh-0001A9-3w; Sun, 27 Mar 2005 14:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdYY-00079q-Fb; Sun, 27 Mar 2005 14:36:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdYW-00079e-4b for ltru@megatron.ietf.org; Sun, 27 Mar 2005 14:36:16 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28366 for ; Sun, 27 Mar 2005 14:36:13 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFdWg-0000NQ-Qp for ltru@lists.ietf.org; Sun, 27 Mar 2005 21:34:22 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 21:34:22 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 21:34:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 21:28:39 +0200 Organization: Lines: 24 Message-ID: <42470967.2A10@xyzzy.claranet.de> References: <4246FFEF.543A@xyzzy.claranet.de> <20050327190031.B486F24C3DCE4@postie2.hosting365.ie> 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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: XML registries now available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Jon Hanna wrote: >> å - the W3C now prefers hex. (C048), but that's a >> "no-BC" idea for (X)HTML. > In practice only for HTML, with XHTML if that's causing > you BC problems so will a whole lot else. IMHO XHTML 1.0 transitional is the best available HTML 3.2 for new "BC" pages. My vintage 1997 browser generally loves it as long as I stay away from . It's only sad that there's no similar later XHTML version for new simple "BC" pages, where I can avoid almost all legacy markup except from a few cases of align= and name=, and maybe bgcolor= together with the color= part of . Very off topic, pro forma on topic: IANA publishs many of its registries as (X)HTML pages, and if the future registry will be a 
...
part of an (X)HTML page no matter what we do, then plain text us-ascii solutions at any cost instead of XML would be a dubious idea. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 14:55:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29526; Sun, 27 Mar 2005 14:55:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdxa-0001k6-SF; Sun, 27 Mar 2005 15:02:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdqj-0001n0-P7; Sun, 27 Mar 2005 14:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdqi-0001mv-Dk for ltru@megatron.ietf.org; Sun, 27 Mar 2005 14:55:04 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29485 for ; Sun, 27 Mar 2005 14:55:02 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFdpn-0001w8-7z for ltru@lists.ietf.org; Sun, 27 Mar 2005 21:54:07 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 21:54:07 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Mar 2005 21:54:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 27 Mar 2005 21:48:48 +0200 Organization: Lines: 11 Message-ID: <42470E20.6AC6@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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: XML registries now available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Misha Wolf wrote: > Surely the registry wouldn't be *in* an RFC? The _initial_ registry could be in an RfC, compare RfC 4021 and http://www.iana.org/assignments/message-headers/perm-headers.html In that case IANA invented its own format instead of using the initial registry, the time lag between RfC 3864, 3865, and 4021 could be the reason, maybe they'll fix this later. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 14:58:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29723; Sun, 27 Mar 2005 14:58:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFe0r-0001pu-P5; Sun, 27 Mar 2005 15:05:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdtZ-0002Eh-4C; Sun, 27 Mar 2005 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdtY-0002Ec-0Z for ltru@megatron.ietf.org; Sun, 27 Mar 2005 14:58:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29679 for ; Sun, 27 Mar 2005 14:57:58 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdzt-0001ow-4O for ltru@ietf.org; Sun, 27 Mar 2005 15:04:34 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2RJvh8p000368; Sun, 27 Mar 2005 11:57:43 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77GY04>; Sun, 27 Mar 2005 11:57:44 -0800 Message-ID: From: "McDonald, Ira" To: "'Misha Wolf'" , ltru@ietf.org Subject: RE: [Ltru] Re: XML registries now available Date: Sun, 27 Mar 2005 11:57:39 -0800 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: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Misha, We're talking about XML in an RFC (and non-ASCII not being legal in an RFC) because many or most new IANA registries are _originally_ published in an RFC (because the outside reviewers of the IANA procedures can clearly see what the intended result is during the IESG 'last call'). If our IETF Area Directors and IANA are willing to forgo such an RFC and go straight to the IANA registry plus the procedures defined in LTRU 'IANA Considerations' section, then this issue is irrelevant. Although using non-ASCII and non-UTF-8 charsets in IANA registries (like ISO 8859-1 which has been suggested) may still get pushback from IESG and IANA. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Misha Wolf Sent: Sunday, March 27, 2005 2:05 PM To: ltru@ietf.org Subject: RE: [Ltru] Re: XML registries now available Why are we talking about XML in an RFC. Surely the registry wouldn't be *in* an RFC? HTML 4.01 allows hex NCRs [1], as does XHTML. [1] http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.3 Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 15:05:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00760; Sun, 27 Mar 2005 15:05:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFe7X-00028k-JZ; Sun, 27 Mar 2005 15:12:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFe0R-0003Z3-1n; Sun, 27 Mar 2005 15:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFe0P-0003Yy-4x for ltru@megatron.ietf.org; Sun, 27 Mar 2005 15:05:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00656 for ; Sun, 27 Mar 2005 15:05:03 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFe6l-00024w-EG for ltru@ietf.org; Sun, 27 Mar 2005 15:11:39 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2RK4sAU000689; Sun, 27 Mar 2005 12:04:54 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77GZBW>; Sun, 27 Mar 2005 12:04:54 -0800 Message-ID: From: "McDonald, Ira" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: XML registries now available Date: Sun, 27 Mar 2005 12:04:44 -0800 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, I am _not_ opposed to an XML registry for language tags. I'm opposed to _only_ an XML registry. I liked the option (4) a while back on this list with both: (a) Normative record-jar format in straight 7-bit ASCII (b) Informative XML for ease-of-use by some automata Separately, the discussion about how small a device (e.g., PDA or cellphone) needs to cache the registry is flawed. No software should EVER download the registry from IANA in a running device - this is a denial-of-service nightmare. Software that downloaded newer language tags wouldn't know what to do with them 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 16:50:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08719; Sun, 27 Mar 2005 16:50:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFflF-0004zj-Dg; Sun, 27 Mar 2005 16:57:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFfdd-0004BL-9m; Sun, 27 Mar 2005 16:49:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFfdb-0004BG-AN for ltru@megatron.ietf.org; Sun, 27 Mar 2005 16:49:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08667 for ; Sun, 27 Mar 2005 16:49:37 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFfjx-0004xP-Ie for ltru@ietf.org; Sun, 27 Mar 2005 16:56:14 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2RLnRGx012782; Sun, 27 Mar 2005 16:49:28 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 27 Mar 2005 16:49:39 -0500 Date: Sun, 27 Mar 2005 16:49:39 -0500 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: XML registries now available Message-ID: <20050327214939.GN24325@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 McDonald, Ira scripsit: > Software that downloaded newer language tags wouldn't know > what to do with them anyway. This point deserves to be written up somewhere in letters of gold. It is why there is absolutely no comparison between the LTR and the DNS. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 16:57:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09220; Sun, 27 Mar 2005 16:57:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFfrP-00059F-1g; Sun, 27 Mar 2005 17:03:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFfkf-0005O8-5L; Sun, 27 Mar 2005 16:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFfkc-0005LQ-SJ for ltru@megatron.ietf.org; Sun, 27 Mar 2005 16:56:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09202 for ; Sun, 27 Mar 2005 16:56:52 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFfqz-00058k-3M for ltru@ietf.org; Sun, 27 Mar 2005 17:03:30 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFfkY-00084R-Tq; Sun, 27 Mar 2005 13:56:51 -0800 Message-Id: <6.1.2.0.2.20050327234016.03784a10@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 27 Mar 2005 23:56:49 +0200 To: "Jon Hanna" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Registry in record-jar format In-Reply-To: <20050327183644.A64EE24C1FD9A@postie2.hosting365.ie> References: <4246EB5A.6FF1@xyzzy.claranet.de> <20050327183644.A64EE24C1FD9A@postie2.hosting365.ie> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 At 20:36 27/03/2005, Jon Hanna wrote: >What is the "dumbest" device we're likely to want to have a cache of the >registry? > >This clearly isn't an elevator-control matter, but how much smarter than >that would something have to be before having a access to the registry is >useful, and hence before the size of the cache becomes a significant matter? Could the authors (or anyone have a good command of their intent) document the exact _use_ of the IANA files as they see it. - an application reads a langtag. - what does it do? - when is it going to need a IANA originated data? - will it be usually in the application code? will be it be updated in a parameter file? will it call the IANA? Should it call a cache/mirror? Then who should manage them? - which applications will do that? - how many times a day/month/year will this happen for a single user? or ISP? or designer? For example, I understand that the non documented CLDR application mostly needs the langtag as a reference and will maintain its own files to be themselves used by OS programmers. So the load should be very low, unless someone develops an updating tool direct from the IANA and people use it at each reboot. I am not sure about HTML and XML applications? I am not sure about the need of updates? Will it be on a regular basis, or when an error is met an update will be requested? Should there be a solution to prevent an application to loop (like there are tools for Whois from hat I know)? etc. We do have to document in detail the IANA section, and I am really at loss understanding what we are talking about. I maintain a daily review of the IANA files for ccTLDs (http://afrac.org/intldate.txt). It actually decreases the load on IANA since people know if there is an update of not for them to look. But if many people made the same thing as me for their own us, or if my cron had a problem, it could create an overload. Without that information the whole Draft does not make any sense, because it is to document a IANA service and there are different strategies to address the need, depending on the load it represents. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 17:17:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10486; Sun, 27 Mar 2005 17:17:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFgAf-0005WP-NR; Sun, 27 Mar 2005 17:23:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFg34-0000DD-GS; Sun, 27 Mar 2005 17:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFg32-00009p-A8 for ltru@megatron.ietf.org; Sun, 27 Mar 2005 17:15:56 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10256 for ; Sun, 27 Mar 2005 17:15:53 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DFg2E-0005bO-Pw for ltru@lists.ietf.org; Mon, 28 Mar 2005 00:15:06 +0200 Received: from d253251.dialin.hansenet.de ([80.171.253.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Mar 2005 00:15:06 +0200 Received: from nobody by d253251.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Mar 2005 00:15:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 28 Mar 2005 00:14:11 +0200 Organization: Lines: 16 Message-ID: <42473033.4DF8@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: d253251.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: XML registries now available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > No software should EVER download the registry from IANA in > a running device - this is a denial-of-service nightmare. > Software that downloaded newer language tags wouldn't know > what to do with them anyway. What I had in mind was the configuration of "accept-languages" with my browser: It came with a huge list of choices, and it offered to add other values manually. The relevant part for "small devices" is the "huge list" - not dowloaded from IANA for each device, built-in, but you'd need that ROM. No idea how it's today, but a decade ago EPROM / EEPROM / etc. were quite expensive in relation to the complete costs. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 21:20:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28614; Sun, 27 Mar 2005 21:20:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFjxd-0001oO-K4; Sun, 27 Mar 2005 21:26:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFjqc-0007Lx-Rt; Sun, 27 Mar 2005 21:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFGGr-0001lq-3F for ltru@megatron.ietf.org; Sat, 26 Mar 2005 13:44:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19824 for ; Sat, 26 Mar 2005 13:44:25 -0500 (EST) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFGMy-0007b8-Jc for ltru@ietf.org; Sat, 26 Mar 2005 13:50:49 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMBN2YKPU800005R@mauve.mrochek.com> for ltru@ietf.org; Sat, 26 Mar 2005 10:44:19 -0800 (PST) Date: Sat, 26 Mar 2005 10:32:51 -0800 (PST) In-reply-to: "Your message dated Sat, 26 Mar 2005 09:22:49 -0800" <001301c53228$6fc9bd60$030aa8c0@DEWELL> Message-id: <01LMCEAVZ15I00005R@mauve.mrochek.com> References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <001301c53228$6fc9bd60$030aa8c0@DEWELL> Subject: Re: [Ltru] Shelf life of data (was: Re: Question) To: Doug Ewell X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Sun, 27 Mar 2005 21:19:21 -0500 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7BIT > > Retro compatibility is offered for a long nowhere. Try to use your > > 1930 telephone set, I am not sure it will work. Bad example. I have in fact done exactly this, and 1930s era phones are fully funcitonal today on a POTS line. (Of course they won't work on a digital conection, but that's to be expected.) Rotary dial phones were introduced around 1920, and even the phones without dials popular before that will let you listen and talk. (Ringing is another, more complex story.) This poster illustrates this aspect of telephone history rather nicely: http://www.sandman.com/images/telstory.jpg > > Try to publish an > > Internet 1990 terminology. Try to use the root servers file of 1995, > > it will may be still work partly. Try to use DOS on your PC, it works > > very well, but you are missing a lot of things. > People have been quoting RFC 822, which is 23 years old, on this list. > Even though it has been updated by RFC 2822, obviously many of the basic > philosophies and terminology still apply. Exactly right. And more to the point, lots of other RFCs published at or around the same time are nothing but historical artefacts. And at various points along the way if you'd taken a survey you would have found a lot of people believed RFC 822 would join them in short order, having been replaced by X.400. > > Objection to a decade obsolecense cycle? > It's much too general to apply blindly. Some standards and technologies > are obsolete within a year or two; others are good for decades. ASCII > is 42 years old (or 38, depending on what you mean by "ASCII"), and yet > many people still consider it the lowest common denominator necessary to > ensure reliable communications. And furthermore, we aren't good at predicting what will survive and what will be lost. Planned obsolescence is therefore a bad idea for standards, since things often don't go according to plan. > There's nothing magic about 10 years. Absolutely. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 27 21:21:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28680; Sun, 27 Mar 2005 21:21:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFjzV-0001pz-MY; Sun, 27 Mar 2005 21:28:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFjqc-0007Lt-In; Sun, 27 Mar 2005 21:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DExvx-0005cP-6v for ltru@megatron.ietf.org; Fri, 25 Mar 2005 18:09:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26868 for ; Fri, 25 Mar 2005 18:09:37 -0500 (EST) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEy1u-00023b-0V for ltru@ietf.org; Fri, 25 Mar 2005 18:15:51 -0500 Received: from snv-lobby-rtr.corp.yahoo.com (HELO xencraft.com) (216.145.49.17) by smtp04.mrf.mail.rcn.net with ESMTP; 25 Mar 2005 18:09:35 -0500 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.8.1]); Fri, 25 Mar 2005 15:08:35 -0800 Message-ID: <424499F3.5DD89DD3@xencraft.com> Date: Fri, 25 Mar 2005 15:08:35 -0800 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Question References: <20050323112201.IBOG5424.mta6.adelphia.net@megatron.ietf.org><009c01c53105$ac1ce720$030aa8c0@DEWELL><20050325072710.GA14412@ccil.org><0e2d01c53157$9d2c0230$727d3009@sanjose.ibm.com> <4244676A.6FAD@xyzzy.claranet.de> <0f9901c53178$7de93840$727d3009@sanjose.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 27 Mar 2005 21:19:21 -0500 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit The question of speaking up for no-BC is a bit loaded when asked in that way. I would not mind forgoing backward compatibility if there were compensating benefits. I would need to believe that the benefits were real, and also that there weren't a number of hidden dangers that might be more problematic than dealing with the cost of legacy. But given the ambiguities in the legacy of language tags, and its different usages by different technologies, I can certainly see creating a new scheme. In fact would want it to look different so it didnt suffer the confusion and baggage of the current system. I said this a few years ago as well when we discussed solving the problems I raised in the locales paper for the Unicode conference. I would still welcome a new approach. I don't see however, that we have a way to articulate a clean solution. The problem I see is not in architecting the scheme for tagging, but determining what a language is, in a useful way for software developers, so that they can understand which language tag to use, and not an identification which only linguists recognize or criteria which are not clearly expressed. So yes, forget compatibility if I can have a scheme that works. On the other hand, if we maintain compatibility and make the current system more complex and no more usable, I don't need that either. I would welcome a clear set of rules for choosing a tag for content, and rules for finding content with known tags. tex Mark Davis wrote: > > People presumed that 3066 was backwards compatible with 1766, and data was > generated on that basis. The cost of supporting full backwards compatibility > with 1766 and 3066 (for all but the ISO codes that were reused) is extremely > low, just a few additional codes. We then don't disturb the stability of > tags that were generated in good faith, using codes that at some point in > time qualified as 'assigned' in the base standards. > > On that basis, I think it's a no-brainer. > > You are the only one I hear saying that we don't care about backward > compability with codes that were valid under 1766 and 3066. Anyone else want > to speak up for non-backwards compatibility? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 01:27:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17103; Mon, 28 Mar 2005 01:27:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFnox-0006zB-Ix; Mon, 28 Mar 2005 01:33:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFniB-00012g-Tz; Mon, 28 Mar 2005 01:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFniA-00012Y-7I for ltru@megatron.ietf.org; Mon, 28 Mar 2005 01:26:54 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17090 for ; Mon, 28 Mar 2005 01:26:51 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050328062620.XKAT4618.mta13.adelphia.net@DEWELL> for ; Mon, 28 Mar 2005 01:26:20 -0500 Message-ID: <005201c5335f$016c1f60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050327165301.DMEA2140.mta3.adelphia.net@megatron.ietf.org> Date: Sun, 27 Mar 2005 22:25:57 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: 3166-1 state machine (was: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> "Why they are reserved" is not important. Either a code is >> currently assigned, or it was formerly assigned, or it is >> private-use ("user-assigned"). Distinctions between the >> different types of "reserved" are of interest only to the MA. > > I'm not sure, if "transitionally reserved" is essentially the > same as "deprecated", this could be relevant, and if all these > other "reservations" hide what we're interested in here, i.e. > "deprecated" vs. "unassigned", it could be also relevant. We should apply the various ISO 3166 categories of "reserved" or "unassigned" only if they help meet the real goal of allowing all codes that have been in ISO 3166 since 1988, and disallowing all others. Recall that the disallowed codes (withdrawn before 1988) would be BQ, CT, DY, FQ, HV, JT, MI, NH, NQ, PC, PU, PZ, RH, VD, and WK. All of these are marked "unassigned," except for DY and RH, which are "indeterminately reserved" due to their use in car codes. In fact, as seen earlier, RH is reserved because of its association with Haiti, not Southern Rhodesia. Also recall that the allowed codes (withdrawn after 1988) would be BU, DD, FX, NT, SU, TP, YD, YU, and ZR. All of these are "transitionally reserved," except for DD and YD, which are simply "unassigned," and FX, which is "exceptionally reserved." The DD and YD cases seem odd because both were withdrawn in 1990, a year later than BU, which is still "transitionally reserved." FX is a strange code to begin with, but its status in the "exceptionally reserved" category makes things worse; that category is a catch-all, and we learn nothing about FX by finding it there. These exceptions make me uncomfortable with relying on the ISO 3166 categories. > And for Mark's "Joe Blow" or my "Jane Blog" anything on the > 3166-1 web pages could be (ab)used. Especially before 3066bis. > > If we don't have a copy of ISO 3166:1988, then Joe and Jane > also have no copy, that's why they (ab)use ccTLDs or reserved > codes. Until the future 3066bis registry helps to catch such > errors. We're *talking* about the future 3066bis registry. What people do with 3066 is out of scope for this group -- although I have to ask again, is there really any evidence that people are using non-ISO 3166 ccTLDs in language tags? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 01:45:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23321; Mon, 28 Mar 2005 01:45:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFo6E-000805-7s; Mon, 28 Mar 2005 01:51:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFnyz-0003Z3-IM; Mon, 28 Mar 2005 01:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFnyx-0003Yy-R4 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 01:44:15 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23254 for ; Mon, 28 Mar 2005 01:44:14 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050328064344.YWEO2192.mta9.adelphia.net@DEWELL> for ; Mon, 28 Mar 2005 01:43:44 -0500 Message-ID: <005501c53361$71402280$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050326155923.OBLW2135.mta2.adelphia.net@megatron.ietf.org> Date: Sun, 27 Mar 2005 22:43:23 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Question X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> Joe Blow was deciding whether his code should allow "en-BU" > > That's a sad story, like Jane Blog's adventure in cyberspace: > > Seeing RH on a car in Haiti she checks the ISO 3166-1 Web > page and finds something about "RH Haiti" as expected, So > she tags a Creole text with fr-RH, and later she's surprised > when her job application is returned by the ZW embassy. Jane lost the job because the HR director at the embassy also checked the ISO 3166-1 Web page, which clearly says that indeterminately reserved code elements like RH "must not be used in ISO 3166-1," and decided that Jane doesn't follow directions well. > The most serious problem with the actual draft is, that it > forces us to choose between an erroneous concept of backwards > compatibility and compatibility with future country codes for > the known list of "invalid" country codes. At least for the > decade 1995 - 2005 we can get one unambiguous idea of "valid". There is nothing "erroneous" about the concept of backward compatibility being discussed here. RFC 1766 and 3066 allowed language tags to contain any code in the 1988 versions of ISO 639 and 3166. Eliminating the region subtags based on ISO 3166 codes that were withdrawn before 1988 removes 15 of the 24 "problem codes," notably the Antarctic codes you have criticized most strongly. Changing the date to 1995 would add only five more codes (BU, DD, NT, SU, and YD) to the blacklist. Is that worth violating the agreement set down in RFC 1766? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 02:00:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24411; Mon, 28 Mar 2005 02:00:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFoL3-0008R9-5f; Mon, 28 Mar 2005 02:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFoDI-0005Di-7I; Mon, 28 Mar 2005 01:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFoDH-0005Da-AS for ltru@megatron.ietf.org; Mon, 28 Mar 2005 01:59:03 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24020 for ; Mon, 28 Mar 2005 01:59:01 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050328065831.XKEK5402.mta11.adelphia.net@DEWELL> for ; Mon, 28 Mar 2005 01:58:31 -0500 Message-ID: <006c01c53363$80b8c9e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050327200556.CZGC2135.mta4.adelphia.net@megatron.ietf.org> Date: Sun, 27 Mar 2005 22:58:09 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Shelf life of data X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> There's nothing magic about 10 years. > > For our purposes the last 10 years would allow us to get rid > of the A-list country codes (after 1988, before RfC 1766): > > BU, DD, FX, NT, SU, TP, YD, YU, ZR. FX was withdrawn in 1997, TP in 2002, YU in 2003, ZR in 1997. "Getting rid of" these codes -- or, for that matter, the other five you mentioned, which WERE withdrawn before 1995 -- will not significantly improve the registry, but they may render some valid RFC 1766/3066 codes invalid. Group members, can we please come to a decision on this? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 06:44:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07279; Mon, 28 Mar 2005 06:44:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFsmU-0000iB-UD; Mon, 28 Mar 2005 06:51:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsf6-0007sN-Eb; Mon, 28 Mar 2005 06:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsf4-0007s1-Gw for ltru@megatron.ietf.org; Mon, 28 Mar 2005 06:44:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07212 for ; Mon, 28 Mar 2005 06:43:59 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFslY-0000gA-Qs for ltru@ietf.org; Mon, 28 Mar 2005 06:50:45 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFses-0001jf-Mb; Mon, 28 Mar 2005 03:43:51 -0800 Message-Id: <6.1.2.0.2.20050328121911.037a4eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Mar 2005 13:43:47 +0200 To: John Cowan , "McDonald, Ira" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: XML registries now available In-Reply-To: <20050327214939.GN24325@skunk.reutershealth.com> References: <20050327214939.GN24325@skunk.reutershealth.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 At 23:49 27/03/2005, John Cowan wrote: >McDonald, Ira scripsit: > > > Software that downloaded newer language tags wouldn't know > > what to do with them anyway. > >This point deserves to be written up somewhere in letters of gold. >It is why there is absolutely no comparison between the LTR and the DNS. I do not understand this. Could you document that? I assume you consider the situation where: 1. the application gets a langtag 2. consider what do to with it. 3. there are three possible solutions? - it knows the langtag from it being built-in. - it does not know it but it has a filtering/negociation strategy built-in or based upon non IANA parameters - all this fails and its filtering/negociation strategy resort to a IANA input before concluding? I would say this is similar to anti-spam or to anti-virus strategies. Obviously codes change les frequently than spamming hosts and viruses, but the simple fact they change make the load similar (the load is not because there are a lot of changes, but because there is a check if nothing changed). What do I suppose wrong according you? Thanks. jfc >-- >John >Cowan jcowan@reutershealth.com www.reutershealth.com www.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@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 06:46:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07443; Mon, 28 Mar 2005 06:46:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFsnp-0000kS-QI; Mon, 28 Mar 2005 06:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsf6-0007sF-7Q; Mon, 28 Mar 2005 06:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsf4-0007s0-GD for ltru@megatron.ietf.org; Mon, 28 Mar 2005 06:44:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07214 for ; Mon, 28 Mar 2005 06:43:59 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFslY-0000gB-R1 for ltru@ietf.org; Mon, 28 Mar 2005 06:50:45 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFsev-0001jf-Dh; Mon, 28 Mar 2005 03:43:54 -0800 Message-Id: <6.1.2.0.2.20050328131347.04b93aa0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Mar 2005 13:26:33 +0200 To: ned.freed@mrochek.com, Doug Ewell From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Shelf life of data (was: Re: Question) In-Reply-To: <01LMCEAVZ15I00005R@mauve.mrochek.com> References: <20050325170422.OQBN4900.mta8.adelphia.net@megatron.ietf.org> <001301c53228$6fc9bd60$030aa8c0@DEWELL> <01LMCEAVZ15I00005R@mauve.mrochek.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This calls for a few comments to understand what we are discussing. At 20:32 26/03/2005, ned.freed@mrochek.com wrote: > > > Retro compatibility is offered for a long nowhere. Try to use your > > > 1930 telephone set, I am not sure it will work. > >Bad example. I have in fact done exactly this, and 1930s era phones are fully >funcitonal today on a POTS line. (Of course they won't work on a digital >conection, but that's to be expected.) Rotary dial phones were introduced >around 1920, and even the phones without dials popular before that will >let you >listen and talk. (Ringing is another, more complex story.) > >This poster illustrates this aspect of telephone history rather nicely: > > http://www.sandman.com/images/telstory.jpg In a nutshell it does not work, but under constraints rebuilding/protecting the 1930 environment it still works. I hope you can listen and talk, any one having tapped a line knows that. You certainly know how to dial without a rotary too I presume. You just document that the system you have is obsolete, i.e. out of use, of old design. > > > Try to publish an > > > Internet 1990 terminology. Try to use the root servers file of 1995, > > > it will may be still work partly. Try to use DOS on your PC, it works > > > very well, but you are missing a lot of things. > > > People have been quoting RFC 822, which is 23 years old, on this list. > > Even though it has been updated by RFC 2822, obviously many of the basic > > philosophies and terminology still apply. > >Exactly right. And more to the point, lots of other RFCs published at or >around >the same time are nothing but historical artefacts. And at various points >along >the way if you'd taken a survey you would have found a lot of people believed >RFC 822 would join them in short order, having been replaced by X.400. Many of us would have liked it to become osolete :-) and we will keep spam as long as it is not :-)))) I prefer STD 013 as an example. > > > Objection to a decade obsolecense cycle? > > > It's much too general to apply blindly. Some standards and technologies > > are obsolete within a year or two; others are good for decades. ASCII > > is 42 years old (or 38, depending on what you mean by "ASCII"), and yet > > many people still consider it the lowest common denominator necessary to > > ensure reliable communications. > >And furthermore, we aren't good at predicting what will survive and what will >be lost. Planned obsolescence is therefore a bad idea for standards, since >things often don't go according to plan. In our case we do not predict. We consider two things: - the cycles of code reasignment of the ISO standard we consider and their interference - the user behaviors we want to foster. I am afraid you confuse the obsolecence of the "things" and the decided duration of validity of the data. The obsolecense of the validity of an entry has nothing to do wit the standard, the process, the application. The shortest the obsolescnence the greater the accuracy. In DNS this cycle is named TTL and can be from 0 to anything. Usually is one day to one week. If you want to be accurate (Dynamic DNS you can put id down to the minute or less). The difference between those two notions are very important to address the questions risen by the charter. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 06:47:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07622; Mon, 28 Mar 2005 06:47:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFsoi-0000mP-UZ; Mon, 28 Mar 2005 06:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsf6-0007sJ-B7; Mon, 28 Mar 2005 06:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsf4-0007s2-Jz for ltru@megatron.ietf.org; Mon, 28 Mar 2005 06:44:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07211 for ; Mon, 28 Mar 2005 06:43:59 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFslY-0000g1-Qx for ltru@ietf.org; Mon, 28 Mar 2005 06:50:45 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFset-0001jf-Ua; Mon, 28 Mar 2005 03:43:52 -0800 Message-Id: <6.1.2.0.2.20050328122657.037aa150@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Mar 2005 13:07:02 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: XML registries now available In-Reply-To: <42473033.4DF8@xyzzy.claranet.de> References: <42473033.4DF8@xyzzy.claranet.de> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da On 00:14 28/03/2005, Frank Ellermann said: >McDonald, Ira wrote: > > > No software should EVER download the registry from IANA in > > a running device - this is a denial-of-service nightmare. > > Software that downloaded newer language tags wouldn't know > > what to do with them anyway. > >What I had in mind was the configuration of "accept-languages" >with my browser: It came with a huge list of choices, and it >offered to add other values manually. The relevant part for >"small devices" is the "huge list" - not dowloaded from IANA >for each device, built-in, but you'd need that ROM. No idea >how it's today, but a decade ago EPROM / EEPROM / etc. were >quite expensive in relation to the complete costs. Bye, Frank Frank, this reasoning is the same as for DNS. First they started with Hosts.txt [an IP address/name table] everyone had to maintain on their computer. Then the update went too heavy (actually this is not the updating, but the check if there is something to be updated). The DNS permitted only the necessary data to be inquired and updated. A good entry is cached until it is wrong. This experience is good for us with some considerations: 1. PADs (private alias directories) will soon emerge as IPv6 and Multilingualism develop, IETF and ICANN do not want/are unable to address. A PAD can be a list of IP address and names in English in a Hosts.eng file and the same list with names in Breton in file Hosts.bre. To change your computer from an English Internet box to a Breton one you just copy Hosts.bre into Hosts.txt and can use Breton URLs all right. 2. The way ICANN and IETF consider the root is obviously a joke - the entire world real time relying religiously on a file IANA takes up to years to update from public data, to the point to two computers in the same room cannot dialog together if they lose connectivity to the root system for longer than a TTL - but in the langtags we can decide : 1) TTL (time to live) for the langtag to be kept in "cache" - in the langtags.txt file on your computer - is the current year + a random 0/365 value. This means that when your entry is older than maximum 729 days you should update your langtags.txt file (the random figure to avoid everyone call the IANA or mirrors the same day). 2) the structure of expired code is entered in the langtags.txt file as code + current year plus description. When it is reassigned description change and a new code+year is entered. So if the obsolescence cycle of a code is 20 years, another is 10 years, another 50 years, you do not mind. I you know the date of the file the langtag comes from you perfectly know what it relates to. In the case of small devices, like a multilingual translator, etc. you just copy the langtags.txt file on a flash memory as you suggest. Obviously when I talk of langtags.txt this is a generic name you can decline in using ISO 639 code to have them in every language you want, langtags.eng, langtags.bre etc.... jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 09:58:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22960; Mon, 28 Mar 2005 09:58:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFvnM-00075B-9a; Mon, 28 Mar 2005 10:04:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFvgR-0007Ht-Fm; Mon, 28 Mar 2005 09:57:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFvgP-0007Hl-K6 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 09:57:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22941 for ; Mon, 28 Mar 2005 09:57:34 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFvmv-00074X-FE for ltru@ietf.org; Mon, 28 Mar 2005 10:04:21 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 06:57:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Shelf life of data Date: Mon, 28 Mar 2005 06:57:26 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Shelf life of data Thread-Index: AcUzY8vXWtcMCvnLRQWXju8uV0QlRAAQkD4g From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 28 Mar 2005 14:57:26.0542 (UTC) FILETIME=[74B342E0:01C533A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0595059176==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============0595059176== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29kZXMgZWxpbWluYXRlZCBhbmQgbm90IHJlYXNzaWduZWQgYWZ0ZXIgUkZDIDE3NjYgY2FtZSBp bnRvIGVmZmVjdCBzaG91bGQgYmUgaW4gdGhlIHJlZ2lzdHJ5LiBQZXJpb2QuDQoNCkNvZGVzIHBy aW9yIHRvIDE5OTUgKG9yIDE5ODggaWYgeW91IGdvIHdpdGggdGhlIHJlZmVyZW5jZSdzIGRhdGUp IGFyZSByZWFsbHkgdGhlIHF1ZXN0aW9uLiBJJ2Qgc3VwcG9ydCBnb2luZyBiYWNrIHRvIDE5ODgg d2l0aCBjb2Rlcywgc2luY2UgdGhlIHJlZmVyZW5jZSBpbiBSRkMgMTc2NiBhbmQgMzA2NiBpcyB1 bmNsZWFyIGFuZCBJIHdlbGwgcmVtZW1iZXIgdGhlIGRheXMgYmVmb3JlIHRoZSBXZWIgKHdoZW4g Z2V0dGluZyBjb2RlIGxpc3RzIHdhcyBhbiBhcmNhbmUgYXJ0IGFuZCBub3QgYSBzY2llbmNlKS4N Cg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBX b3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0Bs aXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdlbGwNCj4gU2VudDogZGltYW5j aGUgMjcgbWFycyAyMDA1IDIyOjU4DQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVj dDogW0x0cnVdIFJlOiBTaGVsZiBsaWZlIG9mIGRhdGENCj4gDQo+IEZyYW5rIEVsbGVybWFubiA8 bm9ib2R5IGF0IHh5enp5IGRvdCBjbGFyYW5ldCBkb3QgZGU+IHdyb3RlOg0KPiANCj4gPj4gVGhl cmUncyBub3RoaW5nIG1hZ2ljIGFib3V0IDEwIHllYXJzLg0KPiA+DQo+ID4gRm9yIG91ciBwdXJw b3NlcyB0aGUgbGFzdCAxMCB5ZWFycyB3b3VsZCBhbGxvdyB1cyB0byBnZXQgcmlkDQo+ID4gb2Yg dGhlIEEtbGlzdCBjb3VudHJ5IGNvZGVzIChhZnRlciAxOTg4LCBiZWZvcmUgUmZDIDE3NjYpOg0K PiA+DQo+ID4gQlUsIERELCBGWCwgTlQsIFNVLCBUUCwgWUQsIFlVLCBaUi4NCj4gDQo+IEZYIHdh cyB3aXRoZHJhd24gaW4gMTk5NywgVFAgaW4gMjAwMiwgWVUgaW4gMjAwMywgWlIgaW4gMTk5Ny4N Cj4gDQo+ICJHZXR0aW5nIHJpZCBvZiIgdGhlc2UgY29kZXMgLS0gb3IsIGZvciB0aGF0IG1hdHRl ciwgdGhlIG90aGVyIGZpdmUgeW91DQo+IG1lbnRpb25lZCwgd2hpY2ggV0VSRSB3aXRoZHJhd24g YmVmb3JlIDE5OTUgLS0gd2lsbCBub3Qgc2lnbmlmaWNhbnRseQ0KPiBpbXByb3ZlIHRoZSByZWdp c3RyeSwgYnV0IHRoZXkgbWF5IHJlbmRlciBzb21lIHZhbGlkIFJGQyAxNzY2LzMwNjYgY29kZXMN Cj4gaW52YWxpZC4gIEdyb3VwIG1lbWJlcnMsIGNhbiB3ZSBwbGVhc2UgY29tZSB0byBhIGRlY2lz aW9uIG9uIHRoaXM/DQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAgRnVsbGVydG9uLCBDYWxpZm9ybmlh DQo+ICBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvDQo+IA0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFp bGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============0595059176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0595059176==-- From ltru-bounces@ietf.org Mon Mar 28 10:52:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29695; Mon, 28 Mar 2005 10:52:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwdw-0000PZ-TL; Mon, 28 Mar 2005 10:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwWV-0005xb-Su; Mon, 28 Mar 2005 10:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwWT-0005xV-Ol for ltru@megatron.ietf.org; Mon, 28 Mar 2005 10:51:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29564 for ; Mon, 28 Mar 2005 10:51:23 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwcy-0000OB-H4 for ltru@ietf.org; Mon, 28 Mar 2005 10:58:10 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 28 Mar 2005 07:51:13 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 28 Mar 2005 07:51:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Shelf life of data Date: Mon, 28 Mar 2005 07:51:13 -0800 Message-ID: Thread-Topic: [Ltru] Re: Shelf life of data thread-index: AcUzY8vXWtcMCvnLRQWXju8uV0QlRAAQkD4gAADu6IA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 28 Mar 2005 15:51:13.0246 (UTC) FILETIME=[F7F737E0:01C533AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable I'd support including everything in ISO 3166:1988 to ensure not making invalid anything that was valid in RFC 1766. Peter > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Sent: Monday, March 28, 2005 6:57 AM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Shelf life of data >=20 > Codes eliminated and not reassigned after RFC 1766 came into effect should > be in the registry. Period. >=20 > Codes prior to 1995 (or 1988 if you go with the reference's date) are > really the question. I'd support going back to 1988 with codes, since the > reference in RFC 1766 and 3066 is unclear and I well remember the days > before the Web (when getting code lists was an arcane art and not a > science). >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Doug Ewell > > Sent: dimanche 27 mars 2005 22:58 > > To: LTRU Working Group > > Subject: [Ltru] Re: Shelf life of data > > > > Frank Ellermann wrote: > > > > >> There's nothing magic about 10 years. > > > > > > For our purposes the last 10 years would allow us to get rid > > > of the A-list country codes (after 1988, before RfC 1766): > > > > > > BU, DD, FX, NT, SU, TP, YD, YU, ZR. > > > > FX was withdrawn in 1997, TP in 2002, YU in 2003, ZR in 1997. > > > > "Getting rid of" these codes -- or, for that matter, the other five you > > mentioned, which WERE withdrawn before 1995 -- will not significantly > > improve the registry, but they may render some valid RFC 1766/3066 codes > > invalid. Group members, can we please come to a decision on this? > > > > -Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 11:35:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10932; Mon, 28 Mar 2005 11:35:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxJb-0004Ii-BN; Mon, 28 Mar 2005 11:42:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxBu-0002Yg-7f; Mon, 28 Mar 2005 11:34:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxBs-0002XR-Fi for ltru@megatron.ietf.org; Mon, 28 Mar 2005 11:34:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10322 for ; Mon, 28 Mar 2005 11:34:08 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxIN-00044V-1X for ltru@ietf.org; Mon, 28 Mar 2005 11:40:56 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2SGXkCl011501; Mon, 28 Mar 2005 08:33:47 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77HBV7>; Mon, 28 Mar 2005 08:33:47 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Re: Shelf life of data Date: Mon, 28 Mar 2005 08:33:46 -0800 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: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Hi, I agree with Addison below. Let's go back to 1988, because it's the most conservative approach to backwards compatibility. We're wasting an awful lot of electronic ink on saving or losing a very small number of existing (??) language tags. Cheers, - Ira PS - Why do we care if someone ever tagged information with an invalid language tag that used a ccTLD not in ISO 3166? Misuse of a standard is not a valid reason to revise the standard. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Addison Phillips Sent: Monday, March 28, 2005 9:57 AM To: Doug Ewell; LTRU Working Group Subject: RE: [Ltru] Re: Shelf life of data Codes eliminated and not reassigned after RFC 1766 came into effect should be in the registry. Period. Codes prior to 1995 (or 1988 if you go with the reference's date) are really the question. I'd support going back to 1988 with codes, since the reference in RFC 1766 and 3066 is unclear and I well remember the days before the Web (when getting code lists was an arcane art and not a science). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > Sent: dimanche 27 mars 2005 22:58 > To: LTRU Working Group > Subject: [Ltru] Re: Shelf life of data > > Frank Ellermann wrote: > > >> There's nothing magic about 10 years. > > > > For our purposes the last 10 years would allow us to get rid > > of the A-list country codes (after 1988, before RfC 1766): > > > > BU, DD, FX, NT, SU, TP, YD, YU, ZR. > > FX was withdrawn in 1997, TP in 2002, YU in 2003, ZR in 1997. > > "Getting rid of" these codes -- or, for that matter, the other five you > mentioned, which WERE withdrawn before 1995 -- will not significantly > improve the registry, but they may render some valid RFC 1766/3066 codes > invalid. Group members, can we please come to a decision on this? > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 11:36:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11755; Mon, 28 Mar 2005 11:36:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxKp-0004ax-P6; Mon, 28 Mar 2005 11:43:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwpu-0000vY-HT; Mon, 28 Mar 2005 11:11:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwps-0000vB-F6 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 11:11:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02350 for ; Mon, 28 Mar 2005 11:11:25 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwwN-0001G5-8L for ltru@ietf.org; Mon, 28 Mar 2005 11:18:12 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DFwpe-0000la-Bu; Mon, 28 Mar 2005 08:11:14 -0800 Message-Id: <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Mar 2005 18:11:10 +0200 To: "Addison Phillips" , "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Shelf life of data In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 16:57 28/03/2005, Addison Phillips wrote: >Codes eliminated and not reassigned after RFC 1766 came into effect should >be in the registry. Period. Yes. >Codes prior to 1995 (or 1988 if you go with the reference's date) are >really the question. I'd support going back to 1988 with codes, since the >reference in RFC 1766 and 3066 is unclear and I well remember the days >before the Web (when getting code lists was an arcane art and not a science). Yes. Would you have a dated list we could use as a reference? Or would someone have one no one can dispute? We started using alpha-3 by mid-77 and formalized it in oct 1978 (Mike Rude); and alpha-2 in 1981. Earlier entries are probably not necessary, unless for archives, historics and experience/testing. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 11:40:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13558; Mon, 28 Mar 2005 11:40:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxOk-0005Bw-SC; Mon, 28 Mar 2005 11:47:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxHh-00075y-91; Mon, 28 Mar 2005 11:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxHf-00075P-EX for ltru@megatron.ietf.org; Mon, 28 Mar 2005 11:40:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13311 for ; Mon, 28 Mar 2005 11:40:08 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxO6-00055l-7Z for ltru@ietf.org; Mon, 28 Mar 2005 11:46:56 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2SGdksA011811; Mon, 28 Mar 2005 08:39:46 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77HBX8>; Mon, 28 Mar 2005 08:39:46 -0800 Message-ID: From: "McDonald, Ira" To: "'Tex Texin'" , Mark Davis Subject: RE: [Ltru] Re: Question Date: Mon, 28 Mar 2005 08:39:45 -0800 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi Tex, Doesn't the question of criteria for choosing tags for content properly belong in the W3C Internationalization activity? It's a darn good question, but the LTR just provides the nuts and bolts, not the pre-punched sheet metal. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Tex Texin Sent: Friday, March 25, 2005 6:09 PM To: Mark Davis Cc: Frank Ellermann; ltru@ietf.org Subject: Re: [Ltru] Re: Question <...snip...> The problem I see is not in architecting the scheme for tagging, but determining what a language is, in a useful way for software developers, so that they can understand which language tag to use, and not an identification which only linguists recognize or criteria which are not clearly expressed. So yes, forget compatibility if I can have a scheme that works. On the other hand, if we maintain compatibility and make the current system more complex and no more usable, I don't need that either. I would welcome a clear set of rules for choosing a tag for content, and rules for finding content with known tags. tex _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 11:51:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15524; Mon, 28 Mar 2005 11:51:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxZE-0005kF-NC; Mon, 28 Mar 2005 11:58:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxSV-0006QF-Ua; Mon, 28 Mar 2005 11:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxSU-0006Q3-63 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 11:51:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15480 for ; Mon, 28 Mar 2005 11:51:19 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFxZ0-0005jZ-LJ for ltru@ietf.org; Mon, 28 Mar 2005 11:58:07 -0500 Received: from Lugh (83-70-45-3.b-ras1.prp.dublin.eircom.net [83.70.45.3]) by postie2.hosting365.ie (Postfix) with ESMTP id DEB69251E516F for ; Mon, 28 Mar 2005 17:51:18 +0100 (IST) From: "Jon Hanna" To: Subject: RE: [Ltru] Re: Question Date: Mon, 28 Mar 2005 17:51:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcUztOPdtyANlbxOQQCJ5SciQYzEYQAATjFA Message-Id: <20050328165118.DEB69251E516F@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit > Doesn't the question of criteria for choosing tags for content > properly belong in the W3C Internationalization activity? Not all Internet content is web content. Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 12:28:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19094; Mon, 28 Mar 2005 12:28:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFy8x-000760-HQ; Mon, 28 Mar 2005 12:35:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxzF-0005KF-5s; Mon, 28 Mar 2005 12:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFxzE-0005K7-23 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 12:25:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18708 for ; Mon, 28 Mar 2005 12:25:06 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFy5i-0006vy-JP for ltru@ietf.org; Mon, 28 Mar 2005 12:31:55 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 09:24:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Shelf life of data Date: Mon, 28 Mar 2005 09:24:58 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC2A2F3@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Shelf life of data Thread-Index: AcUzsMWFA+IGd9c8Rt+KC7AQQY4DagAChguA From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 28 Mar 2005 17:24:58.0595 (UTC) FILETIME=[10EF5B30:01C533BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable I refer you to Doug's prototype registry, which has reconstructed all of = the necessary codes already. We are merely fighting over the table = scraps here. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: lundi 28 mars 2005 08:11 > To: Addison Phillips; Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Shelf life of data >=20 > At 16:57 28/03/2005, Addison Phillips wrote: > >Codes eliminated and not reassigned after RFC 1766 came into effect > should > >be in the registry. Period. >=20 > Yes. >=20 > >Codes prior to 1995 (or 1988 if you go with the reference's date) are > >really the question. I'd support going back to 1988 with codes, since = the > >reference in RFC 1766 and 3066 is unclear and I well remember the = days > >before the Web (when getting code lists was an arcane art and not a > science). >=20 > Yes. Would you have a dated list we could use as a reference? > Or would someone have one no one can dispute? >=20 > We started using alpha-3 by mid-77 and formalized it in oct 1978 (Mike > Rude); and alpha-2 in 1981. Earlier entries are probably not = necessary, > unless for archives, historics and experience/testing. > jfc >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 12:30:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19707; Mon, 28 Mar 2005 12:30:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyBM-0007Jd-S3; Mon, 28 Mar 2005 12:37:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFy3a-0006YT-QN; Mon, 28 Mar 2005 12:29:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFy3Z-0006TN-63 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 12:29:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19460 for ; Mon, 28 Mar 2005 12:29:38 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyA6-0007C3-UT for ltru@ietf.org; Mon, 28 Mar 2005 12:36:27 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2SHTUvb019154; Mon, 28 Mar 2005 12:29:30 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 28 Mar 2005 12:29:35 -0500 Date: Mon, 28 Mar 2005 12:29:34 -0500 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: XML registries now available Message-ID: <20050328172934.GQ24325@skunk.reutershealth.com> References: <20050327214939.GN24325@skunk.reutershealth.com> <6.1.2.0.2.20050328121911.037a4eb0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050328121911.037a4eb0@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c JFC (Jefsey) Morfin scripsit: > I assume you consider the situation where: > 1. the application gets a langtag > 2. consider what do to with it. > 3. there are three possible solutions? > - it knows the langtag from it being built-in. > - it does not know it but it has a filtering/negociation strategy > built-in or based upon non IANA parameters > - all this fails and its filtering/negociation strategy resort to a > IANA input before concluding? In practice, the second and third strategies are a matter of using a matching algorithm (which need not be standardized and can rely on local knowledge as well) to reduce the unknown langtag to a known one. With an absolutely unknown langtag, nothing useful can be done except to display the full name of the language, which is useful but not very useful. Without translators, spelling checkers, and other such tools, one can do little with such a document. This is quite different from the DNS case, where given the mapping of a computer's name to an IP address, one can indeed interact with that computer in useful ways. If I know how to reach newmachine.somedomain.fi, I can try to discover what resources it provides. If I receive a document langtagged "sms", the most I could do with it is label it "Skolt Sami". > I would say this is similar to anti-spam or to anti-virus strategies. Languages aren't constantly being created: on the contrary, they are constantly going extinct. The list of living languages will probably shrink by 90% over the next century or two. > Obviously codes change les frequently than spamming hosts and viruses, but > the simple fact they change make the load similar (the load is not because > there are a lot of changes, but because there is a check if nothing > changed). In practice this table will probably be updated only when the operating system is. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 12:36:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20404; Mon, 28 Mar 2005 12:36:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyGr-0007az-JX; Mon, 28 Mar 2005 12:43:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFy9M-0008NG-HI; Mon, 28 Mar 2005 12:35:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFy9K-0008N8-MD for ltru@megatron.ietf.org; Mon, 28 Mar 2005 12:35:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20321 for ; Mon, 28 Mar 2005 12:35:35 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyFs-0007Uy-DL for ltru@ietf.org; Mon, 28 Mar 2005 12:42:24 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 09:35:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] 3166-1 state machie (was: Question) Date: Mon, 28 Mar 2005 09:35:28 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC2A30B@irvmbxw01.quest.com> Thread-Topic: [Ltru] 3166-1 state machie (was: Question) Thread-Index: AcUy7EppkAMY+8OrRxKr13Omh1AYLAAzx3/g From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 28 Mar 2005 17:35:29.0294 (UTC) FILETIME=[88DC62E0:01C533BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable The argument below does not follow. Although "no one" has a copy of = 3166:1988, there are many documents that purport to list the codes = assigned therein. Few of these include the (non-matching) ccTLD codes. And these days 3166 posts the current set of assignments on the Web, = which is where most people look when choosing values for their content = or implementations right now this minute. The problem, of course, is = that "right now this minute" occurs at different discrete moments... In the more distant past, though, the situation was roughly analogous to = where ISO 4217 is today. That standard's official list is not publicly = available for free and thus there are many suspect references that = purport to "be" the list (and have errors). 3066bis corrects this for region codes: we are deciding the manner in = which to correct this. We should be as inclusive as reasonable without = causing ourselves extravagant future problems. For example, adding codes = that were never valid in the past and which already have codes for the = same value would be bad. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: dimanche 27 mars 2005 08:43 > To: ltru@ietf.org > Subject: [Ltru] 3166-1 state machie (was: Question) >=20 > Doug Ewell wrote: >=20 > > "Why they are reserved" is not important. Either a code is > > currently assigned, or it was formerly assigned, or it is > > private-use ("user-assigned"). Distinctions between the > > different types of "reserved" are of interest only to the MA. >=20 > I'm not sure, if "transitionally reserved" is essentially the > same as "deprecated", this could be relevant, and if all these > other "reservations" hide what we're interested in here, i.e. > "deprecated" vs. "unassigned", it could be also relevant. >=20 > And for Mark's "Joe Blow" or my "Jane Blog" anything on the > 3166-1 web pages could be (ab)used. Especially before 3066bis. >=20 > If we don't have a copy of ISO 3166:1988, then Joe and Jane > also have no copy, that's why they (ab)use ccTLDs or reserved > codes. Until the future 3066bis registry helps to catch such > errors. > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 13:05:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24404; Mon, 28 Mar 2005 13:05:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyiY-0000bU-NL; Mon, 28 Mar 2005 13:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyZe-0007yY-FU; Mon, 28 Mar 2005 13:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyZd-0007yI-0z for ltru@megatron.ietf.org; Mon, 28 Mar 2005 13:02:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24137 for ; Mon, 28 Mar 2005 13:02:45 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyg7-0000U4-9A for ltru@ietf.org; Mon, 28 Mar 2005 13:09:34 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2SI2Z75006601 for ; Mon, 28 Mar 2005 13:02:35 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2SI2ZW5242904 for ; Mon, 28 Mar 2005 13:02:35 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2SI2Zpv025929 for ; Mon, 28 Mar 2005 13:02:35 -0500 Received: from markdavis (sig-9-48-114-88.mts.ibm.com [9.48.114.88]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2SI2Vci025656; Mon, 28 Mar 2005 13:02:34 -0500 Message-ID: <157d01c533c0$50e6af40$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "LTRU Working Group" References: Subject: Re: [Ltru] Re: Shelf life of data Date: Mon, 28 Mar 2005 08:18:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id j2SI2Z75006601 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable And I agree as well, of course. The only further question I'd have would require an actual copy of ISO 3166:1988 -- to make sure the exact set of codes that a reasonable person would extract from it. (I don't necessarily trust the later analysis provided on the web). The wording is very vague (repeating again): In the first subtag: - All 2-letter codes are interpreted as ISO 3166 alpha-2 country codes denoting the area in which the language is used.In the references, he sees: ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15. So it depends on what the user would read as "3166 alpha-2 country codes"= , since 1766 does not distinguish between types of codes. If ISO 3166:1988 says "disallowed" or "unassigned", that is pretty clear. But I don't have the exact spec here; anyone have an old copy? =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: "LTRU Working Group" Sent: Monday, March 28, 2005 07:51 Subject: RE: [Ltru] Re: Shelf life of data I'd support including everything in ISO 3166:1988 to ensure not making invalid anything that was valid in RFC 1766. Peter > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Sent: Monday, March 28, 2005 6:57 AM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Shelf life of data > > Codes eliminated and not reassigned after RFC 1766 came into effect should > be in the registry. Period. > > Codes prior to 1995 (or 1988 if you go with the reference's date) are > really the question. I'd support going back to 1988 with codes, since the > reference in RFC 1766 and 3066 is unclear and I well remember the days > before the Web (when getting code lists was an arcane art and not a > science). > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Doug Ewell > > Sent: dimanche 27 mars 2005 22:58 > > To: LTRU Working Group > > Subject: [Ltru] Re: Shelf life of data > > > > Frank Ellermann wrote: > > > > >> There's nothing magic about 10 years. > > > > > > For our purposes the last 10 years would allow us to get rid > > > of the A-list country codes (after 1988, before RfC 1766): > > > > > > BU, DD, FX, NT, SU, TP, YD, YU, ZR. > > > > FX was withdrawn in 1997, TP in 2002, YU in 2003, ZR in 1997. > > > > "Getting rid of" these codes -- or, for that matter, the other five you > > mentioned, which WERE withdrawn before 1995 -- will not significantly > > improve the registry, but they may render some valid RFC 1766/3066 codes > > invalid. Group members, can we please come to a decision on this? > > > > -Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 13:25:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26421; Mon, 28 Mar 2005 13:25:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFz1e-0001JP-Jq; Mon, 28 Mar 2005 13:31:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyuk-0004PH-O4; Mon, 28 Mar 2005 13:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyuj-0004PC-C0 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 13:24:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26412 for ; Mon, 28 Mar 2005 13:24:33 -0500 (EST) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFz1H-0001Ik-Ai for ltru@ietf.org; Mon, 28 Mar 2005 13:31:23 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2SIO8Fp009004 for ; Mon, 28 Mar 2005 13:24:08 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2SIO8W5250934 for ; Mon, 28 Mar 2005 13:24:08 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2SIO7ac008080 for ; Mon, 28 Mar 2005 13:24:07 -0500 Received: from markdavis (sig-9-48-114-88.mts.ibm.com [9.48.114.88]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2SIO6eS008024; Mon, 28 Mar 2005 13:24:07 -0500 Message-ID: <15be01c533c3$5342c050$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Frank Ellermann" , References: <634978A7DF025A40BFEF33EB191E13BC0AC2A30B@irvmbxw01.quest.com> Subject: Re: [Ltru] 3166-1 state machie (was: Question) Date: Mon, 28 Mar 2005 10:24:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id j2SIO8Fp009004 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable You appear to be jumping to some conclusion(s). I'm not at all saying tha= t we want to add the ccTLD codes. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Frank Ellermann" ; Sent: Monday, March 28, 2005 09:35 Subject: RE: [Ltru] 3166-1 state machie (was: Question) The argument below does not follow. Although "no one" has a copy of 3166:1988, there are many documents that purport to list the codes assign= ed therein. Few of these include the (non-matching) ccTLD codes. And these days 3166 posts the current set of assignments on the Web, whic= h is where most people look when choosing values for their content or implementations right now this minute. The problem, of course, is that "right now this minute" occurs at different discrete moments... In the more distant past, though, the situation was roughly analogous to where ISO 4217 is today. That standard's official list is not publicly available for free and thus there are many suspect references that purpor= t to "be" the list (and have errors). 3066bis corrects this for region codes: we are deciding the manner in whi= ch to correct this. We should be as inclusive as reasonable without causing ourselves extravagant future problems. For example, adding codes that wer= e never valid in the past and which already have codes for the same value would be bad. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: dimanche 27 mars 2005 08:43 > To: ltru@ietf.org > Subject: [Ltru] 3166-1 state machie (was: Question) > > Doug Ewell wrote: > > > "Why they are reserved" is not important. Either a code is > > currently assigned, or it was formerly assigned, or it is > > private-use ("user-assigned"). Distinctions between the > > different types of "reserved" are of interest only to the MA. > > I'm not sure, if "transitionally reserved" is essentially the > same as "deprecated", this could be relevant, and if all these > other "reservations" hide what we're interested in here, i.e. > "deprecated" vs. "unassigned", it could be also relevant. > > And for Mark's "Joe Blow" or my "Jane Blog" anything on the > 3166-1 web pages could be (ab)used. Especially before 3066bis. > > If we don't have a copy of ISO 3166:1988, then Joe and Jane > also have no copy, that's why they (ab)use ccTLDs or reserved > codes. Until the future 3066bis registry helps to catch such > errors. > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 14:05:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00176; Mon, 28 Mar 2005 14:05:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFzec-0002nI-Jk; Mon, 28 Mar 2005 14:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFzWl-0004TH-LO; Mon, 28 Mar 2005 14:03:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFzWk-0004T9-3A for ltru@megatron.ietf.org; Mon, 28 Mar 2005 14:03:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00017 for ; Mon, 28 Mar 2005 14:03:52 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFzdI-0002l2-Ew for ltru@ietf.org; Mon, 28 Mar 2005 14:10:40 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 11:03:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] 3166-1 state machie (was: Question) Date: Mon, 28 Mar 2005 11:03:39 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC2A3C5@irvmbxw01.quest.com> Thread-Topic: [Ltru] 3166-1 state machie (was: Question) Thread-Index: AcUzw1k9SLLOk6E0SGmdxWoddfdtagABRI4g From: "Addison Phillips" To: "Mark Davis" , "Frank Ellermann" , X-OriginalArrivalTime: 28 Mar 2005 19:03:41.0070 (UTC) FILETIME=[DB0152E0:01C533C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1909252769==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --===============1909252769== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIHVubGVzcyB5b3UgbWVhbiAiRnJhbmsiIGJ5ICJ5b3UiLiBJIHdhcyBhZGRyZXNzaW5nIEZy YW5rJ3MgY29tbWVudHMgdGhhdCBzZWVtZWQgKHBvc3NpYmx5IG9ubHkgdG8gbWUpIHRvIHN1Z2dl c3QgdGhhdCBjY1RMRCBjb2RlcyB3b3VsZCBiZSBjYW5kaWRhdGVzIGZvciB0aGUgcmVnaXN0cnkg YmVjYXVzZSB0aGV5IG1pZ2h0IGhhdmUgYmVlbiBlcnJvbmVvdXNseSB1c2VkIGluIGxlZ2FjeSBk YXRhLiBWYWxpZCAzMTY2IGNvZGVzIGZyb20gc29tZSBub24tYXJiaXRyYXJ5IGRhdGU6IHllcy4g T3RoZXIgdHdvLWxldHRlciBjb2RlcyBmb3IgcmVnaW9uczogbm8uDQoNCkFkZGlzb24NCg0KQWRk aXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJl DQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0 dXJlLiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBEYXZpcyBb bWFpbHRvOm1hcmsuZGF2aXNAanRjc3YuY29tXQ0KPiBTZW50OiBsdW5kaSAyOCBtYXJzIDIwMDUg MTA6MjQNCj4gVG86IEFkZGlzb24gUGhpbGxpcHM7IEZyYW5rIEVsbGVybWFubjsgbHRydUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIDMxNjYtMSBzdGF0ZSBtYWNoaWUgKHdhczogUXVl c3Rpb24pDQo+IA0KPiBZb3UgYXBwZWFyIHRvIGJlIGp1bXBpbmcgdG8gc29tZSBjb25jbHVzaW9u KHMpLiBJJ20gbm90IGF0IGFsbCBzYXlpbmcgdGhhdA0KPiB3ZSB3YW50IHRvIGFkZCB0aGUgY2NU TEQgY29kZXMuDQo+IA0KPiDigI5NYXJrDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQo+IEZyb206ICJBZGRpc29uIFBoaWxsaXBzIiA8YWRkaXNvbi5waGlsbGlwc0BxdWVzdC5j b20+DQo+IFRvOiAiRnJhbmsgRWxsZXJtYW5uIiA8bm9ib2R5QHh5enp5LmNsYXJhbmV0LmRlPjsg PGx0cnVAaWV0Zi5vcmc+DQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMDUgMDk6MzUNCj4g U3ViamVjdDogUkU6IFtMdHJ1XSAzMTY2LTEgc3RhdGUgbWFjaGllICh3YXM6IFF1ZXN0aW9uKQ0K PiANCj4gDQo+IFRoZSBhcmd1bWVudCBiZWxvdyBkb2VzIG5vdCBmb2xsb3cuIEFsdGhvdWdoICJu byBvbmUiIGhhcyBhIGNvcHkgb2YNCj4gMzE2NjoxOTg4LCB0aGVyZSBhcmUgbWFueSBkb2N1bWVu dHMgdGhhdCBwdXJwb3J0IHRvIGxpc3QgdGhlIGNvZGVzDQo+IGFzc2lnbmVkDQo+IHRoZXJlaW4u IEZldyBvZiB0aGVzZSBpbmNsdWRlIHRoZSAobm9uLW1hdGNoaW5nKSBjY1RMRCBjb2Rlcy4NCj4g DQo+IEFuZCB0aGVzZSBkYXlzIDMxNjYgcG9zdHMgdGhlIGN1cnJlbnQgc2V0IG9mIGFzc2lnbm1l bnRzIG9uIHRoZSBXZWIsIHdoaWNoDQo+IGlzIHdoZXJlIG1vc3QgcGVvcGxlIGxvb2sgd2hlbiBj aG9vc2luZyB2YWx1ZXMgZm9yIHRoZWlyIGNvbnRlbnQgb3INCj4gaW1wbGVtZW50YXRpb25zIHJp Z2h0IG5vdyB0aGlzIG1pbnV0ZS4gVGhlIHByb2JsZW0sIG9mIGNvdXJzZSwgaXMgdGhhdA0KPiAi cmlnaHQgbm93IHRoaXMgbWludXRlIiBvY2N1cnMgYXQgZGlmZmVyZW50IGRpc2NyZXRlIG1vbWVu dHMuLi4NCj4gDQo+IEluIHRoZSBtb3JlIGRpc3RhbnQgcGFzdCwgdGhvdWdoLCB0aGUgc2l0dWF0 aW9uIHdhcyByb3VnaGx5IGFuYWxvZ291cyB0bw0KPiB3aGVyZSBJU08gNDIxNyBpcyB0b2RheS4g VGhhdCBzdGFuZGFyZCdzIG9mZmljaWFsIGxpc3QgaXMgbm90IHB1YmxpY2x5DQo+IGF2YWlsYWJs ZSBmb3IgZnJlZSBhbmQgdGh1cyB0aGVyZSBhcmUgbWFueSBzdXNwZWN0IHJlZmVyZW5jZXMgdGhh dCBwdXJwb3J0DQo+IHRvICJiZSIgdGhlIGxpc3QgKGFuZCBoYXZlIGVycm9ycykuDQo+IA0KPiAz MDY2YmlzIGNvcnJlY3RzIHRoaXMgZm9yIHJlZ2lvbiBjb2Rlczogd2UgYXJlIGRlY2lkaW5nIHRo ZSBtYW5uZXIgaW4NCj4gd2hpY2gNCj4gdG8gY29ycmVjdCB0aGlzLiBXZSBzaG91bGQgYmUgYXMg aW5jbHVzaXZlIGFzIHJlYXNvbmFibGUgd2l0aG91dCBjYXVzaW5nDQo+IG91cnNlbHZlcyBleHRy YXZhZ2FudCBmdXR1cmUgcHJvYmxlbXMuIEZvciBleGFtcGxlLCBhZGRpbmcgY29kZXMgdGhhdCB3 ZXJlDQo+IG5ldmVyIHZhbGlkIGluIHRoZSBwYXN0IGFuZCB3aGljaCBhbHJlYWR5IGhhdmUgY29k ZXMgZm9yIHRoZSBzYW1lIHZhbHVlDQo+IHdvdWxkIGJlIGJhZC4NCj4gDQo+IEFkZGlzb24NCj4g DQo+IEFkZGlzb24gUC4gUGhpbGxpcHMNCj4gR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0 IFNvZnR3YXJlDQo+IENoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5n IEdyb3VwDQo+IA0KPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiBJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3Vu Y2VzQGxpc3RzLmlldGYub3JnXQ0KPiBPbg0KPiA+IEJlaGFsZiBPZiBGcmFuayBFbGxlcm1hbm4N Cj4gPiBTZW50OiBkaW1hbmNoZSAyNyBtYXJzIDIwMDUgMDg6NDMNCj4gPiBUbzogbHRydUBpZXRm Lm9yZw0KPiA+IFN1YmplY3Q6IFtMdHJ1XSAzMTY2LTEgc3RhdGUgbWFjaGllICh3YXM6IFF1ZXN0 aW9uKQ0KPiA+DQo+ID4gRG91ZyBFd2VsbCB3cm90ZToNCj4gPg0KPiA+ID4gIldoeSB0aGV5IGFy ZSByZXNlcnZlZCIgaXMgbm90IGltcG9ydGFudC4gIEVpdGhlciBhIGNvZGUgaXMNCj4gPiA+IGN1 cnJlbnRseSBhc3NpZ25lZCwgb3IgaXQgd2FzIGZvcm1lcmx5IGFzc2lnbmVkLCBvciBpdCBpcw0K PiA+ID4gcHJpdmF0ZS11c2UgKCJ1c2VyLWFzc2lnbmVkIikuICBEaXN0aW5jdGlvbnMgYmV0d2Vl biB0aGUNCj4gPiA+IGRpZmZlcmVudCB0eXBlcyBvZiAicmVzZXJ2ZWQiIGFyZSBvZiBpbnRlcmVz dCBvbmx5IHRvIHRoZSBNQS4NCj4gPg0KPiA+IEknbSBub3Qgc3VyZSwgaWYgInRyYW5zaXRpb25h bGx5IHJlc2VydmVkIiBpcyBlc3NlbnRpYWxseSB0aGUNCj4gPiBzYW1lIGFzICJkZXByZWNhdGVk IiwgdGhpcyBjb3VsZCBiZSByZWxldmFudCwgYW5kIGlmIGFsbCB0aGVzZQ0KPiA+IG90aGVyICJy ZXNlcnZhdGlvbnMiIGhpZGUgd2hhdCB3ZSdyZSBpbnRlcmVzdGVkIGluIGhlcmUsIGkuZS4NCj4g PiAiZGVwcmVjYXRlZCIgdnMuICJ1bmFzc2lnbmVkIiwgaXQgY291bGQgYmUgYWxzbyByZWxldmFu dC4NCj4gPg0KPiA+IEFuZCBmb3IgTWFyaydzICJKb2UgQmxvdyIgb3IgbXkgIkphbmUgQmxvZyIg YW55dGhpbmcgb24gdGhlDQo+ID4gMzE2Ni0xIHdlYiBwYWdlcyBjb3VsZCBiZSAoYWIpdXNlZC4g IEVzcGVjaWFsbHkgYmVmb3JlIDMwNjZiaXMuDQo+ID4NCj4gPiBJZiB3ZSBkb24ndCBoYXZlIGEg Y29weSBvZiBJU08gMzE2NjoxOTg4LCB0aGVuIEpvZSBhbmQgSmFuZQ0KPiA+IGFsc28gaGF2ZSBu byBjb3B5LCB0aGF0J3Mgd2h5IHRoZXkgKGFiKXVzZSBjY1RMRHMgb3IgcmVzZXJ2ZWQNCj4gPiBj b2Rlcy4gIFVudGlsIHRoZSBmdXR1cmUgMzA2NmJpcyByZWdpc3RyeSBoZWxwcyB0byBjYXRjaCBz dWNoDQo+ID4gZXJyb3JzLg0KPiA+ICAgICAgICAgQnllLCBGcmFuaw0KPiA+DQo+ID4NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g THRydSBtYWlsaW5nIGxpc3QNCj4gPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0 DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRydQ0KDQoNCg== --===============1909252769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1909252769==-- From ltru-bounces@ietf.org Mon Mar 28 14:18:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01195; Mon, 28 Mar 2005 14:18:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFzrb-0003Fz-Uw; Mon, 28 Mar 2005 14:25:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFzjH-00073E-A4; Mon, 28 Mar 2005 14:16:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFzjF-00072s-Of for ltru@megatron.ietf.org; Mon, 28 Mar 2005 14:16:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01061 for ; Mon, 28 Mar 2005 14:16:45 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFzpm-00038z-1P for ltru@ietf.org; Mon, 28 Mar 2005 14:23:34 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2SJGYrI020123 for ; Mon, 28 Mar 2005 14:16:34 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2SJGYW5232932 for ; Mon, 28 Mar 2005 14:16:34 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2SJGXNO006511 for ; Mon, 28 Mar 2005 14:16:33 -0500 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.209.142]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2SJGW3a006459; Mon, 28 Mar 2005 14:16:32 -0500 Message-ID: <15fe01c533ca$a6ac3080$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Frank Ellermann" , References: <634978A7DF025A40BFEF33EB191E13BC0AC2A3C5@irvmbxw01.quest.com> Subject: Re: [Ltru] 3166-1 state machie (was: Question) Date: Mon, 28 Mar 2005 11:16:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j2SJGYrI020123 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Sorry; got confused. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Mark Davis" ; "Frank Ellermann" ; Sent: Monday, March 28, 2005 11:03 Subject: RE: [Ltru] 3166-1 state machie (was: Question) > No, unless you mean "Frank" by "you". I was addressing Frank's comments that seemed (possibly only to me) to suggest that ccTLD codes would be candidates for the registry because they might have been erroneously used= in legacy data. Valid 3166 codes from some non-arbitrary date: yes. Other two-letter codes for regions: no. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > -----Original Message----- > > From: Mark Davis [mailto:mark.davis@jtcsv.com] > > Sent: lundi 28 mars 2005 10:24 > > To: Addison Phillips; Frank Ellermann; ltru@ietf.org > > Subject: Re: [Ltru] 3166-1 state machie (was: Question) > > > > You appear to be jumping to some conclusion(s). I'm not at all saying that > > we want to add the ccTLD codes. > > > > =E2=80=8EMark > > > > ----- Original Message ----- > > From: "Addison Phillips" > > To: "Frank Ellermann" ; > > Sent: Monday, March 28, 2005 09:35 > > Subject: RE: [Ltru] 3166-1 state machie (was: Question) > > > > > > The argument below does not follow. Although "no one" has a copy of > > 3166:1988, there are many documents that purport to list the codes > > assigned > > therein. Few of these include the (non-matching) ccTLD codes. > > > > And these days 3166 posts the current set of assignments on the Web, which > > is where most people look when choosing values for their content or > > implementations right now this minute. The problem, of course, is tha= t > > "right now this minute" occurs at different discrete moments... > > > > In the more distant past, though, the situation was roughly analogous= to > > where ISO 4217 is today. That standard's official list is not publicl= y > > available for free and thus there are many suspect references that purport > > to "be" the list (and have errors). > > > > 3066bis corrects this for region codes: we are deciding the manner in > > which > > to correct this. We should be as inclusive as reasonable without caus= ing > > ourselves extravagant future problems. For example, adding codes that were > > never valid in the past and which already have codes for the same val= ue > > would be bad. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.o= rg] > > On > > > Behalf Of Frank Ellermann > > > Sent: dimanche 27 mars 2005 08:43 > > > To: ltru@ietf.org > > > Subject: [Ltru] 3166-1 state machie (was: Question) > > > > > > Doug Ewell wrote: > > > > > > > "Why they are reserved" is not important. Either a code is > > > > currently assigned, or it was formerly assigned, or it is > > > > private-use ("user-assigned"). Distinctions between the > > > > different types of "reserved" are of interest only to the MA. > > > > > > I'm not sure, if "transitionally reserved" is essentially the > > > same as "deprecated", this could be relevant, and if all these > > > other "reservations" hide what we're interested in here, i.e. > > > "deprecated" vs. "unassigned", it could be also relevant. > > > > > > And for Mark's "Joe Blow" or my "Jane Blog" anything on the > > > 3166-1 web pages could be (ab)used. Especially before 3066bis. > > > > > > If we don't have a copy of ISO 3166:1988, then Joe and Jane > > > also have no copy, that's why they (ab)use ccTLDs or reserved > > > codes. Until the future 3066bis registry helps to catch such > > > errors. > > > Bye, Frank > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 15:37:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09334; Mon, 28 Mar 2005 15:37:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG15X-00066d-HX; Mon, 28 Mar 2005 15:43:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG0xI-0006Ue-Gf; Mon, 28 Mar 2005 15:35:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG0xH-0006UY-8n for ltru@megatron.ietf.org; Mon, 28 Mar 2005 15:35:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09135 for ; Mon, 28 Mar 2005 15:35:20 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG13p-000645-3k for ltru@ietf.org; Mon, 28 Mar 2005 15:42:10 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 12:35:10 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 28 Mar 2005 12:35:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Shelf life of data Date: Mon, 28 Mar 2005 12:35:09 -0800 Message-ID: Thread-Topic: [Ltru] Re: Shelf life of data thread-index: AcUzwFWhVm3ScSccQT6eTZmyRmX1mQAE3fdg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 28 Mar 2005 20:35:11.0027 (UTC) FILETIME=[A3464830:01C533D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: Mark Davis [mailto:mark.davis@jtcsv.com] > The only further question I'd have would require an actual copy of ISO > 3166:1988 -- to make sure the exact set of codes that a reasonable person > would extract from it. (I don't necessarily trust the later analysis > provided on the web). I've purchased a copy of ISO 3166-3:1999. The following are items that were valid in 1988 but were discontinued between 1988 and 1999: Country Alpha-2 Alpha-3 Numeric Valid from Valid to ------------------------------------------------------------------------ ----- Burma BU BUR 104 1974 1989 German Democratic Republic DD DDR 278 1974 1990 Yemen, Democratic YD YMD 720 1974 1990 Byelorussian SSR BY BYS 112 1974 1992 USSR SU SUN 810 1974 1992 Czechoslovakia CS CSK 200 1974 1993 Neutral Zone NT NTZ 536 1974 1993 Zaire ZR ZAR 180 1974 1997 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 15:44:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10199; Mon, 28 Mar 2005 15:44:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1Ce-0006N1-PB; Mon, 28 Mar 2005 15:51:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG15k-0008Db-7q; Mon, 28 Mar 2005 15:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG15h-0008DW-Gc for ltru@megatron.ietf.org; Mon, 28 Mar 2005 15:44:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10127 for ; Mon, 28 Mar 2005 15:44:01 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1CD-0006M7-LU for ltru@ietf.org; Mon, 28 Mar 2005 15:50:51 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2SKhm5h024166; Mon, 28 Mar 2005 12:43:48 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77H1SQ>; Mon, 28 Mar 2005 12:43:48 -0800 Message-ID: From: "McDonald, Ira" To: "'Jon Hanna'" , ltru@ietf.org Subject: RE: [Ltru] Re: Question Date: Mon, 28 Mar 2005 12:43:48 -0800 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: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Jon, Agreed - but the IETF doesn't have a working group with the expertise that the W3C Internationalization and GEO activities do. I was merely pointing out that the tough questions of using language tags in W3C specs based on XML belongs to the W3C. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Jon Hanna Sent: Monday, March 28, 2005 11:51 AM To: ltru@ietf.org Subject: RE: [Ltru] Re: Question > Doesn't the question of criteria for choosing tags for content > properly belong in the W3C Internationalization activity? Not all Internet content is web content. Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 16:09:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12040; Mon, 28 Mar 2005 16:09:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1aX-0007LH-QE; Mon, 28 Mar 2005 16:15:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1TL-0005Jq-Om; Mon, 28 Mar 2005 16:08:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1TK-0005Jh-Le for ltru@megatron.ietf.org; Mon, 28 Mar 2005 16:08:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11992 for ; Mon, 28 Mar 2005 16:08:28 -0500 (EST) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1Zs-0007Ha-Sn for ltru@ietf.org; Mon, 28 Mar 2005 16:15:18 -0500 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 28 Mar 2005 21:08:09 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IE20034MQYNS0@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 28 Mar 2005 19:20:47 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 28 Mar 2005 18:20:46 +0000 Date: Mon, 28 Mar 2005 19:20:46 +0100 From: Misha Wolf Subject: RE: [Ltru] Frequency of table update (was: Re: XML registries now available) To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF780360F5B2@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Frequency of table update (was: Re: XML registries now available) Thread-Index: AcUzvA5S5I1xVzA5S5OyxGHTeOctIwABoNfw content-class: urn:content-classes:message X-OriginalArrivalTime: 28 Mar 2005 18:20:46.0948 (UTC) FILETIME=[DCB57A40:01C533C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable John Cowan wrote: > In practice this table will probably be updated only when=20 > the operating system is. In the case of browsers, with each release, right? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 16:14:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12364; Mon, 28 Mar 2005 16:14:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1fX-0007Sb-9f; Mon, 28 Mar 2005 16:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1YO-0006Jm-U1; Mon, 28 Mar 2005 16:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1YN-0006Jh-A3 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 16:13:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12347 for ; Mon, 28 Mar 2005 16:13:40 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1ew-0007S4-TQ for ltru@ietf.org; Mon, 28 Mar 2005 16:20:31 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 13:13:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message Subject: RE: [Ltru] Re: Question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2005 13:13:28 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC2A4D1@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Question Thread-Index: AcUz1u1aFZjiozyZQt+LXvnZKTbj6wAAdaxQ From: "Addison Phillips" To: X-OriginalArrivalTime: 28 Mar 2005 21:13:28.0948 (UTC) FILETIME=[FCF13340:01C533DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Putting on my W3C chair chat.... The W3C Internationalization Core Working Group has the responsibility = (in its charter) for developing guidelines for W3C specifications = regarding the adoption of language tag technology (as a result of this = working group's activities)--and not just for XML based technologies, of = course, but other W3C technologies that are affected, such as Semantic = Web, Web services, and so forth. This should not be confused with = telling people which tags to use in their content, of course. It is a = guideline on how to reference tags and implement such things as = matching.? The I18N GEO working group, chaired by my esteemed colleague Richard = Ishida, develops guidelines for content authors on the selection of = language tags, but these are not normative documents. It should be noted that the I18N Core WG is also chartered to work on = the separate issue of locale identification (mostly for Web services) in = tandem with recommendations on language tags, since at least some = members of the working group feel that these are likely to be related. So I guess the upshot would be: the W3C working group is tracking this = work, but isn't responsible for any aspect of it, since it is interested = in the outcome and any potential impact that arises from changes to = language tags to W3C technologies. Guidelines may be developed for = content authors at a later date, although these are likely to be based = on or strongly influenced by the content of the RFC(s). Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: lundi 28 mars 2005 12:44 > To: 'Jon Hanna'; ltru@ietf.org > Subject: RE: [Ltru] Re: Question >=20 > Hi Jon, >=20 > Agreed - but the IETF doesn't have a working group with the > expertise that the W3C Internationalization and GEO activities > do. I was merely pointing out that the tough questions of using > language tags in W3C specs based on XML belongs to the W3C. >=20 > Cheers, > - Ira >=20 > 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 >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Jon Hanna > Sent: Monday, March 28, 2005 11:51 AM > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Question >=20 >=20 > > Doesn't the question of criteria for choosing tags for content > > properly belong in the W3C Internationalization activity? >=20 > Not all Internet content is web content. >=20 > Regards, > Jon Hanna > Work: > Play: > Chat: >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 16:18:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12616; Mon, 28 Mar 2005 16:18:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1k0-0007be-6s; Mon, 28 Mar 2005 16:25:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1d1-0006xr-DQ; Mon, 28 Mar 2005 16:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1d0-0006xm-9S for ltru@megatron.ietf.org; Mon, 28 Mar 2005 16:18:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12599 for ; Mon, 28 Mar 2005 16:18:28 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1jY-0007bI-CC for ltru@ietf.org; Mon, 28 Mar 2005 16:25:18 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2SLIIAW025719; Mon, 28 Mar 2005 13:18:18 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77H17H>; Mon, 28 Mar 2005 13:18:18 -0800 Message-ID: From: "McDonald, Ira" To: "'Misha Wolf'" , ltru@ietf.org Subject: RE: [Ltru] Frequency of table update (was: Re: XML registries now available) Date: Mon, 28 Mar 2005 13:18:18 -0800 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: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi, And in the case of other applications (databases that access XML records, etc.), with each release right? But not by some user action or auto-fetch when the application is running in the field. 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Misha Wolf Sent: Monday, March 28, 2005 1:21 PM To: ltru@ietf.org Subject: RE: [Ltru] Frequency of table update (was: Re: XML registries now available) John Cowan wrote: > In practice this table will probably be updated only when > the operating system is. In the case of browsers, with each release, right? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 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. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 16:27:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13214; Mon, 28 Mar 2005 16:27:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1sj-0007sP-VI; Mon, 28 Mar 2005 16:34:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1hd-0007dM-6z; Mon, 28 Mar 2005 16:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1hc-0007dH-6v for ltru@megatron.ietf.org; Mon, 28 Mar 2005 16:23:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12915 for ; Mon, 28 Mar 2005 16:23:13 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1oC-0007hZ-1X for ltru@ietf.org; Mon, 28 Mar 2005 16:30:04 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 13:23:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Frequency of table update (was: Re: XML registries nowavailable) Date: Mon, 28 Mar 2005 13:23:05 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AC2A4ED@irvmbxw01.quest.com> Thread-Topic: [Ltru] Frequency of table update (was: Re: XML registries nowavailable) Thread-Index: AcUz29BYoCV9eL7rSvy+7H8D5U80UgAABfuQ From: "Addison Phillips" To: "McDonald, Ira" , "Misha Wolf" , X-OriginalArrivalTime: 28 Mar 2005 21:23:06.0890 (UTC) FILETIME=[556C26A0:01C533DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Yes, exactly so. The only the side point I'd make is: 3066bis is written in a way that = makes a new tag's contents identifiable even if a particular subtag is = not. Even if you don't know what the script 'xyzz' is, you can identify = that it is a script subtag and do something less stupid with it.=20 There are many language tag matching or lookup applications that don't = rely on knowing the "meaning" of a subtag, only how to compare values. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: lundi 28 mars 2005 13:18 > To: 'Misha Wolf'; ltru@ietf.org > Subject: RE: [Ltru] Frequency of table update (was: Re: XML registries > nowavailable) >=20 > Hi, >=20 > And in the case of other applications (databases that access > XML records, etc.), with each release right? >=20 > But not by some user action or auto-fetch when the application > is running in the field. >=20 > Cheers, > - Ira >=20 > 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 >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Misha Wolf > Sent: Monday, March 28, 2005 1:21 PM > To: ltru@ietf.org > Subject: RE: [Ltru] Frequency of table update (was: Re: XML registries > now available) >=20 >=20 > John Cowan wrote: >=20 > > In practice this table will probably be updated only when > > the operating system is. >=20 > In the case of browsers, with each release, right? >=20 > Misha >=20 >=20 >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo >=20 > 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. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 16:29:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13268; Mon, 28 Mar 2005 16:29:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1to-0007tO-2f; Mon, 28 Mar 2005 16:35:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1jk-0007g0-DR; Mon, 28 Mar 2005 16:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG1ji-0007fq-Mw for ltru@megatron.ietf.org; Mon, 28 Mar 2005 16:25:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13023 for ; Mon, 28 Mar 2005 16:25:24 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG1qD-0007kU-Oa for ltru@ietf.org; Mon, 28 Mar 2005 16:32:14 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j2SLPAoV026041; Mon, 28 Mar 2005 13:25:10 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77H19M>; Mon, 28 Mar 2005 13:25:11 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , ltru@ietf.org Subject: RE: [Ltru] Re: Question Date: Mon, 28 Mar 2005 13:25:10 -0800 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: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi, Thanks for that clarification Addison. But the GEO guidelines (like the WAI guidelines) are essentially equivalent (in a standards-process sense) to IETF Best Practices. The GEO guidelines are the only work on "how to tag content appropriately" that seem likely to have an impact. Cheers, - Ira (former collaborator of Richard Ishida at Xerox for years) 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Addison Phillips Sent: Monday, March 28, 2005 4:13 PM To: ltru@ietf.org Subject: RE: [Ltru] Re: Question Putting on my W3C chair chat.... The W3C Internationalization Core Working Group has the responsibility (in its charter) for developing guidelines for W3C specifications regarding the adoption of language tag technology (as a result of this working group's activities)--and not just for XML based technologies, of course, but other W3C technologies that are affected, such as Semantic Web, Web services, and so forth. This should not be confused with telling people which tags to use in their content, of course. It is a guideline on how to reference tags and implement such things as matching.? The I18N GEO working group, chaired by my esteemed colleague Richard Ishida, develops guidelines for content authors on the selection of language tags, but these are not normative documents. It should be noted that the I18N Core WG is also chartered to work on the separate issue of locale identification (mostly for Web services) in tandem with recommendations on language tags, since at least some members of the working group feel that these are likely to be related. So I guess the upshot would be: the W3C working group is tracking this work, but isn't responsible for any aspect of it, since it is interested in the outcome and any potential impact that arises from changes to language tags to W3C technologies. Guidelines may be developed for content authors at a later date, although these are likely to be based on or strongly influenced by the content of the RFC(s). Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of McDonald, Ira > Sent: lundi 28 mars 2005 12:44 > To: 'Jon Hanna'; ltru@ietf.org > Subject: RE: [Ltru] Re: Question > > Hi Jon, > > Agreed - but the IETF doesn't have a working group with the > expertise that the W3C Internationalization and GEO activities > do. I was merely pointing out that the tough questions of using > language tags in W3C specs based on XML belongs to the W3C. > > 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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Jon Hanna > Sent: Monday, March 28, 2005 11:51 AM > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Question > > > > Doesn't the question of criteria for choosing tags for content > > properly belong in the W3C Internationalization activity? > > Not all Internet content is web content. > > Regards, > Jon Hanna > Work: > Play: > Chat: > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 21:03:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06973; Mon, 28 Mar 2005 21:03:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG6B1-0008Hz-5n; Mon, 28 Mar 2005 21:09:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG642-0005AB-R6; Mon, 28 Mar 2005 21:02:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG641-0005A6-R7 for ltru@megatron.ietf.org; Mon, 28 Mar 2005 21:02:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06943 for ; Mon, 28 Mar 2005 21:02:39 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG6Ac-0008HS-UT for ltru@ietf.org; Mon, 28 Mar 2005 21:09:32 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DG63x-0008Cx-2x; Mon, 28 Mar 2005 18:02:37 -0800 Message-Id: <6.1.2.0.2.20050328230617.049c0430@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Mar 2005 23:58:44 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: XML registries now available In-Reply-To: <20050328172934.GQ24325@skunk.reutershealth.com> References: <20050327214939.GN24325@skunk.reutershealth.com> <6.1.2.0.2.20050328121911.037a4eb0@mail.jefsey.com> <20050328172934.GQ24325@skunk.reutershealth.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 At 19:29 28/03/2005, John Cowan wrote: >JFC (Jefsey) Morfin scripsit: > > > I assume you consider the situation where: > > 1. the application gets a langtag > > 2. consider what do to with it. > > 3. there are three possible solutions? > > - it knows the langtag from it being built-in. > > - it does not know it but it has a filtering/negociation strategy > > built-in or based upon non IANA parameters > > - all this fails and its filtering/negociation strategy resort to a > > IANA input before concluding? > >In practice, the second and third strategies are a matter of using a >matching algorithm (which need not be standardized and can rely on local >knowledge as well) to reduce the unknown langtag to a known one. With an >absolutely unknown langtag, nothing useful can be done except to display >the full name of the language, which is useful but not very useful. >Without translators, spelling checkers, and other such tools, one can >do little with such a document. Yeap. But the first and second strategy has no big load on the IANA. The first point is to know if the langtag is registered. Then to know its environment. With the maximum of speed and the lowest load for the database system. The rest is a matter of other services as you say. >This is quite different from the DNS case, where given the mapping of >a computer's name to an IP address, one can indeed interact with that >computer in useful ways. If I know how to reach newmachine.somedomain.fi, >I can try to discover what resources it provides. If I receive a document >langtagged "sms", the most I could do with it is label it "Skolt Sami". I do not quote the DNS as a way to reach an IP (what can also be the use for). The IP address given by the DNS is just an information as another. The DNS is first a distributed database system, which can easily supports a billion of information at low load and low cost. With a distributed management system. > > I would say this is similar to anti-spam or to anti-virus strategies. > >Languages aren't constantly being created: In term of load, the problem is the same. What motivates a query is the change. Whatever it is. Actually this is not totally true: the number of _documented_languages_ is going to increase. >on the contrary, they are >constantly going extinct. The list of living languages will probably >shrink by 90% over the next century or two. Who knows? The change over the last 50 years when a cultural development policy is engaged is not necessarily that way. The debate I follow right now is for example to know if a regional language (Occitan) is to be registered as one (as today in the 639-3 draft) or as six languages. I see young kids in my family having more Breton than French. 20 years ago it was unthinkable. IMHO, Multilingual Internet MAY (I mean nothing more) lead to a change in the current trend. We start having statistics (it will still take time to have significant results in number of people and in number of languages and cultures). They seem to show that bilingual people have a slightly higher IQ and that "apparent IQ" (when you test the same person's IQ in different languages) is lower in English (common language) than in their mother tongue. > > Obviously codes change les frequently than spamming hosts and viruses, but > > the simple fact they change make the load similar (the load is not because > > there are a lot of changes, but because there is a check if nothing > > changed). > >In practice this table will probably be updated only when the operating >system is. Probably yes, and this is in line with/below the figures I gave. Question is from where: from the OS CD or from IANA? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 22:23:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13639; Mon, 28 Mar 2005 22:23:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG7QY-000287-DU; Mon, 28 Mar 2005 22:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG7Jh-0001el-6u; Mon, 28 Mar 2005 22:22:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG7Jf-0001eL-Ko for ltru@megatron.ietf.org; Mon, 28 Mar 2005 22:22:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13603 for ; Mon, 28 Mar 2005 22:22:53 -0500 (EST) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG7QI-00027K-Dj for ltru@ietf.org; Mon, 28 Mar 2005 22:29:46 -0500 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050329032241.VMUF4618.mta13.adelphia.net@DEWELL> for ; Mon, 28 Mar 2005 22:22:41 -0500 Message-ID: <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> Subject: Re: [Ltru] Re: Shelf life of data Date: Mon, 28 Mar 2005 19:22:22 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> Codes prior to 1995 (or 1988 if you go with the reference's date) are >> really the question. I'd support going back to 1988 with codes, since >> the reference in RFC 1766 and 3066 is unclear and I well remember the >> days before the Web (when getting code lists was an arcane art and >> not a science). > > Yes. Would you have a dated list we could use as a reference? > Or would someone have one no one can dispute? That's why it's important to have a publicly available registry that everyone can turn to, instead of leaving it to each user or app to figure out which codes are valid. Now that Peter Constable has a copy of ISO 3166-3, it is possible to verify the information I've gotten from Clive Feather's page (I really need to touch base with Clive, BTW). So far, everything appears good. > We started using alpha-3 by mid-77 and formalized it in oct 1978 > (Mike Rude); and alpha-2 in 1981. Earlier entries are probably not > necessary, unless for archives, historics and experience/testing. I'm not sure who "we" is in this case, but ISO 3166 has always had alpha-2 codes since its debut in 1974, and language tags under RFC 1766 and 3066 have always used them, never the alpha-3 country codes. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 22:32:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14554; Mon, 28 Mar 2005 22:32:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG7ZX-0002Ps-1o; Mon, 28 Mar 2005 22:39:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG7S9-0003BK-S5; Mon, 28 Mar 2005 22:31:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG7S8-0003BB-RJ for ltru@megatron.ietf.org; Mon, 28 Mar 2005 22:31:41 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14537 for ; Mon, 28 Mar 2005 22:31:38 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050329033109.CACC2192.mta9.adelphia.net@DEWELL> for ; Mon, 28 Mar 2005 22:31:09 -0500 Message-ID: <00cd01c5340f$b45ee980$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050328212937.OXKS2132.mta5.adelphia.net@megatron.ietf.org> Date: Mon, 28 Mar 2005 19:30:48 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Frequency of table update X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit McDonald, Ira wrote: >>> In practice this table will probably be updated only when >>> the operating system is. >> >> In the case of browsers, with each release, right? > > And in the case of other applications (databases that access > XML records, etc.), with each release right? > > But not by some user action or auto-fetch when the application > is running in the field. I could imagine an application offering a user action to update the registry from the official site. But it would certainly be a hard-hat power-user option, and should never be required. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 28 22:43:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15085; Mon, 28 Mar 2005 22:43:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG7js-0002kh-7S; Mon, 28 Mar 2005 22:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG7cl-0004uz-IZ; Mon, 28 Mar 2005 22:42:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG7ck-0004ut-2i for ltru@megatron.ietf.org; Mon, 28 Mar 2005 22:42:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15067 for ; Mon, 28 Mar 2005 22:42:35 -0500 (EST) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG7jM-0002kA-BA for ltru@ietf.org; Mon, 28 Mar 2005 22:49:29 -0500 Received: from Lugh (unknown [83.70.45.3]) by postie2.hosting365.ie (Postfix) with ESMTP id BAA4D25489C2F for ; Tue, 29 Mar 2005 04:42:25 +0100 (IST) From: "Jon Hanna" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: Frequency of table update Date: Tue, 29 Mar 2005 04:42:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <00cd01c5340f$b45ee980$030aa8c0@DEWELL> Thread-Index: AcU0D+552tH9zoKQQRGNBmUMVKB7KgAAUbYQ Message-Id: <20050329034225.BAA4D25489C2F@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable > I could imagine an application offering a user action to update the > registry from the official site. But it would certainly be a hard-hat > power-user option, and should never be required. I could definitely see some sem-web applications doing such with an = RDF/XML version of the registry. Regards, Jon Hanna Work: Play: Chat: =20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 00:50:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25964; Tue, 29 Mar 2005 00:50:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG9in-0006ef-3N; Tue, 29 Mar 2005 00:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG9bl-0006U8-C1; Tue, 29 Mar 2005 00:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG9bj-0006U3-DF for ltru@megatron.ietf.org; Tue, 29 Mar 2005 00:49:43 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25930 for ; Tue, 29 Mar 2005 00:49:39 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050329054911.GPFQ2192.mta9.adelphia.net@DEWELL> for ; Tue, 29 Mar 2005 00:49:11 -0500 Message-ID: <00fe01c53422$fc5e5460$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050328114446.HPKI2140.mta3.adelphia.net@megatron.ietf.org> Date: Mon, 28 Mar 2005 21:48:50 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Could the authors (or anyone have a good command of their intent) > document the exact _use_ of the IANA files as they see it. > > - an application reads a langtag. > - what does it do? Well, clearly that depends on the application. A server might simply attach a tag to content and be done with it (though hopefully it would check that the tag was well-formed). A browser or other user agent might perform matching, but still not care what the tags being matched actually "mean." An application that performs some kind of text processing, such as spell-checking or speech synthesis, would have to know something about the meaning of the tags. Some other application might display the name of the language but not know anything else about it. > - when is it going to need a IANA originated data? You mean, when is it going to need the list of valid subtags and grandfathered whole-tags? Always, if its functionality depends on the meaning of the tag. The only exceptions would be private-use tags and subtags, and extension subtags (in which case it needs the RFC(s) that define those). Never, if it only performs matching and doesn't care what the subtags mean or whether they are even assigned. Take a look at Section 2.2.10, "Classes of Conformance," which describes the difference between a processor that checks for "well-formedness" and one that also checks for "validity." The "well-formed processor" only needs (a) knowledge of the generative syntax and (b) a list of grandfathered tags, both of which are carved in stone. Such an app would never need a complete registry at all. > - will it be usually in the application code? will be it be updated > in a parameter file? will it call the IANA? Should it call a cache/ > mirror? Then who should manage them? > - which applications will do that? > - how many times a day/month/year will this happen for a single user? > or ISP? or designer? All of that is up to the application. We'd be a sorry bunch if we attempted to dictate that to implementers. I have a program that generates RFC 3066bis language tags from drop-down lists, and can validate any tag, using all the information available in the registry, in full compliance with Section 2.2.10. Obviously, that application cannot do its job correctly if its copy of the registry is even slightly out of date. Equally obviously, those constraints do not apply to every application. > For example, I understand that the non documented CLDR application It's not documented as an application because it's a Data Repository. > mostly needs the langtag as a reference and will maintain its own > files to be themselves used by OS programmers. So the load should be > very low, unless someone develops an updating tool direct from the > IANA and people use it at each reboot. That's their problem. The draft explicitly discourages implementers from relying on the registry being constantly available online, because of the denial-of-service scenario. > Without that information the whole Draft does not make any sense, > because it is to document a IANA service and there are different > strategies to address the need, depending on the load it represents. By far, the most unused aspect of RFC 1766 and 3066 has been the registered tags. Few applications recognize even the oldest and best-known registered tags, like "i-mingo" and "zh-guoyu", let alone the newer ones like "bs-Latn" and "sl-rozaj". Even though RFC 3066bis applications will rely on the registry rather than ISO code lists, history does not suggest that application developers and vendors will go to great lengths to keep local copies of the registry updated. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 04:32:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06878; Tue, 29 Mar 2005 04:32:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGDBs-0005b6-Sr; Tue, 29 Mar 2005 04:39:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGD3v-0006mC-B4; Tue, 29 Mar 2005 04:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGD3r-0006kG-R5 for ltru@megatron.ietf.org; Tue, 29 Mar 2005 04:30:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06811 for ; Tue, 29 Mar 2005 04:30:58 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGDAW-0005Zz-Up for ltru@ietf.org; Tue, 29 Mar 2005 04:37:54 -0500 Received: from lns-p19-8-idf-82-65-71-22.adsl.proxad.net ([82.65.71.22] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DGD3o-0001Hd-Pu; Tue, 29 Mar 2005 01:30:57 -0800 Message-Id: <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 29 Mar 2005 10:31:14 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Shelf life of data In-Reply-To: <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c At 05:22 29/03/2005, Doug Ewell wrote: > > We started using alpha-3 by mid-77 and formalized it in oct 1978 > > (Mike Rude); and alpha-2 in 1981. Earlier entries are probably not > > necessary, unless for archives, historics and experience/testing. > >I'm not sure who "we" is in this case, but ISO 3166 has always had >alpha-2 codes since its debut in 1974, and language tags under RFC 1766 >and 3066 have always used them, never the alpha-3 country codes. "We" is the world at large. Started in Feb. 1971 as a private service and became FCC licensed, ITU sponsored common understanding/agreements by monopolies in 77. History is interesting when it can teach for the future. I think this is what is happening with Multilingual Internet, of which langtags are the very first step. 1. It started using alpha-3 codes for public monopolies, plus US International Record Carriers logos (ITT, WUI, etc.). 2 letters codes were accepted for refilers (telex operators refilling traffic into the packet switch network as did the Internet communities further on). They were just cut and pasted for ARPANET ccTLD (RFC 920). 2. IRT languages. First tests of language support were with French, German, etc. languages in 76/78 then more seriously with 82/83 with EEC and ESA and non Latin with Kokusai Tymshare and KDD. C&W had some effort made in 84/85 with Chinese test services in HK. Tests with French and German Videotex were without problem in 84/86. Israeli had something in Hebrew at their Chief Scientist office in 1985. Arabic was also tested at that time by Egyptian PTT. OTE in Athens shown me a rudimentary service, probably in 1985. EBCDIC code was supported from the very beginning but not permitted for a long and abandoned when OSI started being supported. 3. For consistency with these past archives we should include all the past codes in the first base, so this is settled once for all. On-Line public documents started with NLM Bethesda. Then there were quick development by Dialog, Lockheed and a few other large US information services and the Diane members in Europe. They were mostly in American, English and French (France and Canada). It is fun, when you stabilize something to be able to support everything down to its very roots. But also, it provides more occasions to test the way the adopted solution stands table changes. BTW IRT ISO 3166-3 we will have a copyright problem that has to be addressed in the Draft. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 11:44:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27382; Tue, 29 Mar 2005 11:44:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJwB-0006L9-Tk; Tue, 29 Mar 2005 11:51:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJdQ-00012Z-Ul; Tue, 29 Mar 2005 11:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJdP-000128-Fr for ltru@megatron.ietf.org; Tue, 29 Mar 2005 11:32:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22839 for ; Tue, 29 Mar 2005 11:32:04 -0500 (EST) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJk8-0004k4-Or for ltru@ietf.org; Tue, 29 Mar 2005 11:39:05 -0500 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050329163152.ROJU5402.mta11.adelphia.net@DEWELL> for ; Tue, 29 Mar 2005 11:31:52 -0500 Message-ID: <002501c5347c$b6c3c700$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> Subject: Re: [Ltru] Re: Shelf life of data Date: Tue, 29 Mar 2005 08:31:08 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > 3. For consistency with these past archives we should include all the > past codes in the first base, so this is settled once for all. We're not trying to maintain compatibility with every country coding system ever invented, just the one used for language tags. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 15:37:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22685; Tue, 29 Mar 2005 15:37:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGNZU-0006db-Je; Tue, 29 Mar 2005 15:44:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNRa-0007bn-Lt; Tue, 29 Mar 2005 15:36:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGNRZ-0007bE-ID for ltru@megatron.ietf.org; Tue, 29 Mar 2005 15:36:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22542 for ; Tue, 29 Mar 2005 15:36:07 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGNYK-0006bd-35 for ltru@ietf.org; Tue, 29 Mar 2005 15:43:09 -0500 Received: from lns-p19-1-idf-82-251-78-93.adsl.proxad.net ([82.251.78.93] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DGNRG-0004PI-Er; Tue, 29 Mar 2005 12:35:51 -0800 Message-Id: <6.1.2.0.2.20050329190657.0393f170@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 29 Mar 2005 22:35:17 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Shelf life of data In-Reply-To: <002501c5347c$b6c3c700$030aa8c0@DEWELL> References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> <002501c5347c$b6c3c700$030aa8c0@DEWELL> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0533754991==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --===============0533754991== Content-Type: multipart/alternative; boundary="=====================_179639788==.ALT" --=====================_179639788==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 18:31 29/03/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > 3. For consistency with these past archives we should include all the > > past codes in the first base, so this is settled once for all. > >We're not trying to maintain compatibility with every country coding >system ever invented, just the one used for language tags. The ultimate target is to facilitare the exchange goods and services through the elimination of technical barriers to trade and to foster the human cultural development through a through multingual internet, something the IETF has never been good at - due to the Internet default parameters logic I documented. And IAB demonstrated by the choice of its priorities in TFC 3869. This is the reason why we need the support from other experiences and motivation by new demands from NGN and WSIS. If ISO is not enough, any other adequate subtag source is to be supported. jfc --=====================_179639788==.ALT Content-Type: text/html; charset="us-ascii"
At 18:31 29/03/2005, Doug Ewell wrote:
JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:
> 3. For consistency with these past archives we should include all the
> past codes in the first base, so this is settled once for all.

We're not trying to maintain compatibility with every country coding
system ever invented, just the one used for language tags.
The ultimate target is to facilitare the exchange goods and services through the elimination of technical barriers to trade and to foster the human cultural development through a through multingual internet, something the IETF has never been good at - due to the Internet default parameters logic I documented. And IAB demonstrated by the choice of its priorities in TFC 3869. This is the reason why we need the support from other experiences and motivation by new demands from NGN and WSIS. If ISO is not enough, any other adequate subtag source is to be supported.
jfc



--=====================_179639788==.ALT-- --===============0533754991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0533754991==-- From ltru-bounces@ietf.org Tue Mar 29 20:12:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18341; Tue, 29 Mar 2005 20:12:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGRrZ-00076l-Ez; Tue, 29 Mar 2005 20:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGRkY-0000u0-4s; Tue, 29 Mar 2005 20:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGRkW-0000sm-AY for ltru@megatron.ietf.org; Tue, 29 Mar 2005 20:12:00 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18328 for ; Tue, 29 Mar 2005 20:11:57 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGRjL-0007dA-5Z for ltru@lists.ietf.org; Wed, 30 Mar 2005 03:10:47 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 03:10:47 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 03:10:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 03:10:29 +0200 Organization: Lines: 13 Message-ID: <4249FC85.6D26@xyzzy.claranet.de> References: <20050328114446.HPKI2140.mta3.adelphia.net@megatron.ietf.org> <00fe01c53422$fc5e5460$030aa8c0@DEWELL> 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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > let alone the newer ones like "bs-Latn" and "sl-rozaj". The IANA/assignments/lang-tags/ Web page doesn't list bs-Latn. The most recent IANA tag is still en-GB-oed (2003-07-09). BTW, should we deprecate en-GB-oed and zh-min-nan ? And / or list the few grandfathered exceptions from the new general pattern directly in the ABNF ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 20:20:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19065; Tue, 29 Mar 2005 20:20:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGRzt-0007N4-Gi; Tue, 29 Mar 2005 20:27:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGRrt-0002HP-S6; Tue, 29 Mar 2005 20:19:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGRrs-0002HH-TO for ltru@megatron.ietf.org; Tue, 29 Mar 2005 20:19:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18947 for ; Tue, 29 Mar 2005 20:19:35 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGRyg-0007J9-IA for ltru@ietf.org; Tue, 29 Mar 2005 20:26:39 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 17:19:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Registry in record-jar format Date: Tue, 29 Mar 2005 17:19:25 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17347@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU0xYBLNUYWpyubSS++9Ev552YO7gAACJCg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 30 Mar 2005 01:19:25.0780 (UTC) FILETIME=[831CD140:01C534C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable bs-Latn was registered, or should have been. I suppose one could dig out = the approval note and bug Michael about it. > BTW, should we deprecate en-GB-oed and zh-min-nan ?=20 Maybe, although it isn't necessary. After the draft is completed a new = variant can be registered and the canonical mapping field updated to = deal with these few cases. This could be done in the prototype registry = for completeness sake, I suppose. > And / or > list the few grandfathered exceptions from the new general > pattern directly in the ABNF ? I think listing the grandfathered tags in the ABNF just makes very hard = to read ABNF. Besides, the list can change up to the point where the = draft takes effect. The text of the draft does a good enough job of = enumerating these beasts, IMHO. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 29 mars 2005 17:10 > To: ltru@ietf.org > Subject: [Ltru] Re: Registry in record-jar format >=20 > Doug Ewell wrote: >=20 > > let alone the newer ones like "bs-Latn" and "sl-rozaj". >=20 > The IANA/assignments/lang-tags/ Web page doesn't list bs-Latn. > The most recent IANA tag is still en-GB-oed (2003-07-09). >=20 > BTW, should we deprecate en-GB-oed and zh-min-nan ? And / or > list the few grandfathered exceptions from the new general > pattern directly in the ABNF ? >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 20:55:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21863; Tue, 29 Mar 2005 20:55:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGSX6-0008L1-5w; Tue, 29 Mar 2005 21:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGSPp-00085n-Sz; Tue, 29 Mar 2005 20:54:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGSPl-00085f-AI for ltru@megatron.ietf.org; Tue, 29 Mar 2005 20:54:41 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21832 for ; Tue, 29 Mar 2005 20:54:35 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGSOe-00037M-Sk for ltru@lists.ietf.org; Wed, 30 Mar 2005 03:53:28 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 03:53:28 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 03:53:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 03:52:57 +0200 Organization: Lines: 31 Message-ID: <424A0679.1189@xyzzy.claranet.de> References: <20050326155923.OBLW2135.mta2.adelphia.net@megatron.ietf.org> <005501c53361$71402280$030aa8c0@DEWELL> 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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] DD, YD, and YU (was: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Doug Ewell wrote: > RFC 1766 and 3066 allowed language tags to contain any code > in the 1988 versions of ISO 639 and 3166. Apparently. Or maybe Harald forgot to update his references in RfC 3066. Or he's the lucky owner of a 1988 edition, and didn't want to pay for a newer edition of ISO 3166. > Changing the date to 1995 would add only five more codes > (BU, DD, NT, SU, and YD) to the blacklist. Is that worth > violating the agreement set down in RFC 1766? I'm not sure. BU, NT, and SU are still visible on the 3166-1 page. DD and YD are officially unassigned. In other words they could be assigned to a new region tomorrow when necessary. Let's work on some decent "union" / "split" rules for a while, that's more important than the two 1988 DD and YD incarnations of "old" draft -00 oddities. A simple fix could be a new rule, that whenever an existing (3166-1 CC = UN number) relation for a registered CC is changed by the introduction of a new UN number for the CC, then the old UN number is added to the registry. That also proves that the stability in draft -00 is partially an illusion. But at least it doesn't lose complete regions like the old DE, YE, or YU. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 21:48:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26254; Tue, 29 Mar 2005 21:48:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGTMd-0001Lo-65; Tue, 29 Mar 2005 21:55:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGTFH-0008Pe-3H; Tue, 29 Mar 2005 21:47:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGTFF-0008PW-5H for ltru@megatron.ietf.org; Tue, 29 Mar 2005 21:47:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26214 for ; Tue, 29 Mar 2005 21:47:47 -0500 (EST) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGTM3-0001Kt-FM for ltru@ietf.org; Tue, 29 Mar 2005 21:54:52 -0500 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050330024732.NAZV7277.mta10.adelphia.net@DEWELL> for ; Tue, 29 Mar 2005 21:47:32 -0500 Message-ID: <003d01c534d2$c5edce00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> <002501c5347c$b6c3c700$030aa8c0@DEWELL> <6.1.2.0.2.20050329190657.0393f170@mail.jefsey.com> Date: Tue, 29 Mar 2005 18:47:10 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Shelf life of data X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> We're not trying to maintain compatibility with every country coding >> system ever invented, just the one used for language tags. > > The ultimate target is to facilitare the exchange goods and services > through the elimination of technical barriers to trade and to foster > the human cultural development through a through multingual internet, > something the IETF has never been good at - due to the Internet > default parameters logic I documented. And IAB demonstrated by the > choice of its priorities in TFC 3869. This is the reason why we need > the support from other experiences and motivation by new demands from > NGN and WSIS. If ISO is not enough, any other adequate subtag source > is to be supported. You're reading a different charter from the one I'm reading, that's for sure. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 22:16:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28588; Tue, 29 Mar 2005 22:16:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGToK-0002C0-Rf; Tue, 29 Mar 2005 22:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGTh6-0004eX-Un; Tue, 29 Mar 2005 22:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGTh4-0004eP-GZ for ltru@megatron.ietf.org; Tue, 29 Mar 2005 22:16:35 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28486 for ; Tue, 29 Mar 2005 22:16:31 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGTfu-0002jb-JI for ltru@lists.ietf.org; Wed, 30 Mar 2005 05:15:22 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 05:15:22 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 05:15:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 05:13:26 +0200 Organization: Lines: 14 Message-ID: <424A1956.605A@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AC2A3C5@irvmbxw01.quest.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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: 3166-1 state machine X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > I was addressing Frank's comments that seemed (possibly only > to me) to suggest that ccTLD codes would be candidates for > the registry because they might have been erroneously used > in legacy data. No, you and Doug convinced me that ccTLDs are a bad idea, let ISO 3166 do "the right thing" for AC, GG, IM, and JE. "Jane Blog" was only a counter-example to "Joe Blow", and her RH is no ccTLD, like Joe's BU. They didn't check whois.iana.org ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 22:49:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00679; Tue, 29 Mar 2005 22:49:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGUK6-00036H-2s; Tue, 29 Mar 2005 22:56:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGUD9-0001nO-68; Tue, 29 Mar 2005 22:49:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGUD8-0001n5-0k for ltru@megatron.ietf.org; Tue, 29 Mar 2005 22:49:42 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00672 for ; Tue, 29 Mar 2005 22:49:39 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGUBm-0005rv-4C for ltru@lists.ietf.org; Wed, 30 Mar 2005 05:48:18 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 05:48:18 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 05:48:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 05:48:23 +0200 Organization: Lines: 9 Message-ID: <424A2187.62C0@xyzzy.claranet.de> References: <20050327165301.DMEA2140.mta3.adelphia.net@megatron.ietf.org> <005201c5335f$016c1f60$030aa8c0@DEWELL> 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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: 3166-1 state machine X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Doug Ewell wrote: > is there really any evidence that people are using non-ISO > 3166 ccTLDs in language tags? For some time I thought that en-UK is correct... :-( Maybe I confuse it with a locale. Google claims to have 300,000 hits for "en-uk" (quoted), most of them probably irrelevant. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 29 22:53:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01320; Tue, 29 Mar 2005 22:53:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGUNv-0003GX-JO; Tue, 29 Mar 2005 23:00:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGUFD-00025y-CZ; Tue, 29 Mar 2005 22:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGUFC-00025s-1c for ltru@megatron.ietf.org; Tue, 29 Mar 2005 22:51:50 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00851 for ; Tue, 29 Mar 2005 22:51:47 -0500 (EST) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DGUE1-000680-Tv for ltru@lists.ietf.org; Wed, 30 Mar 2005 05:50:38 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 05:50:37 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 05:50:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 05:48:23 +0200 Organization: Lines: 9 Message-ID: <424A2187.62C0@xyzzy.claranet.de> References: <20050327165301.DMEA2140.mta3.adelphia.net@megatron.ietf.org> <005201c5335f$016c1f60$030aa8c0@DEWELL> 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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: 3166-1 state machine X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Doug Ewell wrote: > is there really any evidence that people are using non-ISO > 3166 ccTLDs in language tags? For some time I thought that en-UK is correct... :-( Maybe I confuse it with a locale. Google claims to have 300,000 hits for "en-uk" (quoted), most of them probably irrelevant. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 00:39:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12155; Wed, 30 Mar 2005 00:39:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGW1t-0007NP-BM; Wed, 30 Mar 2005 00:46:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGVuO-0007b9-6x; Wed, 30 Mar 2005 00:38:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGVuM-0007b3-9z for ltru@megatron.ietf.org; Wed, 30 Mar 2005 00:38:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12137 for ; Wed, 30 Mar 2005 00:38:23 -0500 (EST) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGW1C-0007KP-5u for ltru@ietf.org; Wed, 30 Mar 2005 00:45:31 -0500 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050330053810.NYUR2192.mta9.adelphia.net@DEWELL> for ; Wed, 30 Mar 2005 00:38:10 -0500 Message-ID: <006001c534ea$8dc95220$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> Subject: Re: [Ltru] Re: Shelf life of data Date: Tue, 29 Mar 2005 21:37:23 -0800 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-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > BTW IRT ISO 3166-3 we will have a copyright problem that has to be > addressed in the Draft. Or, more precisely, there is a *potential* copyright issue that needs to be handled properly so it doesn't *become* a problem. For all the other standards, the code list is freely available over the Internet but the standard itself must be purchased. ISO 3166-3 is the only one where even the code list is not free. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 01:06:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14342; Wed, 30 Mar 2005 01:06:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGWSc-0008AO-4d; Wed, 30 Mar 2005 01:13:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWGG-0002bp-Dl; Wed, 30 Mar 2005 01:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWGE-0002bQ-0R for ltru@megatron.ietf.org; Wed, 30 Mar 2005 01:01:02 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13753 for ; Wed, 30 Mar 2005 01:01:01 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050330060030.TSBA7277.mta10.adelphia.net@DEWELL> for ; Wed, 30 Mar 2005 01:00:30 -0500 Message-ID: <007a01c534ed$a603fd60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 29 Mar 2005 21:59:33 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > The IANA/assignments/lang-tags/ Web page doesn't list bs-Latn. > The most recent IANA tag is still en-GB-oed (2003-07-09). That's the problem. Nine tags *have* been registered since then, but they're still not listed on the IANA page. > BTW, should we deprecate en-GB-oed and zh-min-nan ? Why would we want to do that? If you're thinking about registering new subtags to replace these, remember: Grandfathered tags are forever. They don't drop off the registry just because they've been deprecated. All that does is create a duplicate tag with the same meaning, which is not a desirable thing in and of itself. > And / or list the few grandfathered exceptions from the new general > pattern directly in the ABNF ? No, for exactly the reasons Addison mentioned. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 01:20:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15837; Wed, 30 Mar 2005 01:20:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGWfX-00006h-AE; Wed, 30 Mar 2005 01:27:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWY9-0005YD-G4; Wed, 30 Mar 2005 01:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWY7-0005XI-Fq for ltru@megatron.ietf.org; Wed, 30 Mar 2005 01:19:31 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15822 for ; Wed, 30 Mar 2005 01:19:30 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050330061859.OVDZ2192.mta9.adelphia.net@DEWELL> for ; Wed, 30 Mar 2005 01:18:59 -0500 Message-ID: <008001c534f0$35c31560$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 29 Mar 2005 22:17:53 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: DD, YD, and YU (was: Question) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> RFC 1766 and 3066 allowed language tags to contain any code >> in the 1988 versions of ISO 639 and 3166. > > Apparently. Or maybe Harald forgot to update his references > in RfC 3066. Or he's the lucky owner of a 1988 edition, and > didn't want to pay for a newer edition of ISO 3166. Doesn't matter. Compatibility requires that we allow all codes that were valid in either RFC 1766 *or* 3066. >> Changing the date to 1995 would add only five more codes >> (BU, DD, NT, SU, and YD) to the blacklist. Is that worth >> violating the agreement set down in RFC 1766? > > I'm not sure. BU, NT, and SU are still visible on the 3166-1 > page. DD and YD are officially unassigned. In other words > they could be assigned to a new region tomorrow when necessary. So could the others. Look, we've already agreed (I think) that the codes withdrawn before 1988 can be removed without sacrificing compatibility. That's 15 of the 24 withdrawn codes, or 62%. I think we should move on. > Let's work on some decent "union" / "split" rules for a while, > that's more important than the two 1988 DD and YD incarnations > of "old" draft -00 oddities. > > A simple fix could be a new rule, that whenever an existing > (3166-1 CC = UN number) relation for a registered CC is changed > by the introduction of a new UN number for the CC, then the old > UN number is added to the registry. > > That also proves that the stability in draft -00 is partially > an illusion. But at least it doesn't lose complete regions > like the old DE, YE, or YU. Personally, I think this is overkill. I don't think any more fine-tuning of the repertoire of region subtags is necessary or justified. I've said this before, but there is an established history of using ISO 3166-1 alpha-2 codes to represent the country or quasi-country in which a language (variant) is used. They're not perfect. They have flaws. UN M.49 numeric codes are probably better suited in some ways. But almost nobody knows about them; they have no mnemonic value. The main value of allowing 'DD' as well as 'DE' is that tags in 'DD' were allowed under RFC 1766. Yes, I know that means we have a code for present-day Germany and a code for the former East Germany, but no code for the former West Germany. I don't see that as a significant gap in tagging flexibility. What does everyone else think? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 01:23:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16009; Wed, 30 Mar 2005 01:23:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGWiU-0000Bl-4H; Wed, 30 Mar 2005 01:30:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWbN-00065D-O6; Wed, 30 Mar 2005 01:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGWbL-00064G-8u for ltru@megatron.ietf.org; Wed, 30 Mar 2005 01:22:51 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15985 for ; Wed, 30 Mar 2005 01:22:50 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050330062220.OWYC2192.mta9.adelphia.net@DEWELL> for ; Wed, 30 Mar 2005 01:22:20 -0500 Message-ID: <008601c534f0$ab306c80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 29 Mar 2005 22:21:11 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: 3166-1 state machine X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> is there really any evidence that people are using non-ISO >> 3166 ccTLDs in language tags? > > For some time I thought that en-UK is correct... :-( Maybe I > confuse it with a locale. Google claims to have 300,000 hits > for "en-uk" (quoted), most of them probably irrelevant. That's not evidence of ccTLDs in language tags, that's just an error. :-) -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 01:50:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18267; Wed, 30 Mar 2005 01:50:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGX8Z-0000uO-LG; Wed, 30 Mar 2005 01:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGX1R-0001hp-Hm; Wed, 30 Mar 2005 01:49:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGX1P-0001hc-Ps for ltru@megatron.ietf.org; Wed, 30 Mar 2005 01:49:47 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18179 for ; Wed, 30 Mar 2005 01:49:46 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050330064916.ETBG5402.mta11.adelphia.net@DEWELL> for ; Wed, 30 Mar 2005 01:49:16 -0500 Message-ID: <009201c534f4$65efb500$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 29 Mar 2005 22:47:52 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit I propose the following changes to the region subtags. I'd like to see if we can reach a rough consensus on these items by next Wednesday, April 6, at which point I will float a new version of the registry, as well as complete step-by-step instructions for populating all parts of the registry. 1. Remove all region subtags that were withdrawn from ISO 3166 before 1988. The list comprises BQ, CT, DY, FQ, HV, JT, MI, NH, NQ, PC, PU, PZ, RH, VD, and WK. 2. For the remaining region subtags that were withdrawn from ISO 3166 after 1988, change the description as necessary to match the name originally associated with the ISO code (not the new name). BU: change "Myanmar" to "Burma" DD: change "East Germany" to "German Democratic Republic" TP: change "Timor-Leste" to "East Timor" YD: change "People's Democratic Republic of Yemen" to "Yemen, Democratic" YU: change "Serbia and Montenegro" to "Yugoslavia" ZR: change "Congo, The Democratic Republic of the" to "Zaire" Note that subtags corresponding to current ISO codes are not affected. For example, MM is still "Myanmar" and TL is still "Timor-Leste." 3. For this same set of region subtags, change the canonical value as necessary to match ISO 3166:1998, regardless of whether the physical entity is the same. DD: change '--' to 'DE' FX: change '--' to 'FR' YD: change '--' to 'YE' 4. For this same set, change the format of the comments as follows (where X is the old country name and Y is the new name): "Y... changed yyyy-mm-dd, formerly X" --> "X... withdrawn yyyy-mm-dd, replaced by Y" "deprecated yyyy-mm-dd" --> "withdrawn yyyy-mm-dd" 5. Remove region subtag 172 (Commonwealth of Independent States) on the basis that it is classified among the economic codes (otherwise not allowed), and 200 (Czechoslovakia) on the basis that including it is inconsistent with other principles for populating the registry. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 01:54:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18695; Wed, 30 Mar 2005 01:54:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXCj-0000zs-Kx; Wed, 30 Mar 2005 02:01:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGX5R-0002aW-Ln; Wed, 30 Mar 2005 01:53:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGX5Q-0002aR-74 for ltru@megatron.ietf.org; Wed, 30 Mar 2005 01:53:56 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18682 for ; Wed, 30 Mar 2005 01:53:54 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGX41-0005Xy-Dp for ltru@lists.ietf.org; Wed, 30 Mar 2005 08:52:29 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 08:52:29 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 08:52:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 08:49:42 +0200 Organization: Lines: 11 Message-ID: <424A4C06.70A@xyzzy.claranet.de> References: <007a01c534ed$a603fd60$030aa8c0@DEWELL> 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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] zh-min-nan and en-GB-oed (was: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> should we deprecate en-GB-oed and zh-min-nan ? > Why would we want to do that? They don't follow the normal lang + extlang + variant or lang + region + variant patterns. But if the parser isn't broken it should find that these _must_ be grandfathered tags, sorry, please ignore my stupid question. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 02:09:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28103; Wed, 30 Mar 2005 02:09:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXR4-0001FW-Qk; Wed, 30 Mar 2005 02:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXI8-0004Jr-Mr; Wed, 30 Mar 2005 02:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXI7-0004Jm-7a for ltru@megatron.ietf.org; Wed, 30 Mar 2005 02:07:03 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26029 for ; Wed, 30 Mar 2005 02:07:02 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGXH4-0007Fh-UA for ltru@lists.ietf.org; Wed, 30 Mar 2005 09:05:58 +0200 Received: from 212.82.251.134 ([212.82.251.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 09:05:58 +0200 Received: from nobody by 212.82.251.134 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2005 09:05:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 30 Mar 2005 09:05:22 +0200 Organization: Lines: 13 Message-ID: <424A4FB2.4EBD@xyzzy.claranet.de> References: <009201c534f4$65efb500$030aa8c0@DEWELL> 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.134 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I propose the following changes to the region subtags. Seconded. We can discuss the finer points of "losing" regions by unions or splits (if a new region inherits an old CC) later. > 200 (Czechoslovakia) on the basis that including it is > inconsistent with other principles Yes, that's one of these finer points, at the moment it's OUT, but maybe we invent a proper rule to add it again later. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 02:11:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00062; Wed, 30 Mar 2005 02:11:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXT2-0001Gt-E3; Wed, 30 Mar 2005 02:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXLp-0004w1-OS; Wed, 30 Mar 2005 02:10:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXLp-0004vu-0Z for ltru@megatron.ietf.org; Wed, 30 Mar 2005 02:10:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29697 for ; Wed, 30 Mar 2005 02:10:51 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXSf-0001GS-7s for ltru@ietf.org; Wed, 30 Mar 2005 02:17:58 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2U7AZ0g003112; Wed, 30 Mar 2005 02:10:36 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 30 Mar 2005 02:10:35 -0500 Date: Wed, 30 Mar 2005 02:10:35 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Shelf life of data Message-ID: <20050330071035.GK13803@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> <006001c534ea$8dc95220$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006001c534ea$8dc95220$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Doug Ewell scripsit: > For all the other standards, the code list is freely available over the > Internet but the standard itself must be purchased. ISO 3166-3 is the > only one where even the code list is not free. We are not planning to reprint the code list; we are planning to use the information in the code list to make something new. The fact that a cookbook is copyright doesn't mean that the copyright owner can control who can make dishes according to the recipes. IANAL, TINLA. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com Economists were put on this planet to make astrologers look good. --Leo McGarry _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 02:13:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02064; Wed, 30 Mar 2005 02:13:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXUy-0001Iw-Tz; Wed, 30 Mar 2005 02:20:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXMy-00056H-8F; Wed, 30 Mar 2005 02:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXMw-000564-FB for ltru@megatron.ietf.org; Wed, 30 Mar 2005 02:12:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00912 for ; Wed, 30 Mar 2005 02:12:01 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXTn-0001I9-9v for ltru@ietf.org; Wed, 30 Mar 2005 02:19:08 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2U7Bk9w003119; Wed, 30 Mar 2005 02:11:47 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 30 Mar 2005 02:11:49 -0500 Date: Wed, 30 Mar 2005 02:11:49 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: DD, YD, and YU (was: Question) Message-ID: <20050330071149.GL13803@skunk.reutershealth.com> References: <008001c534f0$35c31560$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008001c534f0$35c31560$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Doug Ewell scripsit: > So could the others. Look, we've already agreed (I think) that the > codes withdrawn before 1988 can be removed without sacrificing > compatibility. That's 15 of the 24 withdrawn codes, or 62%. I think we > should move on. +1 > The main value of allowing 'DD' as well as 'DE' is that tags in 'DD' > were allowed under RFC 1766. Yes, I know that means we have a code for > present-day Germany and a code for the former East Germany, but no code > for the former West Germany. I don't see that as a significant gap in > tagging flexibility. What does everyone else think? +1 -- It was dreary and wearisome. Cold clammy winter still held way in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --"The Passage of the Marshes" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 02:31:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23060; Wed, 30 Mar 2005 02:31:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXms-0001bV-Ko; Wed, 30 Mar 2005 02:38:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXfy-0000wC-MJ; Wed, 30 Mar 2005 02:31:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGXfv-0000vt-Hn for ltru@megatron.ietf.org; Wed, 30 Mar 2005 02:31:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22981 for ; Wed, 30 Mar 2005 02:31:38 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGXmm-0001bF-Fj for ltru@ietf.org; Wed, 30 Mar 2005 02:38:45 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2U7VRnH003183; Wed, 30 Mar 2005 02:31:28 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 30 Mar 2005 02:31:32 -0500 Date: Wed, 30 Mar 2005 02:31:32 -0500 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] zh-min-nan and en-GB-oed (was: Registry in record-jar format) Message-ID: <20050330073132.GM13803@skunk.reutershealth.com> References: <007a01c534ed$a603fd60$030aa8c0@DEWELL> <424A4C06.70A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424A4C06.70A@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Frank Ellermann scripsit: > They don't follow the normal lang + extlang + variant or > lang + region + variant patterns. But if the parser isn't > broken it should find that these _must_ be grandfathered > tags, sorry, please ignore my stupid question. This brings up an interesting point: Of the 25 current grandfathered tags in the registry: 18 are not well-formed (en-gb-oed, i-*, sgn-*-*, zh-min-nan). 6 are of the reserved xx-yyy form: 3 (zh-gan, zh-wuu, zh-yue) will be well-formed and valid in 3066ter; 3 (zh-min, no-bok, no-nyn) will be well-formed but not valid in 3066ter. 1 is well-formed already (art-lojban) but appears to make "lojban" a variant, which it is not. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 10:31:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09156; Wed, 30 Mar 2005 10:31:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGfHT-00037F-2u; Wed, 30 Mar 2005 10:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGf8s-0000GU-Pf; Wed, 30 Mar 2005 10:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGf8q-0000C3-J8 for ltru@megatron.ietf.org; Wed, 30 Mar 2005 10:30:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08946 for ; Wed, 30 Mar 2005 10:29:58 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGfFm-00035U-Fn for ltru@ietf.org; Wed, 30 Mar 2005 10:37:10 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2UFTksJ026184 for ; Wed, 30 Mar 2005 10:29:46 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2UFTkfl082416 for ; Wed, 30 Mar 2005 10:29:46 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2UFTk1Z027152 for ; Wed, 30 Mar 2005 10:29:46 -0500 Received: from markdavis (sig-9-48-117-252.mts.ibm.com [9.48.117.252]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j2UFTi1U027005; Wed, 30 Mar 2005 10:29:46 -0500 Message-ID: <1f7f01c5353d$4d7a3920$727d3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <009201c534f4$65efb500$030aa8c0@DEWELL> Subject: Re: [Ltru] Proposed changes to region subtags Date: Wed, 30 Mar 2005 07:24:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j2UFTksJ026184 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable I agree with those changes. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Tuesday, March 29, 2005 22:47 Subject: [Ltru] Proposed changes to region subtags > I propose the following changes to the region subtags. I'd like to see > if we can reach a rough consensus on these items by next Wednesday, > April 6, at which point I will float a new version of the registry, as > well as complete step-by-step instructions for populating all parts of > the registry. > > 1. Remove all region subtags that were withdrawn from ISO 3166 before > 1988. > > The list comprises BQ, CT, DY, FQ, HV, JT, MI, NH, NQ, PC, PU, PZ, RH, > VD, and WK. > > 2. For the remaining region subtags that were withdrawn from ISO 3166 > after 1988, change the description as necessary to match the name > originally associated with the ISO code (not the new name). > > BU: change "Myanmar" to "Burma" > DD: change "East Germany" to "German Democratic Republic" > TP: change "Timor-Leste" to "East Timor" > YD: change "People's Democratic Republic of Yemen" to "Yemen, > Democratic" > YU: change "Serbia and Montenegro" to "Yugoslavia" > ZR: change "Congo, The Democratic Republic of the" to "Zaire" > > Note that subtags corresponding to current ISO codes are not affected. > For example, MM is still "Myanmar" and TL is still "Timor-Leste." > > 3. For this same set of region subtags, change the canonical value as > necessary to match ISO 3166:1998, regardless of whether the physical > entity is the same. > > DD: change '--' to 'DE' > FX: change '--' to 'FR' > YD: change '--' to 'YE' > > 4. For this same set, change the format of the comments as follows > (where X is the old country name and Y is the new name): > > "Y... changed yyyy-mm-dd, formerly X" > --> "X... withdrawn yyyy-mm-dd, replaced by Y" > > "deprecated yyyy-mm-dd" > --> "withdrawn yyyy-mm-dd" > > 5. Remove region subtag 172 (Commonwealth of Independent States) on th= e > basis that it is classified among the economic codes (otherwise not > allowed), and 200 (Czechoslovakia) on the basis that including it is > inconsistent with other principles for populating the registry. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 11:40:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16595; Wed, 30 Mar 2005 11:40:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgMU-0004pC-Pe; Wed, 30 Mar 2005 11:48:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgFJ-0002X2-23; Wed, 30 Mar 2005 11:40:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgFI-0002Wx-La for ltru@megatron.ietf.org; Wed, 30 Mar 2005 11:40:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16560 for ; Wed, 30 Mar 2005 11:40:42 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgMA-0004oc-WC for ltru@ietf.org; Wed, 30 Mar 2005 11:47:52 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 08:40:50 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 30 Mar 2005 08:40:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] DD, YD, and YU (was: Question) Date: Wed, 30 Mar 2005 08:40:50 -0800 Message-ID: Thread-Topic: [Ltru] DD, YD, and YU (was: Question) Thread-Index: AcU0y3xbYU6PYTqRQEKUj1ddugbkWQAeg4bg From: "Peter Constable" To: X-OriginalArrivalTime: 30 Mar 2005 16:40:29.0146 (UTC) FILETIME=[2EA543A0:01C53547] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > > Changing the date to 1995 would add only five more codes > > (BU, DD, NT, SU, and YD) to the blacklist. Is that worth > > violating the agreement set down in RFC 1766? >=20 > I'm not sure. BU, NT, and SU are still visible on the 3166-1 > page. DD and YD are officially unassigned. In other words > they could be assigned to a new region tomorrow when necessary. One of the basic issues in 3066bis is to ensure stability of tags. DD and YD *are* valid under RFC 3066; we should not change that. It is not very likely that they'll get reassigned any time soon, but if they happen to get reassigned after a new RFC is in place, it will have means to deal with that. It is so unlikely that they will get reassigned before then that there is no need to waste time making contingency plans. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 11:49:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17408; Wed, 30 Mar 2005 11:49:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgV8-00050y-0E; Wed, 30 Mar 2005 11:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgO2-0003x9-V1; Wed, 30 Mar 2005 11:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgO1-0003x4-MR for ltru@megatron.ietf.org; Wed, 30 Mar 2005 11:49:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17398 for ; Wed, 30 Mar 2005 11:49:43 -0500 (EST) Received: from web42004.mail.yahoo.com ([66.218.93.172]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGgUv-00050X-5R for ltru@ietf.org; Wed, 30 Mar 2005 11:56:56 -0500 Received: (qmail 43934 invoked by uid 60001); 30 Mar 2005 16:49:32 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=z5Fy375JhaOJAzGU5OSO6wwvGVvLQi/FggzfB25TaQTkTCehaT0bxxF8A0jahTZFjiLVHEt7FhLHBQv1UXQILPKY7icf5+45tW0jMuBgA+PWjK/uX4lXSH/FurM+D36IcTUu9B1uDi3E4ECeb2FPieYSTfcJDirMKrpzjSizepE= ; Message-ID: <20050330164932.43932.qmail@web42004.mail.yahoo.com> Received: from [158.169.9.14] by web42004.mail.yahoo.com via HTTP; Wed, 30 Mar 2005 17:49:32 BST Date: Wed, 30 Mar 2005 17:49:32 +0100 (BST) From: "M.T. Carrasco Benitez" To: ltru@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: 8bit Subject: [Ltru] Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: 8bit I am sending this today to the editor. Regards Tomas ------------------------------------------------------------------- Internet-Draft M.T. Carrasco Benitez Expires: 1 October 2005 European Commission 30 March 2005 Codes for language transformation draft-carrasco-language-code-02.txt Intellectual Property Rights Statement 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. Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes codes for language transformation such as transliteration and transcription. Language transformation means that a language is expressed in another way (e.g., in another alphabet) for people familiar with the target alphabet and language. For example, Greek converted to Latin script for English users. Note that this is not translation. The text continues to be in Greek, but written in another alphabet. Carrasco Expires 1 October 2005 [Page 1] Internet-Draft Language Transformation March 2005 1. Introduction Natural languages can be written in scripts that are not their usual scripts. For example, the ideogram for the Chinese capital is transliterated as "Beijing". Transliteration tries to transform scripts. Transcription tries to transform sounds. It is wise to avoid discussion on what is transliteration or transcription: often transformation schemes are a mixture of several approaches. Hence, this document uses the term transformation. Transformation is aimed at a target user. For example, transformation from Greek for English is different from a transformation from Greek for Arab: the scripts are different. Scripts are not the only issue. Transformation from Greek for French is different from transformation from Greek for Spanish: same target script, different target languages; but different transformation schemes. One can also have more than one transformation scheme from a language to another language. For example, there are several transformation schemes from Chinese for English: same target script, same target language; but different transformation schemes. Hence, one needs a list of transformation schemes, each with one unique identifier. The transformation identifier indicates the source language(s), the source script, the target language(s) and the target script. Following the publication of the Internet-Draft Tags for Identification of Languages [TID], this long expired Internet-Draft is revived as a feedback to the ongoing work by the Language Tag Registry Update (LTRU). 2. Transformation To tag a transformed language one needs the following: - Transformation indicator - Source language - Transformation scheme Example: tran-zh-wadegiles This means: Transformation of Chinese using the Wade-Gide scheme. Carrasco Expires 1 October 2005 [Page 2] Internet-Draft Language Transformation March 2005 The above is a pseudo-code. In particular, it is not a syntactic proposition for LTRU. This should come later, assuming that LTRU want to consider language transformations. Indeed, the transformation token does not need to be present and it could be implied. For example; zh-wadegiles 3. Syntax Ideally, the syntax should be of the form: zh-wadegiles i.e., the transformation indicator should be implicit. Otherwise, the syntax should be discussed in LTRU. 4. Registries Two registries are need: - IANA - Schemes for Language Transformation IANA must be concerned only with scheme identifiers. In the example above the string "wadegiles". The Registry of Schemes for Language Transformation must contain the scheme identifier, source and target language(s)/script(s), description, etc. A proposition will follow. 5. Security Considerations The same as stated in TID, section 4. 6. References [LIST] Previous discussion in the list www-international@w3.org http://lists.w3.org/Archives/Public/ www-international/1998OctDec/0002.html [LTRU] Language Tag Registry Update (ltru) http://www.ietf.org/html.charters/ltru-charter.html Carrasco Expires 1 October 2005 [Page 3] Internet-Draft Language Transformation March 2005 [TC46/SC2] International Technical Committee 46 / Subcommittee 2 Conversion of Written Languages This committee has little or no activities http://elot.gr/tc46sc2 [TID] Tags for Identifying Languages Editors, A. Phillips, M. Davis. http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt Work in progress 7. Author Address Manuel Tomas CARRASCO BENITEZ European Commission Jean Monnet Building L-2920 Luxembourg Telephone: +352 4301 36943 Email: lanco@dragoman.org 8. Disclaimer Though the intention is of a feedback to LTRU, this document has not been endorsed by LTRU. This document represents the view of the author. It does not necessarily represent the views of any other parties. 9. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. Carrasco Expires 1 October 2005 [Page 4] Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 11:51:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17570; Wed, 30 Mar 2005 11:51:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgWm-00054Q-1m; Wed, 30 Mar 2005 11:58:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgOU-000402-QF; Wed, 30 Mar 2005 11:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgOS-0003zu-Gi for ltru@megatron.ietf.org; Wed, 30 Mar 2005 11:50:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17427 for ; Wed, 30 Mar 2005 11:50:10 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgVO-00051A-Ek for ltru@ietf.org; Wed, 30 Mar 2005 11:57:23 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 08:50:22 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 30 Mar 2005 08:50:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: DD, YD, and YU (was: Question) Date: Wed, 30 Mar 2005 08:50:22 -0800 Message-ID: Thread-Topic: [Ltru] Re: DD, YD, and YU (was: Question) Thread-Index: AcU08Ipa32f60in3SOGtqFWiuuNZUgAVt1+Q From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 30 Mar 2005 16:50:24.0545 (UTC) FILETIME=[9187F110:01C53548] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Doug Ewell > The main value of allowing 'DD' as well as 'DE' is that tags in 'DD' > were allowed under RFC 1766. Yes, I know that means we have a code for > present-day Germany and a code for the former East Germany, but no code > for the former West Germany. I don't see that as a significant gap in > tagging flexibility. What does everyone else think? I just started thinking about how country mergers and splits affect language tags, and quickly realized this can be somewhat tricky. It's more complicated than if two entries in ISO 639-3 get merged, for instance.=20 For instance, in a merger, factors include: - If countries AA and BB join, is the code for the new entity one of AA or BB, or is it rather something distinct, CC? - Were there real differences between AA and BB wrt a given language, or were users simply blindly applying tags of the form ll-CC since they could and were under the impression that that's the preferred form? - If there were real differences before, do they disappear after the merger? (This might possibly happen, for instance if the differences are spelling.) No time to elaborate any further at the moment. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 12:14:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19966; Wed, 30 Mar 2005 12:14:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgsY-0005iR-TZ; Wed, 30 Mar 2005 12:21:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgkS-0007Xf-Op; Wed, 30 Mar 2005 12:12:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgkQ-0007XU-Ta for ltru@megatron.ietf.org; Wed, 30 Mar 2005 12:12:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19858 for ; Wed, 30 Mar 2005 12:12:52 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgrM-0005fw-Of for ltru@ietf.org; Wed, 30 Mar 2005 12:20:06 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 09:12:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry in record-jar format Date: Wed, 30 Mar 2005 09:12:31 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD1761D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU07pSpl76IulnWTq+JhHNasYyZ2wAXH9rg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 30 Mar 2005 17:12:32.0691 (UTC) FILETIME=[A92AF030:01C5354B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1632396289==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 --===============1632396289== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJZiB5b3UncmUgdGhpbmtpbmcgYWJvdXQgcmVnaXN0ZXJpbmcgbmV3IHN1YnRhZ3MgdG8gcmVw bGFjZSB0aGVzZSwNCj4gcmVtZW1iZXI6ICBHcmFuZGZhdGhlcmVkIHRhZ3MgYXJlIGZvcmV2ZXIu ICBUaGV5IGRvbid0IGRyb3Agb2ZmIHRoZQ0KPiByZWdpc3RyeSBqdXN0IGJlY2F1c2UgdGhleSd2 ZSBiZWVuIGRlcHJlY2F0ZWQuICBBbGwgdGhhdCBkb2VzIGlzIGNyZWF0ZQ0KPiBhIGR1cGxpY2F0 ZSB0YWcgd2l0aCB0aGUgc2FtZSBtZWFuaW5nLCB3aGljaCBpcyBub3QgYSBkZXNpcmFibGUgdGhp bmcgaW4NCj4gYW5kIG9mIGl0c2VsZi4NCg0KSSB3b3VsZCBhZGQgdGhhdCB0aGVyZSBpc24ndCBh IHJlcXVpcmVtZW50IHRoYXQgZXZlcnkgZ3JhbmRmYXRoZXJlZCB0YWcgc3RhcnQgbGlmZSBhcyBh IGRlcHJlY2F0ZWQgdGFnLiBSZWdpc3RlcmluZyBhIG5ldyB2YXJpYW50IHN1YnRhZyB0byByZXBs YWNlIChmb3IgZXhhbXBsZSkgZW4tR0Itb2VkIHdvdWxkIHByb3ZpZGUgYSB3YXkgb2YgcmVmZXJl bmNpbmcgdGhhdCBwYXJ0aWN1bGFyIG9ydGhvZ3JhcGhpYyBkaXN0aW5jdGlvbiAoT0VEIHByZWZl cnJlZCBzcGVsbGluZ3Mgb2YgRW5nbGlzaCkgZm9yIHVzZSB3aXRoIHRoZSBnZW5lcmF0aXZlIG1l Y2hhbmlzbSBvciBpbiBjb21iaW5hdGlvbiB3aXRoIG90aGVyIHZhcmlhdGlvbnMgb3IgZXh0ZW5z aW9ucy4NCg0KQnV0IHRoZXJlIGlzbid0IGEgcmVxdWlyZW1lbnQgdGhhdCB0aGlzIGJlIGRvbmUg YW5kIHRoZSB0YWcgImVuLUdCLW9lZCIgd2lsbCBzdGlsbCBiZSB2YWxpZCBmb3IgcmVwcmVzZW50 aW5nIHN1Y2ggY29udGVudC4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9i YWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRp b25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlz IG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFp bHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdl bGwNCj4gU2VudDogbWFyZGkgMjkgbWFycyAyMDA1IDIyOjAwDQo+IFRvOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogW0x0cnVdIFJlOiBSZWdpc3RyeSBpbiByZWNvcmQtamFyIGZvcm1h dA0KPiANCj4gRnJhbmsgRWxsZXJtYW5uIDxub2JvZHkgYXQgeHl6enkgZG90IGNsYXJhbmV0IGRv dCBkZT4gd3JvdGU6DQo+IA0KPiA+IFRoZSBJQU5BL2Fzc2lnbm1lbnRzL2xhbmctdGFncy8gV2Vi IHBhZ2UgZG9lc24ndCBsaXN0IGJzLUxhdG4uDQo+ID4gVGhlIG1vc3QgcmVjZW50IElBTkEgdGFn IGlzIHN0aWxsIGVuLUdCLW9lZCAoMjAwMy0wNy0wOSkuDQo+IA0KPiBUaGF0J3MgdGhlIHByb2Js ZW0uICBOaW5lIHRhZ3MgKmhhdmUqIGJlZW4gcmVnaXN0ZXJlZCBzaW5jZSB0aGVuLCBidXQNCj4g dGhleSdyZSBzdGlsbCBub3QgbGlzdGVkIG9uIHRoZSBJQU5BIHBhZ2UuDQo+IA0KPiA+IEJUVywg c2hvdWxkIHdlIGRlcHJlY2F0ZSBlbi1HQi1vZWQgYW5kIHpoLW1pbi1uYW4gPw0KPiANCj4gV2h5 IHdvdWxkIHdlIHdhbnQgdG8gZG8gdGhhdD8NCj4gDQo+IElmIHlvdSdyZSB0aGlua2luZyBhYm91 dCByZWdpc3RlcmluZyBuZXcgc3VidGFncyB0byByZXBsYWNlIHRoZXNlLA0KPiByZW1lbWJlcjog IEdyYW5kZmF0aGVyZWQgdGFncyBhcmUgZm9yZXZlci4gIFRoZXkgZG9uJ3QgZHJvcCBvZmYgdGhl DQo+IHJlZ2lzdHJ5IGp1c3QgYmVjYXVzZSB0aGV5J3ZlIGJlZW4gZGVwcmVjYXRlZC4gIEFsbCB0 aGF0IGRvZXMgaXMgY3JlYXRlDQo+IGEgZHVwbGljYXRlIHRhZyB3aXRoIHRoZSBzYW1lIG1lYW5p bmcsIHdoaWNoIGlzIG5vdCBhIGRlc2lyYWJsZSB0aGluZyBpbg0KPiBhbmQgb2YgaXRzZWxmLg0K PiANCj4gPiBBbmQgLyBvciBsaXN0IHRoZSBmZXcgZ3JhbmRmYXRoZXJlZCBleGNlcHRpb25zIGZy b20gdGhlIG5ldyBnZW5lcmFsDQo+ID4gcGF0dGVybiBkaXJlY3RseSBpbiB0aGUgQUJORiA/DQo+ IA0KPiBObywgZm9yIGV4YWN0bHkgdGhlIHJlYXNvbnMgQWRkaXNvbiBtZW50aW9uZWQuDQo+IA0K PiAtRG91ZyBFd2VsbA0KPiAgRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ICBodHRwOi8vdXNlcnMu YWRlbHBoaWEubmV0L35kZXdlbGwvDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVA bGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHRydQ0KDQo= --===============1632396289== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1632396289==-- From ltru-bounces@ietf.org Wed Mar 30 12:14:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20035; Wed, 30 Mar 2005 12:14:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgsp-0005ji-FR; Wed, 30 Mar 2005 12:21:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgle-0007yf-K1; Wed, 30 Mar 2005 12:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGglc-0007vr-Uw for ltru@megatron.ietf.org; Wed, 30 Mar 2005 12:14:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19985 for ; Wed, 30 Mar 2005 12:14:06 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgsZ-0005iA-42 for ltru@ietf.org; Wed, 30 Mar 2005 12:21:20 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 09:13:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: DD, YD, and YU (was: Question) Date: Wed, 30 Mar 2005 09:13:57 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD1761E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: DD, YD, and YU (was: Question) Thread-Index: AcU09+6iDU5Loxf3Scuo9y3RaXSAVAAU+f/g From: "Addison Phillips" To: "John Cowan" , "Doug Ewell" X-OriginalArrivalTime: 30 Mar 2005 17:13:58.0595 (UTC) FILETIME=[DC5ED930:01C5354B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable +1 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: mardi 29 mars 2005 23:12 > To: Doug Ewell > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: DD, YD, and YU (was: Question) >=20 > Doug Ewell scripsit: >=20 > > So could the others. Look, we've already agreed (I think) that the > > codes withdrawn before 1988 can be removed without sacrificing > > compatibility. That's 15 of the 24 withdrawn codes, or 62%. I = think we > > should move on. >=20 > +1 >=20 > > The main value of allowing 'DD' as well as 'DE' is that tags in 'DD' > > were allowed under RFC 1766. Yes, I know that means we have a code = for > > present-day Germany and a code for the former East Germany, but no = code > > for the former West Germany. I don't see that as a significant gap = in > > tagging flexibility. What does everyone else think? >=20 > +1 >=20 > -- > It was dreary and wearisome. Cold clammy winter still held way in = this > forsaken country. The only green was the scum of livid weed on the = dark > greasy surfaces of the sullen waters. Dead grasses and rotting reeds > loomed > up in the mists like ragged shadows of long-forgotten summers. > --"The Passage of the Marshes" = http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 12:19:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20313; Wed, 30 Mar 2005 12:19:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgxZ-0005oT-MQ; Wed, 30 Mar 2005 12:26:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgpb-0001A7-Ja; Wed, 30 Mar 2005 12:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgpZ-0001A2-6T for ltru@megatron.ietf.org; Wed, 30 Mar 2005 12:18:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20256 for ; Wed, 30 Mar 2005 12:18:10 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgwV-0005nb-D7 for ltru@ietf.org; Wed, 30 Mar 2005 12:25:24 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 09:18:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] zh-min-nan and en-GB-oed (was: Registry in record-jarformat) Date: Wed, 30 Mar 2005 09:18:02 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17624@irvmbxw01.quest.com> Thread-Topic: [Ltru] zh-min-nan and en-GB-oed (was: Registry in record-jarformat) Thread-Index: AcU0+pZ6QVEMYFquS52GITObYnZyDwAUVUaw From: "Addison Phillips" To: "John Cowan" , "Frank Ellermann" X-OriginalArrivalTime: 30 Mar 2005 17:18:03.0031 (UTC) FILETIME=[6E10D270:01C5354C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable art-lojban is deprecated in favor of 'jbo'. Changes in draft-00 make it = a grandfathered entry (it was formerly redundant) to prevent creating = the variant subtag 'lojban'. This also applies in various ways to some of the = well-formed-but-not-valid values (no-nyn, for example). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: mardi 29 mars 2005 23:32 > To: Frank Ellermann > Cc: ltru@ietf.org > Subject: Re: [Ltru] zh-min-nan and en-GB-oed (was: Registry in record- > jarformat) >=20 > Frank Ellermann scripsit: >=20 > > They don't follow the normal lang + extlang + variant or > > lang + region + variant patterns. But if the parser isn't > > broken it should find that these _must_ be grandfathered > > tags, sorry, please ignore my stupid question. >=20 > This brings up an interesting point: >=20 > Of the 25 current grandfathered tags in the registry: >=20 > 18 are not well-formed (en-gb-oed, i-*, sgn-*-*, zh-min-nan). >=20 > 6 are of the reserved xx-yyy form: > 3 (zh-gan, zh-wuu, zh-yue) will be well-formed and valid > in 3066ter; > 3 (zh-min, no-bok, no-nyn) will be well-formed but not > valid in 3066ter. >=20 > 1 is well-formed already (art-lojban) but appears to make > "lojban" a variant, which it is not. >=20 > -- > John Cowan jcowan@reutershealth.com www.reutershealth.com > www.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 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 12:35:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21511; Wed, 30 Mar 2005 12:35:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhDD-00068j-JZ; Wed, 30 Mar 2005 12:42:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGh4p-00045V-Q2; Wed, 30 Mar 2005 12:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGh4o-00043j-Vu for ltru@megatron.ietf.org; Wed, 30 Mar 2005 12:33:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21348 for ; Wed, 30 Mar 2005 12:33:56 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhBl-00066X-7D for ltru@ietf.org; Wed, 30 Mar 2005 12:41:10 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2UHXhY4006273; Wed, 30 Mar 2005 12:33:43 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 30 Mar 2005 12:33:47 -0500 Date: Wed, 30 Mar 2005 12:33:47 -0500 From: John Cowan To: Peter Constable Subject: Re: [Ltru] Re: DD, YD, and YU (was: Question) Message-ID: <20050330173347.GR13803@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Peter Constable scripsit: > - If countries AA and BB join, is the code for the new entity one of AA > or BB, or is it rather something distinct, CC? That would tend to depend on whether the new entity adopted a distinct name. AFAIK the last time that happened was in 1958, when Egypt and Syria merged to form the United Arab Republic; the union dissolved in 1961, although Egypt retained the name until 1971. > - Were there real differences between AA and BB wrt a given language, or > were users simply blindly applying tags of the form ll-CC since they > could and were under the impression that that's the preferred form? > > - If there were real differences before, do they disappear after the > merger? (This might possibly happen, for instance if the differences are > spelling.) It doesn't much matter from the POV of standardizers, since whatever was valid before is still valid, so ll-AA and ll-BB tags would still be so. Language-taggers would have to make their own decisions. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 12:47:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22696; Wed, 30 Mar 2005 12:47:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhPL-0006Ow-Ne; Wed, 30 Mar 2005 12:55:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhHz-0005uH-1G; Wed, 30 Mar 2005 12:47:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhHx-0005u4-KR for ltru@megatron.ietf.org; Wed, 30 Mar 2005 12:47:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22645 for ; Wed, 30 Mar 2005 12:47:31 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhOt-0006Nq-Tn for ltru@ietf.org; Wed, 30 Mar 2005 12:54:45 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2UHlGhP006318; Wed, 30 Mar 2005 12:47:19 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 30 Mar 2005 12:46:39 -0500 Date: Wed, 30 Mar 2005 12:46:39 -0500 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] zh-min-nan and en-GB-oed (was: Registry in record-jarformat) Message-ID: <20050330174639.GS13803@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AD17624@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AD17624@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Addison Phillips scripsit: > art-lojban is deprecated in favor of 'jbo'. Changes in draft-00 make it > a grandfathered entry (it was formerly redundant) to prevent creating > the variant subtag 'lojban'. Nobody knows that better than I; my name's on the registration requests for both "art-lojban" and "jbo", not surprisingly. > This also applies in various ways to some of the > well-formed-but-not-valid values (no-nyn, for example). Sure. I was just interested in exploring how many of the grandfathered tags were recognizable as such by their syntax alone (per Frank's remarks). In particular, is it a feasible strategy for RFC 3066bis parsers to recognize grandfathered tags only after attempting to parse the tag, in order not to expend cycles on tests for grandfathered tags that will almost always fail? Answer: almost. /me goes back in time and kicks himself for registering art-lojban. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 13:02:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24219; Wed, 30 Mar 2005 13:02:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhd2-0006oE-3Y; Wed, 30 Mar 2005 13:09:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhVW-0000kX-Ns; Wed, 30 Mar 2005 13:01:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhVV-0000kP-6X for ltru@megatron.ietf.org; Wed, 30 Mar 2005 13:01:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24199 for ; Wed, 30 Mar 2005 13:01:30 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhcR-0006ne-KX for ltru@ietf.org; Wed, 30 Mar 2005 13:08:45 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 30 Mar 2005 10:01:47 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 30 Mar 2005 10:01:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Proposed changes to region subtags Date: Wed, 30 Mar 2005 10:01:22 -0800 Message-ID: Thread-Topic: [Ltru] Proposed changes to region subtags Thread-Index: AcU09Mg1olxHwYC7QyCGvJaI+aw60AAXZqVQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 30 Mar 2005 18:01:20.0912 (UTC) FILETIME=[7A860100:01C53552] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > I propose the following changes to the region subtags... Looks good to me. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 16:37:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28086; Wed, 30 Mar 2005 16:37:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkzL-00088T-DB; Wed, 30 Mar 2005 16:44:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGks8-00042U-4v; Wed, 30 Mar 2005 16:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGks6-00040j-P3 for ltru@megatron.ietf.org; Wed, 30 Mar 2005 16:37:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27948 for ; Wed, 30 Mar 2005 16:37:04 -0500 (EST) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkz1-00084o-Vx for ltru@ietf.org; Wed, 30 Mar 2005 16:44:20 -0500 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN3-4424b1beb395; Wed, 30 Mar 2005 16:36:44 -0500 Received: from DEBHOME (ACCAA018.ipt.aol.com [172.202.160.24]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2ULaVro025954; Wed, 30 Mar 2005 16:36:32 -0500 Message-Id: <200503302136.j2ULaVro025954@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'John Cowan'" , "'Peter Constable'" Subject: RE: [Ltru] Re: DD, YD, and YU (was: Question) Date: Wed, 30 Mar 2005 22:36:46 +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: AcU1Tsw5n+uljhYASMeoidE79Yp50AAIGImA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050330173347.GR13803@skunk.reutershealth.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "'LTRU Working Group'" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.7 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit John Cowan wrote: >It doesn't much matter from the POV of standardizers, since whatever was >valid before is still valid, so ll-AA and ll-BB tags would still be so. Agreed >Language-taggers would have to make their own decisions. Surely, if there are two options for tagging it is not standardised, it would have to be distinct... as the merger creates new meaning and that meaning is neither ll-AA or ll-BB, as was previously known, ll-CC should be created and ll-AA and ll-BB deprecated (if this means what I think it means, as in, stays in registry for backward compatibility) but with a recommendation not to use) or at least if not deprecated, annotated. Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of John Cowan Sent: 30 March 2005 18:34 To: Peter Constable Cc: LTRU Working Group Subject: Re: [Ltru] Re: DD, YD, and YU (was: Question) Peter Constable scripsit: > - If countries AA and BB join, is the code for the new entity one of AA > or BB, or is it rather something distinct, CC? That would tend to depend on whether the new entity adopted a distinct name. AFAIK the last time that happened was in 1958, when Egypt and Syria merged to form the United Arab Republic; the union dissolved in 1961, although Egypt retained the name until 1971. > - Were there real differences between AA and BB wrt a given language, or > were users simply blindly applying tags of the form ll-CC since they > could and were under the impression that that's the preferred form? > > - If there were real differences before, do they disappear after the > merger? (This might possibly happen, for instance if the differences are > spelling.) It doesn't much matter from the POV of standardizers, since whatever was valid before is still valid, so ll-AA and ll-BB tags would still be so. Language-taggers would have to make their own decisions. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 16:57:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00781; Wed, 30 Mar 2005 16:57:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGlIc-0000Qh-Hn; Wed, 30 Mar 2005 17:04:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGlBQ-0005gi-J6; Wed, 30 Mar 2005 16:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGlBO-0005gd-DW for ltru@megatron.ietf.org; Wed, 30 Mar 2005 16:57:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00753 for ; Wed, 30 Mar 2005 16:56:58 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGlIL-0000Q3-41 for ltru@ietf.org; Wed, 30 Mar 2005 17:04:14 -0500 Received: from lns-p19-19-idf-82-254-253-201.adsl.proxad.net ([82.254.253.201] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DGlBG-0004U8-0U; Wed, 30 Mar 2005 13:56:54 -0800 Message-Id: <6.1.2.0.2.20050330234829.04156c80@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 30 Mar 2005 23:50:46 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Shelf life of data In-Reply-To: <003d01c534d2$c5edce00$030aa8c0@DEWELL> References: <634978A7DF025A40BFEF33EB191E13BC0AC2A1CB@irvmbxw01.quest.com> <6.1.2.0.2.20050328174831.03778c00@mail.jefsey.com> <00ac01c5340e$8697a9c0$030aa8c0@DEWELL> <6.1.2.0.2.20050329095430.047d6a80@mail.jefsey.com> <002501c5347c$b6c3c700$030aa8c0@DEWELL> <6.1.2.0.2.20050329190657.0393f170@mail.jefsey.com> <003d01c534d2$c5edce00$030aa8c0@DEWELL> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 04:47 30/03/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > >> We're not trying to maintain compatibility with every country coding > >> system ever invented, just the one used for language tags. > > > > The ultimate target is to facilitare the exchange of goods and services > > through the elimination of technical barriers to trade and to foster > > the human cultural development through a multingual internet, > > something the IETF has never been good at - due to the Internet > > default parameters logic I documented, and IAB demonstrated by the > > choice of its priorities in RFC 3869. This is the reason why we need > > the support from other experiences and motivation by new demands from > > NGN and WSIS. If ISO is not enough, any other adequate subtag source > > is to be supported. > >You're reading a different charter from the one I'm reading, that's for >sure. ??? I only read the Charter, the RFC, ISO and WSIS. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 30 20:31:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19958; Wed, 30 Mar 2005 20:31:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGode-0004uY-U2; Wed, 30 Mar 2005 20:38:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGoVg-0004yu-4p; Wed, 30 Mar 2005 20:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGoVe-0004ym-4N for ltru@megatron.ietf.org; Wed, 30 Mar 2005 20:30:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19943 for ; Wed, 30 Mar 2005 20:30:09 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGoce-0004tu-N4 for ltru@ietf.org; Wed, 30 Mar 2005 20:37:26 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 30 Mar 2005 17:30:42 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 30 Mar 2005 17:30:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: DD, YD, and YU (was: Question) Date: Wed, 30 Mar 2005 17:29:58 -0800 Message-ID: Thread-Topic: [Ltru] Re: DD, YD, and YU (was: Question) Thread-Index: AcU1TrRIJN3sBoW6TRm7uCtgCM90qwAQD0IQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Mar 2005 01:30:04.0738 (UTC) FILETIME=[2A5FD220:01C53591] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:jcowan@reutershealth.com] > > - If there were real differences before, do they disappear after the > > merger? (This might possibly happen, for instance if the differences are > > spelling.) >=20 > It doesn't much matter from the POV of standardizers, since whatever was > valid before is still valid, so ll-AA and ll-BB tags would still be so. > Language-taggers would have to make their own decisions. They'd still be valid, but the semantics might have changed. Suppose AA and BB merge, and the new entity has an ID of AA. But suppose there continue to be dialect differences. For existing content, ll-AA means dialect A of ll; on new content, though, ll-AA means dialects A or B. Peter _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 00:14:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09306; Thu, 31 Mar 2005 00:14:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGs7V-000121-Ge; Thu, 31 Mar 2005 00:21:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGrz7-0006yt-QW; Thu, 31 Mar 2005 00:12:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGrz1-0006yk-Ca for ltru@megatron.ietf.org; Thu, 31 Mar 2005 00:12:47 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09176 for ; Thu, 31 Mar 2005 00:12:39 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DGrxk-0008SC-E5 for ltru@lists.ietf.org; Thu, 31 Mar 2005 07:11:24 +0200 Received: from 212.82.251.39 ([212.82.251.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Mar 2005 07:11:24 +0200 Received: from nobody by 212.82.251.39 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Mar 2005 07:11:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 31 Mar 2005 07:11:34 +0200 Organization: Lines: 23 Message-ID: <424B8686.1A87@xyzzy.claranet.de> References: <20050330164932.43932.qmail@web42004.mail.yahoo.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.39 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit M.T. Carrasco Benitez wrote: > I am sending this today to the editor. Interesting, if I get it right you want LTRU to use a scheme which allows the later addition of transliterations. You identify five relevant parts: 1: source language, 2: source script, 3: target laguage(s), 3: target script, 5: (registered) transliteration scheme. Two of these parts could be irrelevant, the source script, and target language(s) if they are implied by the scheme. This would fit into a lang + script + variant pattern, if you consider a "registered transliteration scheme" as some kind of "registered variant". Is that good enough for your purposes, and do you want it as an example for "variants" in the registry draft ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 04:41:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26786; Thu, 31 Mar 2005 04:41:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGwIh-00071T-CJ; Thu, 31 Mar 2005 04:49:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGw9v-0007Yy-OE; Thu, 31 Mar 2005 04:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGw7K-00076A-93 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 04:37:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26313 for ; Thu, 31 Mar 2005 04:37:32 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGwEO-0006tz-T8 for ltru@ietf.org; Thu, 31 Mar 2005 04:44:54 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 01:37:23 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 31 Mar 2005 01:38:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Language transformation Date: Thu, 31 Mar 2005 01:37:31 -0800 Message-ID: Thread-Topic: [Ltru] Language transformation Thread-Index: AcU1SLK4IYQ5/dBJQQWzhl3PbZnjbAAha1NA From: "Peter Constable" To: X-OriginalArrivalTime: 31 Mar 2005 09:38:23.0544 (UTC) FILETIME=[61D2D380:01C535D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of M.T. Carrasco Benitez Some comments: You have called this "language transformation".=20 > Language transformation means that a language is expressed in another > way (e.g., in another alphabet) for people familiar with the target > alphabet and language... > Transliteration tries to transform scripts. Transcription tries to > transform sounds.=20 I agree that transliteration is a transformation, because there is a source script that is distinct from the target script. But transliteration involves only one written form, and so is no more a transformation than a standard orthographic form, which is not generally referred to as transformation. I have for some time assumed that it should be possible to accommodate tags for transcriptions within a successor to RFC 3066, with requiring any special new apparatus. If Azeri in Cyrillic and Azeri in Latin are two written representations of Azeri language, then Azeri in IPA or Azeri in some form of shorthand are just two more written representations. If RFC3066bis can handle the former, then handling the latter is a matter only of having the relevant subtags. If my assumption is correct, then transcriptions should be readily handled in RFC3066bis with only a need for some new "script" and variant subtags. Transliteration is slightly more involved, however, and needs additional consideration.=20 You rightly note that transliterations are often tailored to suit speakers of a particular language, and can be done in more than one way for a given target audience. So, whereas if we had a "script" ID for IPA (for sake of discussion, suppose it's Lipa), then Greek in IPA transcription could be tagged as "el-Lipa", but for transliteration into Latin (say) it's not enough to use "el-Latn" since different schemes might exist for a French audience vs. a Spanish audience, and there might be more than one scheme intended for speakers of a given language. There's also the matter of tagging processing resources versus tagging content. Not only do we want to tag content, but we also want to tag processing resources such as spelling checkers. So, an "en-US" spelling checker is one intended for "en-US" content. Consider a given transliteration scheme for some language: the concept of a spelling checker for transliterated content is certainly feasible, and a tag for the content would be the same as the tag for the spelling checker. Now, consider a transliteration processor: if the scheme is specific to a particular source language, then the same tag can be used for the process as for resulting content. But, not all transliteration schemes are specific to a given source language. In that case, a tag for the process would have a different form since it wouldn't have to begin with a language subtag! > To tag a transformed language one needs the following: >=20 > - Transformation indicator > - Source language > - Transformation scheme >=20 > Example: >=20 > tran-zh-wadegiles ... > Indeed, the transformation > token does not need to be present and it could be implied. For > example; >=20 > zh-wadegiles It's not clear to me that a "transformation indicator" would ever be necessary. (BTW, I'm not a Sinologist, so don't know, but am curious: is Wade-Giles a transcription/orthographic convention or a transliteration scheme?) > 4. Registries >=20 > Two registries are need: >=20 > - IANA > - Schemes for Language Transformation There's validity to this idea. If schemes are well known, or well documented somewhere, then they don't really need to be defined in a registry. It seems likely that there might be schemes that are not well known and for which documentation is not readily available, however, and a registry might well serve a useful purpose in such cases. (This might even be a sensible project for ISO TC 46, though so far their interest in transliteration schemes appears to be limited to a proscriptive approach of defining particular schemes that conform to their requirements.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 09:51:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28131; Thu, 31 Mar 2005 09:51:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH182-00016A-IY; Thu, 31 Mar 2005 09:58:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH0zr-0000bS-QC; Thu, 31 Mar 2005 09:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH0zq-0000bG-UO for ltru@megatron.ietf.org; Thu, 31 Mar 2005 09:50:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28072 for ; Thu, 31 Mar 2005 09:50:09 -0500 (EST) Received: from web42004.mail.yahoo.com ([66.218.93.172]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH16x-00011q-Rb for ltru@ietf.org; Thu, 31 Mar 2005 09:57:33 -0500 Received: (qmail 66077 invoked by uid 60001); 31 Mar 2005 14:49:59 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=jP1m+tjq0Q7GR0cU8riryCJ+EpGcD4d3Tg7f022FeRO4TW2FSuQvp3P6PsnAPzcWyzbTwYALr8JwbvhFfoQsAXBpHQE5fZ3M3UgiBg3rS/dlCO670x2Afpj6McVIZiqS2YzrscYZ3KqOP0kBUH8O0FlbsryNPSYAk8vhNzzzSUc= ; Message-ID: <20050331144959.66075.qmail@web42004.mail.yahoo.com> Received: from [158.169.9.14] by web42004.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 15:49:59 BST Date: Thu, 31 Mar 2005 15:49:59 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit > [Ellermann] > Interesting, if I get it right you want LTRU to use a scheme > which allows the later addition of transliterations. You > identify five relevant parts: > > 1: source language, 2: source script, 3: target laguage(s), > 3: target script, 5: (registered) transliteration scheme. For the "Schemes for Language Transformation", there could be more than five. I will later submit a full record. This does not need to be hosted by LTRU (IANA). > Two of these parts could be irrelevant, the source script, > and target language(s) if they are implied by the scheme. LTRU must be concerned only by the "transformation identifier". For example, "widegiles". Any new type would be needed. For example: # Transformations transformation | widegiles | | yyyy-mm-dd | | transformation | pinyin| | yyyy-mm-dd | | > This would fit into a lang + script + variant pattern, if > you consider a "registered transliteration scheme" as some > kind of "registered variant". No. See above. The transformation identifer carries the information regarding the target script. > Is that good enough for your purposes, and do you want it > as an example for "variants" in the registry draft ? See above. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 10:54:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05961; Thu, 31 Mar 2005 10:54:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH272-0003ml-GB; Thu, 31 Mar 2005 11:01:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH1zZ-0006YD-It; Thu, 31 Mar 2005 10:53:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH1zX-0006Y5-N0 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 10:53:55 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05936 for ; Thu, 31 Mar 2005 10:53:53 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050331155324.QHFF7277.mta10.adelphia.net@DEWELL> for ; Thu, 31 Mar 2005 10:53:24 -0500 Message-ID: <004b01c53609$b5d0e920$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050330165046.TVVC4900.mta8.adelphia.net@megatron.ietf.org> Date: Thu, 31 Mar 2005 07:52:57 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> I propose the following changes to the region subtags. > > Seconded. We can discuss the finer points of "losing" regions > by unions or splits (if a new region inherits an old CC) later. Last Call for the registry draft is scheduled for May, and it's almost April already. I think we need to figure out the rules now, rather than saving things for an unspecified "later." >> 200 (Czechoslovakia) on the basis that including it is >> inconsistent with other principles > > Yes, that's one of these finer points, at the moment it's OUT, > but maybe we invent a proper rule to add it again later. See "later" above. Can you think of a use case for 200? It's not needed for current tagging needs, nor for backward compatibility. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 10:59:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06220; Thu, 31 Mar 2005 10:59:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2Bu-0003xU-UB; Thu, 31 Mar 2005 11:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH22p-0007O9-On; Thu, 31 Mar 2005 10:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH22o-0007O3-FD for ltru@megatron.ietf.org; Thu, 31 Mar 2005 10:57:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06122 for ; Thu, 31 Mar 2005 10:57:16 -0500 (EST) Received: from web42001.mail.yahoo.com ([66.218.93.169]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH29x-0003pH-4h for ltru@ietf.org; Thu, 31 Mar 2005 11:04:41 -0500 Received: (qmail 61774 invoked by uid 60001); 31 Mar 2005 15:57:08 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=XLdSeKLkKIJvwEI7TUh8LKXP5NtFO4pJESD8T2n3A5NyPLfItPXg9hxdBn8hxEm4sXZfz9hXFVr/EnsXFv4x0KUZPtgSrky/3cAE5jOGO2h09qqgQm7iFnfZl8wO1krEPeClTrrnd9DfGVr1hrHu5zihBotmK8Ot8ll7wIg1ciw= ; Message-ID: <20050331155708.61772.qmail@web42001.mail.yahoo.com> Received: from [158.169.9.14] by web42001.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 16:57:08 BST Date: Thu, 31 Mar 2005 16:57:08 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Language transformation To: ltru@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA06122 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable > [Constable] > Some comments: >=20 > You have called this "language transformation".=20 >=20 > > Language transformation means that a language is expressed in another > > way (e.g., in another alphabet) for people familiar with the target > > alphabet and language... >=20 > > Transliteration tries to transform scripts. Transcription tries to > > transform sounds.=20 >=20 > I agree that transliteration is a transformation, because there is a > source script that is distinct from the target script. But > transliteration involves only one written form, and so is no more a > transformation than a standard orthographic form, which is not generall= y > referred to as transformation. We could use another term; for example, "conversion" as used by the TC46/= SC2. I do not recommend to use either the terms "transliteration" or "transcri= ption" as we risk to start a polemy. > I have for some time assumed that it should be possible to accommodate > tags for transcriptions within a successor to RFC 3066, with requiring > any special new apparatus. As long as I am aware, it is not possible. The original Internet-Draft is from 1998 and Alvestrand was involved in the discusison. Have a look to: http://lists.w3.org/Archives/Public/www-international/1998OctDec/0002.htm= l > If Azeri in Cyrillic and Azeri in Latin are > two written representations of Azeri language, then Azeri in IPA or > Azeri in some form of shorthand are just two more written > representations. If RFC3066bis can handle the former, then handling the > latter is a matter only of having the relevant subtags. Azeri is probably a worse case example. In less than a century it has use= d the Arabic, Cyrillic and Latin alphabets. These changes were supposed to = be "permanent". Transformation does not addresses permanent changes, like Az= eri or Turkish (changed in 1928). This should be addressed with other existin= g mechanisms in LTRU. Transformation addresses expression "non-native" to the language. For exa= mple, Armenian transformed (or transliterated) into the Latin script. By the way, Armenians are celebrating this year the 1600th anniversary of= their script. It would be nice to go to the "Targmanchats Ton" (translators day= ).=20 This is a case of very successful standardisation: would LTRU be here in 1600 years ? -:) > If my assumption is correct, then transcriptions should be readily > handled in RFC3066bis with only a need for some new "script" and varian= t > subtags. Transliteration is slightly more involved, however, and needs > additional consideration.=20 Yes. It has to be checked. But the script is not sufficient. Examples: Peking Beijing ΠΑΠΑΔΟΠΟΥ= ΛΟΣ PAPADOPOULOS PAPADOPULOS lang in pseudo-code. > You rightly note that transliterations are often tailored to suit > speakers of a particular language, and can be done in more than one way > for a given target audience. So, whereas if we had a "script" ID for IP= A > (for sake of discussion, suppose it's Lipa), then Greek in IPA > transcription could be tagged as "el-Lipa", but for transliteration int= o > Latin (say) it's not enough to use "el-Latn" since different schemes > might exist for a French audience vs. a Spanish audience, and there > might be more than one scheme intended for speakers of a given language. See above. > There's also the matter of tagging processing resources versus tagging > content. Not only do we want to tag content, but we also want to tag > processing resources such as spelling checkers. So, an "en-US" spelling > checker is one intended for "en-US" content. Consider a given > transliteration scheme for some language: the concept of a spelling > checker for transliterated content is certainly feasible, and a tag for > the content would be the same as the tag for the spelling checker. Now, > consider a transliteration processor: if the scheme is specific to a > particular source language, then the same tag can be used for the > process as for resulting content. But, not all transliteration schemes > are specific to a given source language. In that case, a tag for the > process would have a different form since it wouldn't have to begin wit= h > a language subtag! The intention is very much to tag for content. So if one want to implemen= t a spelling checker for "es-forSpanish", it has to follow this ortography. A transformation scheme "tranFoo" could be use by more that one source an= d target languages; particulaly when the source languages are similars and = the target languages are similar. For example, tranFoo could be used for transformation from the source languages Bulgarian or Russian to the targ= et languages Spanish and Italian. The proposed registry for "Schemes for Language Transformation" will contain this information. Hence, it should not be the business of AINA. Examples: Bulgarian transformed for Spanish and Italian: Blabla Russian transformed for Spanish and Italian: Bleble But note, "Blabla" is Bulgarian even after the transformation. Similar for the second example. >=20 >=20 > > To tag a transformed language one needs the following: > >=20 > > - Transformation indicator > > - Source language > > - Transformation scheme > >=20 > > Example: > >=20 > > tran-zh-wadegiles > ... >=20 > > Indeed, the transformation > > token does not need to be present and it could be implied. For > > example; > >=20 > > zh-wadegiles >=20 > It's not clear to me that a "transformation indicator" would ever be > necessary. I agree. Conceptually is there. But I would not like to see it as a token. =20 > (BTW, I'm not a Sinologist, so don't know, but am curious: is Wade-Gile= s > a transcription/orthographic convention or a transliteration scheme?) I am not a Sinologist, either. But even I am were one, I would not state if it is a transliteration or transcription. I learnt this the hard way: I am pretty certain that a non ending discussion will follow. >=20 > > 4. Registries > >=20 > > Two registries are need: > >=20 > > - IANA > > - Schemes for Language Transformation >=20 > There's validity to this idea. If schemes are well known, or well > documented somewhere, then they don't really need to be defined in a > registry. It seems likely that there might be schemes that are not well > known and for which documentation is not readily available, however, an= d > a registry might well serve a useful purpose in such cases. (This might > even be a sensible project for ISO TC 46, though so far their interest > in transliteration schemes appears to be limited to a proscriptive > approach of defining particular schemes that conform to their > requirements.) >=20 TC46/SC2 is defunct. I have done some preliminary work. And we should loo= k for an acceptable host. (Martin D=FCrst: do you think that we could do it in Unicode ?) Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.co= m=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 11:21:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08930; Thu, 31 Mar 2005 11:21:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2Xa-0004xo-E9; Thu, 31 Mar 2005 11:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2Pv-0004W4-Sw; Thu, 31 Mar 2005 11:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2Pu-0004Vz-9B for ltru@megatron.ietf.org; Thu, 31 Mar 2005 11:21:10 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08886 for ; Thu, 31 Mar 2005 11:21:08 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050331162031.NISH2192.mta9.adelphia.net@DEWELL> for ; Thu, 31 Mar 2005 11:20:31 -0500 Message-ID: <005201c5360d$6c77ea40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050330165046.TVVC4900.mta8.adelphia.net@megatron.ietf.org> Date: Thu, 31 Mar 2005 08:19:32 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit M.T. Carrasco Benitez wrote: > I am sending this today to the editor. It's sometimes considered helpful to discuss ideas on the list first, before going to the effort of writing a draft (or even adapting an existing one). > Transliteration tries to transform scripts. Transcription tries to > transform sounds. It is wise to avoid discussion on what is > transliteration or transcription: often transformation schemes are a > mixture of several approaches. Hence, this document uses the term > transformation. The most important distinction is that a transliteration must be unambiguously reversible. That said, it's true that non-professionals often use the terms interchangeably, and I don't see a problem with lumping them together for this discussion. > Hence, one needs a list of transformation schemes, each with one > unique identifier. The transformation identifier indicates the source > language(s), the source script, the target language(s) and the target > script. It's more than just target language; multiple transcription systems can exist for the same set of four variables (SL, SS, TL, TS). > The above is a pseudo-code. In particular, it is not a syntactic > proposition for LTRU. This should come later, assuming that LTRU want > to consider language transformations. Indeed, the transformation > token does not need to be present and it could be implied. For > example; > > zh-wadegiles I think this might make a good candidate for an extension RFC. It's not strictly an attribute of the language, but might be important for content storage and retrieval. For example, it might be valuable to specify whether "kr-Latn" text is romanized using McCune-Reischauer, Yale, or Revised Romanization, or whether "ru-Latn" is romanized using ISO 9, GOST, or some other language-dependent scheme (which is common for Russian). Extensions are described in detail at: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.html#extensions If this were approved, and assuming for the sake of argument that the singleton 't' were assigned, then the example in Section 2 of Tomas's draft could be coded as "zh-Latn-t-wadeg" or even just "zh-t-wadeg" (since the existence of a subtag for Wade-Giles implies the Latin script). Note that subtags must be 8 characters of less, so "wadegiles" would be too long. Transcription schemes that don't have a name, but are dependent on the target language (again, common for Russian), might be indicated with a 2-character subtag representing the target language. Thus "ru(-Latn)-t-de" would be a transcription of Russian intended for German readers, while "ru(-Latn)-t-fr" would be the same for French speakers. In that case, subtags that don't represent a target language would have to be 3 or more characters long. > Two registries are need: > > - IANA > - Schemes for Language Transformation > > IANA must be concerned only with scheme identifiers. In the example > above the string "wadegiles". If this were approved as an extension RFC, then that RFC -- not IANA -- would control the list of valid subtags. IANA would maintain a URL pointing to the current table. Obviously, none of this can happen until RFC 3066bis is published. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 11:38:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10334; Thu, 31 Mar 2005 11:38:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2ng-0005Zw-1K; Thu, 31 Mar 2005 11:45:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2fo-000848-Sn; Thu, 31 Mar 2005 11:37:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2fn-000840-Df for ltru@megatron.ietf.org; Thu, 31 Mar 2005 11:37:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10273 for ; Thu, 31 Mar 2005 11:37:33 -0500 (EST) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2mv-0005YL-Lq for ltru@ietf.org; Thu, 31 Mar 2005 11:44:59 -0500 Received: from korppi.cs.tut.fi (korppi.cs.tut.fi [130.230.4.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id A4415B50 for ; Thu, 31 Mar 2005 19:37:20 +0300 (EEST) Date: Thu, 31 Mar 2005 19:37:19 +0300 (EEST) From: "Jukka K. Korpela" To: LTRU Working Group Subject: Re: [Ltru] Re: 3166-1 state machine In-Reply-To: <008601c534f0$ab306c80$030aa8c0@DEWELL> Message-ID: References: <008601c534f0$ab306c80$030aa8c0@DEWELL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Tue, 29 Mar 2005, Doug Ewell wrote: > > For some time I thought that en-UK is correct... :-( Maybe I > > confuse it with a locale. Google claims to have 300,000 hits > > for "en-uk" (quoted), most of them probably irrelevant. > > That's not evidence of ccTLDs in language tags, that's just an error. > :-) Well, yes, it is an error, but a common one. Even the Dublin Core documents have contained it, e.g. http://dublincore.org/documents/1999/07/02/dces/ (the current version has it fixed to en-GB). The error is understandable, since the official name of the country is "United Kingdom" (long form: "United Kingdom of Great Britain and Northern Ireland"). Besides, the official European Union policy is to use "UK" as the country code (otherwise using ISO 3166 except for Greece). Is there a point after which erroneous usage becomes common enough to be taken so seriously that it be recognized? That would mean keeping "UK" as country code unassigned (reserved) and treating any use of "UK" as country code as an error in principle but with the error recovery that it is interpreted (perhaps with a warning) to mean 'United Kingdom'. Someone might say that this would mean virtually accepting "UK" as synonym for "GB" - and this might be regarded as a very bad move. But after all, metadata is about giving information about data, and if an author labels his data as, say, applying to country "UK" or being in language "en-UK", shouldn't we work by what we know he must have _meant_, instead of just blowing horns and sending error messages around? -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 11:56:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11444; Thu, 31 Mar 2005 11:56:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH34p-0006CW-P5; Thu, 31 Mar 2005 12:03:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2x4-0002vA-2Q; Thu, 31 Mar 2005 11:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2x2-0002v4-I4 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 11:55:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11417 for ; Thu, 31 Mar 2005 11:55:22 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH34C-0006Bg-2P for ltru@ietf.org; Thu, 31 Mar 2005 12:02:48 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 08:55:14 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 31 Mar 2005 08:56:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Language transformation Date: Thu, 31 Mar 2005 08:55:12 -0800 Message-ID: Thread-Topic: [Ltru] Language transformation Thread-Index: AcU2CqV54asBJiGCTGGVEK1ToYv6mAAA4XMw From: "Peter Constable" To: X-OriginalArrivalTime: 31 Mar 2005 16:56:30.0611 (UTC) FILETIME=[9622EE30:01C53612] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On Behalf Of M.T. > Carrasco Benitez > We could use another term; for example, "conversion" as used by the = TC46/SC2. > I do not recommend to use either the terms "transliteration" or = "transcription" > as we risk to start a polemy. I agree that "transliterations" are not as cut and dried as TC46 makes = them out to be. My only point was that there are many things that fall = in the category of "transcription" (clearly that and not = transliteration), such as IPA, that really aren't conversions or = transformations. =20 > > I have for some time assumed that it should be possible to = accommodate > > tags for transcriptions within a successor to RFC 3066, with = requiring > > any special new apparatus. >=20 > As long as I am aware, it is not possible. The original Internet-Draft = is > from 1998 and Alvestrand was involved in the discusison. Have a look = to: >=20 > = http://lists.w3.org/Archives/Public/www-international/1998OctDec/0002.htm= l Well, obviously I disagree with some of the opinions that were = expressed. I think very definitely there should be a way to tag content = to indicate both it's language variety and written form -- we've had = consensus for some time that RFC3066 tags should be able to distinguish = e.g. zh-Hans and zh-Hant. IMO, Chinese in phonetic transcription or in = Wade-Giles are just additional written forms. > Azeri is probably a worse case example. In less than a century it has = used > the Arabic, Cyrillic and Latin alphabets. These changes were supposed = to be > "permanent". Transformation does not addresses permanent changes, like = Azeri > or Turkish (changed in 1928). This should be addressed with other = existing > mechanisms in LTRU. >=20 > Transformation addresses expression "non-native" to the language. For = example, > Armenian transformed (or transliterated) into the Latin script. I don't think your distinction between "permanent changes" and = transformations is really relevant. (Note that someone might create a = written representation for something like Azeri intending it to be = permanent, but that doesn't mean it will be widely adopted, let alone = endure.) All we need to concern ourselves with is what it takes to = identify content in a given form, and to identify linguistic processing = resources. > > (BTW, I'm not a Sinologist, so don't know, but am curious: is = Wade-Giles > > a transcription/orthographic convention or a transliteration = scheme?) >=20 > I am not a Sinologist, either. But even I am were one, I would not = state > if it is a transliteration or transcription. I learnt this the hard = way: > I am pretty certain that a non ending discussion will follow. You're probably right, and it would be rather off topic. > TC46/SC2 is defunct.=20 I think you're right.=20 > I have done some preliminary work. And we should look > for an acceptable host. >=20 > (Martin D=FCrst: do you think that we could do it in Unicode ?) Martin's not the right one to be asking that; you should be addressing = the question to Mark Davis. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 12:10:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12708; Thu, 31 Mar 2005 12:10:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3JC-0006j2-CQ; Thu, 31 Mar 2005 12:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Aw-0004SM-Mz; Thu, 31 Mar 2005 12:09:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Av-0004Rw-T6 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:09:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12505 for ; Thu, 31 Mar 2005 12:09:43 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3I4-0006gj-PY for ltru@ietf.org; Thu, 31 Mar 2005 12:17:10 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 31 Mar 2005 09:09:39 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 31 Mar 2005 09:09:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: 3166-1 state machine Date: Thu, 31 Mar 2005 09:09:33 -0800 Message-ID: Thread-Topic: [Ltru] Re: 3166-1 state machine Thread-Index: AcU2EAir1zsu0QYBTW2QVwn9/TU6KQAA9ZxQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Mar 2005 17:09:35.0140 (UTC) FILETIME=[69C08E40:01C53614] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Jukka K. Korpela > Well, yes, it is an error, but a common one. Even the Dublin Core > documents have contained it... > Is there a point after which erroneous usage becomes common enough to be > taken so seriously that it be recognized? Certainly a valid question for a case like "UK". It is one thing to specify what is *supposed* to be done; it is another for implementations to actually support de facto practice. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 12:11:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12740; Thu, 31 Mar 2005 12:11:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3JQ-0006mV-Db; Thu, 31 Mar 2005 12:18:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH37w-00042a-Sn; Thu, 31 Mar 2005 12:06:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH37u-00042T-Tt for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:06:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12249 for ; Thu, 31 Mar 2005 12:06:34 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3F1-0006bs-Gk for ltru@ietf.org; Thu, 31 Mar 2005 12:14:00 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 09:06:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Language transformation Date: Thu, 31 Mar 2005 09:06:22 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17C70@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU1sH1pIQx1cSlOQhalncj8spQJvwAYyk+w From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 31 Mar 2005 17:06:22.0738 (UTC) FILETIME=[F7125720:01C53613] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Why not an extension? Using variants for this strikes me as stretching = the use of language tags beyond their reasonable usefulness. Transliteration seems like it might be handled using script codes in a = gross sense. For the finer sense this draft wants to convey, an = extension seems like a better fit.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mercredi 30 mars 2005 21:12 > To: ltru@ietf.org > Subject: [Ltru] Re: Language transformation >=20 > M.T. Carrasco Benitez wrote: >=20 > > I am sending this today to the editor. >=20 > Interesting, if I get it right you want LTRU to use a scheme > which allows the later addition of transliterations. You > identify five relevant parts: >=20 > 1: source language, 2: source script, 3: target laguage(s), > 3: target script, 5: (registered) transliteration scheme. >=20 > Two of these parts could be irrelevant, the source script, > and target language(s) if they are implied by the scheme. >=20 > This would fit into a lang + script + variant pattern, if > you consider a "registered transliteration scheme" as some > kind of "registered variant". >=20 > Is that good enough for your purposes, and do you want it > as an example for "variants" in the registry draft ? >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 12:11:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12803; Thu, 31 Mar 2005 12:11:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3KA-0006qd-5P; Thu, 31 Mar 2005 12:19:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH36K-0003qy-OF; Thu, 31 Mar 2005 12:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH36J-0003qk-Jv for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:04:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12111 for ; Thu, 31 Mar 2005 12:04:57 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3DT-0006WW-DM for ltru@ietf.org; Thu, 31 Mar 2005 12:12:23 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 31 Mar 2005 09:04:54 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 31 Mar 2005 09:06:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Language transformation Date: Thu, 31 Mar 2005 09:04:48 -0800 Message-ID: Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2DarMiREOGTVLQiaVerZSk2DrqAABNqEQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 31 Mar 2005 17:06:06.0304 (UTC) FILETIME=[ED46B600:01C53613] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Doug Ewell > > zh-wadegiles >=20 > I think this might make a good candidate for an extension RFC. It's not > strictly an attribute of the language, but might be important for > content storage and retrieval. For example, it might be valuable to > specify whether "kr-Latn" text is romanized using McCune-Reischauer, > Yale, or Revised Romanization, or whether "ru-Latn" is romanized using > ISO 9, GOST, or some other language-dependent scheme (which is common > for Russian). I don't see why an extension RFC should be necessary at all. Think of these different Romanizations for kr as being comparable to different spelling conventions. A variant subtag should be sufficient: kr-Latn-mccnrsch kr-Latn-yalermn kr-Latn-revdrmn ru-Latn-iso9rmn ru-Latn-gostrmn zh-Latn-wadegile (Or perhaps "Latn" is redundant here and can be omitted.) > Transcription schemes that don't have a name, but are dependent on the > target language (again, common for Russian), might be indicated with a > 2-character subtag representing the target language. Thus > "ru(-Latn)-t-de" would be a transcription of Russian intended for German > readers, while "ru(-Latn)-t-fr" would be the same for French speakers. > In that case, subtags that don't represent a target language would have > to be 3 or more characters long. I'd rather (i) avoid the use of extensions, and (ii) see particular conventions documented somewhere and given an ID that can be used as a variant subtag. Except for cases that are general enough, such as perhaps IPA, that it might make sense to get an alpha-4 ID added to ISO 15924. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 12:11:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12828; Thu, 31 Mar 2005 12:11:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3K8-0006qU-Ho; Thu, 31 Mar 2005 12:19:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Ah-0004QQ-7L; Thu, 31 Mar 2005 12:09:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Af-0004QL-Sl for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:09:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12457 for ; Thu, 31 Mar 2005 12:09:24 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3Hl-0006g2-F0 for ltru@ietf.org; Thu, 31 Mar 2005 12:16:51 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2VH934I342320 for ; Thu, 31 Mar 2005 12:09:03 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2VH928D190298 for ; Thu, 31 Mar 2005 10:09:02 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2VH92fA030706 for ; Thu, 31 Mar 2005 10:09:02 -0700 Received: from markdavis (sig-9-48-116-61.mts.ibm.com [9.48.116.61]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j2VH91Gq030628; Thu, 31 Mar 2005 10:09:01 -0700 Message-ID: <091b01c53614$55a3c850$857e3009@sanjose.ibm.com> From: "Mark Davis" To: "M.T. Carrasco Benitez" , References: <20050331144959.66075.qmail@web42004.mail.yahoo.com> Subject: Re: [Ltru] Re: Language transformation Date: Thu, 31 Mar 2005 09:09:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j2VH934I342320 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable While the direction is interesting, the devil is in the details. We've do= ne a fair amount of work on text transformations, and have found that the transliterations can be general by script (script-script), by language (language-language), and with variants. For example, there is an ISO transliteration Cyrillic-to-Latin (which almost nobody uses); there are UNGEGN transliterations for different cases, and you also have language specific Russian-English and Russian-German, etc. which differ in the use= of letters. Various style guides provide their own, such as the Chicago Manu= al of Style. And then there are variants; Hangul-Latin has different transliterations according to whether you follow the Ministry of Educatio= n or other agencies, and within the Ministry of Education transliteration there are different choices that you can make. And the details of what is involved in a transliterations (or transcripti= on) may vary. Some examples are on http://ibm.com/software/globalization/icu/demo/transform, with a descript= ion through the Help link, and documentation at http://icu.sourceforge.net/userguide/Transform.html and continuing. The rules for transliterations are non-trivial, and we found that many standa= rds that purport to describe complete transliterations have gapping holes in them, cases where the result is not determinant. As far as language tags go, what one would be naming would be the *result= * of applying such a transformation, so the result of applying a Cyrillic-Latin transliteration to Russian would be ru-Latn, plus some variant to specify which of the many different transliterations was in us= e. These variants could be encompassed with the current variant mechanism, s= o I don't see the necessity for any changes to 3066bis. My main concern is that the actual variants used for transliterations not= be a disaster like the IANA charset repository, where people can't tell what the registry is describing. The plan is for transliterations to be added = to CLDR at some point, and that would provide stable, predictable IDs that could be used for variants. I suggest that we not try to incorporate transliteration variants prematurely. For some more formal, structured mechanism of describing the variants, it would a perfect case for the extension mechanism proposed in the draft, where some other RFC could hav= e something like ru-Latn-t-ungegn-t-en. =E2=80=8EMark ----- Original Message -----=20 From: "M.T. Carrasco Benitez" To: Sent: Thursday, March 31, 2005 06:49 Subject: Re: [Ltru] Re: Language transformation > > [Ellermann] > > Interesting, if I get it right you want LTRU to use a scheme > > which allows the later addition of transliterations. You > > identify five relevant parts: > > > > 1: source language, 2: source script, 3: target laguage(s), > > 3: target script, 5: (registered) transliteration scheme. > > For the "Schemes for Language Transformation", there could be > more than five. I will later submit a full record. This does > not need to be hosted by LTRU (IANA). > > > Two of these parts could be irrelevant, the source script, > > and target language(s) if they are implied by the scheme. > > LTRU must be concerned only by the "transformation identifier". > For example, "widegiles". Any new type would be needed. For example: > > # Transformations > transformation | widegiles | | yyyy-mm-dd | | > transformation | pinyin| | yyyy-mm-dd | | > > > This would fit into a lang + script + variant pattern, if > > you consider a "registered transliteration scheme" as some > > kind of "registered variant". > > No. See above. The transformation identifer carries the information > regarding the target script. > > > Is that good enough for your purposes, and do you want it > > as an example for "variants" in the registry draft ? > > See above. > > Regards > Tomas > > > Send instant messages to your online friends http://uk.messenger.yahoo.= com > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 12:33:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14502; Thu, 31 Mar 2005 12:33:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3en-0007gd-Tk; Thu, 31 Mar 2005 12:40:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3UA-0002ET-CI; Thu, 31 Mar 2005 12:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3U9-0002EM-Ct for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:29:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14201 for ; Thu, 31 Mar 2005 12:29:32 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3bD-0007Uw-F7 for ltru@ietf.org; Thu, 31 Mar 2005 12:36:56 -0500 Received: from lns-p19-4-idf-82-65-253-170.adsl.proxad.net ([82.65.253.170] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DH3U1-0006IJ-85; Thu, 31 Mar 2005 09:29:29 -0800 Message-Id: <6.1.2.0.2.20050331191828.0ca22ad0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 31 Mar 2005 19:29:23 +0200 To: "Mark Davis" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Language transformation In-Reply-To: <091b01c53614$55a3c850$857e3009@sanjose.ibm.com> References: <20050331144959.66075.qmail@web42004.mail.yahoo.com> <091b01c53614$55a3c850$857e3009@sanjose.ibm.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On 19:09 31/03/2005, Mark Davis said: >The plan is for transliterations to be added to CLDR at some point, and >that would provide stable, predictable IDs that could be used for >variants. I suggest that we not try to incorporate transliteration >variants prematurely. For some more formal, structured mechanism of >describing the variants, it would a perfect case for the extension >mechanism proposed in the draft, where some other RFC could have >something like ru-Latn-t-ungegn-t-en. This kind of remark obviously make me react. Whose plan: IETF, IESG, IAB? 1. this CLDR plan should be documented in the Draft as per Charter. At least to explain why it is not supported now. 2. if I am correct a locale is loaded once in a machine not every time it wants to change contexts. Obviously a Locale could support many languages. Where is the locale to be loaded from? If it is from the IANA should not a provision be made in the IANA section. If this is from an outside URL listed on the IANA? This should be documented. 3. I am glad you adopt the thinking that the first draft should be a framework, completed by additional specialized RFCs. Very positive. Thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 12:43:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15556; Thu, 31 Mar 2005 12:43:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3pD-00083n-2i; Thu, 31 Mar 2005 12:51:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3gu-0005Xz-Ux; Thu, 31 Mar 2005 12:42:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3gu-0005Xr-FL for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:42:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15484 for ; Thu, 31 Mar 2005 12:42:45 -0500 (EST) Received: from web42006.mail.yahoo.com ([66.218.93.174]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH3o3-00082B-AO for ltru@ietf.org; Thu, 31 Mar 2005 12:50:12 -0500 Received: (qmail 98270 invoked by uid 60001); 31 Mar 2005 17:42:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LQwOCx3kyHSIwyMaX95NxImaAAwviwxdevTfIrv46GBnKGQwG4FsyYL1j4YAK7C9Fxg2LDXyZmzID+CFhJzA7pjXnoSZQ/1eC9/cs7yCV7ZpndkbntRxTt88rI90P48XGM6PPZM/1KA2XTW36d82Yy9gPa9gN5/RbokRrjvc5XI= ; Message-ID: <20050331174237.98268.qmail@web42006.mail.yahoo.com> Received: from [83.99.66.202] by web42006.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 18:42:37 BST Date: Thu, 31 Mar 2005 18:42:37 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 8bit > [Ewell] > The most important distinction is that a transliteration must be > unambiguously reversible. That said, it's true that non-professionals > often use the terms interchangeably, and I don't see a problem with > lumping them together for this discussion. Not necessarilly. LTRU should be concerned with tagging the transformed language. The methodollogy should be out of scope. > > Hence, one needs a list of transformation schemes, each with one > > unique identifier. The transformation identifier indicates the source > > language(s), the source script, the target language(s) and the target > > script. > > It's more than just target language; multiple transcription systems can > exist for the same set of four variables (SL, SS, TL, TS). Yes. > > The above is a pseudo-code. In particular, it is not a syntactic > > proposition for LTRU. This should come later, assuming that LTRU want > > to consider language transformations. Indeed, the transformation > > token does not need to be present and it could be implied. For > > example; > > > > zh-wadegiles > > I think this might make a good candidate for an extension RFC. It's not > strictly an attribute of the language, but might be important for > content storage and retrieval. For example, it might be valuable to > specify whether "kr-Latn" text is romanized using McCune-Reischauer, > Yale, or Revised Romanization, or whether "ru-Latn" is romanized using > ISO 9, GOST, or some other language-dependent scheme (which is common > for Russian). Yes. > Extensions are described in detail at: > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.html#extensions > > If this were approved, and assuming for the sake of argument that the > singleton 't' were assigned, then the example in Section 2 of Tomas's > draft could be coded as "zh-Latn-t-wadeg" or even just "zh-t-wadeg" > (since the existence of a subtag for Wade-Giles implies the Latin > script). Note that subtags must be 8 characters of less, so "wadegiles" > would be too long. I left the syntax Better "zh-t-wadeg" Regarding the syntax, in the draft I left it as "should be discussed in LTRU". > Transcription schemes that don't have a name, but are dependent on the > target language (again, common for Russian), might be indicated with a > 2-character subtag representing the target language. Thus > "ru(-Latn)-t-de" would be a transcription of Russian intended for German > readers, while "ru(-Latn)-t-fr" would be the same for French speakers. > In that case, subtags that don't represent a target language would have > to be 3 or more characters long. >From the experience of the last time, having the target language caused confusion: it must be very clear that the text tagged by "ru-t-foo" is Russian. So having "ru-t-fr" lead to believe that there was some French in the text. Also, I suspect (I am not certain) that transformation schemes would typically target more than one language; except in languages like Armenian with a very specific script. But artificially naming transformation schemes is not a solution. Hence, the entity that registers a transformation scheme with the proposed "Schemes for Language Transformation" should propose a non-allocated "transformation identifier" within the syntactic restrictions of LTRU. > > Two registries are need: > > > > - IANA > > - Schemes for Language Transformation > > > > IANA must be concerned only with scheme identifiers. In the example > > above the string "wadegiles". > > If this were approved as an extension RFC, then that RFC -- not IANA -- > would control the list of valid subtags. IANA would maintain a URL > pointing to the current table. Yes. I am doing the preliminary work. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:05:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17811; Thu, 31 Mar 2005 13:05:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4AH-0000a1-DQ; Thu, 31 Mar 2005 13:13:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3vo-0000FF-Hx; Thu, 31 Mar 2005 12:58:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3vn-0000FA-SI for ltru@megatron.ietf.org; Thu, 31 Mar 2005 12:58:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17016 for ; Thu, 31 Mar 2005 12:58:09 -0500 (EST) Received: from web42005.mail.yahoo.com ([66.218.93.173]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH42x-0000D0-1N for ltru@ietf.org; Thu, 31 Mar 2005 13:05:36 -0500 Received: (qmail 39329 invoked by uid 60001); 31 Mar 2005 17:58:00 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HGAQAkoSKBH/nve7AivhUXFKR0ufEZq3Gx88dBNtW0f9Syi+XFkyhM/oX+F4y4NyWxFU5IejtisC+0JMcndazDeb5oQL4TcY75i3tj4l/XR+yeQcitRsiuCzHBfWq25x2tzQ+ogmFp86dqdgkzlXljjaveB5WjDWFbsMD1DZl7g= ; Message-ID: <20050331175800.39327.qmail@web42005.mail.yahoo.com> Received: from [83.99.66.202] by web42005.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 18:58:00 BST Date: Thu, 31 Mar 2005 18:58:00 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit > I agree that "transliterations" are not as cut and dried as TC46 makes them out to be. My only > point was that there are many things that fall in the category of "transcription" (clearly that > and not transliteration), such as IPA, that really aren't conversions or transformations. I am ready to accepts almost any term; as long as it is decide once and for all. A secret; do not tell anybody -:) I preferred term is "transliteration", but I got hammered by the parties that want to make a difference with "transcription". Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:06:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17979; Thu, 31 Mar 2005 13:06:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4BK-0000cS-Pm; Thu, 31 Mar 2005 13:14:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3xk-0000XD-Nb; Thu, 31 Mar 2005 13:00:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3xj-0000X5-3d for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:00:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17287 for ; Thu, 31 Mar 2005 13:00:08 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH44s-0000GH-1j for ltru@ietf.org; Thu, 31 Mar 2005 13:07:35 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 31 Mar 2005 18:59:52 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 18:59:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] is there some wiskey in the jar - [was: Registry in record-jar format] Date: Thu, 31 Mar 2005 18:59:51 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Thread-Index: AcUw05Xm9SWJA3hGTQ6XjxnDXx+/JAFO5uTw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 31 Mar 2005 17:59:51.0442 (UTC) FILETIME=[6F9BB720:01C5361B] X-Spam-Score: 1.2 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 1.2 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable JFC, > why to be agressive?=20 ... > If you are a programer and a standardizer=20 ... > If you are involved in the Internet as a programer and as a = standardizer you know as=20 > much as I do about IPv6? ... > May be you are not a network architect ... > May be you are an operational too ... > - you are selfish grown boys ... > I hope - and still hope - you could help, as an European=20 > academic, with a=20 > more open minded apporach, culturally more sophisticated and=20 > inclusive than=20 > employees of large multinational coporations or of their=20 > resellers are allowed. Please do not make assumptions about what others do or do not, or aim = accusations at others and then accuse them of being aggressive when they = correct you - it does not help the discussion.=20 Also, where did you discover that Moore's law was a "joke"? Not from = Intel, surely? (http://www.intel.com/research/silicon/mooreslaw.htm) > Happily, the law of Moore does not necessarily apply.=20 While applying Moore's law to every situation does not necessarily fit, = technology moves quickly. UDC, and its predecessor, was a good example = of a large system of identifiers in existence before any of the web = technologies. The truth, I suspect, is a consideration of technological = capabilities and advances alongside expectations of growth. But these = are both predictions, and we know what the problem with prediction is. = Now, you suggested that an "IANA considerations" section needs to = predict how many accesses such a registry will have, right? Based = perhaps on the frequency of access of the list that goes along with RFC = 3066? Can you point to somewhere that this has been done already? I'm = interested in how people have made such predictions in these documents - = predicting system loading is an interesting topic. As a network architect, perhaps you also have good suggestions to make = for how to handle a distributed registry that would reduce = infrastructural requirements and help to fulfill such a requirement. = Though you seemed to dismiss John Cowan's (or somebody else's) = suggestions of cacheing. Is your concern purely financial?=20 > In your reasoning, the law of Reed applies(from each language to each = language) If it did, we'd have a massive amount of languages based on every person = possibly speaking to every other person in the world. We have standards = of terminology in specific areas. The contrast between these 2 = statements seems to be very relevant to such considerations. Perhaps the = former is why you suggest significant loading on systems? > the current Draft will not fly. As usual on the Internet: it is a = default ASCII Internet=20 > solution for one application having circumvented another one. I do not understand this comment, perhaps you would like you to = elaborate on it? Are you suggesting to "do away" with ASCII? Why does an = ASCII solution for language tagging pose a problem? The tag provides the = interoperability - what it "stands in place of" requires representation = (its human-readable name in given a language and associated data). The = multilinguality of which you speak would be its representation, not its = tag. Call the airport what you want, your luggage tag will have 3 = letters and be in ASCII.=20 > Lang5tag is no problem managing as such: it happens to be=20 > well managed for centuries by every library. No need for the IANA. Where is it documented? How do people use it for interoperability? Who = ensures it is well maintained? I've no experiences of libraries that use = such a systems. I am also intrigued by your suggestion that it's less = complex than what you refer to as a lang3tag, when what you identify as = lang5tag seems to be an extension of lang3tag. > you are not taking care of the needs of others (like me)=20 What exactly are these needs that you allude to? I don't consider these = to be clear. A number of others have asked this also. I'm not sure = people can realistically take an individual's budget into consideration = when they aim to provide something for the wider community. Should the = tail wag the dog? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:08:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18118; Thu, 31 Mar 2005 13:07:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4CV-0000hq-3y; Thu, 31 Mar 2005 13:15:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH41J-00012v-07; Thu, 31 Mar 2005 13:03:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH41H-00012q-6W for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:03:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17593 for ; Thu, 31 Mar 2005 13:03:48 -0500 (EST) Received: from web42002.mail.yahoo.com ([66.218.93.170]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH48O-0000Ru-AQ for ltru@ietf.org; Thu, 31 Mar 2005 13:11:15 -0500 Received: (qmail 17582 invoked by uid 60001); 31 Mar 2005 18:03:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ZeYjWG2xysqnhqZdoDvM3XfIENcXPrUUi+o6cCIJgrlEMO6jjFCDSfDXwhnqxc0nj+e7Aqu120v2ZykusY0OW0v+HgHRCU1IHfnYNJzgLc2PLN+t2TZbpHg9ZlIgj5tz67qzAMGzOWOaU/pB6ub7gpG4c3f2jqYK5rAP9poF+R0= ; Message-ID: <20050331180337.17580.qmail@web42002.mail.yahoo.com> Received: from [83.99.66.202] by web42002.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 19:03:36 BST Date: Thu, 31 Mar 2005 19:03:36 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 8bit > I don't see why an extension RFC should be necessary at all. Think of > these different Romanizations for kr as being comparable to different > spelling conventions. A variant subtag should be sufficient: > > kr-Latn-mccnrsch > kr-Latn-yalermn > kr-Latn-revdrmn > > ru-Latn-iso9rmn > ru-Latn-gostrmn > > zh-Latn-wadegile > > (Or perhaps "Latn" is redundant here and can be omitted.) The script token should not be present and it shoudl be implied y the scheme. Hence, zh-wadegile Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:08:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18218; Thu, 31 Mar 2005 13:08:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4D6-0000iR-Vv; Thu, 31 Mar 2005 13:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH43d-0001WY-KW; Thu, 31 Mar 2005 13:06:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH43b-0001WN-U5 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:06:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17876 for ; Thu, 31 Mar 2005 13:06:12 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4Al-0000aP-I8 for ltru@ietf.org; Thu, 31 Mar 2005 13:13:40 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 10:05:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: 3166-1 state machine Date: Thu, 31 Mar 2005 10:05:58 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17CE5@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: 3166-1 state machine Thread-Index: AcU2EAbzKe4gOI49RNumMjxmq5m3VgABMhUQ From: "Addison Phillips" To: "Jukka K. Korpela" , "LTRU Working Group" X-OriginalArrivalTime: 31 Mar 2005 18:05:59.0559 (UTC) FILETIME=[4B05E970:01C5361C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable > Is there a point after which erroneous usage becomes common enough to = be > taken so seriously that it be recognized? That would mean keeping "UK" = as > country code unassigned (reserved) and treating any use of "UK" as = country > code as an error in principle but with the error recovery that it is > interpreted (perhaps with a warning) to mean 'United Kingdom'. Someone > might say that this would mean virtually accepting "UK" as synonym for > "GB" - and this might be regarded as a very bad move. No. It makes a mess. While many users regrettably don't know that UK is not the country code = to use in language tags, allowing both as synonyms makes life a lot = harder for the kinds of processes that language tags are designed for. For example, in a web page, if I use the CSS :lang pseudo attribute to = assign a style to content in a particular language: p:lang(en-GB) { color: blue; } Then the user agent (for example) has to perform complex matching of = tags in the document to see if the rule should be applied.

This text is blue?

Processes that currently rely on left-prefix matching (which is to say, = nearly all of them) must now normalize both requests (in this case the = CSS rule) and content (in this case the XHTML). One of the nice benefits of having a registry is that users at least can = look up the valid values somewhere and not have to go to four or five = places not identified by the standard to find out what to use. > But after all, metadata is about giving information about data, and if = an > author labels his data as, say, applying to country "UK" or being in > language "en-UK", shouldn't we work by what we know he must have = _meant_, > instead of just blowing horns and sending error messages around? Well, RFC 3066 matching by non-validating processors does work with = those tags, from the point of view that if you ONLY use en-UK then all = is well. If you don't want to know the meaning of the tag, then "en-UK" = works as a blob of identifier. RFC 3066bis even allows the unknown 'UK' = subtag to be recognized unambiguously as a region. If you care about the = meaning of the subtag, then it becomes important, though. And content = authors or end users who use "en-UK" will not find all of the content = that they "know" they are asking for but which the machines, poor little = grasshoppers, can't match to the more proper 'GB' subtag. Don't forget: this isn't just a few tags that we're talking about here. = This processing would have to be applied to ALL tags and ranges. And no = doubt where we allow one exception there will be others. Lots of tags = for the same thing makes life easy on content authors, who don't have to = learn anything, but makes life much harder for implementations or, = ultimately, the much larger audience of end users. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Jukka K. Korpela > Sent: jeudi 31 mars 2005 08:37 > To: LTRU Working Group > Subject: Re: [Ltru] Re: 3166-1 state machine >=20 > On Tue, 29 Mar 2005, Doug Ewell wrote: >=20 > > > For some time I thought that en-UK is correct... :-( Maybe I > > > confuse it with a locale. Google claims to have 300,000 hits > > > for "en-uk" (quoted), most of them probably irrelevant. > > > > That's not evidence of ccTLDs in language tags, that's just an = error. > > :-) >=20 > Well, yes, it is an error, but a common one. Even the Dublin Core > documents have contained it, e.g. > http://dublincore.org/documents/1999/07/02/dces/ > (the current version has it fixed to en-GB). >=20 > The error is understandable, since the official name of the country is > "United Kingdom" (long form: "United Kingdom of Great Britain and = Northern > Ireland"). Besides, the official European Union policy is to use "UK" = as > the country code (otherwise using ISO 3166 except for Greece). >=20 > Is there a point after which erroneous usage becomes common enough to = be > taken so seriously that it be recognized? That would mean keeping "UK" = as > country code unassigned (reserved) and treating any use of "UK" as = country > code as an error in principle but with the error recovery that it is > interpreted (perhaps with a warning) to mean 'United Kingdom'. Someone > might say that this would mean virtually accepting "UK" as synonym for > "GB" - and this might be regarded as a very bad move. >=20 > But after all, metadata is about giving information about data, and if = an > author labels his data as, say, applying to country "UK" or being in > language "en-UK", shouldn't we work by what we know he must have = _meant_, > instead of just blowing horns and sending error messages around? >=20 > -- > Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:09:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18330; Thu, 31 Mar 2005 13:09:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4EM-0000ju-AW; Thu, 31 Mar 2005 13:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH45J-0001yf-3z; Thu, 31 Mar 2005 13:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH45H-0001y7-B8 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:07:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18109 for ; Thu, 31 Mar 2005 13:07:56 -0500 (EST) Received: from web42006.mail.yahoo.com ([66.218.93.174]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH4CQ-0000e3-If for ltru@ietf.org; Thu, 31 Mar 2005 13:15:24 -0500 Received: (qmail 6973 invoked by uid 60001); 31 Mar 2005 18:07:48 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=oMnGx8DwvQY5Xu+MFyotLhJmiv7QzGBRNvlhzIVyDJXqLOS4JotqwzY1DmH4m4cMTdmU/mXb6vHfyxvDyziqczA+rilJoWlHok7X1sdkQo/k/tFVZScaqPgiu4SF+ZL668xvnd51kAMnwr84lIsBRhtUUuVFV6hll/pZ/U2ZBvs= ; Message-ID: <20050331180748.6971.qmail@web42006.mail.yahoo.com> Received: from [83.99.66.202] by web42006.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 19:07:47 BST Date: Thu, 31 Mar 2005 19:07:47 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit > Transliteration seems like it might be handled using script codes in a gross sense. For the > finer sense this draft wants to convey, an extension seems like a better fit. Script are not sufficient. Examples: Peking Beijing Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:29:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19865; Thu, 31 Mar 2005 13:29:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4X1-0001Ti-3s; Thu, 31 Mar 2005 13:36:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4JD-0006PX-92; Thu, 31 Mar 2005 13:22:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4JB-0006PK-UF for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:22:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19499 for ; Thu, 31 Mar 2005 13:22:19 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4QL-0001EZ-CL for ltru@ietf.org; Thu, 31 Mar 2005 13:29:46 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 10:22:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Language transformation Date: Thu, 31 Mar 2005 10:22:10 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17D0B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2HNGClNeGLJoCS0KCNCtW/V3OcQAAGANA From: "Addison Phillips" To: "M.T. Carrasco Benitez" , X-OriginalArrivalTime: 31 Mar 2005 18:22:10.0778 (UTC) FILETIME=[8DEA2BA0:01C5361E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable No, I understood that script would only be a gross indicator of a = transliteration and a rather inexact one at that. "zh-Latn" would cover = both of your examples, but wouldn't convey much information about the = content. However, using variants complicates matters. The transformation applied = to the text is only one dimension of the content. It may still have a = language ("zh"), a dialect (in 3066ter a 639-3 extland code, such as = wuu???), a script (Grek, Latn, Hant, etc.), a region (CN, HK, SG, = TW...), and a variant not related to the transformation itself. These = may be as important to tag the content with as the transformation = applied. Extensions allow this kind of semi-orthogonal, language-related = distinction to be applied. Consider: zh-wuu-CN-t-wadegile Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of M.T. Carrasco Benitez > Sent: jeudi 31 mars 2005 10:08 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > > Transliteration seems like it might be handled using script codes in = a > gross sense. For the > > finer sense this draft wants to convey, an extension seems like a = better > fit. >=20 > Script are not sufficient. Examples: >=20 > Peking > Beijing >=20 > Regards > Tomas >=20 >=20 > Send instant messages to your online friends = http://uk.messenger.yahoo.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:34:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20354; Thu, 31 Mar 2005 13:34:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4bn-0001av-AW; Thu, 31 Mar 2005 13:41:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4U2-00008N-HW; Thu, 31 Mar 2005 13:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4U1-00008G-Mq for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:33:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20194 for ; Thu, 31 Mar 2005 13:33:30 -0500 (EST) Received: from web42002.mail.yahoo.com ([66.218.93.170]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH4bB-0001YF-1C for ltru@ietf.org; Thu, 31 Mar 2005 13:40:58 -0500 Received: (qmail 26301 invoked by uid 60001); 31 Mar 2005 18:33:22 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=OVwdOEIZEsK+6jv8aWnFGzI0WmJzUNAQKU9i9xkoli7tlJ1It926KSi7mMLRyG88rZTnQtqetA//Dx+xmV371FvqNBMq5wIhfZuTMf/YQ0ISbkHx1GAhcDgj+ceHrhtNcFPFUjjozmWwtuQKKCvAJTecUEAJ8VaVdK5jyztoy/Y= ; Message-ID: <20050331183322.26299.qmail@web42002.mail.yahoo.com> Received: from [83.99.66.202] by web42002.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 19:33:22 BST Date: Thu, 31 Mar 2005 19:33:22 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 8bit > As far as language tags go, what one would be naming would be the *result* > of applying such a transformation, I agree. LTRU should only be concerned with tagging result. > My main concern is that the actual variants used for transliterations not be > a disaster like the IANA charset repository, where people can't tell what > the registry is describing. The plan is for transliterations to be added to > CLDR at some point, and that would provide stable, predictable IDs that > could be used for variants. I suggest that we not try to incorporate > transliteration variants prematurely. For some more formal, structured > mechanism of describing the variants, it would a perfect case for the > extension mechanism proposed in the draft, where some other RFC could have > something like ru-Latn-t-ungegn-t-en. The proposal is to forseen the requirement in the syntax. LTRU should only be concerned with the list of "transformation identifier". Example: # Transformations transformation | widegile | | yyyy-mm-dd | | transformation | pinyin| | yyyy-mm-dd | | The Registry of Schemes for Language Transformation (out of scope of LTRU) should address the description of the transformation. Example: %% id:widegile sourcelang:zh targetlang:en uri:http://somewhere.xxx/speficationofwidegiles foo:foo %% id:pinyin sourcelang:zh targetlang:en uri:http://somewhereelse.xxx/speficationofpinyin foo:foo %% This registry should not address the methodology of the transformation. It should just point with the URI to the entity maintaining the methodology. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 13:48:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22401; Thu, 31 Mar 2005 13:48:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4pE-0002J3-2w; Thu, 31 Mar 2005 13:55:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4hV-0003l3-Ve; Thu, 31 Mar 2005 13:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4hU-0003kx-F5 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 13:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22289 for ; Thu, 31 Mar 2005 13:47:25 -0500 (EST) Received: from web42007.mail.yahoo.com ([66.218.93.175]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH4oe-0002H9-07 for ltru@ietf.org; Thu, 31 Mar 2005 13:54:53 -0500 Received: (qmail 89529 invoked by uid 60001); 31 Mar 2005 18:47:17 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=3oj2EUfq7saFqQ4Vi77TmIEKFFOHDIbfnZo86whg2OmZ49KgGJe9AMyzpF2TQQVHYConGqC7K2f14AAILwe1gFM5IRsRSRCLR19J8dWXWy43ERM+QCbCR7dIWLYEwSeSvVIysFHXX2Q0WFT3AbAjMctEvd4mqyplHuabCfYMQeI= ; Message-ID: <20050331184717.89527.qmail@web42007.mail.yahoo.com> Received: from [83.99.66.202] by web42007.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 19:47:17 BST Date: Thu, 31 Mar 2005 19:47:17 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit > However, using variants complicates matters. The transformation applied to the text is only one > dimension of the content. It may still have a language ("zh"), a dialect (in 3066ter a 639-3 > extland code, such as wuu???), a script (Grek, Latn, Hant, etc.), a region (CN, HK, SG, TW...), > and a variant not related to the transformation itself. These may be as important to tag the > content with as the transformation applied. > > Extensions allow this kind of semi-orthogonal, language-related distinction to be applied. > Consider: > > zh-wuu-CN-t-wadegile Corrent. This the requirement. I do not know if this would be the appropiate syntax. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 14:01:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23593; Thu, 31 Mar 2005 14:01:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH52H-0002o9-VP; Thu, 31 Mar 2005 14:08:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4u6-0006QM-3w; Thu, 31 Mar 2005 14:00:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH4u4-0006QE-Id for ltru@megatron.ietf.org; Thu, 31 Mar 2005 14:00:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23480 for ; Thu, 31 Mar 2005 14:00:26 -0500 (EST) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH51C-0002n8-TG for ltru@ietf.org; Thu, 31 Mar 2005 14:07:52 -0500 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2VJ0Fua024774 for ; Thu, 31 Mar 2005 14:00:15 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2VJ0FUk168626 for ; Thu, 31 Mar 2005 12:00:15 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2VJ0FQF004564 for ; Thu, 31 Mar 2005 12:00:15 -0700 Received: from markdavis (sig-9-48-116-61.mts.ibm.com [9.48.116.61]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j2VJ0EKo004501; Thu, 31 Mar 2005 12:00:14 -0700 Message-ID: <09ac01c53623$deef7f00$857e3009@sanjose.ibm.com> From: "Mark Davis" To: "M.T. Carrasco Benitez" , References: <20050331183322.26299.qmail@web42002.mail.yahoo.com> Subject: Re: [Ltru] Re: Language transformation Date: Thu, 31 Mar 2005 11:00:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j2VJ0Fua024774 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable > uri:http://somewhere.xxx/speficationofwidegiles That very policy has been a disaster with IANA charsets. The references don't supply a complete description, or are not stable. That's why I thin= k this is premature. =E2=80=8EMark ----- Original Message -----=20 From: "M.T. Carrasco Benitez" To: Sent: Thursday, March 31, 2005 10:33 Subject: Re: [Ltru] Re: Language transformation > > As far as language tags go, what one would be naming would be the *result* > > of applying such a transformation, > > I agree. LTRU should only be concerned with tagging result. > > > My main concern is that the actual variants used for transliterations not be > > a disaster like the IANA charset repository, where people can't tell what > > the registry is describing. The plan is for transliterations to be ad= ded to > > CLDR at some point, and that would provide stable, predictable IDs th= at > > could be used for variants. I suggest that we not try to incorporate > > transliteration variants prematurely. For some more formal, structure= d > > mechanism of describing the variants, it would a perfect case for the > > extension mechanism proposed in the draft, where some other RFC could have > > something like ru-Latn-t-ungegn-t-en. > > The proposal is to forseen the requirement in the syntax. LTRU should o= nly be > concerned with the list of "transformation identifier". Example: > > # Transformations > transformation | widegile | | yyyy-mm-dd | | > transformation | pinyin| | yyyy-mm-dd | | > > The Registry of Schemes for Language Transformation (out of scope of LT= RU) > should address the description of the transformation. Example: > > %% > id:widegile > sourcelang:zh > targetlang:en > uri:http://somewhere.xxx/speficationofwidegiles > foo:foo > %% > id:pinyin > sourcelang:zh > targetlang:en > uri:http://somewhereelse.xxx/speficationofpinyin > foo:foo > %% > > This registry should not address the methodology of the transformation.= It should > just point with the URI to the entity maintaining the methodology. > > Regards > Tomas > > > Send instant messages to your online friends http://uk.messenger.yahoo.= com > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 14:25:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25521; Thu, 31 Mar 2005 14:25:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5P6-0003eo-GC; Thu, 31 Mar 2005 14:32:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5HZ-000333-Uc; Thu, 31 Mar 2005 14:24:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5HW-00032p-5z for ltru@megatron.ietf.org; Thu, 31 Mar 2005 14:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25508 for ; Thu, 31 Mar 2005 14:24:41 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5Oh-0003eV-1B for ltru@ietf.org; Thu, 31 Mar 2005 14:32:07 -0500 Received: from lns-p19-4-idf-82-65-253-170.adsl.proxad.net ([82.65.253.170] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DH5HT-0006eU-8v; Thu, 31 Mar 2005 11:24:40 -0800 Message-Id: <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 31 Mar 2005 21:15:00 +0200 To: "L.Gillam" , ltru From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 1.3 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 1.3 (+) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f At 19:59 31/03/2005, L.Gillam wrote: >Also, where did you discover that Moore's law was a "joke"? Not from >Intel, surely? (http://www.intel.com/research/silicon/mooreslaw.htm) Moore law applies to computers not to networks. On networks Metcalfe and Reeds laws are to be used as a never reached limit or as a maximum filtering. >appily, the law of Moore does not necessarily apply. >While applying Moore's law to every situation does not necessarily fit, >technology moves quickly. UDC, and its predecessor, was a good example of >a large system of identifiers in existence before any of the web >technologies. The truth, I suspect, is a consideration of technological >capabilities and advances alongside expectations of growth. But these are >both predictions, and we know what the problem with prediction is. Now, >you suggested that an "IANA considerations" section needs to predict how >many accesses such a registry will have, right? Based perhaps on the >frequency of access of the list that goes along with RFC 3066? Can you >point to somewhere that this has been done already? I'm interested in how >people have made such predictions in these documents - predicting system >loading is an interesting topic. I have no other model to offer than existing systems. This is why I ask and why I worry. I do not document, I ask it to be documented. There is to date no other request to IANA such as some of the discussed propositions. IMHO the IANA is not conceptually what fits these demands. I just want to understand first what is the demand. This Draft is made to address specific application needs: I just ask how will this applications operate. What are the risks of usage creep. >As a network architect, perhaps you also have good suggestions to make for >how to handle a distributed registry that would reduce infrastructural >requirements and help to fulfill such a requirement. Though you seemed to >dismiss John Cowan's (or somebody else's) suggestions of cacheing. I am open to every suggestion. But first I want to understand the problem. Who is accessing, for what purpose, the length and the size of the transaction. For example caching what, where, when, for how long. I documented long caching in using a langtags file and yearly update??? >Is your concern purely financial? My concern is also financial. There is a necessary compromise between cost, quality of the service, volume of access, procedures, ways to limiting traffic. I want to understand first what we are talking about. So, I ask. > > In your reasoning, the law of Reed applies(from each language to each > language) > >If it did, we'd have a massive amount of languages based on every person >possibly speaking to every other person in the world. We have standards of >terminology in specific areas. The contrast between these 2 statements >seems to be very relevant to such considerations. Perhaps the former is >why you suggest significant loading on systems? I am not sure that impact of every language to every language is so important on the resulting load (but again I have yet no real idea of when people will access, why, etc. and I mean in real life, not in theory: we all know that real use if far bigger than the supposed one). My rational is that when two people want to talk they talk, whatever the language. But obviously there is certainly an impact. If someone updates his tables every time it calls someone, the impact is zero, but if he does it only when he calls a new language, if he speaks only one language, no impact, but if he speaks 10 languages the impact if 10 times more, plus possible errors. >Are you suggesting to "do away" with ASCII? Why does an ASCII solution for >language tagging pose a problem? The tag provides the interoperability - >what it "stands in place of" requires representation (its human-readable >name in given a language and associated data). The multilinguality of >which you speak would be its representation, not its tag. Call the airport >what you want, your luggage tag will have 3 letters and be in ASCII. There is no use in having to enter/read something which is not on your keyboard. People at the Airport can type ASCII - for the time being as probably RFID will change many things. Not end users. > > Lang5tag is no problem managing as such: it happens to be > > well managed for centuries by every library. No need for the IANA. > >Where is it documented? How do people use it for interoperability? Who >ensures it is well maintained? No one. You know the Babel symbolism: it is precisely to free people from the one who wanted things to be well maintained. So people are free to do it the way they want. So there is no single point of failure. 7520 languages are the way to make us free from someone ensuring maintenance. This is for us to feel secure we found a reliable way to be stable, secure and innovative without having to rely on a single one, with all the possible cross verifications, which will insure us that our system is well maintained. More complex, smarter, more work to find it? Probably yes. >I've no experiences of libraries that use such a systems. I am also >intrigued by your suggestion that it's less complex than what you refer to >as a lang3tag, when what you identify as lang5tag seems to be an extension >of lang3tag. Open a dictionary. It will tell you five things about every word, plus information on the meaning, nature and syntax: - the language (on the cover) - the script (you see it) - where it was published (ISSN-ISBN) or the title - the author (on the cover) - either it is standard style by default, or it mentions the style: fam. pop, old, etc. > > you are not taking care of the needs of others (like me) There are many needs to consider. 1. application needs. The only considered needs are XML/HTML pages by W3C and some CLDR needs? OPES, DNS, Web Services, History, Users communities, CRC, etc. and innovation. 2. there is not such a thing as a "wider community". There are machines, bandwidth, operators, etc. These people need a budget and someone to pay for this budget. In the case of the IANA the budget is the ICANN budget. ICANN need to collect that money. I am one of those who are asked to pay. I suggest you access the ICANN strategic plan for the years to come http://nuts/strategic-plan/strategic-plan-v6.pdf and search for IANA. It will give you a fair understanding of what ICANN intents to pay when you compare the number of times RIRs, DNS and Parameters and quoted. >What exactly are these needs that you allude to? I don't consider these to >be clear. A number of others have asked this also. I'm not sure people can >realistically take an individual's budget into consideration when they aim >to provide something for the wider community. Should the tail wag the dog? Depends what is the tail what is the dog. This is precisely what I want to determine. Let assume that one of the self regulation of IANA load is the delay in getting a IANA response. Let assume that the delay is 1 minutes. Is this acceptable? Is this because there a lot abandon? Is this not draining resources on developing countries more than larger bandwidth countries? etc. Again, at this time we do not discuss a solution. We just need to understand if there is a problem (I am surprised nobody came in saying: there is no problem because ....). Roughly there are comments saying "on OS installation" - I do not know why, nor the size of the access. But with usual 10 times markup this means 3 to 4 billions a year increasing. I do not know the size, but I tend to think the lower the size the greater the number of accesses? My first real concern is why do I need the IANA for? Let take the DNS. The IANA delivers the Master file to the Alpha Machine and to the Internic, and the Whois file online. I would be very interested in IANA documenting the load each represents. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 14:25:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25539; Thu, 31 Mar 2005 14:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5P7-0003es-HQ; Thu, 31 Mar 2005 14:32:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5HW-00032u-Lk; Thu, 31 Mar 2005 14:24:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5HU-00030k-Qh for ltru@megatron.ietf.org; Thu, 31 Mar 2005 14:24:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25505 for ; Thu, 31 Mar 2005 14:24:39 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5Oe-0003eR-Tg for ltru@ietf.org; Thu, 31 Mar 2005 14:32:06 -0500 Received: from lns-p19-4-idf-82-65-253-170.adsl.proxad.net ([82.65.253.170] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DH5HS-0006eU-27; Thu, 31 Mar 2005 11:24:38 -0800 Message-Id: <6.1.2.0.2.20050331194739.04282a90@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 31 Mar 2005 21:24:31 +0200 To: "M.T. Carrasco Benitez" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Language transformation In-Reply-To: <20050331174237.98268.qmail@web42006.mail.yahoo.com> References: <20050331174237.98268.qmail@web42006.mail.yahoo.com> Mime-Version: 1.0 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 - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 What should be considered is the result to the user. A recording or a transcoding resulting in the same voice-text, look the same to me? I do not see script difference between a voice, in Russian and a voice in English speaking the same way? Questions can be about the sex, accent, timber, age of the voice and about the speaking style? Same a short-hand or phonetic or icons or music or menu figures (as long as there is a common understanding of what means what - what is a script?) Describing the process would be like documenting the version of Apache being used to show an HTML page? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 14:33:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26189; Thu, 31 Mar 2005 14:33:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5Wm-0003ya-AO; Thu, 31 Mar 2005 14:40:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5P1-0004IZ-8Y; Thu, 31 Mar 2005 14:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5Oz-0004IL-SG for ltru@megatron.ietf.org; Thu, 31 Mar 2005 14:32:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26160 for ; Thu, 31 Mar 2005 14:32:24 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5W9-0003xb-Le for ltru@ietf.org; Thu, 31 Mar 2005 14:39:51 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2VJW9Pb012881; Thu, 31 Mar 2005 14:32:09 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 31 Mar 2005 14:32:03 -0500 Date: Thu, 31 Mar 2005 14:32:01 -0500 From: John Cowan To: Peter Constable Subject: Re: [Ltru] Language transformation Message-ID: <20050331193200.GG28005@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Peter Constable scripsit: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of M.T. > > Carrasco Benitez > > > > We could use another term; for example, "conversion" as used by the TC46/SC2. > > I do not recommend to use either the terms "transliteration" or "transcription" > > as we risk to start a polemy. > > I agree that "transliterations" are not as cut and dried as TC46 > makes them out to be. My only point was that there are many things > that fall in the category of "transcription" (clearly that and not > transliteration), such as IPA, that really aren't conversions or > transformations. I propose the term "trans*tions" for these unnatural acts of orthography, thus covering transliteration, transcription, and transformation. I further propose that the Right Thing with these is to use the RFC 3066bis language, optional script, and variant fields, using variants specifically chosen for the purpose: thus Wade-Giles could be zh-Latn-wadegiles, or just zh-wadegiles. The English-language trans*tion of Russian might be ru-transen or ru-Latn-transen; I think it is unnecessary to introduce an extension feature for this purpose. But I think it would be good to introduce an example (perhaps the wadegiles one) into the draft, to make it clear that variants may be orthographic as well as linguistic. -- Her he asked if O'Hare Doctor tidings sent from far John Cowan coast and she with grameful sigh him answered that www.ccil.org/~cowan O'Hare Doctor in heaven was. Sad was the man that word www.reutershealth.com to hear that him so heavied in bowels ruthful. All jcowan@reutershealth.com she there told him, ruing death for friend so young, algate sore unwilling God's rightwiseness to withsay. Ulysses, "Oxen" _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 14:44:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27213; Thu, 31 Mar 2005 14:44:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5iK-0004Oe-EO; Thu, 31 Mar 2005 14:52:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5ai-0005rJ-6u; Thu, 31 Mar 2005 14:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5ag-0005rD-MO for ltru@megatron.ietf.org; Thu, 31 Mar 2005 14:44:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27190 for ; Thu, 31 Mar 2005 14:44:29 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH5hr-0004O9-VR for ltru@ietf.org; Thu, 31 Mar 2005 14:51:56 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2VJiKCH012918; Thu, 31 Mar 2005 14:44:20 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 31 Mar 2005 14:44:31 -0500 Date: Thu, 31 Mar 2005 14:44:30 -0500 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: Language transformation Message-ID: <20050331194430.GH28005@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AD17D0B@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AD17D0B@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Addison Phillips scripsit: > However, using variants complicates matters. The transformation applied > to the text is only one dimension of the content. It may still have > a language ("zh"), a dialect (in 3066ter a 639-3 extland code, such > as wuu???), a script (Grek, Latn, Hant, etc.), a region (CN, HK, SG, > TW...), and a variant not related to the transformation itself. These > may be as important to tag the content with as the transformation > applied. The variant unrelated to the trans*tion is the only issue that would actually be a problem, and I'd like to see a RL example before I agree. > zh-wuu-CN-t-wadegile FWIW, Wade-Giles romanization doesn't handle anything but Mandarin. -- A: "Spiro conjectures Ex-Lax." John Cowan Q: "What does Pat Nixon frost her cakes with?" jcowan@reutershealth.com --"Jeopardy" for generative semanticists http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 15:13:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00713; Thu, 31 Mar 2005 15:13:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH69f-0005ZT-MT; Thu, 31 Mar 2005 15:20:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH60K-0002LG-E1; Thu, 31 Mar 2005 15:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH60J-0002L6-4E for ltru@megatron.ietf.org; Thu, 31 Mar 2005 15:10:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00397 for ; Thu, 31 Mar 2005 15:10:57 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH67T-0005SJ-Jr for ltru@ietf.org; Thu, 31 Mar 2005 15:18:24 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j2VKAWti013030; Thu, 31 Mar 2005 15:10:45 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 31 Mar 2005 15:10:12 -0500 Date: Thu, 31 Mar 2005 15:10:10 -0500 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Message-ID: <20050331201010.GA6550@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru , "L.Gillam" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a JFC (Jefsey) Morfin scripsit: > Open a dictionary. It will tell you five things about every word, plus > information on the meaning, nature and syntax: > > - the language (on the cover) > - the script (you see it) > - where it was published (ISSN-ISBN) or the title > - the author (on the cover) > - either it is standard style by default, or it mentions the style: fam. > pop, old, etc. Many dictionaries do not have this last item, particularly dictionaries of and in English, where the boundaries are extremely permeable. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 15:47:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04089; Thu, 31 Mar 2005 15:47:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6gP-0006qQ-2W; Thu, 31 Mar 2005 15:54:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH6Yh-0000F2-DQ; Thu, 31 Mar 2005 15:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH6Yd-0000Er-Rw for ltru@megatron.ietf.org; Thu, 31 Mar 2005 15:46:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04050 for ; Thu, 31 Mar 2005 15:46:26 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6fo-0006mb-FD for ltru@ietf.org; Thu, 31 Mar 2005 15:53:53 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 12:46:40 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 31 Mar 2005 12:46:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Language transformation Date: Thu, 31 Mar 2005 12:45:55 -0800 Message-ID: Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2HNGClNeGLJoCS0KCNCtW/V3OcQAAGANAAAU3z6A= From: "Peter Constable" To: X-OriginalArrivalTime: 31 Mar 2005 20:46:16.0000 (UTC) FILETIME=[AEDE5C00:01C53632] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > However, using variants complicates matters. The transformation applied to the text > is only one dimension of the content... The complication you site is that variants can distinguish dialectal variants, or variants in written form (just as region subtags can distinguish regional variations in dialect or regional variations in written form), and the two are not distinguish (any more than they are for region subtags). > Extensions allow this kind of semi-orthogonal, language-related distinction to be > applied. Consider: >=20 > zh-wuu-CN-t-wadegile I don't see why this is superior in any way to zh-wuu-CN-wadegile, and can see reasons why it's inferior: the extension is ignorable by anything that knows only RFC 3066bis and not some other extensions RFC. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 16:26:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13812; Thu, 31 Mar 2005 16:26:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7IC-0001ms-VF; Thu, 31 Mar 2005 16:33:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7AQ-00006L-51; Thu, 31 Mar 2005 16:25:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7AP-00006E-8y for ltru@megatron.ietf.org; Thu, 31 Mar 2005 16:25:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13776 for ; Thu, 31 Mar 2005 16:25:27 -0500 (EST) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7Ha-0001fx-Fj for ltru@ietf.org; Thu, 31 Mar 2005 16:32:55 -0500 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN8-9424c6ab49; Thu, 31 Mar 2005 16:25:08 -0500 Received: from DEBHOME (ACD8C638.ipt.aol.com [172.216.198.56]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2VLP58t003352; Thu, 31 Mar 2005 16:25:05 -0500 Message-Id: <200503312125.j2VLP58t003352@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Re: Language transformation Date: Thu, 31 Mar 2005 22:25:24 +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.2900.2180 Thread-Index: AcU2HNGClNeGLJoCS0KCNCtW/V3OcQAAGANAAAU3z6AAAXHe0A== In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Peter Constable wrote: >I don't see why this is superior in any way to zh-wuu-CN-wadegile, and can >see reasons why it's inferior: the extension is ignorable by anything that > knows only RFC 3066bis and not some other extensions RFC. Good point... unless of course the -t- is added to RFC3066bis Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Peter Constable Sent: 31 March 2005 21:46 To: ltru@ietf.org Subject: RE: [Ltru] Re: Language transformation > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > However, using variants complicates matters. The transformation applied to the text > is only one dimension of the content... The complication you site is that variants can distinguish dialectal variants, or variants in written form (just as region subtags can distinguish regional variations in dialect or regional variations in written form), and the two are not distinguish (any more than they are for region subtags). > Extensions allow this kind of semi-orthogonal, language-related distinction to be > applied. Consider: > > zh-wuu-CN-t-wadegile I don't see why this is superior in any way to zh-wuu-CN-wadegile, and can see reasons why it's inferior: the extension is ignorable by anything that knows only RFC 3066bis and not some other extensions RFC. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 16:30:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14140; Thu, 31 Mar 2005 16:30:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7MW-0001wd-EY; Thu, 31 Mar 2005 16:38:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7Ef-00011M-7T; Thu, 31 Mar 2005 16:29:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7Ed-00011H-Le for ltru@megatron.ietf.org; Thu, 31 Mar 2005 16:29:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14102 for ; Thu, 31 Mar 2005 16:29:49 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7Lp-0001vU-PQ for ltru@ietf.org; Thu, 31 Mar 2005 16:37:18 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 13:29:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Language transformation Date: Thu, 31 Mar 2005 13:29:38 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17E90@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2HNGClNeGLJoCS0KCNCtW/V3OcQAAGANAAAU3z6AAAXHe0AAAJsMg From: "Addison Phillips" To: "Debbie Garside" , "Peter Constable" , X-OriginalArrivalTime: 31 Mar 2005 21:29:39.0272 (UTC) FILETIME=[BE8A2480:01C53638] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Extensions are defined in the draft. They are separated from the rest of = the tag and identified by a singleton---a one letter subtag such as 't'. = My examples in this thread show an extension whose identifier is 't'. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Debbie Garside > Sent: jeudi 31 mars 2005 13:25 > To: 'Peter Constable'; ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > Peter Constable wrote: >=20 > >I don't see why this is superior in any way to zh-wuu-CN-wadegile, = and > can > >see reasons why it's inferior: the extension is ignorable by anything > that > > knows only RFC 3066bis and not some other extensions RFC. >=20 > Good point... unless of course the -t- is added to RFC3066bis >=20 > Debbie >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: 31 March 2005 21:46 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Addison Phillips >=20 >=20 > > However, using variants complicates matters. The transformation > applied to the text > > is only one dimension of the content... >=20 > The complication you site is that variants can distinguish dialectal > variants, or variants in written form (just as region subtags can > distinguish regional variations in dialect or regional variations in > written form), and the two are not distinguish (any more than they are > for region subtags). >=20 >=20 > > Extensions allow this kind of semi-orthogonal, language-related > distinction to be > > applied. Consider: > > > > zh-wuu-CN-t-wadegile >=20 > I don't see why this is superior in any way to zh-wuu-CN-wadegile, and > can see reasons why it's inferior: the extension is ignorable by > anything that knows only RFC 3066bis and not some other extensions = RFC. >=20 >=20 >=20 > Peter Constable >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:00:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16939; Thu, 31 Mar 2005 17:00:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7pe-00034t-Db; Thu, 31 Mar 2005 17:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7h3-00073H-8k; Thu, 31 Mar 2005 16:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7h1-00072Q-PQ for ltru@megatron.ietf.org; Thu, 31 Mar 2005 16:59:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16835 for ; Thu, 31 Mar 2005 16:59:09 -0500 (EST) Received: from web42005.mail.yahoo.com ([66.218.93.173]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH7oD-000332-43 for ltru@ietf.org; Thu, 31 Mar 2005 17:06:38 -0500 Received: (qmail 10185 invoked by uid 60001); 31 Mar 2005 21:59:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=CHhqPqe10VCqpToxmXQf7+CLOVa/Yiifbai7faS1efktYZbSOm2CyDbJ0aMVhdLbDFnfgNHIEwqMawsfC0T3RXoMHGPl7cC5xzzgqJvrpPk1h8iYwBRMI80lWLZ5wxeLViFh1XB+5W2y130Scq2TNkcFadZTT3FYybYX/aMFk74= ; Message-ID: <20050331215901.10183.qmail@web42005.mail.yahoo.com> Received: from [83.99.66.202] by web42005.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 22:59:01 BST Date: Thu, 31 Mar 2005 22:59:01 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit --- Mark Davis wrote: > > uri:http://somewhere.xxx/speficationofwidegiles > > > That very policy has been a disaster with IANA charsets. The references > don't supply a complete description, or are not stable. That's why I think > this is premature. It is not realistic for LTRU to try to specify every imaginable language transformation. The scope should be limited to provide the mechanism. The Registry for Schemes for Language Transformation should try to maintain a minimal discipline. But at the end of the date, it is up to the community interested in any particular transformation to take responsability. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:13:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17722; Thu, 31 Mar 2005 17:13:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH81c-0003TW-Sc; Thu, 31 Mar 2005 17:20:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7tt-0000lW-HR; Thu, 31 Mar 2005 17:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7tr-0000lR-Fl for ltru@megatron.ietf.org; Thu, 31 Mar 2005 17:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17681 for ; Thu, 31 Mar 2005 17:12:25 -0500 (EST) Received: from web42003.mail.yahoo.com ([66.218.93.171]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH812-0003Sp-Uo for ltru@ietf.org; Thu, 31 Mar 2005 17:19:54 -0500 Received: (qmail 3414 invoked by uid 60001); 31 Mar 2005 22:12:15 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ODrXztf0U4qkyb8DxFB31eX0HM+VEnE66mNuLvsaKGoAXZZwQ7/ZbvlViP3R6l++BG+8h5i1kg8Qd/MMOTvpiTlA0/Pe+p/gPBuJP9kU7G+fGGD2+n+s+6n8kpX+7o3bPWhNPTaU3bkOs5x+t3GTmPb8Gjou2NhU1xNRS+pLhVk= ; Message-ID: <20050331221215.3408.qmail@web42003.mail.yahoo.com> Received: from [83.99.66.202] by web42003.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 23:12:15 BST Date: Thu, 31 Mar 2005 23:12:15 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit --- "JFC (Jefsey) Morfin" wrote: > What should be considered is the result to the user. Yes. This is the point. > A recording or a > transcoding resulting in the same voice-text, look the same to me? I do not > see script difference between a voice, in Russian and a voice in English > speaking the same way? Questions can be about the sex, accent, timber, age > of the voice and about the speaking style? Same a short-hand or phonetic or > icons or music or menu figures (as long as there is a common understanding > of what means what - what is a script?) > > Describing the process would be like documenting the version of Apache > being used to show an HTML page? There is real need for tagging transliterations and the requirements are as discussed before. Some of your comments above might well fall in a similar model to transliteration; so any volunteer ? Other comments looks more like metadata, though the language is also metadata. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:21:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18214; Thu, 31 Mar 2005 17:21:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH89b-0003lW-8D; Thu, 31 Mar 2005 17:28:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH81i-0001wm-Qs; Thu, 31 Mar 2005 17:20:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH81h-0001wa-8Z for ltru@megatron.ietf.org; Thu, 31 Mar 2005 17:20:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18182 for ; Thu, 31 Mar 2005 17:20:30 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH88t-0003kj-IA for ltru@ietf.org; Thu, 31 Mar 2005 17:27:59 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 14:20:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Language transformation Date: Thu, 31 Mar 2005 14:20:15 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17EEF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2PuQB4aKkYQBxTsaFY1cpijwDzQAALQpQ From: "Addison Phillips" To: "M.T. Carrasco Benitez" , X-OriginalArrivalTime: 31 Mar 2005 22:20:16.0445 (UTC) FILETIME=[D0D5F6D0:01C5363F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable So let me understand... Are you proposing to create a *separate* standard for tagging = transliterations of content with its own registry? Or are you proposing = the inclusion of these items into language tags proper? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of M.T. Carrasco Benitez > Sent: jeudi 31 mars 2005 14:12 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Language transformation >=20 > --- "JFC (Jefsey) Morfin" wrote: > > What should be considered is the result to the user. >=20 > Yes. This is the point. >=20 > > A recording or a > > transcoding resulting in the same voice-text, look the same to me? I = do > not > > see script difference between a voice, in Russian and a voice in = English > > speaking the same way? Questions can be about the sex, accent, = timber, > age > > of the voice and about the speaking style? Same a short-hand or = phonetic > or > > icons or music or menu figures (as long as there is a common > understanding > > of what means what - what is a script?) > > > > Describing the process would be like documenting the version of = Apache > > being used to show an HTML page? >=20 > There is real need for tagging transliterations and the requirements = are > as > discussed before. >=20 > Some of your comments above might well fall in a similar model to > transliteration; so any volunteer ? Other comments looks more like > metadata, > though the language is also metadata. >=20 > Regards > Tomas >=20 >=20 > Send instant messages to your online friends = http://uk.messenger.yahoo.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:27:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18524; Thu, 31 Mar 2005 17:26:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8FA-0003tg-KO; Thu, 31 Mar 2005 17:34:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH87F-0002z9-DJ; Thu, 31 Mar 2005 17:26:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH87D-0002yx-LQ for ltru@megatron.ietf.org; Thu, 31 Mar 2005 17:26:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18471 for ; Thu, 31 Mar 2005 17:26:13 -0500 (EST) Received: from web42005.mail.yahoo.com ([66.218.93.173]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH8EQ-0003sm-80 for ltru@ietf.org; Thu, 31 Mar 2005 17:33:42 -0500 Received: (qmail 17480 invoked by uid 60001); 31 Mar 2005 22:26:05 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=y2+W3lrIL3IgsA74ojIPjdiO9bXbqLzsOFxS5K2LEnRyo/yW6Tse0k4/ki7NJSSRovobfX8TSb8ujD5q87JEJWuES6AOHbN2VyTaa9rqyfYfIB5zxoK83EgRW2rAr0RZVn2oFP2Syg4hEdVsEVEFSuCOAVRjeo2flWR3zuJZSso= ; Message-ID: <20050331222605.17478.qmail@web42005.mail.yahoo.com> Received: from [83.99.66.202] by web42005.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 23:26:05 BST Date: Thu, 31 Mar 2005 23:26:05 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit --- John Cowan wrote: > I propose the term "trans*tions" for these unnatural acts of orthography, > thus covering transliteration, transcription, and transformation. "trans*tions" would probably create more confusion than "transformation"; this last term covers both transliteration and transcription. TC46/SC2 uses the term "convertion" with the intention of covering also boths aspects. The term that most people associate with these unnatural acts is "transliteration". To use this we just have to: - Define it to cover also transcription and similar nuances. - Resist the attack of the purists. > I further propose that the Right Thing with these is to use the > RFC 3066bis language, optional script, and variant fields, using > variants specifically chosen for the purpose: thus Wade-Giles could > be zh-Latn-wadegiles, or just zh-wadegiles. The English-language > trans*tion of Russian might be ru-transen or ru-Latn-transen; I think > it is unnecessary to introduce an extension feature for this purpose. > > But I think it would be good to introduce an example (perhaps the > wadegiles one) into the draft, to make it clear that variants may be > orthographic as well as linguistic. On purpose, I was staying away from the syntax. Now I am going to have a harder look to the syntax. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:38:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19285; Thu, 31 Mar 2005 17:38:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8Pt-0004LV-5Q; Thu, 31 Mar 2005 17:45:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8I3-0004yV-1Z; Thu, 31 Mar 2005 17:37:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8I1-0004yN-9E for ltru@megatron.ietf.org; Thu, 31 Mar 2005 17:37:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19249 for ; Thu, 31 Mar 2005 17:37:22 -0500 (EST) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8PD-0004HM-QP for ltru@ietf.org; Thu, 31 Mar 2005 17:44:52 -0500 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN6-7424c7b8e52; Thu, 31 Mar 2005 17:37:03 -0500 Received: from DEBHOME (ACD8C638.ipt.aol.com [172.216.198.56]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j2VMaobk019725; Thu, 31 Mar 2005 17:36:51 -0500 Message-Id: <200503312236.j2VMaobk019725@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'M.T. Carrasco Benitez'" , Subject: RE: [Ltru] Re: Language transformation Date: Thu, 31 Mar 2005 23:37:10 +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.2900.2180 Thread-Index: AcU2PuQB4aKkYQBxTsaFY1cpijwDzQAALQpQAAChZbA= In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AD17EEF@irvmbxw01.quest.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 2.6 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Addison Phillips wrote: >Extensions are defined in the draft. They are separated from the rest of >the tag and identified by a singleton---a one letter subtag such as 't'. >My examples in this thread show an extension whose identifier is 't'. So... under section 3.4 a -t/T- singleton could be registered as defining transliteration subtags from the outset? Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Addison Phillips Sent: 31 March 2005 23:20 To: M.T. Carrasco Benitez; ltru@ietf.org Subject: RE: [Ltru] Re: Language transformation So let me understand... Are you proposing to create a *separate* standard for tagging transliterations of content with its own registry? Or are you proposing the inclusion of these items into language tags proper? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of M.T. Carrasco Benitez > Sent: jeudi 31 mars 2005 14:12 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Language transformation > > --- "JFC (Jefsey) Morfin" wrote: > > What should be considered is the result to the user. > > Yes. This is the point. > > > A recording or a > > transcoding resulting in the same voice-text, look the same to me? I do > not > > see script difference between a voice, in Russian and a voice in English > > speaking the same way? Questions can be about the sex, accent, timber, > age > > of the voice and about the speaking style? Same a short-hand or phonetic > or > > icons or music or menu figures (as long as there is a common > understanding > > of what means what - what is a script?) > > > > Describing the process would be like documenting the version of Apache > > being used to show an HTML page? > > There is real need for tagging transliterations and the requirements are > as > discussed before. > > Some of your comments above might well fall in a similar model to > transliteration; so any volunteer ? Other comments looks more like > metadata, > though the language is also metadata. > > Regards > Tomas > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:46:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19797; Thu, 31 Mar 2005 17:46:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8Xh-0004Wu-1U; Thu, 31 Mar 2005 17:53:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8PS-0006H1-IM; Thu, 31 Mar 2005 17:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8PQ-0006E5-PI for ltru@megatron.ietf.org; Thu, 31 Mar 2005 17:45:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19728 for ; Thu, 31 Mar 2005 17:44:59 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8WZ-0004VM-QF for ltru@ietf.org; Thu, 31 Mar 2005 17:52:29 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 14:44:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Language transformation Date: Thu, 31 Mar 2005 14:44:50 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17F1B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2PuQB4aKkYQBxTsaFY1cpijwDzQAALQpQAAChZbAAAApP0A== From: "Addison Phillips" To: "Debbie Garside" , X-OriginalArrivalTime: 31 Mar 2005 22:44:50.0801 (UTC) FILETIME=[3F9ED610:01C53643] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Yes, or at least from nearly the outset: the RFC would be adopted first. = Then section 3.4 could be used to define -t/T- as a singleton for a = transmutation extension. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: jeudi 31 mars 2005 14:37 > To: Addison Phillips; 'M.T. Carrasco Benitez'; ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > Addison Phillips wrote: >=20 > >Extensions are defined in the draft. They are separated from the rest = of > >the tag and identified by a singleton---a one letter subtag such as = 't'. >=20 > >My examples in this thread show an extension whose identifier is 't'. >=20 > So... under section 3.4 a -t/T- singleton could be registered as = defining > transliteration subtags from the outset? >=20 > Debbie >=20 >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: 31 March 2005 23:20 > To: M.T. Carrasco Benitez; ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > So let me understand... >=20 > Are you proposing to create a *separate* standard for tagging > transliterations of content with its own registry? Or are you = proposing > the > inclusion of these items into language tags proper? >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of M.T. Carrasco Benitez > > Sent: jeudi 31 mars 2005 14:12 > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: Language transformation > > > > --- "JFC (Jefsey) Morfin" wrote: > > > What should be considered is the result to the user. > > > > Yes. This is the point. > > > > > A recording or a > > > transcoding resulting in the same voice-text, look the same to me? = I > do > > not > > > see script difference between a voice, in Russian and a voice in > English > > > speaking the same way? Questions can be about the sex, accent, = timber, > > age > > > of the voice and about the speaking style? Same a short-hand or > phonetic > > or > > > icons or music or menu figures (as long as there is a common > > understanding > > > of what means what - what is a script?) > > > > > > Describing the process would be like documenting the version of = Apache > > > being used to show an HTML page? > > > > There is real need for tagging transliterations and the requirements = are > > as > > discussed before. > > > > Some of your comments above might well fall in a similar model to > > transliteration; so any volunteer ? Other comments looks more like > > metadata, > > though the language is also metadata. > > > > Regards > > Tomas > > > > > > Send instant messages to your online friends > http://uk.messenger.yahoo.com > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 17:48:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20016; Thu, 31 Mar 2005 17:48:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8Zo-0004fp-AK; Thu, 31 Mar 2005 17:55:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8Rl-0006Tp-Hr; Thu, 31 Mar 2005 17:47:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8Rk-0006Tk-Gq for ltru@megatron.ietf.org; Thu, 31 Mar 2005 17:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19908 for ; Thu, 31 Mar 2005 17:47:26 -0500 (EST) Received: from web42005.mail.yahoo.com ([66.218.93.173]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH8Yw-0004eI-94 for ltru@ietf.org; Thu, 31 Mar 2005 17:54:55 -0500 Received: (qmail 22922 invoked by uid 60001); 31 Mar 2005 22:47:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=EKcHeyYrCQZatsuZpegnanvKOgAimsL7PqhBjkbi3byozD8SUGK8nfmFn+zGIqSdLFRLg7WfQe+3/UrRZfZ0tPMpBVsSsD5W4S4bBV1ZsPQUfTDAXdR4QpbLBPBK4gv4lmD2+NlxOIRfJj7SnwGby8btXrHkS5xWWtBxDRKqW5s= ; Message-ID: <20050331224718.22920.qmail@web42005.mail.yahoo.com> Received: from [83.99.66.202] by web42005.mail.yahoo.com via HTTP; Thu, 31 Mar 2005 23:47:18 BST Date: Thu, 31 Mar 2005 23:47:18 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 8bit --- Addison Phillips wrote: > So let me understand... > > Are you proposing to create a *separate* standard for tagging transliterations of content with > its own registry? Or are you proposing the inclusion of these items into language tags proper? Transliteration should in the language tag proper. But LTRU should only provide the mechanism for including transliteration in the language tag. Example (pseudo-code): zh-wadegiles As proposed in section 4 of "Codes for language transformation" http://www1.ietf.org/mail-archive/web/ltru/current/msg00387.html "Two registries are need: - IANA - Schemes for Language Transformation" Lets call "wadegiles" the "transliteration identifier". As commented in a previous message, the IANA register should contain the list of unique transliteration identifier. Example: # Transformations transformation | widegile | | yyyy-mm-dd | | transformation | pinyin| | yyyy-mm-dd | | The Registry of Schemes for Language Transformation (out of scope of LTRU) should address the description of the transformation. Example: %% id:widegile sourcelang:zh targetlang:en uri:http://somewhere.xxx/speficationofwidegiles foo:foo %% id:pinyin sourcelang:zh targetlang:en uri:http://somewhereelse.xxx/speficationofpinyin foo:foo %% This registry should not address the methodology of the transformation. It should just point with the URI to the entity maintaining the methodology. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 18:01:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20823; Thu, 31 Mar 2005 18:01:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8mO-00058O-EA; Thu, 31 Mar 2005 18:08:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8et-0000eQ-Uj; Thu, 31 Mar 2005 18:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8eq-0000bK-AS for ltru@megatron.ietf.org; Thu, 31 Mar 2005 18:01:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20799 for ; Thu, 31 Mar 2005 18:00:57 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH8m1-00057o-9R for ltru@ietf.org; Thu, 31 Mar 2005 18:08:26 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 15:00:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Language transformation Date: Thu, 31 Mar 2005 15:00:42 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AD17F2D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2Q8dfZtNkTI/MQCWLNIdhnopkNAAABx/A From: "Addison Phillips" To: "M.T. Carrasco Benitez" , X-OriginalArrivalTime: 31 Mar 2005 23:00:42.0696 (UTC) FILETIME=[76FE7C80:01C53645] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Okay, I understand. It wasn't clear to me previously which way you = wanted to go. Some pointers and comments, then. First, for backward compatibility reasons subtags in language tags are = limited to eight characters (so 'wadegile', not 'wadegiles'). Then, I would point out that 3066bis as it sits defines a complete = syntax for language tags. The subtags are broken out according to type = and are identifiable by length and position in the tag. As John Cowan pointed out, we could have an orthographic variation such = as transliteration as an example of the variant type in the 3066bis = document. At present the only subtag type that can accommodate = transformation subtags would be registered variants. And variants = subtags must be defined in the language subtag registry to be valid in a = language tag. Syntax of the language tags and the interrelation between different = subtags is actually quite critical to progress of the 3066bis draft. I = would urge you to consider the current design carefully and think about = how your proposal could either fit into the existing design or how to = adapt the designs to one-another. I think that the options for what you want to do would be: a) add a new subtag type, distinguished from variants in some form, with = additional verbiage in the 3066bis draft describing any additional = information and usage information for that type b) don't distinguish transformations per-se, just register variants for = the different ones you're interested in on an ad hoc basis under 3066bis c) write an extension per the rules in 3066bis, which would allow you to = have a separate registry and syntax for the subtags and use them in = language tags I would very strongly oppose (a), personally, as I don't see = transformations as being significantly different from other language = variations to warrant greatly complicating the design of language tags = further. You may (or may not) find (b) to be sufficient to your needs. Thanks, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of M.T. Carrasco Benitez > Sent: jeudi 31 mars 2005 14:47 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > --- Addison Phillips wrote: > > So let me understand... > > > > Are you proposing to create a *separate* standard for tagging > transliterations of content with > > its own registry? Or are you proposing the inclusion of these items = into > language tags proper? >=20 > Transliteration should in the language tag proper. But LTRU should = only > provide the mechanism > for including transliteration in the language tag. Example = (pseudo-code): >=20 > zh-wadegiles >=20 > As proposed in section 4 of "Codes for language transformation" > http://www1.ietf.org/mail-archive/web/ltru/current/msg00387.html >=20 > "Two registries are need: >=20 > - IANA > - Schemes for Language Transformation" >=20 > Lets call "wadegiles" the "transliteration identifier". As commented = in a > previous message, > the IANA register should contain the list of unique transliteration > identifier. Example: >=20 > # Transformations > transformation | widegile | | yyyy-mm-dd | | > transformation | pinyin| | yyyy-mm-dd | | >=20 > The Registry of Schemes for Language Transformation (out of scope of = LTRU) > should address the description of the transformation. Example: >=20 > %% > id:widegile > sourcelang:zh > targetlang:en > uri:http://somewhere.xxx/speficationofwidegiles > foo:foo > %% > id:pinyin > sourcelang:zh > targetlang:en > uri:http://somewhereelse.xxx/speficationofpinyin > foo:foo > %% >=20 > This registry should not address the methodology of the = transformation. It > should > just point with the URI to the entity maintaining the methodology. >=20 > Regards > Tomas >=20 >=20 > Send instant messages to your online friends = http://uk.messenger.yahoo.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 18:23:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23490; Thu, 31 Mar 2005 18:23:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH97N-0005wF-RV; Thu, 31 Mar 2005 18:30:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8zd-0004TR-Ui; Thu, 31 Mar 2005 18:22:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH8zb-0004TJ-1K for ltru@megatron.ietf.org; Thu, 31 Mar 2005 18:22:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23456 for ; Thu, 31 Mar 2005 18:22:24 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH96m-0005sT-SU for ltru@ietf.org; Thu, 31 Mar 2005 18:29:54 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 15:22:28 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 31 Mar 2005 15:22:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Language transformation Date: Thu, 31 Mar 2005 15:22:20 -0800 Message-ID: Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2PSzNiR3LZfOFQpCNiQlerINsagACo2HA From: "Peter Constable" To: X-OriginalArrivalTime: 31 Mar 2005 23:22:23.0270 (UTC) FILETIME=[7E325460:01C53648] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of M.T. > Carrasco Benitez > > That very policy has been a disaster with IANA charsets. The references > > don't supply a complete description, or are not stable. That's why I think > > this is premature. >=20 > It is not realistic for LTRU to try to specify every imaginable language transformation. > The scope should be limited to provide the mechanism. The Registry for Schemes for > Language Transformation should try to maintain a minimal discipline. But at the end > of > the date, it is up to the community interested in any particular transformation to take > responsability. Let's be clear about the difference between documenting and providing some identifier for "transformations" on the one hand, and providing tags to declare the linguistic variety and form of content that may result from such "transformations" on the other.=20 Only the latter is relevant for RFC 3066bis; I will assume RFC 3066bis as proposed will be sufficient for such purposes unless scenarios suggesting otherwise can be provided. I'd have to take another look at the charter to see if the former is reasonably within scope for LTRU, but it doesn't seem unreasonable that it could be. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 23:33:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15955; Thu, 31 Mar 2005 23:33:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHDxV-00082K-K8; Thu, 31 Mar 2005 23:40:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHDpH-0000CK-OE; Thu, 31 Mar 2005 23:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHDpF-0000C7-S8 for ltru@megatron.ietf.org; Thu, 31 Mar 2005 23:32:05 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15821 for ; Thu, 31 Mar 2005 23:32:02 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050401043133.DUZF5402.mta11.adelphia.net@DEWELL> for ; Thu, 31 Mar 2005 23:31:33 -0500 Message-ID: <004901c53673$54593ac0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050331162223.SMHP2124.mta7.adelphia.net@megatron.ietf.org> Date: Thu, 31 Mar 2005 20:29:00 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit M.T. Carrasco Benitez wrote: > By the way, Armenians are celebrating this year the 1600th anniversary > of their script. It would be nice to go to the "Targmanchats Ton" > (translators day). This is a case of very successful standardisation: > would LTRU be here in 1600 years ? -:) Well, certainly not the working group. We're only chartered to do 2 documents, and the second is scheduled to go into Last Call this August. If you mean, "Will the revised language tagging standard exist and be relevant in 1600 years?" the answer is probably no. But then, most technology standards don't last as long as most writing systems, so that seems an odd comparison. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 31 23:38:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16250; Thu, 31 Mar 2005 23:38:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHE2f-0008GA-PD; Thu, 31 Mar 2005 23:45:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHDuN-00011p-8K; Thu, 31 Mar 2005 23:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHDuL-00011k-NI for ltru@megatron.ietf.org; Thu, 31 Mar 2005 23:37:21 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16214 for ; Thu, 31 Mar 2005 23:37:19 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050401043650.DYQW5402.mta11.adelphia.net@DEWELL> for ; Thu, 31 Mar 2005 23:36:50 -0500 Message-ID: <005001c53674$09fb5660$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050331180027.LYQV2135.mta4.adelphia.net@megatron.ietf.org> Date: Thu, 31 Mar 2005 20:34:05 -0800 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: 3166-1 state machine X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Peter Constable wrote: >> Is there a point after which erroneous usage becomes common enough to >> be taken so seriously that it be recognized? > > Certainly a valid question for a case like "UK". It is one thing > to specify what is *supposed* to be done; it is another for > implementations to actually support de facto practice. I can certainly imagine an language-tag-generating application being kind and forgiving enough to replace 'UK' with 'GB'. That would be up to the application, though, not part of the standard. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru