From bortzmeyer@nic.fr Wed Jul 1 00:09:41 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414AC3A6F04 for ; Wed, 1 Jul 2009 00:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfLyUsaACjul for ; Wed, 1 Jul 2009 00:09:40 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 526E93A6F17 for ; Wed, 1 Jul 2009 00:09:32 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7D2CC1C006A; Wed, 1 Jul 2009 09:04:52 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 78EBC1C0027; Wed, 1 Jul 2009 09:04:52 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 76EAAA1D9AF; Wed, 1 Jul 2009 09:04:52 +0200 (CEST) Date: Wed, 1 Jul 2009 09:04:56 +0200 From: Stephane Bortzmeyer To: Mark Davis ? Message-ID: <20090701070456.GA29061@nic.fr> References: <30b660a20906271138o186f82a5xd2531f70806ab3be@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20906271138o186f82a5xd2531f70806ab3be@mail.gmail.com> X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: LTRU Working Group Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 07:09:41 -0000 On Sat, Jun 27, 2009 at 11:38:07AM -0700, Mark Davis ? wrote a message of 39 lines which said: > I updated the demo at http://unicode.org/cldr/utility/languageid.jsp > to parse extlangs. The samples include official languages and the > scripts they use (based on CLDR data), and the names have > localizations where available. 1) When asking for 'ca', the language is correctly identified but the link from 'ca' goes to 'cat'. I understand the rationale (always link to the Ethnologue) but it is confusing. It is even worse if you type 'fra', your interface redirects to 'fr' but then offers a link to 'fra'. 2) How do you choose the language name to display? 'zza' has four names in Ethnologue (and in 4645bis), why displaying only 'Zaza'? Because it is the first one in 4645bis? From mark.edward.davis@gmail.com Wed Jul 1 07:13:24 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB3528C534 for ; Wed, 1 Jul 2009 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrwOpj2-GYai for ; Wed, 1 Jul 2009 07:13:23 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 8EB2D28C528 for ; Wed, 1 Jul 2009 07:13:23 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so350649anc.4 for ; Wed, 01 Jul 2009 07:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=2DFsS6JSqlTmH3YpFHs0MfGYS6JTskOs+1ObmGct3xA=; b=RWPzi7HE4q7ahOQs2bfcUAfys9bCmJ9yu54cBDyKYyr8eiW+MYM8cPUlMAbNNNS3yJ /24ipbtSUS0iCUup5rTtAs6y9M+5O43frz9vFTZttnGrhD6bihOaPvLgbSFSMGlCvuZ/ nYKofroJPdlDylyH1YlthzM3GcSrNFO9MP4h4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=iKlKLJXwqib3r8dDAT+B1PVQDD3yuegsIPNxju0ME3fpdhaNw9ylBWmKEekq6A0Wb0 XRkAdyHDfpaHY5hrbiQQJrQwn3+kGATSU9ZGoZ005V+i8Z5Xa/+7eIwVs7lXgoQ1A3x2 2m0//dPlmsMkjfM525esXsxuXRmk7tsz62Mxc= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.250.14 with SMTP id x14mr13415168anh.144.1246457538180; Wed, 01 Jul 2009 07:12:18 -0700 (PDT) In-Reply-To: <20090701070456.GA29061@nic.fr> References: <30b660a20906271138o186f82a5xd2531f70806ab3be@mail.gmail.com> <20090701070456.GA29061@nic.fr> Date: Wed, 1 Jul 2009 07:12:18 -0700 X-Google-Sender-Auth: b5ac156763962fd3 Message-ID: <30b660a20907010712o48d760fdla07b86bf33789210@mail.gmail.com> From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=0016368e1f88ca7534046da58284 Cc: LTRU Working Group Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:13:24 -0000 --0016368e1f88ca7534046da58284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks for the feedback. Mark On Wed, Jul 1, 2009 at 00:04, Stephane Bortzmeyer wrote: > On Sat, Jun 27, 2009 at 11:38:07AM -0700, > Mark Davis ? wrote > a message of 39 lines which said: > > > I updated the demo at http://unicode.org/cldr/utility/languageid.jsp > > to parse extlangs. The samples include official languages and the > > scripts they use (based on CLDR data), and the names have > > localizations where available. > > 1) When asking for 'ca', the language is correctly identified but the > link from 'ca' goes to 'cat'. I understand the rationale (always link > to the Ethnologue) but it is confusing. It is even worse if you type > 'fra', your interface redirects to 'fr' but then offers a link to > 'fra'. I requested some time ago that SIL treat both 2 letter and 3 letter codes equivalently in linking, but as yet no progress. If they do that, we could have: http://www.sil.org/iso639-3/documentation.asp?id=fr instead of http://www.sil.org/iso639-3/documentation.asp?id=fra So that's the only way to get at the code. But on that page it does list 639-1. It probably needs more explanation (the UI is *very* sparse), but I think that's the best I can do for now. > > 2) How do you choose the language name to display? 'zza' has four > names in Ethnologue (and in 4645bis), why displaying only 'Zaza'? > Because it is the first one in 4645bis? Yes. > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --0016368e1f88ca7534046da58284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the feedback.

Mark


On Wed, Jul 1, 2009 at 00:04, Stephane B= ortzmeyer <bortzm= eyer@nic.fr> wrote:
On Sat, Jun 27, 2009 at 11:38:07AM -0700,
=C2=A0Mark Davis ? <mark@macchiato= .com> wrote
=C2=A0a message of 39 lines which said:
> I updated the demo at http://unicode.org/cldr/utility/languageid.jsp=
> to parse extlangs. The samples include official languages and the
> scripts they use (based on CLDR data), and the names have
> localizations where available.

1) When asking for 'ca', the language is correctly iden= tified but the
link from 'ca' goes to 'cat'. I understand the rationale (a= lways link
to the Ethnologue) but it is confusing. It is even worse if you type
'fra', your interface redirects to 'fr' but then offers a l= ink to
'fra'.

I requested some time ago that SIL trea= t both 2 letter and 3 letter codes equivalently in linking, but as yet no p= rogress. If they do that, we could have:

http://www.sil.org/iso639-3/document= ation.asp?id=3Dfr

instead of

http://www.sil.org/iso639-3/documentation.asp?id=3Dfra
So that's the only way to get at the code. But on that page it do= es list 639-1. It probably needs more explanation (the UI is very sp= arse), but I think that's the best I can do for now.



2) How do you choose the language name to display? 'zza' has four names in Ethnologue (and in 4645bis), why displaying only 'Zaza'? Because it is the first one in 4645bis?

Yes.
=C2=A0=





_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--0016368e1f88ca7534046da58284-- From addison@amazon.com Wed Jul 1 13:24:20 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AEF3A682E for ; Wed, 1 Jul 2009 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxce6EWzo0vp for ; Wed, 1 Jul 2009 13:24:19 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by core3.amsl.com (Postfix) with ESMTP id 672893A6838 for ; Wed, 1 Jul 2009 13:24:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,327,1243814400"; d="scan'208";a="290042600" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2009 20:24:34 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id n61KOX9Z004485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 1 Jul 2009 20:24:34 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.30]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Wed, 1 Jul 2009 13:24:33 -0700 From: "Phillips, Addison" To: Stephane Bortzmeyer , Mark Davis ? Date: Wed, 1 Jul 2009 13:24:32 -0700 Thread-Topic: [Ltru] updated demo Thread-Index: Acn6GwRIEuyJUxnORBO/xPHO3zaNGgAbgI+g Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA01AAEFD1F5@EX-SEA5-D.ant.amazon.com> References: <30b660a20906271138o186f82a5xd2531f70806ab3be@mail.gmail.com> <20090701070456.GA29061@nic.fr> In-Reply-To: <20090701070456.GA29061@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: LTRU Working Group Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:24:20 -0000 PiAyKSBIb3cgZG8geW91IGNob29zZSB0aGUgbGFuZ3VhZ2UgbmFtZSB0byBkaXNwbGF5PyAnenph JyBoYXMgZm91cg0KPiBuYW1lcyBpbiBFdGhub2xvZ3VlIChhbmQgaW4gNDY0NWJpcyksIHdoeSBk aXNwbGF5aW5nIG9ubHkgJ1phemEnPw0KPiBCZWNhdXNlIGl0IGlzIHRoZSBmaXJzdCBvbmUgaW4g NDY0NWJpcz8NCg0KTm90ZSB0aGF0IHRoZSBmaXJzdCBuYW1lIGlzIHR5cGljYWxseSB0aGUgSVNP IDYzOS0zIHJlZmVyZW5jZSBuYW1lLCBzZWU6DQoNCiAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1sdHJ1LTQ2NDZiaXMtMjMjc2VjdGlvbi0zLjEuNQ0KDQpBZGRpc29uDQoN CkFkZGlzb24gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIExhYjEyNg0KDQpJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0 dXJlLg0KDQoNCg0K From doug@ewellic.org Fri Jul 3 08:23:03 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2843A6E7B for ; Fri, 3 Jul 2009 08:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50tn5NOWItLW for ; Fri, 3 Jul 2009 08:23:01 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 690CC3A67EB for ; Fri, 3 Jul 2009 08:23:01 -0700 (PDT) Received: (qmail 1131 invoked from network); 3 Jul 2009 15:20:51 -0000 Received: from unknown (67.166.27.148) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 03 Jul 2009 15:20:50 -0000 Message-ID: <5AEC4B04EA2142C49786C1420B21EB83@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 3 Jul 2009 09:20:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:23:03 -0000 "Phillips, Addison" wrote: > Note that the first name is typically the ISO 639-3 reference name, > see: > > http://tools.ietf.org/html/draft-ietf-ltru-4646bis-23#section-3.1.5 In fact, draft-4645bis moves things around when possible to ensure that the ISO 639-3 reference name is first, see: http://tools.ietf.org/html/draft-ietf-ltru-4645bis-10#section-2.3 That said, tools should attempt to display all of the Description fields when possible, and use the first Description field alone only when some constraint prevents displaying the others. All of the Description fields are correct for the given subtag. We just had another thread on ietf-languages in which a contributor apparently thought 'ca' was inadequate to tag "Valencian" content; I don't know if that was because "Catalan" is listed first or because he truly believes they are different languages. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From mark.edward.davis@gmail.com Fri Jul 3 10:20:36 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7107028C2E7 for ; Fri, 3 Jul 2009 10:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blv7Uju6Y-h9 for ; Fri, 3 Jul 2009 10:20:35 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id D714C28C2F3 for ; Fri, 3 Jul 2009 10:19:07 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so965427anc.4 for ; Fri, 03 Jul 2009 10:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=o43g/ZqU6yp7Y+WLnKf6ECQSUSq7FvQ9xMpmK6ztBt8=; b=Sbfs8/TVUJ0RI5a6IqEeTtlOiVdvKiCeQGfx4Gq5dY1S2zSOd/kqmEeD/FmulT1MWo 1GdHYKWmiwKq9rLHMe6GK69Dx01r9bOMsz0s+pZG5SNUqzOG5tzT7hro/qujla5sM63c Au2Gq8Ss6PtOnq+jR2SpteMmY0vEARFZLtvuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=s+WdAEZSRF0l2jP953KmW4eCIrIm9Us56h8tq846HjiDy2oml5uvH/a/m8Z2nSjN5H 3IXUrbbEj7LdOqaLn1PtnzDd3+LTjaHJu+SbKzr+c2eP6dCaUnTlNESosYd+ZT4/Qlxy p9ScEybsNHh0NA6NVG1k3hHf2/VlkjquWMIiA= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.251.6 with SMTP id y6mr2597600anh.44.1246641569444; Fri, 03 Jul 2009 10:19:29 -0700 (PDT) In-Reply-To: <5AEC4B04EA2142C49786C1420B21EB83@DGBP7M81> References: <5AEC4B04EA2142C49786C1420B21EB83@DGBP7M81> Date: Fri, 3 Jul 2009 10:19:29 -0700 X-Google-Sender-Auth: eea5fdfd33ddb355 Message-ID: <30b660a20907031019j6bddb67aq83fa8617ef19e4ac@mail.gmail.com> From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= To: Doug Ewell Content-Type: multipart/alternative; boundary=0016e68b6b2fe8b661046dd05bc5 Cc: LTRU Working Group Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 17:20:36 -0000 --0016e68b6b2fe8b661046dd05bc5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The concatenated Descriptions are much too long in some environments. In a UI pulldown list or menu, for example, displaying all of the names is not really feasible; it leads to much too wide a list for normal UIs. Moreover, the list of Descriptions may or may not make sense for translation. Note, for example, in my demo I even deleted the parentheticals where possible* to shorten the names up. The demo is not subject to such length restrictions, but, but I wanted to be more realistic.http://docs.google.com/View?id=3Ddfqr8rd5_25f4mx9qhr The reference names need to be unique. In an ideal world, they could also b= e used as backup names for UIs, where localizations don't exist. For that, they would be as short as possible but complete enough to prevent misunderstandings. So 'ca' might be "Catalan/Valencian" or something like that. But that was not a goal for the first Descriptions in this version of the registry. Mark On Fri, Jul 3, 2009 at 08:20, Doug Ewell wrote: > "Phillips, Addison" wrote: > > Note that the first name is typically the ISO 639-3 reference name, see: >> >> http://tools.ietf.org/html/draft-ietf-ltru-4646bis-23#section-3.1.5 >> > > In fact, draft-4645bis moves things around when possible to ensure that t= he > ISO 639-3 reference name is first, see: > > http://tools.ietf.org/html/draft-ietf-ltru-4645bis-10#section-2.3 > > That said, tools should attempt to display all of the Description fields > when possible, and use the first Description field alone only when some > constraint prevents displaying the others. All of the Description fields > are correct for the given subtag. > > We just had another thread on ietf-languages in which a contributor > apparently thought 'ca' was inadequate to tag "Valencian" content; I don'= t > know if that was because "Catalan" is listed first or because he truly > believes they are different languages. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --0016e68b6b2fe8b661046dd05bc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The concatenated Descriptions are much too long in some environments. In a = UI pulldown list or menu, for example, displaying all of the names is not r= eally feasible; it leads to much too wide a list for normal UIs. Moreover, = the list of Descriptions may or may not make sense for translation.

Note, for example, in my demo I even deleted the parentheticals where p= ossible* to shorten the names up. The demo is not subject to such length re= strictions, but, but I wanted to be more realistic. http://docs.google.com/View?id=3Ddfqr8rd5= _25f4mx9qhr

The reference names need to be unique. In an ideal world, they could al= so be used as backup names for UIs, where localizations don't exist. Fo= r that, they would be as short as possible but complete enough to prevent m= isunderstandings. So 'ca' might be "Catalan/Valencian" or= something like that. But that was not a goal for the first Descriptions in= this version of the registry.

Mark


On Fri, Jul 3, 2009 at 08:20, Doug Ewell= <doug@ewellic.org> wrote:
"Phillips, Addison" <addison at amazon dot com> wrote:=

Note that the first name is typically the ISO 639-3 reference name, see:
=C2=A0http://tools.ietf.org/html/draft-ietf-ltru-464= 6bis-23#section-3.1.5

In fact, draft-4645bis moves things around when possible to ensure that the= ISO 639-3 reference name is first, see:

http://tools.ietf.org/html/draft-ietf-ltru-4645bis-10#= section-2.3

That said, tools should attempt to display all of the Description fields wh= en possible, and use the first Description field alone only when some const= raint prevents displaying the others. =C2=A0All of the Description fields a= re correct for the given subtag.

We just had another thread on ietf-languages in which a contributor apparen= tly thought 'ca' was inadequate to tag "Valencian" conten= t; I don't know if that was because "Catalan" is listed first= or because he truly believes they are different languages.

--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86


_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--0016e68b6b2fe8b661046dd05bc5-- From felix.sasaki@googlemail.com Fri Jul 3 11:36:20 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0ECD28C28E for ; Fri, 3 Jul 2009 11:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sflp74x3lyD for ; Fri, 3 Jul 2009 11:36:19 -0700 (PDT) Received: from mail-bw0-f207.google.com (mail-bw0-f207.google.com [209.85.218.207]) by core3.amsl.com (Postfix) with ESMTP id 682833A6403 for ; Fri, 3 Jul 2009 11:36:19 -0700 (PDT) Received: by bwz3 with SMTP id 3so514749bwz.37 for ; Fri, 03 Jul 2009 11:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=p1wnnsHwKO/X58vsebG0V9BECWlhbFgH26MDUxkG598=; b=v1nqWifvlgArVkaqad8a69tlNXYOzhCivrRigsML3FI56ebdTsJJlo11XH3QVDHJYF kwt0ugnxWGlaqH8kltd69fmV9D+eSDOEJvf+pOke79jHWu0fmlfmt3VQtiLFw19aa0BZ m9i+shGqkv5+E+Pe9VtWVRDMxnxN++F6mi6XU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rFXC8X4ZmBJGWyM6RxNKZ/HOT4+FLJB5DNRCHL0+oYvLdPhbETRkPDqGcb4jTO2NcQ KxujqPPNWPL/fyyMhax9fjwl9+Zxae28Z73IxnqUy1iEWNC2AuJyFGfrdFW2+7USQCzf YOPIB8dgCpqklOsIW9cLdPgIB6tGwj0VnmqRY= MIME-Version: 1.0 Sender: felix.sasaki@googlemail.com Received: by 10.223.109.148 with SMTP id j20mr1147778fap.43.1246646199996; Fri, 03 Jul 2009 11:36:39 -0700 (PDT) In-Reply-To: <5AEC4B04EA2142C49786C1420B21EB83@DGBP7M81> References: <5AEC4B04EA2142C49786C1420B21EB83@DGBP7M81> Date: Sat, 4 Jul 2009 03:36:39 +0900 X-Google-Sender-Auth: cd7773d3ab0c7f3e Message-ID: From: Felix Sasaki To: Doug Ewell Content-Type: multipart/alternative; boundary=001636c5b54fe954d3046dd16fcb Cc: LTRU Working Group Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 18:36:21 -0000 --001636c5b54fe954d3046dd16fcb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2009/7/4 Doug Ewell > "Phillips, Addison" wrote: > > Note that the first name is typically the ISO 639-3 reference name, see: >> >> http://tools.ietf.org/html/draft-ietf-ltru-4646bis-23#section-3.1.5 >> > > In fact, draft-4645bis moves things around when possible to ensure that t= he > ISO 639-3 reference name is first, see: > > http://tools.ietf.org/html/draft-ietf-ltru-4645bis-10#section-2.3 > > That said, tools should attempt to display all of the Description fields > when possible That is what you get from http://www.w3.org/2008/05/lta/language-tags/04/q?input=3Dca Felix > , and use the first Description field alone only when some constraint > prevents displaying the others. All of the Description fields are correc= t > for the given subtag. > > We just had another thread on ietf-languages in which a contributor > apparently thought 'ca' was inadequate to tag "Valencian" content; I don'= t > know if that was because "Catalan" is listed first or because he truly > believes they are different languages. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 > http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages =CB=86 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --001636c5b54fe954d3046dd16fcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2009/7/4 Doug Ewell &l= t;doug@ewellic.org>
"Phillips, Addison" <addison at amazon dot c= om> wrote:

Note that the first name is typically the ISO 639-3 reference name, see:
=C2=A0http://tools.ietf.org/html/draft-ietf-ltru-464= 6bis-23#section-3.1.5

In fact, draft-4645bis moves things around when possible to ensure that the= ISO 639-3 reference name is first, see:

http://tools.ietf.org/html/draft-ietf-ltru-4645bis-10#= section-2.3

That said, tools should attempt to display all of the Description fields wh= en possible
, and use the first Description field alone only when some cons= traint prevents displaying the others. =C2=A0All of the Description fields = are correct for the given subtag.

We just had another thread on ietf-languages in which a contributor apparen= tly thought 'ca' was inadequate to tag "Valencian" conten= t; I don't know if that was because "Catalan" is listed first= or because he truly believes they are different languages.

--
Doug Ewell =C2=A0* =C2=A0Thornton, Colorado, USA =C2=A0* =C2=A0RFC 4645 =C2= =A0* =C2=A0UTN #14
http://www.ewellic.org=
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages = =C2=A0=CB=86


_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--001636c5b54fe954d3046dd16fcb-- From doug@ewellic.org Fri Jul 3 14:46:33 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061083A6CD5 for ; Fri, 3 Jul 2009 14:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LemF3OgQcezL for ; Fri, 3 Jul 2009 14:46:32 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id 1CDDF3A6B3D for ; Fri, 3 Jul 2009 14:46:31 -0700 (PDT) Received: (qmail 2597 invoked from network); 3 Jul 2009 21:46:22 -0000 Received: from unknown (67.166.27.148) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 03 Jul 2009 21:46:21 -0000 Message-ID: <760BF78CF7B049FA981F2B1A7B3C5C80@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <5AEC4B04EA2142C49786C1420B21EB83@DGBP7M81> <30b660a20907031019j6bddb67aq83fa8617ef19e4ac@mail.gmail.com> Date: Fri, 3 Jul 2009 15:46:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] updated demo X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 21:46:33 -0000 Mark Davis ⌛ wrote: > The concatenated Descriptions are much too long in some environments. > In a UI pulldown list or menu, for example, displaying all of the > names is not really feasible; it leads to much too wide a list for > normal UIs. I did say, "... only when some constraint prevents displaying the others." If you have a drop-down list, that would be such a constraint. I do the same thing in my app: if you type "ca" the drop-down list shows "Catalan," but both "Catalan" and "Valencian" are available on the drop-down list, and both display "ca". -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Tue Jul 7 10:18:39 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1136028C29E; Tue, 7 Jul 2009 10:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt3pQVoEpy-e; Tue, 7 Jul 2009 10:18:38 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5354C28C1A0; Tue, 7 Jul 2009 10:18:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=O+uMr/Lbj4VR4L1vy8GxIHSekz1rn8lY8PnkWre9A6Ah16kye2HV4gS+b+JSqE9X; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.54.210] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MOEJs-0004tJ-F5; Tue, 07 Jul 2009 13:19:04 -0400 Message-ID: <000c01c9ff27$320ba080$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , , "LTRU Working Group" Date: Tue, 7 Jul 2009 10:20:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968be78fbd4ba659d6b4152c9d11d582874350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.210 Subject: [Ltru] Fw: 75th IETF - Final Agenda X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:18:39 -0000 Hi - Forwarded for your information. Randy > From: "IETF Agenda" > To: "IETF Announcement list" > Cc: ; ; > Sent: Monday, July 06, 2009 10:40 PM > Subject: 75th IETF - Final Agenda > > The Final agenda is now available at: > http://www.ietf.org/meetings/75/ > > Online registration for the IETF meeting is at: > http://www.ietf.org/meetings/75/ > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From addison@amazon.com Mon Jul 13 08:26:35 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718113A6E04 for ; Mon, 13 Jul 2009 08:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNPTAT+lN+BG for ; Mon, 13 Jul 2009 08:26:34 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 9FD1D3A6930 for ; Mon, 13 Jul 2009 08:26:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,390,1243814400"; d="scan'208";a="211956569" Received: from smtp-in-4104.sea5.amazon.com ([10.248.183.18]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2009 15:26:26 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-4104.sea5.amazon.com (8.12.11/8.12.11) with ESMTP id n6DFQH8R028658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 13 Jul 2009 15:26:25 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.30]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Mon, 13 Jul 2009 08:26:17 -0700 From: "Phillips, Addison" To: LTRU Working Group Date: Mon, 13 Jul 2009 08:26:14 -0700 Thread-Topic: rechartering to handle 639-6 (was FW: Anomaly in upcoming registry) Thread-Index: AcoDhjP0pruGgNzSSzq8ZllMHrw18gARtoTA Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Ltru] rechartering to handle 639-6 (was FW: Anomaly in upcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:26:35 -0000 UmFuZHkgcG9zdGVkIHRvIHRoZSBpZXRmLWxhbmd1YWdlcyB0aHJlYWQgKGJlbG93KSB0aGF0IG1v c3Qgb2YgeW91IGFyZSBwcm9iYWJseSBhd2FyZSBvZiwgdGhlIGZvbGxvd2luZyBtZXNzYWdlLiBJ J20gY3Jvc3MtcG9zdGluZyBpdCBzbyB0aGF0IEkgY2FuIHJlc3BvbmQuDQoNCkkgb3Bwb3NlIHJl Y2hhcnRlcmluZyBMVFJVIGF0IHRoaXMgdGltZS4gV2UndmUgY29tcGxldGVkIHRoZSBlc3NlbnRp YWwgd29yayBvZiBpbmNvcnBvcmF0aW5nIElTTyA2MzktMyBhbmQgb3VyIHdvcmsgaGFzIGJyb3Vn aHQgYSBmZXcgb3RoZXIgZW5oYW5jZW1lbnRzLiBJIHRoaW5rIHdlJ3ZlIGFsbG93ZWQgc3VmZmlj aWVudCByb29tIGZvciB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgdG8gZG8gaXRzIG1hZ2ljIGFu ZCBoYW5kbGUgbW9zdCBvZiB0aGUgbGFuZ3VhZ2UgaWRlbnRpZmljYXRpb24gY29tbXVuaXR5J3Mg bmVlZHMuIEkgd291bGQgbGlrZSB0byBzZWUgdGhlIG5ldyBkb2N1bWVudCBpbiB1c2UgZm9yIGF3 aGlsZSBiZWZvcmUgd2UgZ28gdG8gdGlua2VyaW5nIHdpdGggaXQuDQoNCklmIElTTyA2MzktNiB3 ZXJlIHJlYWR5IChhcyBpdCBpcyBub3QpLCB0aGVuIExUUlUgY291bGQgYmUgcmVjb25zdGl0dXRl ZCB0byBsb29rIGludG8gd2hldGhlciBvciBub3QgdG8gaW5jb3Jwb3JhdGUgaXQgKGFuZCBpZiBz bywgaG93KS4gSSBzdXNwZWN0IGl0IG1pZ2h0IGJlIGEgY291cGxlIG9mIHllYXJzIGJlZm9yZSB0 aGF0IGlzIHVwb24gdXMuIEluIHRoZSBtZWFudGltZSwgd2UgY291bGQgdXNlIHNvbWUgZXhwZXJp ZW5jZSB3aXRoIHJmYy10by1iZS00NjQ2YmlzLiBDb25zdGFudCByZXdyaXRpbmcgd2lsbCBub3Qg aW1wcm92ZSBtYXR0ZXJzLg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCAtLSBMYWIxMjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4N Ckl0IGlzIGFuIGFyY2hpdGVjdHVyZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGlldGYtbGFuZ3VhZ2VzLWJvdW5jZXNAYWx2ZXN0cmFuZC5ubyBbbWFpbHRvOmlldGYtbGFu Z3VhZ2VzLWJvdW5jZXNAYWx2ZXN0cmFuZC5ub10gT24gQmVoYWxmIE9mIFJhbmR5IFByZXN1aG4N ClNlbnQ6IFN1bmRheSwgSnVseSAxMiwgMjAwOSAxMTo1MSBQTQ0KVG86IGlldGYtbGFuZ3VhZ2Vz QGlhbmEub3JnDQpTdWJqZWN0OiBSZTogQW5vbWFseSBpbiB1cGNvbWluZyByZWdpc3RyeQ0KDQpI aSAtDQoNCkRpc2N1c3Npb24gb2YgcmUtY2hhcnRlcmluZyB0aGUgbHRydSB3b3JraW5nIGdyb3Vw IGJlbG9uZ3Mgb24NCnRoZSBsdHJ1QGlldGYub3JnIG1haWxpbmcgbGlzdCwgbm90IGhlcmUuICBU aGlzIGlzIHRoZSB0aW1lDQpmb3Igc3VjaCBkaXNjdXNzaW9ucy4NCg0KUmFuZHkNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiR2VyYXJkIE1laWpzc2VuIiA8Z2VyYXJkLm1l aWpzc2VuQG9wZW5wcm9ncmVzcy5vcmc+DQpUbzogIkRvdWcgRXdlbGwiIDxkb3VnQGV3ZWxsaWMu b3JnPg0KQ2M6IDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4NClNlbnQ6IFN1bmRheSwgSnVseSAx MiwgMjAwOSAxMToyOCBQTQ0KU3ViamVjdDogUmU6IEFub21hbHkgaW4gdXBjb21pbmcgcmVnaXN0 cnkNCg0KDQpIb2ksDQpXaXRoIGFsbCBkdWUgcmVzcGVjdCBmb3IgdGhlIGRpbGlnZW5jZSBvZiB0 aGUgcHJvY2VzcyBidXQgd2hlbiB5b3UgY29uc2lkZXINCnRoZSBsZW5ndGggb2YgdGltZSBpdCB0 b29rLCB0aGUgSVNPLTYzOS02IHdpbGwgbWFrZSB0aGlzIHNhbWUgcHJvY2Vzcw0KaW1wb3NzaWJs ZSBiZWNhdXNlIG9mIHRoZSBhbW91bnQgb2YgZGF0YSBpbnZvbHZlZC4gV2hlbiB0aGlzIHByb2Nl c3Mgb25seQ0Kc3RhcnRzIHdoZW4gdGhlIHB1YmxpY2F0aW9uIGlzIGltbWluZW50LCBpdCB3aWxs IHRha2UgbWF5YmUgYXQgbGVhc3QgYQ0KZGVjYWRlIGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgbmV3 IGVudHJpZXMgdGhhdCBJU08gNjM5LTYgd2lsbCBicmluZy4gVGhhdA0KbWVhbnMgaW1obyB0aGF0 IGZvciBJU08tNjM5LTYgd2Ugd2lsbCBoYXZlIHRvIHJldGhpbmsgdGhlIHByb2Nlc3MuIFdlIGRv DQpoYXZlIHJvb20gYmVmb3JlIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgbmV3IHN0YW5kYXJkLi4g aXQgY291bGQgYmUgc2VlbiBhcw0KcHJlLWVtcHRpdmUgaW52b2x2ZW1lbnQgYmVjYXVzZSBvZiB0 aGUgaHVnZSBhbW91bnQgb2YgZGF0YSBpbnZvbHZlZC4NClRoYW5rcywNCiAgICAgICBHZXJhcmQN Cg0KMjAwOS83LzEzIERvdWcgRXdlbGwgPGRvdWdAZXdlbGxpYy5vcmc+DQoNCj4gUmFuZHkgUHJl c3VobiA8cmFuZHkgdW5kZXJzY29yZSBwcmVzdWhuIGF0IG1pbmRzcHJpbmcgZG90IGNvbT4gd3Jv dGU6DQo+DQo+ID4gVGhlcmUncyBubyB3YXkgdGhhdCBJJ2QgYmUgd2lsbGluZyB0byBzdGFydCBh bm90aGVyIHJvdW5kIG9mIGx0cnUNCj4gPiByZXZzaW9ucyB0byBtYWtlIHRoZSBoYW5kbGluZyBv ZiBzdWNoIGEgaHlwb3RoZXRpY2FsIGFueSBjbGVhcmVyLiAgQXQNCj4gPiBzb21lIHBvaW50IGZv bGtzIG5lZWQgdG8gcmVhbGl6ZSB0aGF0IHRoZSBCQ1AgaXMgbm90IGFuIGFsZ29yaXRobSBmb3IN Cj4gPiBleGVjdXRpb24gYnkgZmluaXRlIHN0YXRlIGF1dG9tYXRhLiAgSXQgZ2l2ZXMgZ3VpZGVs aW5lcyB0byBodW1hbnMNCj4gPiB3aG8sIG9uZSB3b3VsZCBob3BlLCBhcmUgY2FwYWJsZSBvZiBl eGVyY2lzaW5nIGEgYml0IG9mIGNvbW1vbiBzZW5zZS4NCj4NCj4gSSB3b3VsZCBob3BlIGl0J3Mg YmxpbmRpbmdseSBvYnZpb3VzIHRvIFJhbmR5IGFuZCBldmVyeW9uZSBlbHNlIHRoYXQgSQ0KPiBh Z3JlZSB3aXRoIHRoaXMgc3RhdGVtZW50LiAgSSB3b3VsZCBub3Qgd2FudCB0byBzdGFydCBhbm90 aGVyIHJvdW5kIG9mDQo+IExUUlUgcmV2aXNpb25zIGZvciBhbG1vc3QgYW55IHJlYXNvbi4NCj4N Cj4gRXZlcnkgc28gb2Z0ZW4gd2UgdGFsayBhYm91dCBhZGRpbmcgSVNPIDYzOS02IHN1cHBvcnQs IHdoaWNoIHdvdWxkIGJlIGENCj4gZ29vZCBlbm91Z2ggcmVhc29uLCBidXQgb25seSBpZiAoYSkg dGhlIGRyYWZ0IGFuZCBkYXRhIHdlcmUgZnVsbHkNCj4gYXZhaWxhYmxlIGZvciBXRyByZXZpZXcs IChiKSBJU08gcHVibGljYXRpb24gYXBwZWFyZWQgaW1taW5lbnQsIGFuZCAoYykNCj4gdGhlIFdH IGhhZCBzb21lIGhvcGUgb2YgYWdyZWVpbmcgd2hlcmUgdG8gcHV0IHRoZSBzdWJ0YWdzDQo+IGFy Y2hpdGVjdHVyYWxseS4NCj4NCj4gLS0NCj4gRG91ZyBFd2VsbCAgKiAgVGhvcm50b24sIENvbG9y YWRvLCBVU0EgICogIFJGQyA0NjQ1ICAqICBVVE4gIzE0DQo+IGh0dHA6Ly93d3cuZXdlbGxpYy5v cmcNCj4gaHR0cDovL3d3dzEuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0ZXIuaHRt bA0KPiBodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1 YWdlcyAgy4YNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSWV0Zi1sYW5ndWFnZXMgbWFpbGluZyBsaXN0DQo+IElldGYtbGFuZ3VhZ2VzQGFs dmVzdHJhbmQubm8NCj4gaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8v aWV0Zi1sYW5ndWFnZXMNCj4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZXRmLWxh bmd1YWdlcyBtYWlsaW5nIGxpc3QNCj4gSWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubw0KPiBo dHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcw0K Pg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZXRmLWxhbmd1YWdlcyBtYWlsaW5nIGxpc3QNCklldGYtbGFuZ3VhZ2VzQGFsdmVzdHJhbmQubm8N Cmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFuZ3VhZ2Vz DQo= From petercon@microsoft.com Mon Jul 13 08:46:32 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A2F3A6DFB for ; Mon, 13 Jul 2009 08:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkE-lxJ+sJ4i for ; Mon, 13 Jul 2009 08:46:31 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6D55B3A6E82 for ; Mon, 13 Jul 2009 08:46:28 -0700 (PDT) Received: from tk5-expfs-c107.redmond.corp.microsoft.com (157.54.69.47) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 13 Jul 2009 08:46:59 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-expfs-c107.redmond.corp.microsoft.com ([157.54.69.47]) with mapi; Mon, 13 Jul 2009 08:46:58 -0700 From: Peter Constable To: "Phillips, Addison" , LTRU Working Group Date: Mon, 13 Jul 2009 08:46:57 -0700 Thread-Topic: rechartering to handle 639-6 (was FW: Anomaly in upcoming registry) Thread-Index: AcoDhjP0pruGgNzSSzq8ZllMHrw18gARtoTAAAEFrhA= Message-ID: References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly in upcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:46:32 -0000 KzENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGx0cnUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWxsaXBz LCBBZGRpc29uDQpTZW50OiBNb25kYXksIEp1bHkgMTMsIDIwMDkgODoyNiBBTQ0KVG86IExUUlUg V29ya2luZyBHcm91cA0KU3ViamVjdDogW0x0cnVdIHJlY2hhcnRlcmluZyB0byBoYW5kbGUgNjM5 LTYgKHdhcyBGVzogQW5vbWFseSBpbiB1cGNvbWluZyByZWdpc3RyeSkNCg0KUmFuZHkgcG9zdGVk IHRvIHRoZSBpZXRmLWxhbmd1YWdlcyB0aHJlYWQgKGJlbG93KSB0aGF0IG1vc3Qgb2YgeW91IGFy ZSBwcm9iYWJseSBhd2FyZSBvZiwgdGhlIGZvbGxvd2luZyBtZXNzYWdlLiBJJ20gY3Jvc3MtcG9z dGluZyBpdCBzbyB0aGF0IEkgY2FuIHJlc3BvbmQuDQoNCkkgb3Bwb3NlIHJlY2hhcnRlcmluZyBM VFJVIGF0IHRoaXMgdGltZS4gV2UndmUgY29tcGxldGVkIHRoZSBlc3NlbnRpYWwgd29yayBvZiBp bmNvcnBvcmF0aW5nIElTTyA2MzktMyBhbmQgb3VyIHdvcmsgaGFzIGJyb3VnaHQgYSBmZXcgb3Ro ZXIgZW5oYW5jZW1lbnRzLiBJIHRoaW5rIHdlJ3ZlIGFsbG93ZWQgc3VmZmljaWVudCByb29tIGZv ciB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgdG8gZG8gaXRzIG1hZ2ljIGFuZCBoYW5kbGUgbW9z dCBvZiB0aGUgbGFuZ3VhZ2UgaWRlbnRpZmljYXRpb24gY29tbXVuaXR5J3MgbmVlZHMuIEkgd291 bGQgbGlrZSB0byBzZWUgdGhlIG5ldyBkb2N1bWVudCBpbiB1c2UgZm9yIGF3aGlsZSBiZWZvcmUg d2UgZ28gdG8gdGlua2VyaW5nIHdpdGggaXQuDQoNCklmIElTTyA2MzktNiB3ZXJlIHJlYWR5IChh cyBpdCBpcyBub3QpLCB0aGVuIExUUlUgY291bGQgYmUgcmVjb25zdGl0dXRlZCB0byBsb29rIGlu dG8gd2hldGhlciBvciBub3QgdG8gaW5jb3Jwb3JhdGUgaXQgKGFuZCBpZiBzbywgaG93KS4gSSBz dXNwZWN0IGl0IG1pZ2h0IGJlIGEgY291cGxlIG9mIHllYXJzIGJlZm9yZSB0aGF0IGlzIHVwb24g dXMuIEluIHRoZSBtZWFudGltZSwgd2UgY291bGQgdXNlIHNvbWUgZXhwZXJpZW5jZSB3aXRoIHJm Yy10by1iZS00NjQ2YmlzLiBDb25zdGFudCByZXdyaXRpbmcgd2lsbCBub3QgaW1wcm92ZSBtYXR0 ZXJzLg0KDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBMYWIx MjYNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlldGYtbGFu Z3VhZ2VzLWJvdW5jZXNAYWx2ZXN0cmFuZC5ubyBbbWFpbHRvOmlldGYtbGFuZ3VhZ2VzLWJvdW5j ZXNAYWx2ZXN0cmFuZC5ub10gT24gQmVoYWxmIE9mIFJhbmR5IFByZXN1aG4NClNlbnQ6IFN1bmRh eSwgSnVseSAxMiwgMjAwOSAxMTo1MSBQTQ0KVG86IGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnDQpT dWJqZWN0OiBSZTogQW5vbWFseSBpbiB1cGNvbWluZyByZWdpc3RyeQ0KDQpIaSAtDQoNCkRpc2N1 c3Npb24gb2YgcmUtY2hhcnRlcmluZyB0aGUgbHRydSB3b3JraW5nIGdyb3VwIGJlbG9uZ3Mgb24N CnRoZSBsdHJ1QGlldGYub3JnIG1haWxpbmcgbGlzdCwgbm90IGhlcmUuICBUaGlzIGlzIHRoZSB0 aW1lDQpmb3Igc3VjaCBkaXNjdXNzaW9ucy4NCg0KUmFuZHkNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiR2VyYXJkIE1laWpzc2VuIiA8Z2VyYXJkLm1laWpzc2VuQG9wZW5w cm9ncmVzcy5vcmc+DQpUbzogIkRvdWcgRXdlbGwiIDxkb3VnQGV3ZWxsaWMub3JnPg0KQ2M6IDxp ZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4NClNlbnQ6IFN1bmRheSwgSnVseSAxMiwgMjAwOSAxMToy OCBQTQ0KU3ViamVjdDogUmU6IEFub21hbHkgaW4gdXBjb21pbmcgcmVnaXN0cnkNCg0KDQpIb2ks DQpXaXRoIGFsbCBkdWUgcmVzcGVjdCBmb3IgdGhlIGRpbGlnZW5jZSBvZiB0aGUgcHJvY2VzcyBi dXQgd2hlbiB5b3UgY29uc2lkZXINCnRoZSBsZW5ndGggb2YgdGltZSBpdCB0b29rLCB0aGUgSVNP LTYzOS02IHdpbGwgbWFrZSB0aGlzIHNhbWUgcHJvY2Vzcw0KaW1wb3NzaWJsZSBiZWNhdXNlIG9m IHRoZSBhbW91bnQgb2YgZGF0YSBpbnZvbHZlZC4gV2hlbiB0aGlzIHByb2Nlc3Mgb25seQ0Kc3Rh cnRzIHdoZW4gdGhlIHB1YmxpY2F0aW9uIGlzIGltbWluZW50LCBpdCB3aWxsIHRha2UgbWF5YmUg YXQgbGVhc3QgYQ0KZGVjYWRlIGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgbmV3IGVudHJpZXMgdGhh dCBJU08gNjM5LTYgd2lsbCBicmluZy4gVGhhdA0KbWVhbnMgaW1obyB0aGF0IGZvciBJU08tNjM5 LTYgd2Ugd2lsbCBoYXZlIHRvIHJldGhpbmsgdGhlIHByb2Nlc3MuIFdlIGRvDQpoYXZlIHJvb20g YmVmb3JlIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgbmV3IHN0YW5kYXJkLi4gaXQgY291bGQgYmUg c2VlbiBhcw0KcHJlLWVtcHRpdmUgaW52b2x2ZW1lbnQgYmVjYXVzZSBvZiB0aGUgaHVnZSBhbW91 bnQgb2YgZGF0YSBpbnZvbHZlZC4NClRoYW5rcywNCiAgICAgICBHZXJhcmQNCg0KMjAwOS83LzEz IERvdWcgRXdlbGwgPGRvdWdAZXdlbGxpYy5vcmc+DQoNCj4gUmFuZHkgUHJlc3VobiA8cmFuZHkg dW5kZXJzY29yZSBwcmVzdWhuIGF0IG1pbmRzcHJpbmcgZG90IGNvbT4gd3JvdGU6DQo+DQo+ID4g VGhlcmUncyBubyB3YXkgdGhhdCBJJ2QgYmUgd2lsbGluZyB0byBzdGFydCBhbm90aGVyIHJvdW5k IG9mIGx0cnUNCj4gPiByZXZzaW9ucyB0byBtYWtlIHRoZSBoYW5kbGluZyBvZiBzdWNoIGEgaHlw b3RoZXRpY2FsIGFueSBjbGVhcmVyLiAgQXQNCj4gPiBzb21lIHBvaW50IGZvbGtzIG5lZWQgdG8g cmVhbGl6ZSB0aGF0IHRoZSBCQ1AgaXMgbm90IGFuIGFsZ29yaXRobSBmb3INCj4gPiBleGVjdXRp b24gYnkgZmluaXRlIHN0YXRlIGF1dG9tYXRhLiAgSXQgZ2l2ZXMgZ3VpZGVsaW5lcyB0byBodW1h bnMNCj4gPiB3aG8sIG9uZSB3b3VsZCBob3BlLCBhcmUgY2FwYWJsZSBvZiBleGVyY2lzaW5nIGEg Yml0IG9mIGNvbW1vbiBzZW5zZS4NCj4NCj4gSSB3b3VsZCBob3BlIGl0J3MgYmxpbmRpbmdseSBv YnZpb3VzIHRvIFJhbmR5IGFuZCBldmVyeW9uZSBlbHNlIHRoYXQgSQ0KPiBhZ3JlZSB3aXRoIHRo aXMgc3RhdGVtZW50LiAgSSB3b3VsZCBub3Qgd2FudCB0byBzdGFydCBhbm90aGVyIHJvdW5kIG9m DQo+IExUUlUgcmV2aXNpb25zIGZvciBhbG1vc3QgYW55IHJlYXNvbi4NCj4NCj4gRXZlcnkgc28g b2Z0ZW4gd2UgdGFsayBhYm91dCBhZGRpbmcgSVNPIDYzOS02IHN1cHBvcnQsIHdoaWNoIHdvdWxk IGJlIGENCj4gZ29vZCBlbm91Z2ggcmVhc29uLCBidXQgb25seSBpZiAoYSkgdGhlIGRyYWZ0IGFu ZCBkYXRhIHdlcmUgZnVsbHkNCj4gYXZhaWxhYmxlIGZvciBXRyByZXZpZXcsIChiKSBJU08gcHVi bGljYXRpb24gYXBwZWFyZWQgaW1taW5lbnQsIGFuZCAoYykNCj4gdGhlIFdHIGhhZCBzb21lIGhv cGUgb2YgYWdyZWVpbmcgd2hlcmUgdG8gcHV0IHRoZSBzdWJ0YWdzDQo+IGFyY2hpdGVjdHVyYWxs eS4NCj4NCj4gLS0NCj4gRG91ZyBFd2VsbCAgKiAgVGhvcm50b24sIENvbG9yYWRvLCBVU0EgICog IFJGQyA0NjQ1ICAqICBVVE4gIzE0DQo+IGh0dHA6Ly93d3cuZXdlbGxpYy5vcmcNCj4gaHR0cDov L3d3dzEuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0ZXIuaHRtbA0KPiBodHRwOi8v d3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcyAgy4YNCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWV0 Zi1sYW5ndWFnZXMgbWFpbGluZyBsaXN0DQo+IElldGYtbGFuZ3VhZ2VzQGFsdmVzdHJhbmQubm8N Cj4gaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5ndWFn ZXMNCj4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZXRmLWxhbmd1YWdlcyBtYWls aW5nIGxpc3QNCj4gSWV0Zi1sYW5ndWFnZXNAYWx2ZXN0cmFuZC5ubw0KPiBodHRwOi8vd3d3LmFs dmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcw0KPg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZXRmLWxhbmd1YWdl cyBtYWlsaW5nIGxpc3QNCklldGYtbGFuZ3VhZ2VzQGFsdmVzdHJhbmQubm8NCmh0dHA6Ly93d3cu YWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYtbGFuZ3VhZ2VzDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBtYWlsaW5nIGxpc3QN Ckx0cnVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRy dQ0K From randy_presuhn@mindspring.com Mon Jul 13 10:36:54 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B913A6E9B for ; Mon, 13 Jul 2009 10:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBy47245A4AL for ; Mon, 13 Jul 2009 10:36:53 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 09CE328C1F0 for ; Mon, 13 Jul 2009 10:34:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LDXVEy6fqDOEqCRddlmTvXWb7K5ovF+GjJPl/txTNC0imtvK1Xm3hTtgoFGMzmJ9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.160.240] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MQPQU-0007r1-7j for ltru@ietf.org; Mon, 13 Jul 2009 13:34:54 -0400 Message-ID: <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> Date: Mon, 13 Jul 2009 10:36:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69689551b528e1e357ddab3c5ef842473d4b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.240 Subject: Re: [Ltru] rechartering to handle 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 17:36:54 -0000 Hi - As a technical contributor... I, too, oppose re-chartering ltru at this time. The additions made by the documents recently approved take us well past the point of diminishing returns in terms of language coverage. What that might convince me that re-chartering was needed would be the appearance large quantities of data in large numbers of languages in use by substantial speech communities not covered by the recent updates, and not adequately handled by the registration procedures. I don't think that's going to happen anytime in the foreseeable future. Randy From mark.edward.davis@gmail.com Mon Jul 13 12:47:01 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A7728C438 for ; Mon, 13 Jul 2009 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5tutmjQ-TWg for ; Mon, 13 Jul 2009 12:47:01 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id D6D7C28C31B for ; Mon, 13 Jul 2009 12:47:00 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1178346anc.4 for ; Mon, 13 Jul 2009 12:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=67+AfLELKDdrHNC1xTWDMU1TRmr8IGpbh3e9pGMhjxI=; b=lVRgouVeRInhYkAko1ZoBSVO0mIGnMS5etfzMQZeKkRIdJ6OymxILq3e4z7ITwsDs5 AUE66WrHLCNqCIOAlZp7tZ5SF5i4NJmSxW49NE6rBUgqXFtcIsOeJE7zf/KaCTexeuW+ vW/X2cofnsE5FeSnZMU16uSw1G8bWmmSqjrXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=b2SQh06RcGb+5hXknfVZ3OAez3QTFrulU4y7nZ5EP19IwtWDjAqQaC2GObvxFmituz NNaTHlbvDgebb8NLibf7M6ynshlJUpIK8KXeUZKp1a6bQzEN/rtl4K0xWO9NVfqD6djb PHiV4olR9ufUsjIq1in6arhWD0mRASiqoSNn4= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.138.8 with SMTP id l8mr7782115and.32.1247514431342; Mon, 13 Jul 2009 12:47:11 -0700 (PDT) In-Reply-To: <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> Date: Mon, 13 Jul 2009 12:47:11 -0700 X-Google-Sender-Auth: d9e37589781f71e6 Message-ID: <30b660a20907131247l6113dc52i8ec9656ba9805176@mail.gmail.com> From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= To: Randy Presuhn Content-Type: multipart/alternative; boundary=0016e6408008884e5d046e9b9683 Cc: LTRU Working Group Subject: Re: [Ltru] rechartering to handle 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:47:01 -0000 --0016e6408008884e5d046e9b9683 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I agree. Mark On Mon, Jul 13, 2009 at 10:36, Randy Presuhn wrote: > Hi - > > As a technical contributor... > > I, too, oppose re-chartering ltru at this time. > The additions made by the documents recently approved > take us well past the point of diminishing returns > in terms of language coverage. > > What that might convince me that re-chartering was needed > would be the appearance large quantities of data in large > numbers of languages in use by substantial speech communities > not covered by the recent updates, and not adequately handled > by the registration procedures. I don't think that's going to > happen anytime in the foreseeable future. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --0016e6408008884e5d046e9b9683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree.

Mark


On Mon, Jul 13, 2009 at 10:36, Randy Pre= suhn <= randy_presuhn@mindspring.com> wrote:
Hi -

As a technical contributor...

I, too, oppose re-chartering ltru at this time.
The additions made by the documents recently approved
take us well past the point of diminishing returns
in terms of language coverage.

What that might convince me that re-chartering was needed
would be the appearance large quantities of data in large
numbers of languages in use by substantial speech communities
not covered by the recent updates, and not adequately handled
by the registration procedures. =C2=A0I don't think that's going to=
happen anytime in the foreseeable future.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--0016e6408008884e5d046e9b9683-- From mark.edward.davis@gmail.com Mon Jul 13 12:47:27 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4A528C558 for ; Mon, 13 Jul 2009 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uieoX1yNTl2C for ; Mon, 13 Jul 2009 12:47:26 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 5801228C41C for ; Mon, 13 Jul 2009 12:47:26 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1178346anc.4 for ; Mon, 13 Jul 2009 12:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=62RYrA/D9pJHGeJD32IXowc3VydmNDqQYEWhDjVqm4U=; b=lbNkEOod/vzyN3hAClWdOT/uAtZMYME+JI38rolO8fWFTLEzuJtGja2OYiaXsucVPm qxraQbYkC3+zrvP8jf0pgoSQXwOUpTVQ6+Auo2T8HAmCNF8CkfGSomhMeV6Erkh5yeTv bNt7KtMROgS0Ph38akcf9DLNju9L9huIK37Cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=U3udCC1h1iPE9POq+wtx6feX2VxdeKS4RSqpuHg+TZ23Fiv8StYvyLkYF1ZWYqBvm7 rtbkvMXpWdqmfzrc4d/pMtyCqjY4UkjL9GPnPAP96s3UXlYUSuy1gRkvPfQ8fW4dZ05y 7ecRqnwmDbMHShDOLbtLJv56D0sXapyZXSeSY= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.231.8 with SMTP id d8mr7531095anh.196.1247514477330; Mon, 13 Jul 2009 12:47:57 -0700 (PDT) In-Reply-To: <30b660a20907131247l6113dc52i8ec9656ba9805176@mail.gmail.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> <30b660a20907131247l6113dc52i8ec9656ba9805176@mail.gmail.com> Date: Mon, 13 Jul 2009 12:47:57 -0700 X-Google-Sender-Auth: 36fcc972e63d05e4 Message-ID: <30b660a20907131247n7b905b13ga404aa4f84610ab2@mail.gmail.com> From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= To: Randy Presuhn Content-Type: multipart/alternative; boundary=0016368e207d460128046e9b99cb Cc: LTRU Working Group Subject: Re: [Ltru] rechartering to handle 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:47:27 -0000 --0016368e207d460128046e9b99cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, I agree on not rechartering for ISO 639-6. As to other matters, I think we need to let the dust settle a bit. Mark On Mon, Jul 13, 2009 at 12:47, Mark Davis =E2=8C=9B wr= ote: > I agree. > > Mark > > > > On Mon, Jul 13, 2009 at 10:36, Randy Presuhn > wrote: > >> Hi - >> >> As a technical contributor... >> >> I, too, oppose re-chartering ltru at this time. >> The additions made by the documents recently approved >> take us well past the point of diminishing returns >> in terms of language coverage. >> >> What that might convince me that re-chartering was needed >> would be the appearance large quantities of data in large >> numbers of languages in use by substantial speech communities >> not covered by the recent updates, and not adequately handled >> by the registration procedures. I don't think that's going to >> happen anytime in the foreseeable future. >> >> Randy >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www.ietf.org/mailman/listinfo/ltru >> > > --0016368e207d460128046e9b99cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, I agree on not rechartering for ISO 639-6. As to other matters, I= think we need to let the dust settle a bit.

Mark


On Mon, Jul 13, 2009 at 12:47, Mark Davi= s =E2=8C=9B <mar= k@macchiato.com> wrote:
I agree.

Mark
=



On Mon, Jul 13, 2009 at 10:36, Randy Pre= suhn <randy_presuhn@mindspring.com> wrote:
Hi -

As a technical contributor...

I, too, oppose re-chartering ltru at this time.
The additions made by the documents recently approved
take us well past the point of diminishing returns
in terms of language coverage.

What that might convince me that re-chartering was needed
would be the appearance large quantities of data in large
numbers of languages in use by substantial speech communities
not covered by the recent updates, and not adequately handled
by the registration procedures. =C2=A0I don't think that's going to=
happen anytime in the foreseeable future.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru


--0016368e207d460128046e9b99cb-- From doug@ewellic.org Mon Jul 13 17:21:13 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB52C28C697 for ; Mon, 13 Jul 2009 17:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSG0s8aHir1Q for ; Mon, 13 Jul 2009 17:21:12 -0700 (PDT) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id 9AEA228C6EB for ; Mon, 13 Jul 2009 17:20:33 -0700 (PDT) Received: (qmail 2351 invoked from network); 14 Jul 2009 00:20:45 -0000 Received: from unknown (67.166.27.148) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 14 Jul 2009 00:20:45 -0000 Message-ID: <1AD53C39B9F24C12BC31AB76AF5D1B89@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 13 Jul 2009 18:20:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly in upcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 00:21:13 -0000 "Phillips, Addison" wrote: > In the meantime, we could use some experience with rfc-to-be-4646bis. > Constant rewriting will not improve matters. I specifically would not want to recharter for the purpose of tweaking the existing text. In fact, I might not participate in a LTRU 3.0 at all if tweaking the existing text turns out to take a large percentage of the WG's time, as it did in LTRU 2.0. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From randy_presuhn@mindspring.com Mon Jul 13 18:13:39 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771ED3A6EA0 for ; Mon, 13 Jul 2009 18:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaa0vnq7fpMS for ; Mon, 13 Jul 2009 18:13:38 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A95AF3A6DE8 for ; Mon, 13 Jul 2009 18:13:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=W2v4b7aaRoNKmDHRrZr6dsgxx6oNJOuAN0IvIBQ1wXwb1umrqPYzJ5h/nkaNllB6; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.48.152] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MQWaq-0006DB-1e for ltru@ietf.org; Mon, 13 Jul 2009 21:14:04 -0400 Message-ID: <000c01ca0420$91428200$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <1AD53C39B9F24C12BC31AB76AF5D1B89@DGBP7M81> Date: Mon, 13 Jul 2009 18:15:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968f8a6e9a3b569520b4aad4b20070f5cd2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.152 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 01:13:39 -0000 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, July 13, 2009 5:20 PM > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcoming registry) ... > I specifically would not want to recharter for the purpose of tweaking > the existing text. In fact, I might not participate in a LTRU 3.0 at > all if tweaking the existing text turns out to take a large percentage > of the WG's time, as it did in LTRU 2.0. ... As a technical contributor... (1) I'm not sure how a "language tag registry update" WG could be chartered that wouldn't involve tweaking existing text. Unless operational experience had demonstrated that text to be seriously broken, I'd see no point in re-opening it. As co-chair... (2) Is there any purpose for which you could conceive of a rechartering of the WG that you *would* support? Randy From doug@ewellic.org Mon Jul 13 22:20:31 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2490B3A6830 for ; Mon, 13 Jul 2009 22:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, FAKE_REPLY_C=2.012, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLLIjz4ag86U for ; Mon, 13 Jul 2009 22:20:30 -0700 (PDT) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 3E39A3A67D9 for ; Mon, 13 Jul 2009 22:20:30 -0700 (PDT) Received: (qmail 31926 invoked from network); 14 Jul 2009 04:54:15 -0000 Received: from unknown (67.166.27.148) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 14 Jul 2009 04:54:15 -0000 Message-ID: <548832E2D1D1486EBAC82789E800224A@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 13 Jul 2009 22:54:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly in upcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 05:20:31 -0000 Randy Presuhn wrote: > As a technical contributor... > (1) I'm not sure how a "language tag registry update" WG could be > chartered that wouldn't involve tweaking existing text. Unless > operational experience had demonstrated that text to be seriously > broken, I'd see no point in re-opening it. Of course any "real" updating activity would entail necessary changes to the existing text. I'm not talking about that when I say "tweaking." I'm talking about the endless lily-gilding, adding more and more caveats and examples for existing edge cases and inserting new sections to cover the most extreme corner cases, almost as if, as you put it, the BCP were to be implemented by automatons instead of breathing humans. > As co-chair... > (2) Is there any purpose for which you could conceive of a > rechartering of the WG that you *would* support? I wouldn't mind seeing supporters of ISO 639-6 put together a serious proposal that maintains compatibility with BCP 47 matching logic, keeps duplicate-tag redundancy to a minimum, AND adds value. I'm not sure it can be done, and I won't support adding 639-6 if it can't be, but I think it deserves a chance in the marketplace of ideas. So far we haven't seen any proposal that accomplishes all three goals. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From duerst@it.aoyama.ac.jp Mon Jul 13 22:35:11 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A500F3A6995 for ; Mon, 13 Jul 2009 22:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.381 X-Spam-Level: X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_75=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUaVj75D0GCB for ; Mon, 13 Jul 2009 22:35:10 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 2A8293A6903 for ; Mon, 13 Jul 2009 22:35:10 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n6E5XwR9024621 for ; Tue, 14 Jul 2009 14:33:58 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4a54_eda2dae4_7037_11de_922d_001d096c566a; Tue, 14 Jul 2009 14:33:58 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35101) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 14 Jul 2009 14:31:40 +0900 Message-ID: <4A5C18B8.9000109@it.aoyama.ac.jp> Date: Tue, 14 Jul 2009 14:33:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "Phillips, Addison" References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: LTRU Working Group Subject: Re: [Ltru] rechartering (to handle 639-6 or otherwise) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 05:35:11 -0000 For the record, and hats off, I can't currently see any purpose in rechartering. The tags being added by RFC4645bis and the ongoing registry process via ISO and via ietf-languages cover the greatest majority of language tagging needs (at least something like four or five nines). Also, while the current text isn't perfect, it's not good use of our time to spend another year or two on further tweaking. In addition, I cannot think of any other topics or issues that are currently unsolved and would need a WG. Regards, Martin. On 2009/07/14 0:26, Phillips, Addison wrote: > Randy posted to the ietf-languages thread (below) that most of you are probably aware of, the following message. I'm cross-posting it so that I can respond. > > I oppose rechartering LTRU at this time. We've completed the essential work of incorporating ISO 639-3 and our work has brought a few other enhancements. I think we've allowed sufficient room for the registration process to do its magic and handle most of the language identification community's needs. I would like to see the new document in use for awhile before we go to tinkering with it. > > If ISO 639-6 were ready (as it is not), then LTRU could be reconstituted to look into whether or not to incorporate it (and if so, how). I suspect it might be a couple of years before that is upon us. In the meantime, we could use some experience with rfc-to-be-4646bis. Constant rewriting will not improve matters. > > Addison Phillips > Globalization Architect -- Lab126 > > Internationalization is not a feature. > It is an architecture. > > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Randy Presuhn > Sent: Sunday, July 12, 2009 11:51 PM > To: ietf-languages@iana.org > Subject: Re: Anomaly in upcoming registry > > Hi - > > Discussion of re-chartering the ltru working group belongs on > the ltru@ietf.org mailing list, not here. This is the time > for such discussions. > > Randy > ----- Original Message ----- > From: "Gerard Meijssen" > To: "Doug Ewell" > Cc: > Sent: Sunday, July 12, 2009 11:28 PM > Subject: Re: Anomaly in upcoming registry > > > Hoi, > With all due respect for the diligence of the process but when you consider > the length of time it took, the ISO-639-6 will make this same process > impossible because of the amount of data involved. When this process only > starts when the publication is imminent, it will take maybe at least a > decade based on the number of new entries that ISO 639-6 will bring. That > means imho that for ISO-639-6 we will have to rethink the process. We do > have room before the publication of the new standard.. it could be seen as > pre-emptive involvement because of the huge amount of data involved. > Thanks, > Gerard > > 2009/7/13 Doug Ewell > >> Randy Presuhn wrote: >> >>> There's no way that I'd be willing to start another round of ltru >>> revsions to make the handling of such a hypothetical any clearer. At >>> some point folks need to realize that the BCP is not an algorithm for >>> execution by finite state automata. It gives guidelines to humans >>> who, one would hope, are capable of exercising a bit of common sense. >> I would hope it's blindingly obvious to Randy and everyone else that I >> agree with this statement. I would not want to start another round of >> LTRU revisions for almost any reason. >> >> Every so often we talk about adding ISO 639-6 support, which would be a >> good enough reason, but only if (a) the draft and data were fully >> available for WG review, (b) ISO publication appeared imminent, and (c) >> the WG had some hope of agreeing where to put the subtags >> architecturally. >> >> -- >> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 >> http://www.ewellic.org >> http://www1.ietf.org/html.charters/ltru-charter.html >> http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ >> >> _______________________________________________ >> Ietf-languages mailing list >> Ietf-languages@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/ietf-languages >> > > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> Ietf-languages mailing list >> Ietf-languages@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/ietf-languages >> > > > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From prvs=144618e121=debbie@ictmarketing.co.uk Tue Jul 14 05:03:01 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D873A699C for ; Tue, 14 Jul 2009 05:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFqLzRc70iqM for ; Tue, 14 Jul 2009 05:03:00 -0700 (PDT) Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132]) by core3.amsl.com (Postfix) with ESMTP id 06C703A6822 for ; Tue, 14 Jul 2009 05:02:59 -0700 (PDT) Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.6) with ESMTP id md50009627843.msg for ; Tue, 14 Jul 2009 12:11:39 +0100 X-Spam-Processed: mx1.nexbyte.net, Tue, 14 Jul 2009 12:11:39 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=144618e121=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org Received: from Vickynew ([213.208.115.6]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 14 Jul 2009 11:51:34 +0100 From: "Debbie Garside" To: "'Randy Presuhn'" , "'LTRU Working Group'" References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> Date: Tue, 14 Jul 2009 11:52:25 +0100 Message-ID: <3e0701ca0471$2cbf4ab0$0300a8c0@Vickynew> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> thread-index: AcoD4bQ+D/G5PZFDQCmTpi1sjgPW9AAi4njw X-MDAV-Processed: mx1.nexbyte.net, Tue, 14 Jul 2009 12:11:39 +0100 Subject: Re: [Ltru] rechartering to handle 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 12:40:58 -0000 Whilst I can see that the process for including ISO 639-3 and updating RFC4646 has been long and arduous and people are pretty tired, I believe there will be a need for inclusion of ISO 639-6 data at some point in the future - particularly when end users request a language tag on IETF-Languages that is facilitated within the ISO 639-6 code once published. This begs the question, who is ultimately going to make the decision to ignore an ISO 639 standard? The ISO 639-6 data is hierarchical in nature, goes to a level of granularity that will facilitate virtually any requirement and also differentiates between written and spoken language variations - something that will be extremely useful for metadata registries within archive industries as well as tagging for the visually impaired, deaf and hard of hearing. That said, I don't believe now is the correct time to re-charter for the purposes of including ISO 639-6 data. I don't think I am ready for this - I may be in 6-12 months. I do, however, think it would be a good idea to keep this list open for general discussions and if this proves the case I will inform the list as and when I consider ISO 639-6 data sufficiently ready for incorporation. Whether you decide to re-charter at that point (or at any other time) is up to you. Best regards Debbie Garside Editor ISO FDIS 639-6 -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: 13 July 2009 18:36 To: LTRU Working Group Subject: Re: [Ltru] rechartering to handle 639-6 Hi - As a technical contributor... I, too, oppose re-chartering ltru at this time. The additions made by the documents recently approved take us well past the point of diminishing returns in terms of language coverage. What that might convince me that re-chartering was needed would be the appearance large quantities of data in large numbers of languages in use by substantial speech communities not covered by the recent updates, and not adequately handled by the registration procedures. I don't think that's going to happen anytime in the foreseeable future. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 270.12.26/2116 - Release Date: 15/05/2009 06:16 Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 270.12.26/2116 - Release Date: 15/05/2009 06:16 From prvs=144618e121=debbie@ictmarketing.co.uk Tue Jul 14 10:16:46 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A049428C32A for ; Tue, 14 Jul 2009 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l95Kckff4hXZ for ; Tue, 14 Jul 2009 10:16:45 -0700 (PDT) Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132]) by core3.amsl.com (Postfix) with ESMTP id 3DB2728C16D for ; Tue, 14 Jul 2009 10:16:45 -0700 (PDT) Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.6) with ESMTP id md50009629912.msg for ; Tue, 14 Jul 2009 18:07:57 +0100 X-Spam-Processed: mx1.nexbyte.net, Tue, 14 Jul 2009 18:07:57 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=144618e121=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 14 Jul 2009 17:47:50 +0100 From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81> Date: Tue, 14 Jul 2009 17:47:25 +0100 Message-ID: <1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoEQwBttiSv7DFvRV6BpvpBHwv1YwAXxINw In-Reply-To: <548832E2D1D1486EBAC82789E800224A@DGBP7M81> X-MDAV-Processed: mx1.nexbyte.net, Tue, 14 Jul 2009 18:07:59 +0100 Cc: L.Gillam@surrey.ac.uk Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:16:46 -0000 Doug wrote: > I wouldn't mind seeing supporters of ISO 639-6 put together a > serious proposal that maintains compatibility with BCP 47 > matching logic, keeps duplicate-tag redundancy to a minimum, > AND adds value. I'm not sure it can be done, and I won't > support adding 639-6 if it can't be, but I think it deserves > a chance in the marketplace of ideas. So far we haven't seen > any proposal that accomplishes all three goals. I think we pretty much worked this out a few years ago... See http://www.ietf.org/mail-archive/web/ltru/current/msg06482.html But as I said in my previous message, I am not quite ready yet as it will involve some flagging of the data. Best Debbie > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > Behalf Of Doug Ewell > Sent: 14 July 2009 05:54 > To: LTRU Working Group > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: > Anomaly inupcoming registry) > > Randy Presuhn wrote: > > > As a technical contributor... > > (1) I'm not sure how a "language tag registry update" WG could be > > chartered that wouldn't involve tweaking existing text. Unless > > operational experience had demonstrated that text to be seriously > > broken, I'd see no point in re-opening it. > > Of course any "real" updating activity would entail necessary > changes to the existing text. I'm not talking about that > when I say "tweaking." > I'm talking about the endless lily-gilding, adding more and > more caveats and examples for existing edge cases and > inserting new sections to cover the most extreme corner > cases, almost as if, as you put it, the BCP were to be > implemented by automatons instead of breathing humans. > > > As co-chair... > > (2) Is there any purpose for which you could conceive of a > > rechartering of the WG that you *would* support? > > I wouldn't mind seeing supporters of ISO 639-6 put together a > serious proposal that maintains compatibility with BCP 47 > matching logic, keeps duplicate-tag redundancy to a minimum, > AND adds value. I'm not sure it can be done, and I won't > support adding 639-6 if it can't be, but I think it deserves > a chance in the marketplace of ideas. So far we haven't seen > any proposal that accomplishes all three goals. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN > #14 http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages ^ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > From randy_presuhn@mindspring.com Tue Jul 14 13:54:44 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5FA3A68F3 for ; Tue, 14 Jul 2009 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wouf0p3JTIYE for ; Tue, 14 Jul 2009 13:54:44 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 670F63A6841 for ; Tue, 14 Jul 2009 13:53:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GQyL0Ln7UFphQAy6/+1yyOZfIC88rWiQ8ArOX4TR7ro1PhvGDMQDckB2hhQuvn4F; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.174.119] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MQlvL-0002KF-Ii for ltru@ietf.org; Tue, 14 Jul 2009 13:36:15 -0400 Message-ID: <036201ca04a9$c6500ec0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81> <1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> Date: Tue, 14 Jul 2009 10:37:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968b8b354b0ab1091cb11587ce006d23894350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.119 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 20:54:45 -0000 Hi - > From: "Debbie Garside" > To: "'Doug Ewell'" ; "'LTRU Working Group'" > Cc: > Sent: Tuesday, July 14, 2009 9:47 AM > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcomingregistry) ... > I think we pretty much worked this out a few years ago... See > http://www.ietf.org/mail-archive/web/ltru/current/msg06482.html > But as I said in my previous message, I am not quite ready yet as it will > involve some flagging of the data. ... As a technical contributor... How much content (as a percentage of internet traffic, or as a percentage of on-line library holdings, for example) would be covered by 639-6 (when it's done) that would not (or could not) be covered by the registry updates recently approved and the normal operation of ietf-languages@iana.org? What languages does it cover that cannot be addressed under the current regime? I'd really like to know the what language tagging problem would be fixed by digging into 639-6, what the payoff (in terms of users served or content tagged) would be, and why a working group would be necessary to cope with it. Randy From doug@ewellic.org Tue Jul 14 19:25:37 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BE53A6996 for ; Tue, 14 Jul 2009 19:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=1.362, BAYES_00=-2.599, GB_I_LETTER=-2, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os0JpEBNlgLC for ; Tue, 14 Jul 2009 19:25:35 -0700 (PDT) Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by core3.amsl.com (Postfix) with SMTP id D90783A6881 for ; Tue, 14 Jul 2009 19:25:35 -0700 (PDT) Received: (qmail 7157 invoked from network); 15 Jul 2009 02:24:12 -0000 Received: from unknown (67.166.27.148) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 15 Jul 2009 02:24:11 -0000 Message-ID: <9998597D06284EEC836787FD5DF74732@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81> <1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> Date: Tue, 14 Jul 2009 20:24:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcoming registry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 02:25:37 -0000 Debbie Garside wrote: >> So far we haven't seen any proposal that accomplishes all three >> goals. > > I think we pretty much worked this out a few years ago... See > http://www.ietf.org/mail-archive/web/ltru/current/msg06482.html > But as I said in my previous message, I am not quite ready yet as it > will involve some flagging of the data. I think there are still some basic concepts to be worked out since that post 2½ years ago. For example, John Cowan has since suggested using 5-character variant subtags starting with "6" to hold ISO 639-6 code elements, instead of using the 4-letter language subtags reserved for (shhhh) this purpose. That wasn't mentioned in the November 2006 post, but it's something we would have to decide upon. Randy Presuhn replied: > I'd really like to know the what language tagging problem would be > fixed by digging into 639-6, what the payoff (in terms of users served > or content tagged) would be, and why a working group would be > necessary to cope with it. Well, that's exactly what I said before: we need to know. We don't need to recharter the WG to find out these facts if we can have the discussion now. Of course, having the text of the standard and the data available would help immensely, but that's not available now, so we're left to do some guessing and projecting. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From duerst@it.aoyama.ac.jp Tue Jul 14 21:35:58 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE0E28C0D7 for ; Tue, 14 Jul 2009 21:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gNWuNPs05CX for ; Tue, 14 Jul 2009 21:35:58 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id A095B28C0CE for ; Tue, 14 Jul 2009 21:35:56 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n6F4Q9IU021961 for ; Wed, 15 Jul 2009 13:26:13 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 32ea_9edd73cc_70f7_11de_9186_001d096c5782; Wed, 15 Jul 2009 13:26:09 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53140) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 15 Jul 2009 13:23:51 +0900 Message-ID: <4A5D5A52.7080308@it.aoyama.ac.jp> Date: Wed, 15 Jul 2009 13:25:54 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: debbie@ictmarketing.co.uk References: <4D25F22093241741BC1D0EEBC2DBB1DA01AB579874@EX-SEA5-D.ant.amazon.com> <000801ca03e0$6a22bea0$6801a8c0@oemcomputer> <3e0701ca0471$2cbf4ab0$0300a8c0@Vickynew> In-Reply-To: <3e0701ca0471$2cbf4ab0$0300a8c0@Vickynew> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'LTRU Working Group' Subject: Re: [Ltru] rechartering to handle 639-6 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 04:35:59 -0000 On 2009/07/14 19:52, Debbie Garside wrote: > I do, however, think it would be a good idea to keep this list open for > general discussions This is the plan. This happens with most if not all IETF WG list once the WG is done. Regards, Martin. > and if this proves the case I will inform the list as > and when I consider ISO 639-6 data sufficiently ready for incorporation. > Whether you decide to re-charter at that point (or at any other time) is up > to you. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From prvs=1447403586=debbie@ictmarketing.co.uk Wed Jul 15 00:37:31 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF0D3A6881 for ; Wed, 15 Jul 2009 00:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnxMaQGeiGSV for ; Wed, 15 Jul 2009 00:37:30 -0700 (PDT) Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132]) by core3.amsl.com (Postfix) with ESMTP id 8DD813A6828 for ; Wed, 15 Jul 2009 00:37:29 -0700 (PDT) Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.6) with ESMTP id md50009631693.msg for ; Wed, 15 Jul 2009 08:31:09 +0100 X-Spam-Processed: mx1.nexbyte.net, Wed, 15 Jul 2009 08:31:09 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1447403586=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 15 Jul 2009 08:11:00 +0100 From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81><1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> <9998597D06284EEC836787FD5DF74732@DGBP7M81> Date: Wed, 15 Jul 2009 08:10:31 +0100 Message-ID: <1dd001ca051b$573f1bd0$0c00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoE89m7RvQTypSMRiGAs9Q4OVfH8gAJn0Fw In-Reply-To: <9998597D06284EEC836787FD5DF74732@DGBP7M81> X-MDAV-Processed: mx1.nexbyte.net, Wed, 15 Jul 2009 08:31:10 +0100 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly inupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 11:33:15 -0000 Doug wrote: > I think there are still some basic concepts to be worked out > since that post 2½ years ago. For example, John Cowan has > since suggested using 5-character variant subtags starting > with "6" to hold ISO 639-6 code elements, instead of using > the 4-letter language subtags reserved for > (shhhh) this purpose. That wasn't mentioned in the November > 2006 post, but it's something we would have to decide upon. Actually Peter constable suggested 5 characters some 6/7 years ago when I first joined the list. I really don't have the time at present to enter into in-depth discussions on the inclusion/benefits/problems of incorporating ISO 639-6 especially as it would appear to be an uphill battle. I would rather wait until the standard is published and somebody comes along and states their need. Best regards Debbie > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > Behalf Of Doug Ewell > Sent: 15 July 2009 03:24 > To: LTRU Working Group > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: > Anomaly inupcomingregistry) > > Debbie Garside wrote: > > >> So far we haven't seen any proposal that accomplishes all three > >> goals. > > > > I think we pretty much worked this out a few years ago... See > > http://www.ietf.org/mail-archive/web/ltru/current/msg06482.html > > But as I said in my previous message, I am not quite ready > yet as it > > will involve some flagging of the data. > > I think there are still some basic concepts to be worked out > since that post 2½ years ago. For example, John Cowan has > since suggested using 5-character variant subtags starting > with "6" to hold ISO 639-6 code elements, instead of using > the 4-letter language subtags reserved for > (shhhh) this purpose. That wasn't mentioned in the November > 2006 post, but it's something we would have to decide upon. > > Randy Presuhn com> replied: > > > I'd really like to know the what language tagging problem would be > > fixed by digging into 639-6, what the payoff (in terms of > users served > > or content tagged) would be, and why a working group would be > > necessary to cope with it. > > Well, that's exactly what I said before: we need to know. We > don't need to recharter the WG to find out these facts if we > can have the discussion now. Of course, having the text of > the standard and the data available would help immensely, but > that's not available now, so we're left to do some guessing > and projecting. > > -- > Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN > #14 http://www.ewellic.org > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > From prvs=1447403586=debbie@ictmarketing.co.uk Wed Jul 15 05:32:51 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03FD3A6C88 for ; Wed, 15 Jul 2009 05:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTbD38sRCb+e for ; Wed, 15 Jul 2009 05:32:51 -0700 (PDT) Received: from mx1.nexbyte.net (132.nexbyte.net [62.197.41.132]) by core3.amsl.com (Postfix) with ESMTP id B0EA13A6C75 for ; Wed, 15 Jul 2009 05:32:50 -0700 (PDT) Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.6) with ESMTP id md50009631663.msg for ; Wed, 15 Jul 2009 08:21:08 +0100 X-Spam-Processed: mx1.nexbyte.net, Wed, 15 Jul 2009 08:21:08 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1447403586=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 15 Jul 2009 08:01:02 +0100 From: "Debbie Garside" To: "'Randy Presuhn'" , "'LTRU Working Group'" References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81><1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> <036201ca04a9$c6500ec0$6801a8c0@oemcomputer> Date: Wed, 15 Jul 2009 08:00:33 +0100 Message-ID: <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4Rw In-Reply-To: <036201ca04a9$c6500ec0$6801a8c0@oemcomputer> X-MDAV-Processed: mx1.nexbyte.net, Wed, 15 Jul 2009 08:21:09 +0100 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 12:32:51 -0000 Well for starters, there are separate codes for Catalan and Valencian :-) And, I rather like the way ISO 639-6 deals with variants of Chinese. Perhaps you would like to tell me how many of the 7000+ codes of ISO 639-3 will be used. My guess is approximately 2-300 at present but over time more and more. The answer is the same for ISO 639-6. Essentially, all the reasons for including ISO 639-6 are the same as for including ISO 639-3. Unless of course, you think that ISO 639-3 is perfect and defines all languages distinctly and that anything else cannot, is not, and definitely is not a language. Then of course you have to decide that BCP 47 will only deal with languages and not dialects. Then, and only then, may you exclude ISO 639-6. Debbie > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: 14 July 2009 18:38 > To: LTRU Working Group > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: > Anomalyinupcomingregistry) > > Hi - > > > From: "Debbie Garside" > > To: "'Doug Ewell'" ; "'LTRU Working Group'" > > > > Cc: > > Sent: Tuesday, July 14, 2009 9:47 AM > > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly > > inupcomingregistry) > ... > > I think we pretty much worked this out a few years ago... See > > http://www.ietf.org/mail-archive/web/ltru/current/msg06482.html > > But as I said in my previous message, I am not quite ready > yet as it > > will involve some flagging of the data. > ... > > As a technical contributor... > > How much content (as a percentage of internet traffic, or as > a percentage of on-line library holdings, for example) would > be covered by 639-6 (when it's done) that would not (or could > not) be covered by the registry updates recently approved and > the normal operation of ietf-languages@iana.org? > What languages does it cover that cannot be addressed under > the current regime? > > I'd really like to know the what language tagging problem > would be fixed by digging into 639-6, what the payoff (in > terms of users served or content tagged) would be, and why a > working group would be necessary to cope with it. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > > From kent.karlsson14@comhem.se Wed Jul 15 06:29:45 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919733A6ABC for ; Wed, 15 Jul 2009 06:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.407 X-Spam-Level: X-Spam-Status: No, score=-4.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-C6c7YD76sf for ; Wed, 15 Jul 2009 06:29:44 -0700 (PDT) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by core3.amsl.com (Postfix) with ESMTP id D086D3A6993 for ; Wed, 15 Jul 2009 06:29:16 -0700 (PDT) Received: from c83-248-191-93.bredband.comhem.se ([83.248.191.93]:34084 helo=[192.168.1.2]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MR4X4-00076Q-4U; Wed, 15 Jul 2009 15:28:28 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 15:27:50 +0200 From: Kent Karlsson To: , 'LTRU Working Group' Message-ID: Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwAA3VKU4= In-Reply-To: <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 83.248.191.93 X-Scan-Result: No virus found in message 1MR4X4-00076Q-4U. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MR4X4-00076Q-4U 23b581b330dca20333f0a7ffbdf1b198 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 13:29:45 -0000 Den 2009-07-15 09.00, skrev "Debbie Garside" : > Well for starters, there are separate codes for Catalan and Valencian :-) So does BCP 47 (well, nearly): ca ca-valencia There is nothing in principle hindering a registration of a variant subtag specifically for "true" Catalan (no value judgement implied). > And, I rather like the way ISO 639-6 deals with variants of Chinese. 639-3 also deals with "variants" of Chinese (separate languages, really). How does 639-6 do it differently (apart from using 4-letter codes instead of 3-letter codes)? > Perhaps you would like to tell me how many of the 7000+ codes of ISO 639-3 > will be used. My guess is approximately 2-300 at present but over time more > and more. The answer is the same for ISO 639-6. > > Essentially, all the reasons for including ISO 639-6 are the same as for > including ISO 639-3. Unless of course, you think that ISO 639-3 is perfect > and defines all languages distinctly and that anything else cannot, is not, > and definitely is not a language. Then of course you have to decide that > BCP 47 will only deal with languages and not dialects. BCP 47 does deal with dialects, using variant subtags. However, it is very very far from systematic or comprehensive. It requires individual registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers of BCP 47, IMHO. /kent k > Then, and only then, > may you exclude ISO 639-6. > > > Debbie From gerard.meijssen@gmail.com Wed Jul 15 07:19:21 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8473A6B43 for ; Wed, 15 Jul 2009 07:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEszip3G9QW1 for ; Wed, 15 Jul 2009 07:19:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id EE1063A6AB4 for ; Wed, 15 Jul 2009 07:19:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so805238fga.18 for ; Wed, 15 Jul 2009 07:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Lio2eVoZwTPuH1sEbmlwuHtw2hkqyysSZR3DuAoNwq0=; b=IT7j38SyIhcofVAR2EyQy7JBcJn1mBi9qpPQpvDrFw452u86vD//+wtMgIv5xzOe1h a3DRqRQ/ysbTXvtDwgcwgtuitdh5anURd7ePU8YQEy4TZ1Gs/gqiKjioGGBm98I/5Zli /qSjBJ7jbiDvOruQyRzb4SRPQuXOD1Jrl7TFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xzInxjJaYDmJJ3X6Q0j4miBL++NEKlPWKuagv0NZRtbqyUshVkIcmrQsdDCaCQZBbS /vLxtdzuCRSUCq8HmNi2v+uLW++z47W+M7TgtxcWqn7uu2vZLVfFQn9zGscBuRcOSebz UWeBlowrqHAdDa3MixvQaamoZ2tqEEpUomcvw= MIME-Version: 1.0 Received: by 10.86.84.16 with SMTP id h16mr5103074fgb.36.1247665666064; Wed, 15 Jul 2009 06:47:46 -0700 (PDT) In-Reply-To: References: <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> From: Gerard Meijssen Date: Wed, 15 Jul 2009 15:47:26 +0200 Message-ID: <41a006820907150647i1d1b7a8avb79e9fbd1af9c432@mail.gmail.com> To: Kent Karlsson Content-Type: multipart/alternative; boundary=000e0cd289c2d30432046ebecc6c Cc: LTRU Working Group Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 14:19:21 -0000 --000e0cd289c2d30432046ebecc6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hoi, The "best practice" is limited to a subset what these codes can be used for. Imho defending a practice that will never inherently provide a systematic or comprehensive approach is hard when a replacement with a more systematic and comprehensive approach becomes available. Thanks, GerardM 2009/7/15 Kent Karlsson > > Den 2009-07-15 09.00, skrev "Debbie Garside" : > > > Well for starters, there are separate codes for Catalan and Valencian :-) > > So does BCP 47 (well, nearly): > ca > ca-valencia > > There is nothing in principle hindering a registration of a variant subtag > specifically for "true" Catalan (no value judgement implied). > > > And, I rather like the way ISO 639-6 deals with variants of Chinese. > > 639-3 also deals with "variants" of Chinese (separate languages, really). > How does 639-6 do it differently (apart from using 4-letter codes instead > of > 3-letter codes)? > > > Perhaps you would like to tell me how many of the 7000+ codes of ISO > 639-3 > > will be used. My guess is approximately 2-300 at present but over time > more > > and more. The answer is the same for ISO 639-6. > > > > Essentially, all the reasons for including ISO 639-6 are the same as for > > including ISO 639-3. Unless of course, you think that ISO 639-3 is > perfect > > and defines all languages distinctly and that anything else cannot, is > not, > > and definitely is not a language. Then of course you have to decide that > > BCP 47 will only deal with languages and not dialects. > > BCP 47 does deal with dialects, using variant subtags. However, it is very > very far from systematic or comprehensive. It requires individual > registration of each variant. I would venture to guess that that process > will never result in a systematic or (in some sense) comprehensive set > of variant subtags for dialects. On the other hand, the call for tagging > dialects separately, currently seems fairly small amongst the consumers of > BCP 47, IMHO. > > /kent k > > > Then, and only then, > > may you exclude ISO 639-6. > > > > > > Debbie > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > --000e0cd289c2d30432046ebecc6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hoi,
The "best practice" is limited to a subset what these cod= es can be used for. Imho defending a practice that will never inherently pr= ovide a systematic or comprehensive approach is hard when a replacement wit= h a more systematic and comprehensive approach becomes available.
Thanks,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GerardM

2009/7/15 Kent Karlsson <kent.karlsson14@comhem.se>

Den 2009-07-15 09.00, skrev "Debbie Garside" <debbie@ictmarketing.co.uk>:

> Well for starters, there are separate codes for Catalan and Valencian = :-)

So does BCP 47 (well, nearly):
=C2=A0 =C2=A0ca
=C2=A0 =C2=A0ca-valencia

There is nothing in principle hindering a registration of a variant subtag<= br> specifically for "true" Catalan (no value judgement implied).

> And, I rather like the way ISO 639-6 deals with variants of Chinese.
639-3 also deals with "variants" of Chinese (separate langu= ages, really).
How does 639-6 do it differently (apart from using 4-letter codes instead o= f
3-letter codes)?

> Perhaps you would like to tell me how many of the 7000+ codes of ISO 6= 39-3
> will be used. =C2=A0My guess is approximately 2-300 at present but ove= r time more
> and more. =C2=A0The answer is the same for ISO 639-6.
>
> Essentially, all the reasons for including ISO 639-6 are the same as f= or
> including ISO 639-3. =C2=A0Unless of course, you think that ISO 639-3 = is perfect
> and defines all languages distinctly and that anything else cannot, is= not,
> and definitely is not a language. =C2=A0Then of course you have to dec= ide that
> BCP 47 will only deal with languages and not dialects.

BCP 47 does deal with dialects, using variant subtags. However, it is= very
very far from systematic or comprehensive. It requires individual
registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set
of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers of<= br> BCP 47, IMHO.

=C2=A0 =C2=A0/kent k

> Then, and only then,
> may you exclude ISO 639-6.
>
>
> Debbie


___________________________________= ____________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru

--000e0cd289c2d30432046ebecc6c-- From petercon@microsoft.com Wed Jul 15 08:26:35 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7244028C13C for ; Wed, 15 Jul 2009 08:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKLfE+ZcZqDF for ; Wed, 15 Jul 2009 08:26:33 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0EAF03A6CED for ; Wed, 15 Jul 2009 08:26:33 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 15 Jul 2009 08:25:14 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Wed, 15 Jul 2009 08:25:14 -0700 From: Peter Constable To: "debbie@ictmarketing.co.uk" , 'Randy Presuhn' , 'LTRU Working Group' Date: Wed, 15 Jul 2009 08:25:10 -0700 Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwABHdjjA= Message-ID: References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81><1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> <036201ca04a9$c6500ec0$6801a8c0@oemcomputer> <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> In-Reply-To: <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:26:35 -0000 SIL certainly has projects involving way more than 2-300. For them, 2000 is= not unrealistic. Peter -----Original Message----- From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Deb= bie Garside Sent: Wednesday, July 15, 2009 12:01 AM To: 'Randy Presuhn'; 'LTRU Working Group' Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcoming= registry) Well for starters, there are separate codes for Catalan and Valencian :-) And, I rather like the way ISO 639-6 deals with variants of Chinese. Perhaps you would like to tell me how many of the 7000+ codes of ISO 639-3 will be used. My guess is approximately 2-300 at present but over time mor= e and more. The answer is the same for ISO 639-6. Essentially, all the reasons for including ISO 639-6 are the same as for including ISO 639-3. Unless of course, you think that ISO 639-3 is perfect and defines all languages distinctly and that anything else cannot, is not, and definitely is not a language. Then of course you have to decide that BCP 47 will only deal with languages and not dialects. Then, and only then= , may you exclude ISO 639-6. Debbie > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: 14 July 2009 18:38 > To: LTRU Working Group > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: > Anomalyinupcomingregistry) > > Hi - > > > From: "Debbie Garside" > > To: "'Doug Ewell'" ; "'LTRU Working Group'" > > > > Cc: > > Sent: Tuesday, July 14, 2009 9:47 AM > > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomaly > > inupcomingregistry) > ... > > I think we pretty much worked this out a few years ago... See > > http://www.ietf.org/mail-archive/web/ltru/current/msg06482.html > > But as I said in my previous message, I am not quite ready > yet as it > > will involve some flagging of the data. > ... > > As a technical contributor... > > How much content (as a percentage of internet traffic, or as > a percentage of on-line library holdings, for example) would > be covered by 639-6 (when it's done) that would not (or could > not) be covered by the registry updates recently approved and > the normal operation of ietf-languages@iana.org? > What languages does it cover that cannot be addressed under > the current regime? > > I'd really like to know the what language tagging problem > would be fixed by digging into 639-6, what the payoff (in > terms of users served or content tagged) would be, and why a > working group would be necessary to cope with it. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru From petercon@microsoft.com Wed Jul 15 08:34:58 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32B33A6B9F for ; Wed, 15 Jul 2009 08:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwQrk5toZw5i for ; Wed, 15 Jul 2009 08:34:58 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 085553A6B79 for ; Wed, 15 Jul 2009 08:34:58 -0700 (PDT) Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 15 Jul 2009 08:33:45 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exmlt-c102.redmond.corp.microsoft.com ([157.54.24.67]) with mapi; Wed, 15 Jul 2009 08:33:45 -0700 From: Peter Constable To: "debbie@ictmarketing.co.uk" , 'Randy Presuhn' , 'LTRU Working Group' Date: Wed, 15 Jul 2009 08:33:43 -0700 Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwABHxWeA= Message-ID: References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81><1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110> <036201ca04a9$c6500ec0$6801a8c0@oemcomputer> <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> In-Reply-To: <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:34:58 -0000 From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Deb= bie Garside > Essentially, all the reasons for including ISO 639-6 are the same as for > including ISO 639-3. Unless of course, you think that ISO 639-3 is perfe= ct > and defines all languages distinctly and that anything else cannot, is no= t, > and definitely is not a language. Then of course you have to decide that > BCP 47 will only deal with languages and not dialects. Then, and only th= en, > may you exclude ISO 639-6. Your qualifications notwithstanding, I disagree. While the boundaries of la= nguages and dialects may be debatable generally and in many cases, I think = it is the case that there are a good number of cases for which there is cur= rent practice and convention in terms of recognizing languages, that this n= umber well exceeds what was covered in 639-1/-2 and is largely encompassed = within 639-3. There will remain a relatively small number of cases in which= conventionally-recognized language entities are not covered, and those may= be covered in 639-6, but if there is conventional acceptance that they sho= uld be deemed languages then they are probably candidates for part 3; it wo= uld not be worth supporting all of 639-6 just for this particular tail, IMO= . Rather, I think if there is potential benefit from 639-6 it will be in rela= tion to sub-language variations.=20 Peter From Karen.Broome@am.sony.com Wed Jul 15 08:37:50 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AEB28C123 for ; Wed, 15 Jul 2009 08:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2hf5gQiMMGh for ; Wed, 15 Jul 2009 08:37:49 -0700 (PDT) Received: from SG2EHSOBE005.bigfish.com (sg2ehsobe005.messaging.microsoft.com [207.46.51.79]) by core3.amsl.com (Postfix) with ESMTP id 2E80F28C11E for ; Wed, 15 Jul 2009 08:37:49 -0700 (PDT) Received: from mail225-sin-R.bigfish.com (10.210.100.243) by SG2EHSOBE005.bigfish.com (10.210.112.25) with Microsoft SMTP Server id 8.1.340.0; Wed, 15 Jul 2009 15:37:33 +0000 Received: from mail225-sin (localhost.localdomain [127.0.0.1]) by mail225-sin-R.bigfish.com (Postfix) with ESMTP id 9BEA218D80A4; Wed, 15 Jul 2009 15:37:21 +0000 (UTC) X-SpamScore: -48 X-BigFish: VPS-48(z518kz542N1432R936eM1442J9371Pzz1202hzz1033ILz2fh6bh61h) X-Spam-TCS-SCL: 0:0 Received: by mail225-sin (MessageSwitch) id 1247672238953396_25965; Wed, 15 Jul 2009 15:37:18 +0000 (UCT) Received: from mail8.fw-sd.sony.com (mail8.fw-sd.sony.com [160.33.66.75]) by mail225-sin.bigfish.com (Postfix) with ESMTP id 7FB6D13A8059; Wed, 15 Jul 2009 15:37:18 +0000 (UTC) Received: from mail1.bc.in.sel.sony.com (mail1.bc.in.sel.sony.com [43.144.65.111]) by mail8.fw-sd.sony.com (8.14.2/8.14.2) with ESMTP id n6FFbSmw027916; Wed, 15 Jul 2009 15:37:28 GMT Received: from USBMAXIM02.am.sony.com ([43.145.108.26]) by mail1.bc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id n6FFbSPu021453; Wed, 15 Jul 2009 15:37:28 GMT Received: from USBMAXRG01.am.sony.com ([43.145.108.23]) by USBMAXIM02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 11:37:27 -0400 Received: from USSDIXRG02.am.sony.com ([43.130.140.32]) by USBMAXRG01.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 11:37:27 -0400 Received: from USSDIXRG01.am.sony.com ([43.130.140.31]) by USSDIXRG02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 08:37:07 -0700 Received: from USSDIXMS01.am.sony.com ([43.130.140.21]) by USSDIXRG01.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 08:37:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0562.1BFEBDFF" Date: Wed, 15 Jul 2009 08:37:06 -0700 Message-ID: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW:Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwAA3VKU4ABDzJYw== References: From: "Broome, Karen" To: "Kent Karlsson" , , "LTRU Working Group" X-OriginalArrivalTime: 15 Jul 2009 15:37:07.0584 (UTC) FILETIME=[1C74F000:01CA0562] X-SEL-encryption-scan: scanned Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:37:50 -0000 ------_=_NextPart_001_01CA0562.1BFEBDFF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For what it's worth, the film and television world does have a pretty = heavy requirement for dialect distinctions. We also have a need to = identify spoken and written variants. ISO 639-6 also provides a = fixed-length tag, which can be advantageous in some situations. While I = tend to see ISO 639-6 as an interesting alternative to xml:lang and not = necessarily something I'd use within xml:lang, I wanted to correct the = assumption that dialect tagging is obscure and the distinction between = spoken and written variants is not useful. Regards, Karen Broome -----Original Message----- From: ltru-bounces@ietf.org on behalf of Kent Karlsson Sent: Wed 7/15/2009 6:27 AM To: debbie@ictmarketing.co.uk; 'LTRU Working Group' Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: = Anomalyinupcomingregistry) =20 Den 2009-07-15 09.00, skrev "Debbie Garside" = : > Well for starters, there are separate codes for Catalan and Valencian = :-) So does BCP 47 (well, nearly): ca ca-valencia There is nothing in principle hindering a registration of a variant = subtag specifically for "true" Catalan (no value judgement implied). > And, I rather like the way ISO 639-6 deals with variants of Chinese. 639-3 also deals with "variants" of Chinese (separate languages, = really). How does 639-6 do it differently (apart from using 4-letter codes = instead of 3-letter codes)? > Perhaps you would like to tell me how many of the 7000+ codes of ISO = 639-3 > will be used. My guess is approximately 2-300 at present but over = time more > and more. The answer is the same for ISO 639-6. >=20 > Essentially, all the reasons for including ISO 639-6 are the same as = for > including ISO 639-3. Unless of course, you think that ISO 639-3 is = perfect > and defines all languages distinctly and that anything else cannot, is = not, > and definitely is not a language. Then of course you have to decide = that > BCP 47 will only deal with languages and not dialects. BCP 47 does deal with dialects, using variant subtags. However, it is = very very far from systematic or comprehensive. It requires individual registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers = of BCP 47, IMHO. /kent k > Then, and only then, > may you exclude ISO 639-6. >=20 >=20 > Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01CA0562.1BFEBDFF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ltru] rechartering to handle 639-6 (was FW: = Anomalyinupcomingregistry)

For what it's worth, the film and television world = does have a pretty heavy requirement for dialect distinctions. We also = have a need to identify spoken and written variants. ISO 639-6 also = provides a fixed-length tag, which can be advantageous in some = situations. While I tend to see ISO 639-6 as an interesting alternative = to xml:lang and not necessarily something I'd use within xml:lang, I = wanted to correct the assumption that dialect tagging is obscure and the = distinction between spoken and written variants is not useful.

Regards,

Karen Broome


-----Original Message-----
From: ltru-bounces@ietf.org on behalf of Kent Karlsson
Sent: Wed 7/15/2009 6:27 AM
To: debbie@ictmarketing.co.uk; 'LTRU Working Group'
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: = Anomalyinupcomingregistry)


Den 2009-07-15 09.00, skrev "Debbie Garside" = <debbie@ictmarketing.co.uk>:

> Well for starters, there are separate codes for Catalan and = Valencian :-)

So does BCP 47 (well, nearly):
    ca
    ca-valencia

There is nothing in principle hindering a registration of a variant = subtag
specifically for "true" Catalan (no value judgement = implied).

> And, I rather like the way ISO 639-6 deals with variants of = Chinese.

639-3 also deals with "variants" of Chinese (separate = languages, really).
How does 639-6 do it differently (apart from using 4-letter codes = instead of
3-letter codes)?

> Perhaps you would like to tell me how many of the 7000+ codes of = ISO 639-3
> will be used.  My guess is approximately 2-300 at present but = over time more
> and more.  The answer is the same for ISO 639-6.
>
> Essentially, all the reasons for including ISO 639-6 are the same = as for
> including ISO 639-3.  Unless of course, you think that ISO = 639-3 is perfect
> and defines all languages distinctly and that anything else cannot, = is not,
> and definitely is not a language.  Then of course you have to = decide that
> BCP 47 will only deal with languages and not dialects.

BCP 47 does deal with dialects, using variant subtags. However, it is = very
very far from systematic or comprehensive. It requires individual
registration of each variant. I would venture to guess that that = process
will never result in a systematic or (in some sense) comprehensive = set
of variant subtags for dialects. On the other hand, the call for = tagging
dialects separately, currently seems fairly small amongst the consumers = of
BCP 47, IMHO.

    /kent k

> Then, and only then,
> may you exclude ISO 639-6.
>
>
> Debbie


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

------_=_NextPart_001_01CA0562.1BFEBDFF-- From mark.edward.davis@gmail.com Wed Jul 15 10:31:57 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E039D3A69F4 for ; Wed, 15 Jul 2009 10:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AENBTeqcqVrP for ; Wed, 15 Jul 2009 10:31:56 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 5E9EB3A683A for ; Wed, 15 Jul 2009 10:31:55 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1759565anc.4 for ; Wed, 15 Jul 2009 10:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=aHIoawcncIDmzW/w1ur/SWAv2vjunyE3x8LGCIbF5W4=; b=a8RH2JDwCDsi/u3ox/NdNclgF9XbN2wwxrzvwtgCF6B4nm4BVJzpn8BM9/krmOgbjN cQr2vP6WAFiYeCm9gxRVBMP/666es/BzeB9aEsTPQYD0UgKqHyUge5WeZ8bE3wiTz125 dtHYFE1xStcuzTwD9nWh94atlw4+xieVxvGts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uuFrXbYWQP+Y8mp3cnGrPClBb75EtsKWOGHIuls7Sn/q7RWFIeVot6wFPl+2MEAwbS sxBRCSg8h80zd9wPvPZwVRCuZvJlHRv2lvhslcyqOrkyy+PRc92zyvcvtcvAzt1d2OJg z2hAtdu21GeYmc465B57+CMoiTlxmY5YLSIQQ= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.210.8 with SMTP id i8mr10219356ang.172.1247679075641; Wed, 15 Jul 2009 10:31:15 -0700 (PDT) In-Reply-To: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> References: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> Date: Wed, 15 Jul 2009 10:31:15 -0700 X-Google-Sender-Auth: 89a2444b86d35fb0 Message-ID: <30b660a20907151031i6e8bbeedyc4d33ffa59cce113@mail.gmail.com> From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= To: "Broome, Karen" Content-Type: multipart/alternative; boundary=001636af01de18ec45046ec1ecf1 Cc: LTRU Working Group Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 17:31:58 -0000 --001636af01de18ec45046ec1ecf1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the difference among dialects is important, but 639-6 doesn't work for incorporation into BCP47. The advantage of the BCP47 structure is that it allows reasonable behavior for applications that don't recognize the dialectical distinctions. That is, if we have: en-US-southern en-US-newengla en-US-philly (pronouncing "huge" as /jud=CA=92/) en-US-general en-GB-scots ... (cf http://en.wikipedia.org/wiki/List_of_dialects_of_the_English_language) Then applications that don't recognize the variants can fall back to en-US and en-GB. If these all had different atomic primary language codes, then applications would be forced to keep all the relationship data for all the codes hanging around - which, frankly, they are not going to do. Mark On Wed, Jul 15, 2009 at 08:37, Broome, Karen wrot= e: > For what it's worth, the film and television world does have a pretty > heavy requirement for dialect distinctions. We also have a need to identi= fy > spoken and written variants. ISO 639-6 also provides a fixed-length tag, > which can be advantageous in some situations. While I tend to see ISO 639= -6 > as an interesting alternative to xml:lang and not necessarily something I= 'd > use within xml:lang, I wanted to correct the assumption that dialect tagg= ing > is obscure and the distinction between spoken and written variants is not > useful. > > Regards, > > Karen Broome > > > -----Original Message----- > From: ltru-bounces@ietf.org on behalf of Kent Karlsson > Sent: Wed 7/15/2009 6:27 AM > To: debbie@ictmarketing.co.uk; 'LTRU Working Group' > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: > Anomalyinupcomingregistry) > > > Den 2009-07-15 09.00, skrev "Debbie Garside" : > > > Well for starters, there are separate codes for Catalan and Valencian := -) > > So does BCP 47 (well, nearly): > ca > ca-valencia > > There is nothing in principle hindering a registration of a variant subta= g > specifically for "true" Catalan (no value judgement implied). > > > And, I rather like the way ISO 639-6 deals with variants of Chinese. > > 639-3 also deals with "variants" of Chinese (separate languages, really). > How does 639-6 do it differently (apart from using 4-letter codes instead > of > 3-letter codes)? > > > Perhaps you would like to tell me how many of the 7000+ codes of ISO > 639-3 > > will be used. My guess is approximately 2-300 at present but over time > more > > and more. The answer is the same for ISO 639-6. > > > > Essentially, all the reasons for including ISO 639-6 are the same as fo= r > > including ISO 639-3. Unless of course, you think that ISO 639-3 is > perfect > > and defines all languages distinctly and that anything else cannot, is > not, > > and definitely is not a language. Then of course you have to decide th= at > > BCP 47 will only deal with languages and not dialects. > > BCP 47 does deal with dialects, using variant subtags. However, it is ver= y > very far from systematic or comprehensive. It requires individual > registration of each variant. I would venture to guess that that process > will never result in a systematic or (in some sense) comprehensive set > of variant subtags for dialects. On the other hand, the call for tagging > dialects separately, currently seems fairly small amongst the consumers o= f > BCP 47, IMHO. > > /kent k > > > Then, and only then, > > may you exclude ISO 639-6. > > > > > > Debbie > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > --001636af01de18ec45046ec1ecf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the difference among dialects is important, but 639-6 doesn't w= ork for incorporation into BCP47. The advantage of the BCP47 structure is t= hat it allows reasonable behavior for applications that don't recognize= the dialectical distinctions. That is, if we have:

en-US-southern
en-US-newengla
en-US-philly (pronouncing "hug= e" as /jud=CA=92/)
en-US-general
en-GB-scots
...
(cf http://en.wikipedia.org/wiki/List_of_diale= cts_of_the_English_language)

Then applications that don't re= cognize the variants can fall back to en-US and en-GB. If these all had dif= ferent atomic primary language codes, then applications would be forced to = keep all the relationship data for all the codes hanging around - which, fr= ankly, they are not going to do.

Mark


On Wed, Jul 15, 2009 at 08:37, Broome, K= aren <Kare= n.Broome@am.sony.com> wrote:

For what it's worth, the film and television world = does have a pretty heavy requirement for dialect distinctions. We also have= a need to identify spoken and written variants. ISO 639-6 also provides a = fixed-length tag, which can be advantageous in some situations. While I ten= d to see ISO 639-6 as an interesting alternative to xml:lang and not necess= arily something I'd use within xml:lang, I wanted to correct the assump= tion that dialect tagging is obscure and the distinction between spoken and= written variants is not useful.

Regards,

Karen Broome




-----Original Message-----
From: ltru-bounc= es@ietf.org on behalf of Kent Karlsson
Sent: Wed 7/15/2009 6:27 AM
To: debbie@i= ctmarketing.co.uk; 'LTRU Working Group'
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcoming= registry)


Den 2009-07-15 09.00, skrev "Debbie Garside" <debbie@ictmarketing.co.uk>:

> Well for starters, there are separate codes for Catalan and Valencian = :-)

So does BCP 47 (well, nearly):
=C2=A0=C2=A0=C2=A0 ca
=C2=A0=C2=A0=C2=A0 ca-valencia

There is nothing in principle hindering a registration of a variant subtag<= br> specifically for "true" Catalan (no value judgement implied).

> And, I rather like the way ISO 639-6 deals with variants of Chinese.
639-3 also deals with "variants" of Chinese (separate languages, = really).
How does 639-6 do it differently (apart from using 4-letter codes instead o= f
3-letter codes)?

> Perhaps you would like to tell me how many of the 7000+ codes of ISO 6= 39-3
> will be used.=C2=A0 My guess is approximately 2-300 at present but ove= r time more
> and more.=C2=A0 The answer is the same for ISO 639-6.
>
> Essentially, all the reasons for including ISO 639-6 are the same as f= or
> including ISO 639-3.=C2=A0 Unless of course, you think that ISO 639-3 = is perfect
> and defines all languages distinctly and that anything else cannot, is= not,
> and definitely is not a language.=C2=A0 Then of course you have to dec= ide that
> BCP 47 will only deal with languages and not dialects.

BCP 47 does deal with dialects, using variant subtags. However, it is very<= br> very far from systematic or comprehensive. It requires individual
registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set
of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers of<= br> BCP 47, IMHO.

=C2=A0=C2=A0=C2=A0 /kent k

> Then, and only then,
> may you exclude ISO 639-6.
>
>
> Debbie


_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru



_______________________________________________
Ltru mailing list
Ltru@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ltru


--001636af01de18ec45046ec1ecf1-- From kent.karlsson14@comhem.se Wed Jul 15 11:32:04 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54993A693A for ; Wed, 15 Jul 2009 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJupelNCyb2R for ; Wed, 15 Jul 2009 11:32:03 -0700 (PDT) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by core3.amsl.com (Postfix) with ESMTP id E909D3A6BB9 for ; Wed, 15 Jul 2009 11:32:02 -0700 (PDT) Received: from c83-248-191-93.bredband.comhem.se ([83.248.191.93]:35566 helo=[192.168.1.2]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MR9CS-0006vk-5v; Wed, 15 Jul 2009 20:27:36 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 15 Jul 2009 20:26:56 +0200 From: Kent Karlsson To: "Broome, Karen" , , LTRU Working Group Message-ID: Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwAA3VKU4ABDzJYwAGNWFd In-Reply-To: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3330534448_51682217" X-Originating-IP: 83.248.191.93 X-Scan-Result: No virus found in message 1MR9CS-0006vk-5v. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MR9CS-0006vk-5v 73eedc8d25b9c77bbead8d0ae9e846f3 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:32:04 -0000 > Detta meddelande Šr i MIME-format. PŒ grund av att din e-postlŠsare inte fšrstŒr detta format, kommer hela eller delar av detta meddelande inte att vara lŠsbart. --B_3330534448_51682217 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I never intended to give the impression that I assumed that dialect tagging was obscure, nor that having a distinction between spoken and written variants would not be useful. I just noted that the number of registrations for dialect variants in the Language Subtag Registry is miniscule covering only a handful of dialects of even fewer languages. And that after several years of having a Language (Sub)Tag Registry with registration possibility. /kent k Den 2009-07-15 17.37, skrev "Broome, Karen" : > For what it's worth, the film and television world does have a pretty heavy > requirement for dialect distinctions. We also have a need to identify spoken > and written variants. ISO 639-6 also provides a fixed-length tag, which can be > advantageous in some situations. While I tend to see ISO 639-6 as an > interesting alternative to xml:lang and not necessarily something I'd use > within xml:lang, I wanted to correct the assumption that dialect tagging is > obscure and the distinction between spoken and written variants is not useful. > > Regards, > > Karen Broome > > > -----Original Message----- > From: ltru-bounces@ietf.org on behalf of Kent Karlsson > Sent: Wed 7/15/2009 6:27 AM > To: debbie@ictmarketing.co.uk; 'LTRU Working Group' > Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: > Anomalyinupcomingregistry) > > > Den 2009-07-15 09.00, skrev "Debbie Garside" : > >> > Well for starters, there are separate codes for Catalan and Valencian :-) > > So does BCP 47 (well, nearly): > ca > ca-valencia > > There is nothing in principle hindering a registration of a variant subtag > specifically for "true" Catalan (no value judgement implied). > >> > And, I rather like the way ISO 639-6 deals with variants of Chinese. > > 639-3 also deals with "variants" of Chinese (separate languages, really). > How does 639-6 do it differently (apart from using 4-letter codes instead of > 3-letter codes)? > >> > Perhaps you would like to tell me how many of the 7000+ codes of ISO 639-3 >> > will be used. My guess is approximately 2-300 at present but over time >> more >> > and more. The answer is the same for ISO 639-6. >> > >> > Essentially, all the reasons for including ISO 639-6 are the same as for >> > including ISO 639-3. Unless of course, you think that ISO 639-3 is perfect >> > and defines all languages distinctly and that anything else cannot, is not, >> > and definitely is not a language. Then of course you have to decide that >> > BCP 47 will only deal with languages and not dialects. > > BCP 47 does deal with dialects, using variant subtags. However, it is very > very far from systematic or comprehensive. It requires individual > registration of each variant. I would venture to guess that that process > will never result in a systematic or (in some sense) comprehensive set > of variant subtags for dialects. On the other hand, the call for tagging > dialects separately, currently seems fairly small amongst the consumers of > BCP 47, IMHO. > > /kent k > >> > Then, and only then, >> > may you exclude ISO 639-6. >> > >> > >> > Debbie > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru > > > --B_3330534448_51682217 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingre= gistry) I never intended to give the impression that I assumed that dialect taggin= g
was obscure, nor that having a distinction between spoken and written
variants would not be useful. I just noted that the number of registrations=
for dialect variants in the Language Subtag Registry is miniscule covering<= BR> only a handful of dialects of even fewer languages. And that after several<= BR> years of having a Language (Sub)Tag Registry with registration possibility.=

    /kent k


Den 2009-07-15 17.37, skrev "Broome, Karen" <Karen.Broome@am.sony.com>:

<= SPAN STYLE=3D'font-size:11pt'>For what it's worth, the film and television wor= ld does have a pretty heavy requirement for dialect distinctions. We also ha= ve a need to identify spoken and written variants. ISO 639-6 also provides a= fixed-length tag, which can be advantageous in some situations. While I ten= d to see ISO 639-6 as an interesting alternative to xml:lang and not necessa= rily something I'd use within xml:lang, I wanted to correct the assumption t= hat dialect tagging is obscure and the distinction between spoken and writte= n variants is not useful.

Regards,

Karen Broome


-----Original Message-----
From: ltru-bounces@ietf.org on behalf o= f Kent Karlsson
Sent: Wed 7/15/2009 6:27 AM
To: debbie@ictmarketing.co.uk; 'LTR= U Working Group'
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcoming= registry)


Den 2009-07-15 09.00, skrev "Debbie Garside" <debbie@ictmarketing.co.uk>:

> Well for starters, there are separate codes for Catalan and Valencian = :-)

So does BCP 47 (well, nearly):
    ca
    ca-valencia

There is nothing in principle hindering a registration of a variant subtag<= BR> specifically for "true" Catalan (no value judgement implied).

> And, I rather like the way ISO 639-6 deals with variants of Chinese.
639-3 also deals with "variants" of Chinese (separate languages, = really).
How does 639-6 do it differently (apart from using 4-letter codes instead o= f
3-letter codes)?

> Perhaps you would like to tell me how many of the 7000+ codes of ISO 6= 39-3
> will be used.  My guess is approximately 2-300 at present but ove= r time more
> and more.  The answer is the same for ISO 639-6.
>
> Essentially, all the reasons for including ISO 639-6 are the same as f= or
> including ISO 639-3.  Unless of course, you think that ISO 639-3 = is perfect
> and defines all languages distinctly and that anything else cannot, is= not,
> and definitely is not a language.  Then of course you have to dec= ide that
> BCP 47 will only deal with languages and not dialects.

BCP 47 does deal with dialects, using variant subtags. However, it is very<= BR> very far from systematic or comprehensive. It requires individual
registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set
of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers of<= BR> BCP 47, IMHO.

    /kent k

> Then, and only then,
> may you exclude ISO 639-6.
>
>
> Debbie


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/m= ailman/listinfo/ltru



--B_3330534448_51682217-- From petercon@microsoft.com Wed Jul 15 13:31:26 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5799F3A690A for ; Wed, 15 Jul 2009 13:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.226 X-Spam-Level: X-Spam-Status: No, score=-11.226 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1+V-VhoComd for ; Wed, 15 Jul 2009 13:31:20 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CBCB73A63CB for ; Wed, 15 Jul 2009 13:31:19 -0700 (PDT) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 15 Jul 2009 13:27:55 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.18.48]) with mapi; Wed, 15 Jul 2009 13:27:55 -0700 From: Peter Constable To: "Broome, Karen" , Kent Karlsson , "debbie@ictmarketing.co.uk" , LTRU Working Group Date: Wed, 15 Jul 2009 13:27:44 -0700 Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwAA3VKU4ABDzJYwAKSnOw Message-ID: References: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> In-Reply-To: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB8357956B0B299E56NAEXMSGC117re_" MIME-Version: 1.0 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:31:26 -0000 --_000_DDB6DE6E9D27DD478AE6D1BBBB8357956B0B299E56NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Karen: do you want a list of (order of magnitude) 10,000 language variants = for users in the film & television industry to choose from, or just those t= hat they need? What we have now _should_ be able to deliver what they need. One thing that an atomic, fixed-length tag does *not* do well: provide indi= vidual facets of the total information denoted -- the language, the region,= the script - except by relying on carrying tables of data in which those c= an be looked up. Peter From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Bro= ome, Karen Sent: Wednesday, July 15, 2009 8:37 AM To: Kent Karlsson; debbie@ictmarketing.co.uk; LTRU Working Group Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcoming= registry) For what it's worth, the film and television world does have a pretty heavy= requirement for dialect distinctions. We also have a need to identify spok= en and written variants. ISO 639-6 also provides a fixed-length tag, which = can be advantageous in some situations. While I tend to see ISO 639-6 as an= interesting alternative to xml:lang and not necessarily something I'd use = within xml:lang, I wanted to correct the assumption that dialect tagging is= obscure and the distinction between spoken and written variants is not use= ful. Regards, Karen Broome -----Original Message----- From: ltru-bounces@ietf.org on behalf of Kent Karlsson Sent: Wed 7/15/2009 6:27 AM To: debbie@ictmarketing.co.uk; 'LTRU Working Group' Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcoming= registry) Den 2009-07-15 09.00, skrev "Debbie Garside" : > Well for starters, there are separate codes for Catalan and Valencian :-) So does BCP 47 (well, nearly): ca ca-valencia There is nothing in principle hindering a registration of a variant subtag specifically for "true" Catalan (no value judgement implied). > And, I rather like the way ISO 639-6 deals with variants of Chinese. 639-3 also deals with "variants" of Chinese (separate languages, really). How does 639-6 do it differently (apart from using 4-letter codes instead o= f 3-letter codes)? > Perhaps you would like to tell me how many of the 7000+ codes of ISO 639-= 3 > will be used. My guess is approximately 2-300 at present but over time m= ore > and more. The answer is the same for ISO 639-6. > > Essentially, all the reasons for including ISO 639-6 are the same as for > including ISO 639-3. Unless of course, you think that ISO 639-3 is perfe= ct > and defines all languages distinctly and that anything else cannot, is no= t, > and definitely is not a language. Then of course you have to decide that > BCP 47 will only deal with languages and not dialects. BCP 47 does deal with dialects, using variant subtags. However, it is very very far from systematic or comprehensive. It requires individual registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers of BCP 47, IMHO. /kent k > Then, and only then, > may you exclude ISO 639-6. > > > Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru --_000_DDB6DE6E9D27DD478AE6D1BBBB8357956B0B299E56NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)

Karen: do you want a list of (order of magnitude) 10,000 lan= guage variants for users in the film & television industry to choose from, or just those that they need?

 

What we have now _should_ be able to deliver what the= y need.

 

One thing that an atomic, fixed-length tag does *not*= do well: provide individual facets of the total information denoted -- the language, the region, the script – except by relying on carrying tabl= es of data in which those can be looked up.

 

 

Peter

 

From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Br= oome, Karen
Sent: Wednesday, July 15, 2009 8:37 AM
To: Kent Karlsson; debbie@ictmarketing.co.uk; LTRU Working Group
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)

 

For what= it's worth, the film and television world does have a pretty heavy requirement f= or dialect distinctions. We also have a need to identify spoken and written variants. ISO 639-6 also provides a fixed-length tag, which can be advantag= eous in some situations. While I tend to see ISO 639-6 as an interesting alterna= tive to xml:lang and not necessarily something I'd use within xml:lang, I wanted= to correct the assumption that dialect tagging is obscure and the distinction between spoken and written variants is not useful.

Regards,

Karen Broome


-----Original Message-----
From: ltru-bounces@ietf.org on behalf of Kent Karlsson
Sent: Wed 7/15/2009 6:27 AM
To: debbie@ictmarketing.co.uk; 'LTRU Working Group'
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)


Den 2009-07-15 09.00, skrev "Debbie Garside" <debbie@ictmarketing.co.uk>:

> Well for starters, there are separate codes for Catalan and Valencian = :-)

So does BCP 47 (well, nearly):
    ca
    ca-valencia

There is nothing in principle hindering a registration of a variant subtag<= br> specifically for "true" Catalan (no value judgement implied).

> And, I rather like the way ISO 639-6 deals with variants of Chinese.
639-3 also deals with "variants" of Chinese (separate languages, really).
How does 639-6 do it differently (apart from using 4-letter codes instead o= f
3-letter codes)?

> Perhaps you would like to tell me how many of the 7000+ codes of ISO 6= 39-3
> will be used.  My guess is approximately 2-300 at present but ove= r time more
> and more.  The answer is the same for ISO 639-6.
>
> Essentially, all the reasons for including ISO 639-6 are the same as f= or
> including ISO 639-3.  Unless of course, you think that ISO 639-3 = is perfect
> and defines all languages distinctly and that anything else cannot, is not,
> and definitely is not a language.  Then of course you have to dec= ide that
> BCP 47 will only deal with languages and not dialects.

BCP 47 does deal with dialects, using variant subtags. However, it is very<= br> very far from systematic or comprehensive. It requires individual
registration of each variant. I would venture to guess that that process will never result in a systematic or (in some sense) comprehensive set
of variant subtags for dialects. On the other hand, the call for tagging dialects separately, currently seems fairly small amongst the consumers of<= br> BCP 47, IMHO.

    /kent k

> Then, and only then,
> may you exclude ISO 639-6.
>
>
> Debbie


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

--_000_DDB6DE6E9D27DD478AE6D1BBBB8357956B0B299E56NAEXMSGC117re_-- From petercon@microsoft.com Wed Jul 15 13:41:07 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B3328C145 for ; Wed, 15 Jul 2009 13:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUpVedodpDyw for ; Wed, 15 Jul 2009 13:41:07 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1694728C0F9 for ; Wed, 15 Jul 2009 13:41:07 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 15 Jul 2009 13:40:18 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Wed, 15 Jul 2009 13:40:17 -0700 From: Peter Constable To: "debbie@ictmarketing.co.uk" , 'Randy Presuhn' , 'LTRU Working Group' Date: Wed, 15 Jul 2009 13:40:16 -0700 Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW:Anomalyinupcomingregistry) Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwABHxWeAACL/jYAAB3KYQ Message-ID: References: <548832E2D1D1486EBAC82789E800224A@DGBP7M81><1d5f01ca04a2$c495dfd0$0c00a8c0@CPQ86763045110><036201ca04a9$c6500ec0$6801a8c0@oemcomputer> <1dcc01ca0519$f2bbb6b0$0c00a8c0@CPQ86763045110> <1ffd01ca0586$c4de9b00$0c00a8c0@CPQ86763045110> In-Reply-To: <1ffd01ca0586$c4de9b00$0c00a8c0@CPQ86763045110> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ltru] rechartering to handle 639-6 (was FW:Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 20:41:07 -0000 From: Debbie Garside [mailto:debbie@ictmarketing.co.uk]=20 > It is quite possible to design a structure within BCP > 47 for end users to be able to lookup the code within ISO 639-6 and regis= ter > this code within the LSR as a variant of an ISO 639-3/2/1/5 based primary > language subtag. That might not be unreasonable. Of course, we wouldn't need a change in BCP= 47 to effect that; it might be sufficient just to have a working procedure= within ietf-languages that, if a variant registration comes along, then we= always look into the possibility of registering the 639-6 ID, adapted as n= eeded. The most important reason to revise BCP 47 would be to formalize req= uirements on how the ID should be adapted (e.g. requiring "6" + alpha4 -- o= r whatever). > As previously stated, I will come back when ISO 639-6 is published and th= e > data complete and we can decide then whether this WG should be re-charter= ed. Makes sense. Peter From mark.edward.davis@gmail.com Wed Jul 15 14:17:16 2009 Return-Path: X-Original-To: ltru@core3.amsl.com Delivered-To: ltru@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47EDC3A6BBB for ; Wed, 15 Jul 2009 14:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqeYU0fN4XKz for ; Wed, 15 Jul 2009 14:17:13 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id A2F3E3A6B76 for ; Wed, 15 Jul 2009 14:17:12 -0700 (PDT) Received: by yxe34 with SMTP id 34so4698936yxe.29 for ; Wed, 15 Jul 2009 14:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=45KiWwqbuipVdcKqbRTNNZhBf4buO9YrVPPUD26InMM=; b=SIWB/ben44CLVHF6GRqFBOcDUu/elSCkUEFtCNU6qT864EgznR7DHeoJF6YF1NSq6p AS0F6RQkvEdI4yCVKe3AjMccSpopy4UkqY2aINBb8W7PjL6TtClJwDa8VhKFdhWnJLC5 rRWnz4eGwst5QwWic6XbhiUDGBlvIeR0KAxI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jVp/+5YSG68EO/kper/+fz8m6mwDZSK8zY4/jFGA09dU0/pIv+RicM3fr5TJ8CMdL6 coqdUFJs5r629H43XinIvXi0VQnc3qbmnpnMTj9c+gtDXRDlww4bWLZ+/GSPKcbjIRG0 a7vmLjh3X3KJKW3jD3KAq7wm2JjzeK77ThGXI= MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.100.11.4 with SMTP id 4mr10859080ank.84.1247692524933; Wed, 15 Jul 2009 14:15:24 -0700 (PDT) In-Reply-To: <203d01ca058c$7bd8da50$0c00a8c0@CPQ86763045110> References: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> <30b660a20907151031i6e8bbeedyc4d33ffa59cce113@mail.gmail.com> <203d01ca058c$7bd8da50$0c00a8c0@CPQ86763045110> Date: Wed, 15 Jul 2009 14:15:24 -0700 X-Google-Sender-Auth: 9f7cfa918f05347c Message-ID: <30b660a20907151415o36cdaf8br5d5ec951688ebdac@mail.gmail.com> From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= To: debbie@ictmarketing.co.uk Content-Type: multipart/alternative; boundary=0016e640c91ebce2f2046ec50dd4 Cc: LTRU Working Group , "Broome, Karen" Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 21:17:16 -0000 --0016e640c91ebce2f2046ec50dd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A good example. Here's what I suggest you do: The following are all expressible in BCP47, and need to be tossed out: 1. All those already with language codes (ang, enm). 2. All of the written vs non-written differences 3. All "written in