From ltru-bounces@ietf.org Sun Oct 01 05:55:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTy2I-0003Px-Q2; Sun, 01 Oct 2006 05:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTy2H-0003Oa-Pg for ltru@ietf.org; Sun, 01 Oct 2006 05:55:01 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTy2E-0006F2-Vc for ltru@ietf.org; Sun, 01 Oct 2006 05:55:01 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k919sraq017792 for ; Sun, 1 Oct 2006 18:54:53 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 04bd_e2ea5360_5132_11db_8b8c_0014221fa3c9; Sun, 01 Oct 2006 18:54:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:48208) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 1 Oct 2006 18:54:47 +0900 Message-Id: <6.0.0.20.2.20061001103658.0a64d9b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 01 Oct 2006 10:45:06 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] Suppress-Script: fix registration description X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org When preparing the proposal to add a Suppress-Script to Japanese, I discovered the following contradiction in RFC 4646: In 3.4., Stability of IANA Registry Entries: 8. The field 'Suppress-Script' MAY be added or removed via the registration process. In 3.5., Registration Procedure for Subtags: Only subtags of type 'language' and 'variant' will be considered for independent registration of new subtags. Handling of subtags needed for stability and subtags necessary to keep the registry synchronized with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits defined by this document are described in Section 3.3. Stability provisions are described in Section 3.4. This procedure MAY also be used to register or alter the information for the 'Description', 'Comments', 'Deprecated', or 'Prefix' fields in a subtag's record as described in Section 3.4. Changes to all other fields in the IANA registry are NOT permitted. This means that 3.4 says that Suppress-Script can be added or removed, but 3.5 doesn't allow any changes to Suppress-Script. My assumption as a technical contributor is that 3.4 is what we wanted, and the fact that Suppress-Script is missing in 3.5 is an oversight. As a co-chair, I think that we have to eliminate this contradiction, both in RFC 4646bis, and preferably also via an erratum for RFC 4646. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 07:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTz3s-0002hL-64; Sun, 01 Oct 2006 07:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTz3p-0002hB-9i for ltru@lists.ietf.org; Sun, 01 Oct 2006 07:00:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTz3l-00085O-Tg for ltru@lists.ietf.org; Sun, 01 Oct 2006 07:00:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GTz3U-0001El-MA for ltru@lists.ietf.org; Sun, 01 Oct 2006 13:00:20 +0200 Received: from pd9fbad96.dip0.t-ipconnect.de ([217.251.173.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 13:00:20 +0200 Received: from nobody by pd9fbad96.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 13:00:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 01 Oct 2006 12:59:18 +0200 Organization: Lines: 13 Message-ID: <451F9F86.3218@xyzzy.claranet.de> References: <6.0.0.20.2.20061001103658.0a64d9b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad96.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] Re: Suppress-Script: fix registration description X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > 3.4 is what we wanted, and the fact that Suppress-Script is > missing in 3.5 is an oversight. [...] > I think that we have to eliminate this contradiction, both in > RFC 4646bis, and preferably also via an erratum for RFC 4646. Yes. I really don't understand why some prefer a one-step or two-step standards process. Three-step is a sound minimum. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 12:32:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU4Ex-0001kp-1X; Sun, 01 Oct 2006 12:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU4Ew-0001kj-Kp for ltru@ietf.org; Sun, 01 Oct 2006 12:32:30 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU4Eu-0003I4-Bp for ltru@ietf.org; Sun, 01 Oct 2006 12:32:30 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061001163228.DZRK28964.mta10.adelphia.net@DGBP7M81> for ; Sun, 1 Oct 2006 12:32:28 -0400 Message-ID: <00bb01c6e577$2ed30c90$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 1 Oct 2006 09:32:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: RFC 4690 on Review and Recommendations for Internationalized Domain Names (IDNs) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> RFC 4690 > >> URL: http://www.rfc-editor.org/rfc/rfc4690.txt > > Pointer for info, it has references to RFCs 4645 and 4646. I wonder why they chose RFC 4645 as an example of "the most recent IETF work in this area" instead of 4647. We should be relieved that the initial LSR contents were removed from 4645. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 14:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU60p-0002cF-M9; Sun, 01 Oct 2006 14:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU60o-0002cA-Mh for ltru@ietf.org; Sun, 01 Oct 2006 14:26:02 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU60n-00089O-7G for ltru@ietf.org; Sun, 01 Oct 2006 14:26:02 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1446414nfc for ; Sun, 01 Oct 2006 11:26:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=I7vxs25IfFZcah0HB9lQuLXTU8przZ4UJIC4Z2jECxARPVNmqO8xQVAVM7UJZbsgKkEnc8+gFvUBLWUzaLYycxUBgMIfcfysCNPyVqcFSOsORq6uAMDg5s3Wfas92KV8bA/iAqqXOIrBxWWywsgkz4AC9vgh2my2BgJDN5Kg3TE= Received: by 10.49.19.18 with SMTP id w18mr8338495nfi; Sun, 01 Oct 2006 11:26:00 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 1 Oct 2006 11:25:59 -0700 (PDT) Message-ID: <30b660a20610011125x7c3c13d4reec3d5e6051f7dae@mail.gmail.com> Date: Sun, 1 Oct 2006 11:25:59 -0700 From: "Mark Davis" To: "Karen_Broome@spe.sony.com" Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: MIME-Version: 1.0 References: <30b660a20609301249s39fbed9ew9e3454310f3c7d46@mail.gmail.com> X-Google-Sender-Auth: 7aea390518830969 X-Spam-Score: 0.6 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0526769808==" Errors-To: ltru-bounces@ietf.org --===============0526769808== Content-Type: multipart/alternative; boundary="----=_Part_8928_9262020.1159727159620" ------=_Part_8928_9262020.1159727159620 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm all for expanding the guidance to avoid using inappropriate script (or region, for that matter). I was never against addng more information about the issue; just against making it a MUST (for the reasons I outlined earlier). Mark On 9/30/06, Karen_Broome@spe.sony.com wrote: > > > "Mark Davis" wrote on 09/30/2006 12:49:55 PM: > > > > > Let's not make up problems where they don't exist. I see no > > groundswell, nor any realistic prospect of a groundswell, of people > > tagging languages with unnecessary scripts. > > However, when it comes to tagging audiovisual content, I do see this quite > frequently -- at least with Chinese language classification. (And I've > analyzed audiovisual language data from many sources and studios.) The fault > is not always an ill-informed classifier. Developers often advise against > having separate or filtered language lists for spoken and written languages > as they want to be able to do a basic query for all content in Mandarin or > "Chinese" and don't quite understand the issue. "ISO doesn't make this > distinction, why should we?" > > Or classifiers are stuck with a shrink-wrapped system architecture that > assumes written content and a single language list. So when a classifier is > faced with inappropriate choices for a dubbed or spoken work, they often > choose a "scripted" form of Mandarin over suggesting a system redesign. It's > not the role of the working group to design systems, but maybe giving this > issue some attention might help developers who implement RFC 4646bis in > systems that deal with both spoken and written language. > > Regards, > > Karen Broome > Sony Pictures Entertainment > > ------=_Part_8928_9262020.1159727159620 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm all for expanding the guidance to avoid using inappropriate script (or region, for that matter). I was never against addng more information about the issue; just against making it a MUST (for the reasons I outlined earlier).

Mark

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

"Mark Davis" <mark.davis@icu-project.org> wrote on 09/30/2006 12:49:55 PM:

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

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

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

Regards,

Karen Broome
Sony Pictures Entertainment


------=_Part_8928_9262020.1159727159620-- --===============0526769808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0526769808==-- From ltru-bounces@ietf.org Sun Oct 01 14:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU65J-00074k-2B; Sun, 01 Oct 2006 14:30:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU65I-00073y-JO for ltru@ietf.org; Sun, 01 Oct 2006 14:30:40 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU65H-0000Qt-1l for ltru@ietf.org; Sun, 01 Oct 2006 14:30:40 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1447183nfc for ; Sun, 01 Oct 2006 11:30:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jEFHqAdcFGIfxKKy551jICe0threcHD1xuYcv1fGk8nZZ1Okq6CDFBrjyN5fdiNmjEzeTXvWQ9YahBsgFTlxUhOG1lzni2laAFnklpTBctS6TwA7btAa0cCPOaRLajzA4KuEt+/gCqRiblJST80jMxgLC4yB+rXs4ZY/iImb8b0= Received: by 10.49.8.4 with SMTP id l4mr4744752nfi; Sun, 01 Oct 2006 11:30:37 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 1 Oct 2006 11:30:37 -0700 (PDT) Message-ID: <30b660a20610011130r65be18c8oe21079ee3c6957ac@mail.gmail.com> Date: Sun, 1 Oct 2006 11:30:37 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Ltru Digest, Vol 19, Issue 88 In-Reply-To: <00ab01c6e4fd$16bc3610$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <00ab01c6e4fd$16bc3610$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 74e7b5c3724bc532 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1416900962==" Errors-To: ltru-bounces@ietf.org --===============1416900962== Content-Type: multipart/alternative; boundary="----=_Part_9020_7348235.1159727437037" ------=_Part_9020_7348235.1159727437037 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Script tags are applicable to instances of languages. A particular instance (document, record, span) may be Latn or Latf, for example. Our interpretation of Zxxx is the same: marking an instance as being unwritten. The other interpretation wouldn't be particularly useful. Mark On 9/30/06, Doug Ewell wrote: > > Mark Davis wrote: > > > Let's not make up problems where they don't exist. I see no > > groundswell, nor any realistic prospect of a groundswell, of people > > tagging languages with unnecessary scripts. > > +1 to that. > > > Now, this is all getting away from Karen's quite reasonable desire to > > provide people more clarity on the fact that for material that is only > > non-written it isn't a good idea to include a script subtag. I could > > even see, in some applications, tagging records with, for example, > > zh-Zxxx, meaning unwritten Chinese. Then I could search records for zh > > (meaning any zh, no matter whether spoken, or written in traditional, > > or written in simplified, or written in pinyin), or filter that to > > only non-written, or only simplified, or only romanized. > > Hold on, Zxxx is defined as "Code for unwritten languages." I don't see > that as meaning the same as "linguistic content that is not written." > Then again, I'm the literalist who argued for years that "sign language > as used in the United States" wasn't the same as "American Sign > Language." > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_9020_7348235.1159727437037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Script tags are applicable to instances of languages. A particular instance (document, record, span) may be Latn or Latf, for example. Our interpretation of Zxxx is the same: marking an instance as being unwritten. The other interpretation wouldn't be particularly useful.

Mark

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

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

+1 to that.

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

Hold on, Zxxx is defined as "Code for unwritten languages."  I don't see
that as meaning the same as "linguistic content that is not written."
Then again, I'm the literalist who argued for years that "sign language
as used in the United States" wasn't the same as "American Sign
Language."

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


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

------=_Part_9020_7348235.1159727437037-- --===============1416900962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1416900962==-- From ltru-bounces@ietf.org Sun Oct 01 14:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU66x-0008JA-Hs; Sun, 01 Oct 2006 14:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU66w-0008J5-71 for ltru@ietf.org; Sun, 01 Oct 2006 14:32:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU66s-0000h2-KL for ltru@ietf.org; Sun, 01 Oct 2006 14:32:22 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1447562nfc for ; Sun, 01 Oct 2006 11:32:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=uMQDf0E3Dipq0/rOaHbee0kXlwPpw2KTzWXKBWY6JvMa2fUlDm/ekQJotydoZc4e+3rqiK21f+Nz3aPjccEk834E35da9AdWxurL14TvV6syTKD8HPc3Y12rX5dw2gRliGu6NmUm3YHcPJ9ch0nO5iyRcA2QynTN7EgvQTNbDEI= Received: by 10.48.48.15 with SMTP id v15mr8348851nfv; Sun, 01 Oct 2006 11:32:17 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 1 Oct 2006 11:32:17 -0700 (PDT) Message-ID: <30b660a20610011132i64a0ed2ay15bba6623a0c793a@mail.gmail.com> Date: Sun, 1 Oct 2006 11:32:17 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Suppress-Script: fix registration description In-Reply-To: <6.0.0.20.2.20061001103658.0a64d9b0@localhost> MIME-Version: 1.0 References: <6.0.0.20.2.20061001103658.0a64d9b0@localhost> X-Google-Sender-Auth: 597edbaa52a63cdc X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0797848636==" Errors-To: ltru-bounces@ietf.org --===============0797848636== Content-Type: multipart/alternative; boundary="----=_Part_9052_17646616.1159727537419" ------=_Part_9052_17646616.1159727537419 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree about the contradiction, but disagree about the resolution. We need to reserve the right to fix Suppress-Script when it is in error: a) it is often very hard to find out reliable information about particular languages. b) such information can be wrong the first time, and may require fixing c) languages change over time; we've seen within our lifetimes languages be written entirely in a script, and change to allowing another script. There is no need to lock this down for all time -- such a step should only be taken when stability is an absolute requirement, and nobody has shown compelling need for that. Mark On 9/30/06, Martin Duerst wrote: > > When preparing the proposal to add a Suppress-Script to Japanese, > I discovered the following contradiction in RFC 4646: > > In 3.4., Stability of IANA Registry Entries: > > 8. The field 'Suppress-Script' MAY be added or removed via the > registration process. > > In 3.5., Registration Procedure for Subtags: > > Only subtags of type 'language' and 'variant' will be considered for > independent registration of new subtags. Handling of subtags needed > for stability and subtags necessary to keep the registry synchronized > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits > defined by this document are described in Section 3.3. Stability > provisions are described in Section 3.4. > > This procedure MAY also be used to register or alter the information > for the 'Description', 'Comments', 'Deprecated', or 'Prefix' fields > in a subtag's record as described in Section 3.4. Changes to all > other fields in the IANA registry are NOT permitted. > > This means that 3.4 says that Suppress-Script can be added or removed, > but 3.5 doesn't allow any changes to Suppress-Script. > > My assumption as a technical contributor is that 3.4 is what we wanted, > and the fact that Suppress-Script is missing in 3.5 is an oversight. > > As a co-chair, I think that we have to eliminate this contradiction, > both in RFC 4646bis, and preferably also via an erratum for RFC 4646. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_9052_17646616.1159727537419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree about the contradiction, but disagree about the resolution. We need to reserve the right to fix Suppress-Script when it is in error:
a) it is often very hard to find out reliable information about particular languages.
b) such information can be wrong the first time, and may require fixing
c) languages change over time; we've seen within our lifetimes languages be written entirely in a script, and change to allowing another script.

There is no need to lock this down for all time -- such a step should only be taken when stability is an absolute requirement, and nobody has shown compelling need for that.

Mark

On 9/30/06, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
When preparing the proposal to add a Suppress-Script to Japanese,
I discovered the following contradiction in RFC 4646:

In 3.4., Stability of IANA Registry Entries:

   8.   The field 'Suppress-Script' MAY be added or removed via the
        registration process.

In 3.5., Registration Procedure for Subtags:

   Only subtags of type 'language' and 'variant' will be considered for
   independent registration of new subtags.  Handling of subtags needed
   for stability and subtags necessary to keep the registry synchronized
   with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits
   defined by this document are described in Section 3.3.  Stability
   provisions are described in Section 3.4.

   This procedure MAY also be used to register or alter the information
   for the 'Description', 'Comments', 'Deprecated', or 'Prefix' fields
   in a subtag's record as described in Section 3.4.  Changes to all
   other fields in the IANA registry are NOT permitted.

This means that 3.4 says that Suppress-Script can be added or removed,
but 3.5 doesn't allow any changes to Suppress-Script.

My assumption as a technical contributor is that 3.4 is what we wanted,
and the fact that Suppress-Script is missing in 3.5 is an oversight.

As a co-chair, I think that we have to eliminate this contradiction,
both in RFC 4646bis, and preferably also via an erratum for RFC 4646.

Regards,     Martin.



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


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

------=_Part_9052_17646616.1159727537419-- --===============0797848636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0797848636==-- From ltru-bounces@ietf.org Sun Oct 01 14:33:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU67Y-0000A3-OX; Sun, 01 Oct 2006 14:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU67X-00009B-MC for ltru@ietf.org; Sun, 01 Oct 2006 14:32:59 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU67V-0000mm-99 for ltru@ietf.org; Sun, 01 Oct 2006 14:32:59 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1447652nfc for ; Sun, 01 Oct 2006 11:32:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QM0K98fLdhIPLcZm/HtpSrh57FNuZGZ4xWZTzjOJ+hxiO/dtD4KXllcMpNNOvAQMXpZz3ycTBQHuThWE8NHkaf8ba95ejBxfHTAcyT7WTOobeG+W3+aeIw+u9VZIMO12/6pkVU92NZ/7w3PSQMAgc5t9IZI5riAx/oplCGtelKg= Received: by 10.49.41.12 with SMTP id t12mr3892954nfj; Sun, 01 Oct 2006 11:32:56 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 1 Oct 2006 11:32:55 -0700 (PDT) Message-ID: <30b660a20610011132x54f30b8fh640d37450762443c@mail.gmail.com> Date: Sun, 1 Oct 2006 11:32:56 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <6.0.0.20.2.20060930180719.07033ec0@localhost> MIME-Version: 1.0 References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> X-Google-Sender-Auth: b125ae9b9f2227ce X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087995448==" Errors-To: ltru-bounces@ietf.org --===============2087995448== Content-Type: multipart/alternative; boundary="----=_Part_9064_21303360.1159727576017" ------=_Part_9064_21303360.1159727576017 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Martin, I don't think there is any question that everyone agrees with the goal of what you said. But a) *nothing* in 4646 "force[s] people to be unnecessarily detailled when tagging". b) And wouldn't, even if Suppress-Script didn't exist -- here is plenty of text saying the opposite. c) Do we have to add Suppress-Scripts to 7000 entries to achieve the goal? I think not. Mark On 9/30/06, Martin Duerst < duerst@it.aoyama.ac.jp> wrote: > > At 06:39 06/09/30, John Cowan wrote: > > >I'm happy to keep Suppress-Script confined (as a matter of administrative > > >policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. > > As a technical contributor, I'd tend to disagree. There is no need > to force people to be unnecessarily detailled when tagging. If it's > widely accepted general practice that a language is written in a single > script only, then just the language tag should do the job. Scripts, > like regions, should only be added when they are really necessary. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto: duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_9064_21303360.1159727576017 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Martin, I don't think there is any question that everyone agrees with the goal of what you said.
But
a) *nothing* in 4646 "force[s] people to be unnecessarily detailled when tagging".
b) And wouldn't, even if Suppress-Script didn't exist -- here is plenty of text saying the opposite.
c) Do we have to add Suppress-Scripts to 7000 entries to achieve the goal? I think not.

Mark

On 9/30/06, Martin Duerst < duerst@it.aoyama.ac.jp> wrote:
At 06:39 06/09/30, John Cowan wrote:

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

As a technical contributor, I'd tend to disagree. There is no need
to force people to be unnecessarily detailled when tagging. If it's
widely accepted general practice that a language is written in a single
script only, then just the language tag should do the job. Scripts,
like regions, should only be added when they are really necessary.

Regards,    Martin.



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


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

------=_Part_9064_21303360.1159727576017-- --===============2087995448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2087995448==-- From ltru-bounces@ietf.org Sun Oct 01 16:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU7c9-0007Nx-G5; Sun, 01 Oct 2006 16:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU7c8-0007Ns-GJ for ltru@lists.ietf.org; Sun, 01 Oct 2006 16:08:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU7c1-0006bj-6d for ltru@lists.ietf.org; Sun, 01 Oct 2006 16:08:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GU7bZ-0000X7-Qa for ltru@lists.ietf.org; Sun, 01 Oct 2006 22:08:06 +0200 Received: from du-017-171.access.de.clara.net ([212.82.246.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 22:08:05 +0200 Received: from nobody by du-017-171.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 22:08:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 01 Oct 2006 22:07:10 +0200 Organization: Lines: 15 Message-ID: <45201FEE.67A8@xyzzy.claranet.de> References: <00bb01c6e577$2ed30c90$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-171.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: RFC 4690 on Review and Recommendations for Internationalized Domain Names (IDNs) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I wonder why they chose RFC 4645 as an example of "the most > recent IETF work in this area" instead of 4647. 4647 doesn't help with IDN, 4645 is the implementation of 4646. John reviewed 4645, he knows what's what, and Mark apparently also contributed to 4690 (maybe Mark doesn't like it, abusing my crystal ball). Frank -- Honk for 4234 to STD _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 17:09:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU8Z4-0005ZR-JW; Sun, 01 Oct 2006 17:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU8Z3-0005ZA-0f for ltru@lists.ietf.org; Sun, 01 Oct 2006 17:09:33 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU8Z0-00048t-Eq for ltru@lists.ietf.org; Sun, 01 Oct 2006 17:09:32 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1467674nfc for ; Sun, 01 Oct 2006 14:09:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Zkk37slserlDAPgtx0EWDZvyJadQEc+SmCE17XYGob6FKs8wyKedSasDEXIB2B9cixrANB0ReI993g+qVFZjHdyJF9p2OGG+l7f0/VirOC72Cfx35VLATXCfhouxYUWBu4HaPbxJp0MAvoj0NEVKo7VyIyBGcNiX/se0SqVS2YQ= Received: by 10.48.254.10 with SMTP id b10mr4899107nfi; Sun, 01 Oct 2006 14:09:29 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 1 Oct 2006 14:09:29 -0700 (PDT) Message-ID: <30b660a20610011409y21288f03yca4d466e12c121f7@mail.gmail.com> Date: Sun, 1 Oct 2006 14:09:29 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: RFC 4690 on Review and Recommendations for Internationalized Domain Names (IDNs) In-Reply-To: <45201FEE.67A8@xyzzy.claranet.de> MIME-Version: 1.0 References: <00bb01c6e577$2ed30c90$6401a8c0@DGBP7M81> <45201FEE.67A8@xyzzy.claranet.de> X-Google-Sender-Auth: 085c7f44d8b726b6 X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0497704761==" Errors-To: ltru-bounces@ietf.org --===============0497704761== Content-Type: multipart/alternative; boundary="----=_Part_10952_30972953.1159736969334" ------=_Part_10952_30972953.1159736969334 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline While very much in favor of the goals of http://www.rfc-editor.org/rfc/rfc4690.txt, the document itself is flawed. Some of the concerns are were voiced in https://datatracker.ietf.org/documents/LIAISON/file304.pdf. There were some changes in the published version, but unfortunately many new problems were introduced at the same time. Most unsettling in my view is that there was no process of engagement -- none of the kind of dialog such as what we have seen in LTRU -- to get the proponents of particular positions to to present evidence for positions and correct or refine those positions based on open discussion of the issues. Of course, the Unicode Standard is hardly perfect; for such are large, complex standard, with so many issues of compatibility with previously existing systems, that would hardly be possible. Those of us who have worked on it and with it for so many years are well aware of that -- but also aware of the techniques used to work around problems. But the style of the document is not helpful, such as innuendo that certain Unicode formats or features are not well-defined, like "...NFKC does not appear to tell us, nor does the definition of U+0307 appear to tell us what happens when it is combined...". Such statements present a misleading picture to those unfamiliar with the details of the Unicode Standard, when the standard is very explicit about the definition and result of NFKC, and the use of unusual characters like U+0307. Most worrisome is that the overall conclusion seems to be providing an excuse for IDN to stay at Unicode 3.2 ("may leave us "stuck" at Unicode 3.2"), when the arguments for that position are based on a house of cards. (These are my own opinions - the UTC has yet to take a position on the document, not having met since the document was issued.) Mark On 10/1/06, Frank Ellermann wrote: > > Doug Ewell wrote: > > > I wonder why they chose RFC 4645 as an example of "the most > > recent IETF work in this area" instead of 4647. > > 4647 doesn't help with IDN, 4645 is the implementation of 4646. > > John reviewed 4645, he knows what's what, and Mark apparently > also contributed to 4690 (maybe Mark doesn't like it, abusing > my crystal ball). > > Frank > -- > Honk for 4234 to STD > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_10952_30972953.1159736969334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline While very much in favor of the goals of http://www.rfc-editor.org/rfc/rfc4690.txt, the document itself is flawed.

Some of the concerns are were voiced in https://datatracker.ietf.org/documents/LIAISON/file304.pdf. There were some changes in the published version, but unfortunately many new problems were introduced at the same time. Most unsettling in my view is that there was no process of engagement -- none of the kind of dialog such as what we have seen in LTRU -- to get the proponents of particular positions to to present evidence for positions and correct or refine those positions based on open discussion of the issues.

Of course, the Unicode Standard is hardly perfect; for such are large, complex standard, with so many issues of compatibility with previously existing systems, that would hardly be possible. Those of us who have worked on it and with it for so many years are well aware of that -- but also aware of the techniques used to work around problems. But the style of the document is not helpful, such as innuendo that certain Unicode formats or features are not well-defined, like "...NFKC does not appear to tell us, nor does the definition of U+0307 appear to tell us what happens when it is combined...". Such statements present a misleading picture to those unfamiliar with the details of the Unicode Standard, when the standard is very explicit about the definition and result of NFKC, and the use of unusual characters like U+0307.

Most worrisome is that the overall conclusion seems to be providing an excuse for IDN to stay at Unicode 3.2 ("may leave us "stuck" at Unicode 3.2"), when the arguments for that position are based on a house of cards.

(These are my own opinions - the UTC has yet to take a position on the document, not having met since the document was issued.)

Mark

On 10/1/06, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Doug Ewell wrote:

> I wonder why they chose RFC 4645 as an example of "the most
> recent IETF work in this area" instead of 4647.

4647 doesn't help with IDN, 4645 is the implementation of 4646.

John reviewed 4645, he knows what's what, and Mark apparently
also contributed to 4690 (maybe Mark doesn't like it, abusing
my crystal ball).

Frank
--
Honk for 4234 to STD



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

------=_Part_10952_30972953.1159736969334-- --===============0497704761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0497704761==-- From ltru-bounces@ietf.org Sun Oct 01 20:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUBIp-0002xk-Jt; Sun, 01 Oct 2006 20:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUBIo-0002xe-2f for ltru@lists.ietf.org; Sun, 01 Oct 2006 20:04:58 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUBIm-0007RI-IK for ltru@lists.ietf.org; Sun, 01 Oct 2006 20:04:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GUBIa-0005oV-2q for ltru@lists.ietf.org; Mon, 02 Oct 2006 02:04:44 +0200 Received: from du-017-171.access.de.clara.net ([212.82.246.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 02:04:44 +0200 Received: from nobody by du-017-171.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 02:04:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 02 Oct 2006 01:59:45 +0200 Organization: Lines: 95 Message-ID: <45205671.259B@xyzzy.claranet.de> References: <00bb01c6e577$2ed30c90$6401a8c0@DGBP7M81> <45201FEE.67A8@xyzzy.claranet.de> <30b660a20610011409y21288f03yca4d466e12c121f7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-171.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Ltru] Re: RFC 4690 on Review and Recommendations for Internationalized Domain Names (IDNs) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > https://datatracker.ietf.org/documents/LIAISON/file304.pdf. Yes, I read this some weeks ago when I learned that there is now an Unicode liaison statement. "Let's get rid of combining characters in DNS labels" is an attractive idea, but doesn't solve the problem of applications knowing Unicode version X confronted with code points assigned in version Y > X. With nameprep they also need to know more than the combining class. Reserving a plane for 256 future combining characters in 255 classes was my first idea, but unfortunately it doesn't help. An algorithm to predict the relevant properties of unknown code-points without tables would be nice (assuming they are assigned in a later version), but probably somebody tried it already and run out of available bits: 1: a bit for "is mixed case" 2: a bit for "is upper case" (toggles case if bit 1 is ON) 3: a bit for "is letter or digit" (no additional hyphen) 4: a bit for "never changes under NFC after version X" So far it could work, but adding 8 bits for combining classes kills it. Maybe you could limit it to say at most 16 future combining characters per class, 16*255 starting at u+E0200 or similar. Dividing the other unassigned points into 16 equal pieces is probably also no option. That could be reduced - bit 3 OFF or bit 4 OFF are both bad for applications trying to predict what a future version does, With that I'd arrive at four sets: a: stable lower case b: stable upper case (same size as "a") c: digit or stable caseless letter d: forbidden in domain labels forever > Most unsettling in my view is that there was no process of > engagement -- none of the kind of dialog such as what we > have seen in LTRU -- to get the proponents of particular > positions to to present evidence for positions and correct > or refine those positions based on open discussion of the > issues. For that you'd need a WG or another open mailing list. It's only an informational RFC, and the IAB can post their view as informational RFC. In that case the RFC apparently asks the IETF to do what you want. Which won't help. Unless Unicode and ICANN are willing to play along the only possible outcome are a 3454bis, 3490bis (etc.) using the most recent Unicode version, freezing it again. And with objections / appeals by disgruntled RFC 3454 implementors I fear that we're not more talking about this decade. Another frozen version is arguably pointless. > "...NFKC does not appear to tell us, nor does the definition > of U+0307 appear to tell us what happens when it is > combined...". Such statements present a misleading picture to > those unfamiliar with the details of the Unicode Standard, Well, I certainly don't know how the details of combining a dotless i differ from combining a normal i with something else. Apparently dotless i + diaeresis survives under NFKC (?), and that would be not good for IDNA or SASLPREP or similar cases. > the standard is very explicit about the definition and result > of NFKC, and the use of unusual characters like U+0307. In a (mostly futile) attempt to identify "irrelevant" combining characters (= never doing anything under normalization) I got apparently 47 cases where u+0307 does "something". Some weeks ago, I'm not exactly sure what I counted. > the overall conclusion seems to be providing an excuse for > IDN to stay at Unicode 3.2 ("may leave us "stuck" at Unicode > 3.2"), when the arguments for that position are based on a > house of cards. Breaking backwards compatibility for something as important as nameprep / salsprep needs a compelling reason, like a guarantee that it will be never again necessary (fixing minor errors not withstanding). If that's impossible keeping Unicode 3.2 as is makes sense. There should be a better solution, if Unicode can't provide the required predictable sets, then maybe IDNA could roll its own and define mappings. Limited to relevant scripts, not stuff like Shavian / Fraktur / etc, nobody needs that in passwords or DNS labels in the foreseeable future. Frank -- Honk for 4234 to STD _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 22:40:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDix-0004mK-T6; Sun, 01 Oct 2006 22:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDiw-0004mF-TK for ltru@ietf.org; Sun, 01 Oct 2006 22:40:06 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUDis-000067-MV for ltru@ietf.org; Sun, 01 Oct 2006 22:40:06 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUDio-00068z-6p; Sun, 01 Oct 2006 22:39:58 -0400 Date: Sun, 1 Oct 2006 22:39:58 -0400 To: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful Message-ID: <20061002023958.GB22365@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060930180719.07033ec0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > At 06:39 06/09/30, John Cowan wrote: > > >I'm happy to keep Suppress-Script confined (as a matter of administrative > >policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. > > As a technical contributor, I'd tend to disagree. There is no need > to force people to be unnecessarily detailled when tagging. If it's > widely accepted general practice that a language is written in a single > script only, then just the language tag should do the job. Scripts, > like regions, should only be added when they are really necessary. I agree with every word of this, but I don't see how it's relevant to what I said. I am merely saying that we have no need to do the necessary investigations to create Suppress-Script: entries for the thousands of 639-3 entries, none of which will be usable until RFC 4646bis gets an RFC number anyhow. Suppress-Script: is a backward compatibility facility, and people who use script information for the "new" languages inconsistently, IMHO, deserve what they get. -- Work hard, John Cowan play hard, cowan@ccil.org die young, http://www.ccil.org/~cowan rot quickly. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 22:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDn6-000760-NE; Sun, 01 Oct 2006 22:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDn5-00075u-GJ for ltru@ietf.org; Sun, 01 Oct 2006 22:44:23 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUDn4-0001Hw-6t for ltru@ietf.org; Sun, 01 Oct 2006 22:44:23 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061002024421.DAUL28964.mta10.adelphia.net@DGBP7M81>; Sun, 1 Oct 2006 22:44:21 -0400 Message-ID: <00f601c6e5cc$a9b10e80$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00ab01c6e4fd$16bc3610$6401a8c0@DGBP7M81> <30b660a20610011130r65be18c8oe21079ee3c6957ac@mail.gmail.com> Date: Sun, 1 Oct 2006 19:44:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] Re: Suppress-Script batch 1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org (Sorry for munging the Subject line earlier.) Mark Davis wrote: >> Hold on, Zxxx is defined as "Code for unwritten languages." I don't >> see that as meaning the same as "linguistic content that is not >> written." > > Script tags are applicable to instances of languages. A particular > instance (document, record, span) may be Latn or Latf, for example. > Our interpretation of Zxxx is the same: marking an instance as being > unwritten. The other interpretation wouldn't be particularly useful. It might be; someone more familiar than I with Ethnologue might be able to find a language that has no written form. Keeping Karen's examples in mind, there might possibly be a need to tag some spoken content with a specific indication that this language is unwritten -- maybe similar content for other langauges has a text subtitle or whatever. I'm not really sure language tagging can be expected to indicate the spoken vs. written mode of a piece of content, which is the impression I got from what Mark wrote. I suppose I wouldn't argue strongly if we attempted to adopt this rather loose interpretation of "unwritten language," but after the sign-languages experience I'm wary about loose interpretations. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 22:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDpc-0001FS-Dq; Sun, 01 Oct 2006 22:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDpb-0001FM-JB for ltru@ietf.org; Sun, 01 Oct 2006 22:46:59 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUDpa-0001kh-80 for ltru@ietf.org; Sun, 01 Oct 2006 22:46:59 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061002024657.RBOQ437.mta13.adelphia.net@DGBP7M81> for ; Sun, 1 Oct 2006 22:46:57 -0400 Message-ID: <00f801c6e5cd$06a59890$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Suppress-Script: fix registration description Date: Sun, 1 Oct 2006 19:46:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I agree about the contradiction, but disagree about the resolution. We > need to reserve the right to fix Suppress-Script when it is in error > a) it is often very hard to find out reliable information about > particular languages. > b) such information can be wrong the first time, and may require > fixing > c) languages change over time; we've seen within our lifetimes > languages be written entirely in a script, and change to allowing > another script. Then you actually agree about the resolution. Martin had argued that Section 3.4, which allows Suppress-Script to be added or removed via registration, is what we wanted, and Section 3.5, which does not allow this, is not. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 01 23:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUEfn-0004Xt-Si; Sun, 01 Oct 2006 23:40:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUEfm-0004QT-Be for ltru@ietf.org; Sun, 01 Oct 2006 23:40:54 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUEfk-0002zH-Ul for ltru@ietf.org; Sun, 01 Oct 2006 23:40:54 -0400 Received: by nf-out-0910.google.com with SMTP id l23so1477027nfc for ; Sun, 01 Oct 2006 20:40:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=d/+w+ZINQXEpwtO/mBfXLQGRhF3GNhDteVdor4Hn1j1aRewY1brKVI911Xx0l4EItoBEUIqJH/NVoNPaUVf3Q/5QroZ/z10JqCQv3aZUrfQv4UcrdqsOHz6cLyqU9J9Dp24Ww0VVhshMnlCZlhTUWzfdyxy3cKQCPiyXYuF60Ec= Received: by 10.48.210.20 with SMTP id i20mr8789933nfg; Sun, 01 Oct 2006 20:40:51 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Sun, 1 Oct 2006 20:40:51 -0700 (PDT) Message-ID: <30b660a20610012040t44b42057iaa125ee15d8355bd@mail.gmail.com> Date: Sun, 1 Oct 2006 20:40:51 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Suppress-Script: fix registration description In-Reply-To: <00f801c6e5cd$06a59890$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <00f801c6e5cd$06a59890$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 5c1a96e1a7c09574 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1319860282==" Errors-To: ltru-bounces@ietf.org --===============1319860282== Content-Type: multipart/alternative; boundary="----=_Part_15964_23989920.1159760451858" ------=_Part_15964_23989920.1159760451858 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline My mistake, sorry! On 10/1/06, Doug Ewell wrote: > > Mark Davis wrote: > > > I agree about the contradiction, but disagree about the resolution. We > > need to reserve the right to fix Suppress-Script when it is in error > > a) it is often very hard to find out reliable information about > > particular languages. > > b) such information can be wrong the first time, and may require > > fixing > > c) languages change over time; we've seen within our lifetimes > > languages be written entirely in a script, and change to allowing > > another script. > > Then you actually agree about the resolution. Martin had argued that > Section 3.4, which allows Suppress-Script to be added or removed via > registration, is what we wanted, and Section 3.5, which does not allow > this, is not. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_15964_23989920.1159760451858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline My mistake, sorry!

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

> I agree about the contradiction, but disagree about the resolution. We
> need to reserve the right to fix Suppress-Script when it is in error
> a) it is often very hard to find out reliable information about
> particular languages.
> b) such information can be wrong the first time, and may require
> fixing
> c) languages change over time; we've seen within our lifetimes
> languages be written entirely in a script, and change to allowing
> another script.

Then you actually agree about the resolution.  Martin had argued that
Section 3.4, which allows Suppress-Script to be added or removed via
registration, is what we wanted, and Section 3.5, which does not allow
this, is not.

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


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

------=_Part_15964_23989920.1159760451858-- --===============1319860282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1319860282==-- From ltru-bounces@ietf.org Mon Oct 02 01:25:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUGJH-00013M-93; Mon, 02 Oct 2006 01:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUGJG-00013G-0o for ltru@ietf.org; Mon, 02 Oct 2006 01:25:46 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUGJE-0003Mk-IQ for ltru@ietf.org; Mon, 02 Oct 2006 01:25:45 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061002052534.CVPI7818.mta10.adelphia.net@DGBP7M81> for ; Mon, 2 Oct 2006 01:25:34 -0400 Message-ID: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 1 Oct 2006 22:25:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Subject: [Ltru] Re: Registry deltas X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Here's a list of the changes to get from the current (2006-09-29) Registry to the one presented in draft-4645bis-00. This list explicitly excludes the 7,200 new primary and extended language subtags, and includes only changes to existing subtags. This is displayed as a list, rather than a true diff file, because I didn't think it would be very kind to insert a reference to "Line 3459" and expect that to make sense to anyone. Please review this, or at least try to stay awake through it, and let the group and me know what you think of the scope of the changes. I'm particularly wondering about the addition of "inverted" language names from ISO 639-3. These were taken to be The Official Name on the basis of being listed in [iso-dis-639-3_20060421], but apparently both the inverted and non-inverted forms are part of the standard. So it may not be necessary to add "Newari, Classical" where we already have "Classical Newari", simply to reflect the official ISO 639-3 name. This would be an easy rule to add: don't add "B, A" if a Description field of the form "A B" already exists. -----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<----- Language subtag cu Add: Description: Slavic, Church Language subtag frr Add: Description: Frisian, Northern Language subtag fy Add: Description: Frisian, Western Language subtag gd Add: Description: Gaelic (Scots) Language subtag ii Add: Description: Yi, Sichuan Language subtag mh Add: Description: Marshall Language subtag ms Add: Description: Malay (macrolanguage) Language subtag sw Add: Description: Swahili (macrolanguage) Language subtag ain Add: Description: Ainu (Japan) Language subatg alt Add: Description: Altai, Southern Language subtag bas Add: Description: Basa (Cameroon) Language subtag bem Add: Description: Bemba (Zambia) Language subtag chm Add: Description: Mari (Russia) Language subtag doi Add: Description: Dogri (macrolanguage) Language subtag dsb Add: Description: Sorbian, Lower Language subtag fan Add: Description: Fang (Equatorial Guinea) Language subtag frs Add: Description: Frisian, Eastern Language subtag gba Add: â€Description: Gbaya (Central African Republic) Language subtag gsw Add: Description: Schwyzerdütsch Language subtag hsb Add: Description: Sorbian, Upper Language subtag kam Add: Description: Kamba (Kenya) Language subtag kok Add: Description: Konkani (macrolanguage) Language subtag men Add: Description: Mende (Sierra Leone) Language subtag nso Add: Description: Sotho, Northern Language subtag nwc Add: Description: Newari, Classical Language subtag rup Add: Description: Romanian, Macedo Language subtag sam Add: Description: Aramaic, Samaritan Language subtag srn Add: Description: Sranan Language subtag war Add: Description: Waray (Philippines) Region subtag CS Add: Deprecated: 2006-10-01 Region subtag ME Add: Type: region Subtag: ME Description: Montenegro Added: 2006-10-01 Region subtag RS Add: Type: region Subtag: RS Description: Serbia Added: 2006-10-01 Grandfathered tag i-ami Add: Preferred-Value: ami Deprecated: 2007-01-01 Comments: replaced by ISO code ami Grandfathered tag i-bnn Add: Preferred-Value: bnn Deprecated: 2007-01-01 Comments: replaced by ISO code bnn Grandfathered tag i-pwn Add: Preferred-Value: pwn Deprecated: 2007-01-01 Comments: replaced by ISO code pwn Grandfathered tag i-tao Add: Preferred-Value: tao Deprecated: 2007-01-01 Comments: replaced by ISO code tao Grandfathered tag i-tay Add: Preferred-Value: tay Deprecated: 2007-01-01 Comments: replaced by ISO code tay Grandfathered tag i-tsu Add: Preferred-Value: tsu Deprecated: 2007-01-01 Comments: replaced by ISO code tsu Grandfathered tag sgn-CH-de Add: Preferred-Value: sgn-sgg Deprecated: 2007-01-01 Comments: replaced by ISO code sgg Grandfathered tag zh-cmn Reclassify as redundant Grandfathered tag zh-cmn-Hans Reclassify as redundant Grandfathered tag zh-cmn-Hant Reclassify as redundant Grandfathered tag zh-gan Reclassify as redundant Grandfathered tag zh-guoyu Add: Comments: replaced by ISO code cmn Grandfathered tag zh-hakka Add: Preferred-Value: zh-hak Deprecated: 2007-01-01 Comments: replaced by ISO code hak Grandfathered tag zh-min Add: Deprecated: 2007-01-01 Grandfathered tag zh-min-nan Add: Preferred-Value: zh-nan Deprecated: 2007-01-01 Comments: replaced by ISO code nan Grandfathered tag zh-wuu Reclassify as redundant Grandfathered tag zh-xiang Add: Preferred-Value: zh-hsn Deprecated: 2007-01-01 Comments: replaced by ISO code hsn Grandfathered tag zh-yue Reclassify as redundant Redundant tag sgn-BR Add: Preferred-Value: sgn-bzs Deprecated: 2007-01-01 Comments: replaced by ISO code bzs Redundant tag sgn-CO Add: Preferred-Value: sgn-csn Deprecated: 2007-01-01 Comments: replaced by ISO code csn Redundant tag sgn-DE Add: Preferred-Value: sgn-gsg Deprecated: 2007-01-01 Comments: replaced by ISO code gsg Redundant tag sgn-DK Add: Preferred-Value: sgn-dsl Deprecated: 2007-01-01 Comments: replaced by ISO code dsl Redundant tag sgn-ES Add: Preferred-Value: sgn-ssp Deprecated: 2007-01-01 Comments: replaced by ISO code ssp Redundant tag sgn-FR Add: Preferred-Value: sgn-fsl Deprecated: 2007-01-01 Comments: replaced by ISO code fsl Redundant tag sgn-GB Add: Preferred-Value: sgn-bfi Deprecated: 2007-01-01 Comments: replaced by ISO code bfi Redundant tag sgn-GR Add: Preferred-Value: sgn-gss Deprecated: 2007-01-01 Comments: replaced by ISO code gss Redundant tag sgn-IE Add: Preferred-Value: sgn-isg Deprecated: 2007-01-01 Comments: replaced by ISO code isg Redundant tag sgn-IT Add: Preferred-Value: sgn-ise Deprecated: 2007-01-01 Comments: replaced by ISO code ise Redundant tag sgn-JP Add: Preferred-Value: sgn-jsl Deprecated: 2007-01-01 Comments: replaced by ISO code jsl Redundant tag sgn-MX Add: Preferred-Value: sgn-mfs Deprecated: 2007-01-01 Comments: replaced by ISO code mfs Redundant tag sgn-NI Add: Preferred-Value: sgn-ncs Deprecated: 2007-01-01 Comments: replaced by ISO code ncs Redundant tag sgn-NL Add: Preferred-Value: sgn-dse Deprecated: 2007-01-01 Comments: replaced by ISO code dse Redundant tag sgn-NO Add: Preferred-Value: sgn-nsl Deprecated: 2007-01-01 Comments: replaced by ISO code nsl Redundant tag sgn-PT Add: Preferred-Value: sgn-psr Deprecated: 2007-01-01 Comments: replaced by ISO code psr Redundant tag sgn-SE Add: Preferred-Value: sgn-swl Deprecated: 2007-01-01 Comments: replaced by ISO code swl Redundant tag sgn-US Add: Preferred-Value: sgn-ase Deprecated: 2007-01-01 Comments: replaced by ISO code ase Redundant tag sgn-ZA Add: Preferred-Value: sgn-sfs Deprecated: 2007-01-01 Comments: replaced by ISO code sfs Redundant tag yi-latn Change to: Tag: yi-Latn -----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<----- -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnH-00067p-5v; Mon, 02 Oct 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-3L for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgi-00041F-By for ltru@ietf.org; Mon, 02 Oct 2006 08:14:25 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CENcx017998 for ; Mon, 2 Oct 2006 21:14:23 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5c48_8a22d594_520f_11db_90a0_0014221f2a2d; Mon, 02 Oct 2006 21:14:23 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:17 +0900 Message-Id: <6.0.0.20.2.20061002191234.05f2b390@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 19:14:02 +0900 To: Mark Crispin From: Martin Duerst In-Reply-To: References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf-languages@iana.org, LTRU Working Group , Masayasu Ishikawa Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:44 06/09/29, Mark Crispin wrote: >So I assume that means that "karaoke" tagged as ja-Latn would be pronounced (somewhat like "kah-rah-oh-kay" to an English speaker), whereas "karaoke" tagged as "en" would be pronounced as "kerry-oh-key"? :-) Yes, assuming you have a very elaborate text-to-speach engine. Not at all sure current products go that far. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnH-00067y-Ke; Mon, 02 Oct 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-5G for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgc-0003zN-5S for ltru@ietf.org; Mon, 02 Oct 2006 08:14:19 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEHoT000245 for ; Mon, 2 Oct 2006 21:14:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 04ea_8667e674_From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnH-00067p-5v; Mon, 02 Oct 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-3L for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgi-00041F-By for ltru@ietf.org; Mon, 02 Oct 2006 08:14:25 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CENcx017998 for ; Mon, 2 Oct 2006 21:14:23 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5c48_8a22d594_520f_11db_90a0_0014221f2a2d; Mon, 02 Oct 2006 21:14:23 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:17 +0900 Message-Id: <6.0.0.20.2.20061002191234.05f2b390@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 19:14:02 +0900 To: Mark Crispin From: Martin Duerst In-Reply-To: References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf-languages@iana.org, LTRU Working Group , Masayasu Ishikawa Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:44 06/09/29, Mark Crispin wrote: >So I assume that means that "karaoke" tagged as ja-Latn would be pronounced (somewhat like "kah-rah-oh-kay" to an English speaker), whereas "karaoke" tagged as "en" would be pronounced as "kerry-oh-key"? :-) Yes, assuming you have a very elaborate text-to-speach engine. Not at all sure current products go that far. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnH-00067y-Ke; Mon, 02 Oct 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-5G for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgc-0003zN-5S for ltru@ietf.org; Mon, 02 Oct 2006 08:14:19 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEHoT000245 for ; Mon, 2 Oct 2006 21:14:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 04ea_8667e674_From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnH-00067p-5v; Mon, 02 Oct 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-3L for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgi-00041F-By for ltru@ietf.org; Mon, 02 Oct 2006 08:14:25 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CENcx017998 for ; Mon, 2 Oct 2006 21:14:23 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5c48_8a22d594_520f_11db_90a0_0014221f2a2d; Mon, 02 Oct 2006 21:14:23 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:17 +0900 Message-Id: <6.0.0.20.2.20061002191234.05f2b390@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 19:14:02 +0900 To: Mark Crispin From: Martin Duerst In-Reply-To: References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <6.0.0.20.2.20060928133744.04e41840@localhost> <6.0.0.20.2.20060928193237.08122670@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf-languages@iana.org, LTRU Working Group , Masayasu Ishikawa Subject: [Ltru] Re: Korean (and Japanese) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:44 06/09/29, Mark Crispin wrote: >So I assume that means that "karaoke" tagged as ja-Latn would be pronounced (somewhat like "kah-rah-oh-kay" to an English speaker), whereas "karaoke" tagged as "en" would be pronounced as "kerry-oh-key"? :-) Yes, assuming you have a very elaborate text-to-speach engine. Not at all sure current products go that far. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnH-00067y-Ke; Mon, 02 Oct 2006 08:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-5G for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgc-0003zN-5S for ltru@ietf.org; Mon, 02 Oct 2006 08:14:19 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEHoT000245 for ; Mon, 2 Oct 2006 21:14:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 04ea_8667e674_520f_11db_8d4f_0014221fa3c9; Mon, 02 Oct 2006 21:14:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:11 +0900 Message-Id: <6.0.0.20.2.20061002184933.041b8c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 18:53:05 +0900 To: Misha Wolf , ltru@ietf.org From: Martin Duerst Subject: RE: [Ltru] Re: Korean (and Japanese) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Misha, If there is only a Katakana version, this may be better than nothing. But if there are both versions, sending back only the one in the "full mix of scripts" may be much more appropriate. Of course it depends on how low-level your interface is. The more knowlegde an application has about the end devices used for display, the easier it is of course to eliminate ja-Kana. Regards, Martin. At 01:39 06/09/30, Misha Wolf wrote: >> Quite so. The point of Suppress-Script: is to discourage >> pointless "ja-Jpan" tags, because they damage the language-tag >> ecology. > >As I may have mentioned previously, for some Japanese data, >we hold two versions: one using the full mix of scripts and >one using Katakana. My current intention is that an API call >specifying ja-Jpan will return just the former, one specifying >ja-Kana will return just the latter, and one specifying ja >will return whatever is available. I know that doesn't quite >square with the discussion here, but I can't see another way >to do it. > >Misha > > >This email was sent to you by Reuters, the global news and information company. >To find out more about Reuters visit www.about.reuters.com > >Any views expressed in this message are those of the individual sender, >except where the sender specifically states them to be the views of Reuters Ltd. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnK-0006Du-FK; Mon, 02 Oct 2006 08:21:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-00066y-8I for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgV-0003xc-So for ltru@ietf.org; Mon, 02 Oct 2006 08:14:16 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEABT017958 for ; Mon, 2 Oct 2006 21:14:10 +0900 (JST) Received: from (133.2.206.133) by scm520f_11db_8d4f_0014221fa3c9; Mon, 02 Oct 2006 21:14:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:11 +0900 Message-Id: <6.0.0.20.2.20061002184933.041b8c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 18:53:05 +0900 To: Misha Wolf , ltru@ietf.org From: Martin Duerst Subject: RE: [Ltru] Re: Korean (and Japanese) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Misha, If there is only a Katakana version, this may be better than nothing. But if there are both versions, sending back only the one in the "full mix of scripts" may be much more appropriate. Of course it depends on how low-level your interface is. The more knowlegde an application has about the end devices used for display, the easier it is of course to eliminate ja-Kana. Regards, Martin. At 01:39 06/09/30, Misha Wolf wrote: >> Quite so. The point of Suppress-Script: is to discourage >> pointless "ja-Jpan" tags, because they damage the language-tag >> ecology. > >As I may have mentioned previously, for some Japanese data, >we hold two versions: one using the full mix of scripts and >one using Katakana. My current intention is that an API call >specifying ja-Jpan will return just the former, one specifying >ja-Kana will return just the latter, and one specifying ja >will return whatever is available. I know that doesn't quite >square with the discussion here, but I can't see another way >to do it. > >Misha > > >This email was sent to you by Reuters, the global news and information company. >To find out more about Reuters visit www.about.reuters.com > >Any views expressed in this message are those of the individual sender, >except where the sender specifically states them to be the views of Reuters Ltd. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnK-0006Du-FK; Mon, 02 Oct 2006 08:21:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-00066y-8I for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgV-0003xc-So for ltru@ietf.org; Mon, 02 Oct 2006 08:14:16 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEABT017958 for ; Mon, 2 Oct 2006 21:14:10 +0900 (JST) Received: from (133.2.206.133) by scm520f_11db_8d4f_0014221fa3c9; Mon, 02 Oct 2006 21:14:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:11 +0900 Message-Id: <6.0.0.20.2.20061002184933.041b8c40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 18:53:05 +0900 To: Misha Wolf , ltru@ietf.org From: Martin Duerst Subject: RE: [Ltru] Re: Korean (and Japanese) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Misha, If there is only a Katakana version, this may be better than nothing. But if there are both versions, sending back only the one in the "full mix of scripts" may be much more appropriate. Of course it depends on how low-level your interface is. The more knowlegde an application has about the end devices used for display, the easier it is of course to eliminate ja-Kana. Regards, Martin. At 01:39 06/09/30, Misha Wolf wrote: >> Quite so. The point of Suppress-Script: is to discourage >> pointless "ja-Jpan" tags, because they damage the language-tag >> ecology. > >As I may have mentioned previously, for some Japanese data, >we hold two versions: one using the full mix of scripts and >one using Katakana. My current intention is that an API call >specifying ja-Jpan will return just the former, one specifying >ja-Kana will return just the latter, and one specifying ja >will return whatever is available. I know that doesn't quite >square with the discussion here, but I can't see another way >to do it. > >Misha > > >This email was sent to you by Reuters, the global news and information company. >To find out more about Reuters visit www.about.reuters.com > >Any views expressed in this message are those of the individual sender, >except where the sender specifically states them to be the views of Reuters Ltd. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnK-0006Du-FK; Mon, 02 Oct 2006 08:21:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-00066y-8I for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgV-0003xc-So for ltru@ietf.org; Mon, 02 Oct 2006 08:14:16 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEABT017958 for ; Mon, 2 Oct 2006 21:14:10 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0427_825a79ca_520f_11db_978f_0014221fa3c9; Mon, 02 Oct 2006 21:14:09 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:03 +0900 Message-Id: <6.0.0.20.2.20061002174846.05f31630@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 17:53:03 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20061002023958.GB22365@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Are you saying that we should concentrate on getting Suppress-Script information for languages in ISO 639-1/2 first? Then I'd agree. But as in RFC 4646, I would not like to make progress on RFC 4646bis depenednt on any degree of Suppress-Script information. (chair hat on: we don't want this to take longer than necessary!) But the "keep confined" sounded as if you would forbid anybody to do the necessary research and register a Suppress-Script for an ISO 639-3 language. I would definitely have to disagree with this. Regards, Martin. At 11:39 06/10/02, John Cowan wrote: >Martin Duerst scripsit: >> At 06:39 06/09/30, John Cowan wrote: >> >> >I'm happy to keep Suppress-Script confined (as a matter of administrative >> >policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. >> >> As a technical contributor, I'd tend to disagree. There is no need >> to force people to be unnecessarily detailled when tagging. If it's >> widely accepted general practice that a language is written in a single >> script only, then just the language tag should do the job. Scripts, >> like regions, should only be added when they are really necessary. > >I agree with every word of this, but I don't see how it's relevant to >what I said. > >I am merely saying that we have no need to do the necessary investigations >to create Suppress-Script: entries for the thousands of 639-3 entries, >none of which will be usable until RFC 4646bis gets an RFC number anyhow. >Suppress-Script: is a backward compatibility facility, and people who >use script information for the "new" languages inconsistently, IMHO, >deserve what they get. > >-- >Work hard, John Cowan >play hard, cowan@ccil.org >die young, http://www.ccil.org/~cowan >rot quickly. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru se1.scbb.aoyama.ac.jp via smtp id 0427_825a79ca_520f_11db_978f_0014221fa3c9; Mon, 02 Oct 2006 21:14:09 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:03 +0900 Message-Id: <6.0.0.20.2.20061002174846.05f31630@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 17:53:03 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20061002023958.GB22365@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Are you saying that we should concentrate on getting Suppress-Script information for languages in ISO 639-1/2 first? Then I'd agree. But as in RFC 4646, I would not like to make progress on RFC 4646bis depenednt on any degree of Suppress-Script information. (chair hat on: we don't want this to take longer than necessary!) But the "keep confined" sounded as if you would forbid anybody to do the necessary research and register a Suppress-Script for an ISO 639-3 language. I would definitely have to disagree with this. Regards, Martin. At 11:39 06/10/02, John Cowan wrote: >Martin Duerst scripsit: >> At 06:39 06/09/30, John Cowan wrote: >> >> >I'm happy to keep Suppress-Script confined (as a matter of administrative >> >policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. >> >> As a technical contributor, I'd tend to disagree. There is no need >> to force people to be unnecessarily detailled when tagging. If it's >> widely accepted general practice that a language is written in a single >> script only, then just the language tag should do the job. Scripts, >> like regions, should only be added when they are really necessary. > >I agree with every word of this, but I don't see how it's relevant to >what I said. > >I am merely saying that we have no need to do the necessary investigations >to create Suppress-Script: entries for the thousands of 639-3 entries, >none of which will be usable until RFC 4646bis gets an RFC number anyhow. >Suppress-Script: is a backward compatibility facility, and people who >use script information for the "new" languages inconsistently, IMHO, >deserve what they get. > >-- >Work hard, John Cowan >play hard, cowan@ccil.org >die young, http://www.ccil.org/~cowan >rot quickly. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru se1.scbb.aoyama.ac.jp via smtp id 0427_825a79ca_520f_11db_978f_0014221fa3c9; Mon, 02 Oct 2006 21:14:09 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:03 +0900 Message-Id: <6.0.0.20.2.20061002174846.05f31630@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 17:53:03 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20061002023958.GB22365@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Are you saying that we should concentrate on getting Suppress-Script information for languages in ISO 639-1/2 first? Then I'd agree. But as in RFC 4646, I would not like to make progress on RFC 4646bis depenednt on any degree of Suppress-Script information. (chair hat on: we don't want this to take longer than necessary!) But the "keep confined" sounded as if you would forbid anybody to do the necessary research and register a Suppress-Script for an ISO 639-3 language. I would definitely have to disagree with this. Regards, Martin. At 11:39 06/10/02, John Cowan wrote: >Martin Duerst scripsit: >> At 06:39 06/09/30, John Cowan wrote: >> >> >I'm happy to keep Suppress-Script confined (as a matter of administrative >> >policy, not RFC 4646bis rule) to the languages of 639-1 and 639-2. >> >> As a technical contributor, I'd tend to disagree. There is no need >> to force people to be unnecessarily detailled when tagging. If it's >> widely accepted general practice that a language is written in a single >> script only, then just the language tag should do the job. Scripts, >> like regions, should only be added when they are really necessary. > >I agree with every word of this, but I don't see how it's relevant to >what I said. > >I am merely saying that we have no need to do the necessary investigations >to create Suppress-Script: entries for the thousands of 639-3 entries, >none of which will be usable until RFC 4646bis gets an RFC number anyhow. >Suppress-Script: is a backward compatibility facility, and people who >use script information for the "new" languages inconsistently, IMHO, >deserve what they get. > >-- >Work hard, John Cowan >play hard, cowan@ccil.org >die young, http://www.ccil.org/~cowan >rot quickly. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnc-0006ng-VK; Mon, 02 Oct 2006 08:21:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-AK for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgS-0003wh-VZ for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:14:13 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CE5Ya000230 for ; Mon, 2 Oct 2006 21:14:07 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 050e_7f50b898_520f_11db_8de3_0014221fa3c9; Mon, 02 Oct 2006 21:14:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:13:59 +0900 Message-Id: <6.0.0.20.2.20061002172807.041bc300@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 17:28:22 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Re-use of a region code for the same purpose In-Reply-To: <451EA086.7E6A@xyzzy.claranet.de> References: <004101c6e44f$b72df6f0$6401a8c0@DGBP7M81> <451EA086.7E6A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1, chair hat off. Regards, Martin. At 01:51 06/10/01, Frank Ellermann wrote: >Doug Ewell wrote: > >> we would have to be guided by ISO 3166/MA and UNSD on this. > >We only need a statement that a deprecated subtag can be >revived for its former purpose by the relevant ISO standard, >and that the "deprecated" field in the registry should then >be removed - instead of registering UN numbers where this >is not not strictly necessary to avoid conflicts. > >Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMne-0006r3-7Q; Mon, 02 Oct 2006 08:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-000666-6P for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgZ-0003zE-LK for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:14:18 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CEE6E017963 for ; Mon, 2 Oct 2006 21:14:14 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 5c38_84f3d8d4_520f_11db_97fb_0014221f2a2d; Mon, 02 Oct 2006 21:14:13 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:07 +0900 Message-Id: <6.0.0.20.2.20061002180155.05f33ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 18:30:36 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: [OT] Re: [Ltru] Re: RFC 4690 on Review and Recommendations forInternationalized Domain Names (IDNs) In-Reply-To: <45205671.259B@xyzzy.claranet.de> References: <00bb01c6e577$2ed30c90$6401a8c0@DGBP7M81> <45201FEE.67A8@xyzzy.claranet.de> <30b660a20610011409y21288f03yca4d466e12c121f7@mail.gmail.com> <45205671.259B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Frank, Mark, At 08:59 06/10/02, Frank Ellermann wrote: >Mark Davis wrote: > >> https://datatracker.ietf.org/documents/LIAISON/file304.pdf. > >Yes, I read this some weeks ago when I learned that there is >now an Unicode liaison statement. "Let's get rid of combining >characters in DNS labels" is an attractive idea, but doesn't >solve the problem of applications knowing Unicode version X >confronted with code points assigned in version Y > X. With >nameprep they also need to know more than the combining class. Your "thinking out loud" about how to be forward-compatible with combining characters is an interesting intellectual exercise, but totally unnecessary. IDN (stringprep/nameprep) uses NFKC rather than NFC mainly because of the fullwidth/halfwith problem for East Asian Languages. [Being extremely often very frustrated with Japanese Web sites that require input in exactly one of these, I understand the idea but don't see why we needed this for DNS when it's not used in (below) average Web sites.] There are, as far as I know, not too many new characters with compatibility mappings since Unicode 3.2 (Mark, any numbers?), and those that have been added can probably be just forbidden rather than mapped. For NFC, the situation is even easier, except for a few errata for purely clerical errors(*), because NFC was designed to be stable in certain well-defined respects, and the Unicode Consortium is very careful to make sure this stays that way. [(*) These clerical errors have some people wonder whether the sky will fall on our heads if they get corrected. But it's easy to see that nobody will go ahead to register a domain name "foo" if they get asked, in a confirmation message: Please confirm your registration of "bar". And it's exactly such a change from "foo" to "bar" that happens as long as some of these clerical errors are not corrected.] So the only thing a new version of stringprep/nameprep, based on a newer Unicode version, would bring is a larger repertoire of characters. What that means for DNS software is 0 (ZERO) upgrades, because of the way IDN was designed. What it means for registration software is some upgrades, but then registration software is concentrated at a few points and easy to upgrade, in particular for those registries/registrars that are interested in providing the new codepoints. What it means for clients (browsers and so on, or the relevant libraries) is that maybe, some casing functions have to be extended. (But how many new characters with case have been added after Unicode 3.2? The prohibition on decomposable precomposed characters will have kept these to a rather low number.) Other than that, nothing need to upgrade clients, because according to the IDN spec, clients are not supposed to complain about unregistered codepoints, a provision that was carefully designed for forwards-compatibility but now seems to have gone mostly forgotten. How much the authors of RFC 4690 agree with the stuff in the document is unclear to me. A lot of it, when I read it last time, seemed to be of the type of "let's collect all the FUD (fear, uncertainty, doubt) out there so that nobody can complain we didn't listen to them". >Which won't help. Unless Unicode and ICANN are willing to play >along the only possible outcome are a 3454bis, 3490bis (etc.) >using the most recent Unicode version, freezing it again. And >with objections / appeals by disgruntled RFC 3454 implementors >I fear that we're not more talking about this decade. Another >frozen version is arguably pointless. No. Given that the main thing that's frosen are the codepoint restrictions, and these only apply to registrars, a new frozen version every five years, or even more often, is not a big problem at all. The only problem is that last time there was an IDN WG, there were so many requests from special interests ("language X can't possibly exist without this special mapping"; "language Y will be at a great disadvantage with regards to language Z unless we introduce some special provisions in the compression scheme", and so on) that it was very difficult to find a consensus. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnL-0006H8-Vo; Mon, 02 Oct 2006 08:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnG-00066y-9b for ltru@ietf.org; Mon, 02 Oct 2006 08:21:10 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMgV-0003xd-Sn for ltru@ietf.org; Mon, 02 Oct 2006 08:14:13 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k92CE8ei017950 for ; Mon, 2 Oct 2006 21:14:08 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 0430_812791a0_520f_11db_8c9c_0014221fa3c9; Mon, 02 Oct 2006 21:14:07 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49240) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Oct 2006 21:14:00 +0900 Message-Id: <6.0.0.20.2.20061002173707.05f29c20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Oct 2006 17:37:24 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Suppress-Script batch 1 In-Reply-To: <007f01c6e4c9$283ec6c0$6401a8c0@DGBP7M81> References: <30b660a20609291802l359aed85wf8464c2a569ebfdf@mail.gmail.com> <30b660a20609301123r1253c808j3d3c61d447af26d4@mail.gmail.com> <007801c6e4c0$071e7c50$6401a8c0@DGBP7M81> <30b660a20609301218g5c7db7d8yb326fc2e0fbf4bd8@mail.gmail.com> <007f01c6e4c9$283ec6c0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Karen_Broome@spe.sony.com X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1, and very well explained, Doug! Regards, Martin. At 04:46 06/10/01, Doug Ewell wrote: >Mark Davis wrote: > >> "X is not necessary when X is not necessary" is never worth adding to a document, no matter what the X is. > >We are talking about "Don't use X when X is not necessary," which is not the same thing. There are many situations, in computer applications and real life, when it is perfectly OK to do something that is not strictly necessary. Sometimes it is even preferable for some security or verification reason. > >In the C or C++ or C# programming languages, I can write: > >if (x == 0) >{ > do_something(); >} >else >{ > do_something_else(); >} > >or I can write the same thing without the curly braces. There are certain reasons (stylistic or maintenance) why the version with "unnecessary" braces might be preferable. > >I don't see any harm in pointing out that script (and region) subtags do not fall into this category. > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://users.adelphia.net/~dewell/ >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:22:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnq-0007MG-1h; Mon, 02 Oct 2006 08:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnm-0007FY-8r for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:21:42 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMZt-0002la-0a for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:07:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GUMZk-0003lp-Hu for ltru@lists.ietf.org; Mon, 02 Oct 2006 14:07:13 +0200 Received: from pd9fbad58.dip0.t-ipconnect.de ([217.251.173.88]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 14:07:12 +0200 Received: from nobody by pd9fbad58.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 14:07:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 02 Oct 2006 14:01:46 +0200 Organization: Lines: 37 Message-ID: <4520FFAA.AFD@xyzzy.claranet.de> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad58.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ltru] Re: Registry deltas X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Please review this, or at least try to stay awake through it Okay, my first impression is "nothing special or unexpected" - there's no A -> C shortcut for A -> B -> C yet, because that's not yet in the rules (4646bis), correct ? > it may not be necessary to add "Newari, Classical" where we > already have "Classical Newari" Not necessary, but maybe desirable for alphabetically sorted descriptions (?). I'm not hot about it. For the XML fans: http://xyzzy.webhop.info/home/ltru/index.html The script still won't work for collisions of language and variant subtags with 5..8 letters (of course there's no such collision without any non-ISO language subtag). The as child of idea didn't work well with Debbie's application, I've replaced it by this: (deprecated | (preferred, deprecated))? Multi-descriptions (and in theory multi-comments) also didn't work as expected, replaced by more black magic: Same idea as
, certainly not pretty, but "works" is more important. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNG3-0002cV-9X; Mon, 02 Oct 2006 08:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNG2-0002Xu-1Q for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:50:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNFz-0002H5-F9 for ltru@lists.ietf.org; Mon, 02 Oct 2006 08:50:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GUNFN-0004oG-AJ for ltru@lists.ietf.org; Mon, 02 Oct 2006 14:50:14 +0200 Received: from du-001-216.access.de.clara.net ([212.82.227.216]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 14:50:13 +0200 Received: from nobody by du-001-216.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 14:50:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 02 Oct 2006 14:49:41 +0200 Organization: Lines: 24 Message-ID: <45210AE5.7B03@xyzzy.claranet.de> References: <00bb01c6e577$2ed30c90$6401a8c0@DGBP7M81> <45201FEE.67A8@xyzzy.claranet.de> <30b660a20610011409y21288f03yca4d466e12c121f7@mail.gmail.com> <45205671.259B@xyzzy.claranet.de> <6.0.0.20.2.20061002180155.05f33ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-216.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] [OT] Re: RFC 4690 on Review and Recommendations forInternationalized Domain Names (IDNs) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > What that means for DNS software is 0 (ZERO) upgrades, > because of the way IDN was designed. What it means > for registration software is some upgrades, but then > registration software is concentrated at a few points > and easy to upgrade [...] > What it means for clients (browsers and so on, or the > relevant libraries) is that maybe, some casing functions > have to be extended. SASLPREP is a non-IDN case (user names + passwords), the u+00AA case surprised me. > "let's collect all the FUD (fear, uncertainty, doubt) out > there so that nobody can complain we didn't listen to them". Maybe Mark and/or you could post another informational RFC, the dotless i example is apparently no FUD. Taking the "R" in RFC literally is something John might like... :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 08:53:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNIk-00040U-VX; Mon, 02 Oct 2006 08:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNIi-0003v6-SM for ltru@ietf.org; Mon, 02 Oct 2006 08:53:40 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNIg-0002yL-LI for ltru@ietf.org; Mon, 02 Oct 2006 08:53:40 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUNIe-00032n-BS; Mon, 02 Oct 2006 08:53:36 -0400 Date: Mon, 2 Oct 2006 08:53:36 -0400 To: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful Message-ID: <20061002125336.GC22365@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> <6.0.0.20.2.20061002174846.05f31630@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061002174846.05f31630@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > Are you saying that we should concentrate on getting Suppress-Script > information for languages in ISO 639-1/2 first? > > Then I'd agree. Good. > But as in RFC 4646, I would not like to make progress on RFC 4646bis > depenednt on any degree of Suppress-Script information. > (chair hat on: we don't want this to take longer than necessary!) By no means. > But the "keep confined" sounded as if you would forbid anybody to > do the necessary research and register a Suppress-Script for an > ISO 639-3 language. By no means. -- In politics, obedience and support John Cowan are the same thing. --Hannah Arendt http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 11:39:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPt0-0004Ba-C0; Mon, 02 Oct 2006 11:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPsz-0004BU-H5 for ltru@ietf.org; Mon, 02 Oct 2006 11:39:17 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPsy-0001Vz-6J for ltru@ietf.org; Mon, 02 Oct 2006 11:39:17 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUPsx-0000ig-Am; Mon, 02 Oct 2006 11:39:15 -0400 Date: Mon, 2 Oct 2006 11:39:15 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Registry deltas Message-ID: <20061002153915.GD22365@ccil.org> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I'm particularly wondering about the addition of "inverted" language > names from ISO 639-3. These were taken to be The Official Name on the > basis of being listed in [iso-dis-639-3_20060421], but apparently both > the inverted and non-inverted forms are part of the standard. So it > may not be necessary to add "Newari, Classical" where we already have > "Classical Newari", simply to reflect the official ISO 639-3 name. On reflection, though, I'm in favor of adding these inverted names, simply because they provide useful information, namely which names can be inverted and where to invert them. I'd be more in favor of merging descriptions that are a prefix of other descriptions: if we have both "Foo (Bar)" and "Foo", to eliminate the latter in favor of the former. I don't feel strongly about this, however. On another note, I'm okay with the comment on this: > Grandfathered tag i-ami > Add: Preferred-Value: ami > Deprecated: 2007-01-01 > Comments: replaced by ISO code ami but on this, not so much: > Grandfathered tag sgn-CH-de > Add: Preferred-Value: sgn-sgg > Deprecated: 2007-01-01 > Comments: replaced by ISO code sgg These "replaced by" comments existed in the RFC 3066 registry as a kind of crude Preferred-Value, and we now have a better mechanism. I can easily see someone looking at this entry and not knowing whether to use "sgn-sgg" or "sgg". -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the part http://ccil.org/~cowan that cooks with olive oil, and the part that cowan@ccil.org cooks with butter. -- David Chessler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 11:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQ2s-0003tr-Cd; Mon, 02 Oct 2006 11:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQ2q-0003th-Th for ltru@ietf.org; Mon, 02 Oct 2006 11:49:28 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQ2l-0002xy-IQ for ltru@ietf.org; Mon, 02 Oct 2006 11:49:28 -0400 Received: from [10.72.72.207] (snvvpn1-10-72-72-c207.corp.yahoo.com [10.72.72.207]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k92FnBCR097028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Oct 2006 08:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=HIhi5J+3Q3F0w8nhS1wXDhmp7TGYr/UsVIp3gFjMpMjlKXmFlpZbeU9i9CY60JnS Message-ID: <452134F3.6010408@yahoo-inc.com> Date: Mon, 02 Oct 2006 08:49:07 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> In-Reply-To: <6.0.0.20.2.20060930164637.09942840@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > > One point I'm wondering are registrations accepted on ietf-languages between the > final internet draft and the point in time when IANA does the update. Already thought of it. See: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.html#ianaconversion Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 11:56:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQ9T-0008Pr-Gw; Mon, 02 Oct 2006 11:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQ9S-0008Pm-Mk for ltru@ietf.org; Mon, 02 Oct 2006 11:56:18 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQ9R-0003nZ-D1 for ltru@ietf.org; Mon, 02 Oct 2006 11:56:18 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUQ9Q-0001JO-Qo for ltru@ietf.org; Mon, 02 Oct 2006 11:56:16 -0400 Date: Mon, 2 Oct 2006 11:56:16 -0400 To: ltru@ietf.org Message-ID: <20061002155616.GF22365@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ltru] Minor error in 4646 Appendix A X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org "Special thanks must go to Michael Everson, who has served as Language Subtag Reviewer for almost the complete period since the publication of RFC 1766" is not technically true, as the LSR role did not exist then. Change in 4646bis to "Language Tag or Subtag Reviewer". -- John Cowan cowan@ccil.org "Not to know The Smiths is not to know K.X.U." --K.X.U. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 13:22:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURVB-0007PN-3B; Mon, 02 Oct 2006 13:22:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURV9-0007PF-9O for ltru@ietf.org; Mon, 02 Oct 2006 13:22:47 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GURV6-0008QI-2q for ltru@ietf.org; Mon, 02 Oct 2006 13:22:47 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1675400nfc for ; Mon, 02 Oct 2006 10:22:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RfOHNiY0oB/yDRI1/F2CWwwz4APEf8vCkw+PLXs/NPKGZF/n1BLfrnK5/26M6nyq9dz4EzVnQaGOl9au813AE3Vs42Gzkdx2CBR2igbKhqSfbgRnup4sNYZDsNSP3rleVeJtMo0fw93tztX8jr4QqGAjZea357UTHDiXHRmzAaQ= Received: by 10.48.48.15 with SMTP id v15mr9577814nfv; Mon, 02 Oct 2006 10:22:41 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Mon, 2 Oct 2006 10:22:41 -0700 (PDT) Message-ID: <30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com> Date: Mon, 2 Oct 2006 10:22:41 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Registry deltas In-Reply-To: <20061002153915.GD22365@ccil.org> MIME-Version: 1.0 References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> X-Google-Sender-Auth: a0bfc5576d026506 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1708727771==" Errors-To: ltru-bounces@ietf.org --===============1708727771== Content-Type: multipart/alternative; boundary="----=_Part_1074_7435162.1159809761438" ------=_Part_1074_7435162.1159809761438 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Overall, I think inverted names are a bad idea. They are rather anglocentric, and we find that translators often do the wrong thing with them. They are also hugely inconsistent in the current registry. I think they are tolerable if (a) every single instance of a comma indicates an inverted name, and (b) all names are consistently inverted. Because of (a) one could programmatically fix the names to the correct value. But we certainly don't follow these now: (a) is broken in Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese which is not: Fuzhou, Hokkien, Amoy, or Taiwanese Min Natisone dialect, Nadiza dialect which is not: Nadiza dialect Natisone dialect Resian, Resianic, Rezijan Yiddish, in Latin script ... and probably the following: Description: English, Oxford English Dictionary spelling That would make the normal form: "Oxford English Dictionary spelling English", which is very odd. German, traditional orthography German, orthography of 1996 German, Austrian variant, traditional orthography German, Austrian variant, orthography of 1996 German, Swiss variant, traditional orthography German, Swiss variant, orthography of 1996 German, German variant, traditional orthography German, German variant, orthography of 1996 (b) is broken in Description: Northern Sotho but Description: Sotho, Southern and many others. Such inconsistency completely defeats the purpose. Plus, we are hardly consistent elsewhere: Description: Church Slavic Description: Old Slavonic Description: Church Slavonic Description: Old Bulgarian Description: Old Church Slavonic but not Description: Slavic, Church Description: Slavonic, Old Description: Slavonic, Church Description: Bulgarian, Old Description: Church Slavonic, Old Description: Slavonic, Old Church (BTW, surely we can add a few dozen more combinations, can't we -- isn't this also Old Russian, Old Ukranian,.... ;-) At the end of this document are the multi-word descriptions where the first word doesn't end with a , and the second doesn't start with a "(", and sorted by the second column. This was a very quick and dirty parse, but shows that many of these would be candidates for inversion, and thus are inconsistent with the ones that have been inverted. But it is also clear that in many cases it is a matter of taste as to whether a name is inverted or not -- and the last thing we need are arguments in the language group as to whether something should be inverted or not; and with 7,000 entries, I see lifetime work for JFC. If people really think they are necessary, however, it would be much better to have more structure so that this was predictable. Eg. Inverted-Description: English, Old (ca. 450-1100) Inverted-Description: Old Italic (Etruscan, Oscan, etc.) where we make it explicit that the structure is: inverted-description := core-name ", " inverted-prefix ["(" comment ")"] Mark Linear A Eastern Africa Middle Africa Northern Africa South Africa Southern Africa Western Africa Central African Republic South African Sign Language Southern Altai Central America Latin America and the Caribbean Northern America South America Central American Indian (Other) Latin American Spanish North American Indian South American Indian (Other) Antigua and Barbuda Australia and New Zealand Bosnia and Herzegovina Creoles and pidgins, English-based (Other) Creoles and pidgins, French-based (Other) Creoles and pidgins, Portuguese-based (Other) Creoles and pidgins (Other) Serbia and Montenegro Svalbard and Jan Mayen Trinidad and Tobago Turks and Caicos Islands Wallis and Futuna Netherlands Antilles Libyan Arab Jamahiriya Syrian Arab Republic United Arab Emirates Saudi Arabia Samaritan Aramaic Eastern Armenian Western Armenian Central Asia Eastern Asia South-Eastern Asia Southern Asia Western Asia Linear B Nepal Bhasa Norwegian Bokmål Norwegian Bokmal Old Bulgarian New Caledonia Unified Canadian Aboriginal Syllabics Ol Chiki (Ol Cemet', Ol, Santali) Macao Chinese in simplified script Macao Chinese in traditional script Mandarin Chinese Mandarin Chinese (Simplified) Mandarin Chinese (Traditional) simplified Chinese Singapore Chinese in simplified script Singapore Chinese in traditional script Taiwan Chinese in simplified script Taiwan Chinese in traditional script traditional Chinese Old Church Slavonic Haitian Creole Brunei Darussalam German Democratic Republic Egyptian demotic Nadiza dialect Natisone dialect Natisone dialect, Nadiza dialect Côte d'Ivoire Eastern Europe Northern Europe Southern Europe Western Europe Burkina Faso Russian Federation (alias for Hiragana + Katakana) Code for unwritten languages Code for undetermined script Code for uncoded script Metropolitan France Eastern Frisian Northern Frisian Western Frisian Scottish Gaelic South Georgia and the South Sandwich Islands Low German Swiss German Swiss German Sign Language Traditional German orthography French Guiana Equatorial Guinea Saint Helena Egyptian hieratic Egyptian hieroglyphs Mayan hieroglyphs Pahawh Hmong Old Hungarian Azerbaijani in Arabic script Azerbaijani in Cyrillic script Azerbaijani in Latin script Belarusian in Latin script Bosnian in Cyrillic script Bosnian in Latin script Inuktitut in Canadian Aboriginal Syllabic script Inuktitut in Latin script Mongolian in Cyrillic script Mongolian in Mongolian script Serbian in Cyrillic script Serbian in Latin script Tajik in Arabic script Tajik in Cyrillic script Uzbek in Cyrillic script Uzbek in Latin script British Indian Ocean Territory Bouvet Island Christmas Island Heard Island and McDonald Islands Norfolk Island Åland Islands Cayman Islands Cook Islands Falkland Islands (Malvinas) Faroe Islands Marshall Islands Solomon Islands Virgin Islands, British Virgin Islands, U.S. Old Italic (Etruscan, Oscan, etc.) Chinook jargon United Kingdom Saint Kitts and Nevis Hong Kong Hong Kong Chinese in simplified script Hong Kong Chinese in traditional script Default Language Algonquian languages Apache languages Athapascan languages Australian languages Bamileke languages Chamic languages Iroquoian languages Manobo languages Mayan languages Miscellaneous languages Multiple languages Munda languages Nubian languages Otomian languages Prakrit languages Salishan languages Sami languages (Other) Sign Languages Siouan languages Sorbian languages Tupi languages Wakashan languages Yupik languages Sri Lanka Tai Le Sierra Leone Kayah Li No linguistic content Saint Lucia PRC Mainland Chinese in simplified script PRC Mainland Chinese in traditional script Northern Mariana Islands San Marino Hiri Motu Syloti Nagri Viet Nam North Ndebele South Ndebele Classical Nepal Bhasa Papua New Guinea Classical Newari Old Newari Norwegian Nynorsk Norwegian Nynorsk Isle of Man Union of Soviet Socialist Republics Kan or Gan Mandarin or Standard Chinese Shanghaiese or Wu Xiang or Hunanese German orthography of 1996 Lao People's Democratic Republic Old Permic Old Persian Pollard Phonetic Saint Pierre and Miquelon Tok Pisin French Polynesia Czech Republic Dominican Republic Costa Rica Puerto Rico Western Sahara El Salvador Inari Sami Lule Sami Northern Sami Skolt Sami Southern Sami American Samoa Low Saxon Holy See (Vatican City State) American Sign Language Belgian-Flemish Sign Language Belgian-French Sign Language Brazilian Sign Language British Sign Language Colombian Sign Language Danish Sign Language Dutch Sign Language French Sign Language German Sign Language Greek Sign Language Irish Sign Language Italian Sign Language Japanese Sign Language Mexican Sign Language Nicaraguan Sign Language Norwegian Sign Language Portuguese Sign Language Spanish Sign Language Swedish Sign Language Church Slavic Church Slavonic Old Slavonic Lower Sorbian Upper Sorbian Northern Sotho French Southern Territories Visible Speech United States Minor Outlying Islands United States New Tai Lue Crimean Tatar Palestinian Territory, Occupied East Timor Sao Tome and Principe Sranan Tongo Crimean Turkish PRIVATE USE PRIVATE USE PRIVATE USE PRIVATE USE PRIVATE USE PRIVATE USE Cape Verde Saint Vincent and the Grenadines Sichuan Yi New Zealand Neutral Zone On 10/2/06, John Cowan wrote: > > Doug Ewell scripsit: > > > I'm particularly wondering about the addition of "inverted" language > > names from ISO 639-3. These were taken to be The Official Name on the > > basis of being listed in [iso-dis-639-3_20060421], but apparently both > > the inverted and non-inverted forms are part of the standard. So it > > may not be necessary to add "Newari, Classical" where we already have > > "Classical Newari", simply to reflect the official ISO 639-3 name. > > On reflection, though, I'm in favor of adding these inverted names, > simply because they provide useful information, namely which names can > be inverted and where to invert them. > > I'd be more in favor of merging descriptions that are a prefix of other > descriptions: if we have both "Foo (Bar)" and "Foo", to eliminate the > latter in favor of the former. I don't feel strongly about this, however. > > On another note, I'm okay with the comment on this: > > > Grandfathered tag i-ami > > Add: Preferred-Value: ami > > Deprecated: 2007-01-01 > > Comments: replaced by ISO code ami > > but on this, not so much: > > > Grandfathered tag sgn-CH-de > > Add: Preferred-Value: sgn-sgg > > Deprecated: 2007-01-01 > > Comments: replaced by ISO code sgg > > These "replaced by" comments existed in the RFC 3066 registry as a kind > of crude Preferred-Value, and we now have a better mechanism. I can > easily see someone looking at this entry and not knowing whether to use > "sgn-sgg" or "sgg". > > -- > All Gaul is divided into three parts: the part John Cowan > that cooks with lard and goose fat, the part > http://ccil.org/~cowan > that cooks with olive oil, and the part that cowan@ccil.org > cooks with butter. -- David Chessler > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_1074_7435162.1159809761438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Overall, I think inverted names are a bad idea. They are rather anglocentric, and we find that translators often do the wrong thing with them. They are also hugely inconsistent in the current registry.

I think they are tolerable if (a) every single instance of a comma indicates an inverted name, and (b) all names are consistently inverted. Because of (a) one could programmatically fix the names to the correct value.

But we certainly don't follow these now:

(a) is broken in
Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese

which is not: Fuzhou, Hokkien, Amoy, or Taiwanese Min

Natisone dialect, Nadiza dialect

which is not: Nadiza dialect Natisone dialect

Resian, Resianic, Rezijan
Yiddish, in Latin script
...

and probably the following:

Description: English, Oxford English Dictionary spelling
That would make the normal form: "Oxford English Dictionary spelling English", which is very odd.


German, traditional orthography
German, orthography of 1996
German, Austrian variant, traditional orthography
German, Austrian variant, orthography of 1996
German, Swiss variant, traditional orthography

German, Swiss variant, orthography of 1996
German, German variant, traditional orthography
German, German variant, orthography of 1996

(b) is broken in

Description: Northern Sotho
but
Description: Sotho, Southern


and many others.

Such inconsistency completely defeats the purpose. Plus, we are hardly consistent elsewhere:

Description: Church Slavic
Description: Old Slavonic
Description: Church Slavonic

Description: Old Bulgarian
Description: Old Church Slavonic

but not

Description: Slavic, Church
Description: Slavonic, Old
Description: Slavonic, Church
Description: Bulgarian, Old
Description: Church Slavonic, Old

Description: Slavonic, Old Church

(BTW, surely we can add a few dozen more combinations, can't we -- isn't this also Old Russian, Old Ukranian,.... ;-)

At the end of this document are the multi-word descriptions where the first word doesn't end with a , and the second doesn't start with a "(", and sorted by the second column. This was a very quick and dirty parse, but shows that many of these would be candidates for inversion, and thus are inconsistent with the ones that have been inverted. But it is also clear that in many cases it is a matter of taste as to whether a name is inverted or not -- and the last thing we need are arguments in the language group as to whether something should be inverted or not; and with 7,000 entries, I see lifetime work for JFC.

If people really think they are necessary, however, it would be much better to have more structure so that this was predictable. Eg.

Inverted-Description:  English, Old (ca. 450-1100)
Inverted-Description: Old Italic (Etruscan, Oscan, etc.)

where we make it explicit that the structure is:

inverted-description := core-name ", " inverted-prefix ["(" comment ")"]

Mark

Linear    A                   
Eastern    Africa                   
Middle    Africa                   
Northern    Africa                   
South    Africa                   
Southern    Africa                   
Western    Africa                   
Central    African    Republic               
South    African    Sign    Language           
Southern    Altai                   
Central    America                   
Latin    America    and    the    Caribbean       
Northern    America                   
South    America                   
Central    American    Indian    (Other)           
Latin    American    Spanish               
North    American    Indian               
South    American    Indian    (Other)           
Antigua    and    Barbuda               
Australia    and    New    Zealand           
Bosnia    and    Herzegovina               
Creoles    and    pidgins,    English-based    (Other)       
Creoles    and    pidgins,    French-based    (Other)       
Creoles    and    pidgins,    Portuguese-based    (Other)       
Creoles    and    pidgins    (Other)           
Serbia    and    Montenegro               
Svalbard    and    Jan    Mayen           
Trinidad    and    Tobago               
Turks    and    Caicos    Islands           
Wallis    and    Futuna               
Netherlands    Antilles                   
Libyan    Arab    Jamahiriya               
Syrian    Arab    Republic               
United    Arab    Emirates               
Saudi    Arabia                   
Samaritan    Aramaic                   
Eastern    Armenian                   
Western    Armenian                   
Central    Asia                   
Eastern    Asia                   
South-Eastern    Asia                   
Southern    Asia                   
Western    Asia                   
Linear    B                   
Nepal    Bhasa                   
Norwegian    Bokm&#xE5;l                   
Norwegian    Bokmal                   
Old    Bulgarian                   
New    Caledonia                   
Unified    Canadian    Aboriginal    Syllabics           
Ol    Chiki    (Ol    Cemet',    Ol,    Santali)   
Macao    Chinese    in    simplified    script       
Macao    Chinese    in    traditional    script       
Mandarin    Chinese                   
Mandarin    Chinese    (Simplified)               
Mandarin    Chinese    (Traditional)               
simplified    Chinese                   
Singapore    Chinese    in    simplified    script       
Singapore    Chinese    in    traditional    script       
Taiwan    Chinese    in    simplified    script       
Taiwan    Chinese    in    traditional    script       
traditional    Chinese                   
Old    Church    Slavonic               
Haitian    Creole                   
Brunei    Darussalam                   
German    Democratic    Republic               
Egyptian    demotic                   
Nadiza    dialect                   
Natisone    dialect                   
Natisone    dialect,    Nadiza    dialect           
C&#xF4;te    d'Ivoire                   
Eastern    Europe                   
Northern    Europe                   
Southern    Europe                   
Western    Europe                   
Burkina    Faso                   
Russian    Federation                   
(alias    for    Hiragana    +    Katakana)       
Code    for    unwritten    languages           
Code    for    undetermined    script           
Code    for    uncoded    script           
Metropolitan    France                   
Eastern    Frisian                   
Northern    Frisian                   
Western    Frisian                   
Scottish    Gaelic                   
South    Georgia    and    the    South    Sandwich    Islands
Low    German                   
Swiss    German                   
Swiss    German    Sign    Language           
Traditional    German    orthography               
French    Guiana                   
Equatorial    Guinea                   
Saint    Helena                   
Egyptian    hieratic                   
Egyptian    hieroglyphs                   
Mayan    hieroglyphs                   
Pahawh    Hmong                   
Old    Hungarian                   
Azerbaijani    in    Arabic    script           
Azerbaijani    in    Cyrillic    script           
Azerbaijani    in    Latin    script           
Belarusian    in    Latin    script           
Bosnian    in    Cyrillic    script           
Bosnian    in    Latin    script           
Inuktitut    in    Canadian    Aboriginal    Syllabic    script   
Inuktitut    in    Latin    script           
Mongolian    in    Cyrillic    script           
Mongolian    in    Mongolian    script           
Serbian    in    Cyrillic    script           
Serbian    in    Latin    script           
Tajik    in    Arabic    script           
Tajik    in    Cyrillic    script           
Uzbek    in    Cyrillic    script           
Uzbek    in    Latin    script           
British    Indian    Ocean    Territory           
Bouvet    Island                   
Christmas    Island                   
Heard    Island    and    McDonald    Islands       
Norfolk    Island                   
&#xC5;land    Islands                   
Cayman    Islands                   
Cook    Islands                   
Falkland    Islands    (Malvinas)               
Faroe    Islands                   
Marshall    Islands                   
Solomon    Islands                   
Virgin    Islands,    British               
Virgin    Islands,    U.S.               
Old    Italic    (Etruscan,    Oscan,    etc.)       
Chinook    jargon                   
United    Kingdom                   
Saint    Kitts    and    Nevis           
Hong    Kong                   
Hong    Kong    Chinese    in    simplified    script   
Hong    Kong    Chinese    in    traditional    script   
Default    Language                   
Algonquian    languages                   
Apache    languages                   
Athapascan    languages                   
Australian    languages                   
Bamileke    languages                   
Chamic    languages                   
Iroquoian    languages                   
Manobo    languages                   
Mayan    languages                   
Miscellaneous    languages                   
Multiple    languages                   
Munda    languages                   
Nubian    languages                   
Otomian    languages                   
Prakrit    languages                   
Salishan    languages                   
Sami    languages    (Other)               
Sign    Languages                   
Siouan    languages                   
Sorbian    languages                   
Tupi    languages                   
Wakashan    languages                   
Yupik    languages                   
Sri    Lanka                   
Tai    Le                   
Sierra    Leone                   
Kayah    Li                   
No    linguistic    content               
Saint    Lucia                   
PRC    Mainland    Chinese    in    simplified    script   
PRC    Mainland    Chinese    in    traditional    script   
Northern    Mariana    Islands               
San    Marino                   
Hiri    Motu                   
Syloti    Nagri                   
Viet    Nam                   
North    Ndebele                   
South    Ndebele                   
Classical    Nepal    Bhasa               
Papua    New    Guinea               
Classical    Newari                   
Old    Newari                   
Norwegian    Nynorsk                   
Norwegian    Nynorsk                   
Isle    of    Man               
Union    of    Soviet    Socialist    Republics       
Kan    or    Gan               
Mandarin    or    Standard    Chinese           
Shanghaiese    or    Wu               
Xiang    or    Hunanese               
German    orthography    of    1996           
Lao    People's    Democratic    Republic           
Old    Permic                   
Old    Persian                   
Pollard    Phonetic                   
Saint    Pierre    and    Miquelon           
Tok    Pisin                   
French    Polynesia                   
Czech    Republic                   
Dominican    Republic                   
Costa    Rica                   
Puerto    Rico                   
Western    Sahara                   
El    Salvador                   
Inari    Sami                   
Lule    Sami                   
Northern    Sami                   
Skolt    Sami                   
Southern    Sami                   
American    Samoa                   
Low    Saxon                   
Holy    See    (Vatican    City    State)       
American    Sign    Language               
Belgian-Flemish    Sign    Language               
Belgian-French    Sign    Language               
Brazilian    Sign    Language               
British    Sign    Language               
Colombian    Sign    Language               
Danish    Sign    Language               
Dutch    Sign    Language               
French    Sign    Language               
German    Sign    Language               
Greek    Sign    Language               
Irish    Sign    Language               
Italian    Sign    Language               
Japanese    Sign    Language               
Mexican    Sign    Language               
Nicaraguan    Sign    Language               
Norwegian    Sign    Language               
Portuguese    Sign    Language               
Spanish    Sign    Language               
Swedish    Sign    Language               
Church    Slavic                   
Church    Slavonic                   
Old    Slavonic                   
Lower    Sorbian                   
Upper    Sorbian                   
Northern    Sotho                   
French    Southern    Territories               
Visible    Speech                   
United    States    Minor    Outlying    Islands       
United    States                   
New    Tai    Lue               
Crimean    Tatar                   
Palestinian    Territory,    Occupied               
East    Timor                   
Sao    Tome    and    Principe           
Sranan    Tongo                   
Crimean    Turkish                   
PRIVATE    USE                   
PRIVATE    USE                   
PRIVATE    USE                   
PRIVATE    USE                   
PRIVATE    USE                   
PRIVATE    USE                   
Cape    Verde                   
Saint    Vincent    and    the    Grenadines       
Sichuan    Yi                   
New    Zealand                   
Neutral    Zone   


On 10/2/06, John Cowan <cowan@ccil.org> wrote:
Doug Ewell scripsit:

> I'm particularly wondering about the addition of "inverted"  language
> names from ISO 639-3.  These were taken to be The Official Name on the
> basis of being listed in [iso-dis-639-3_20060421], but apparently both
> the inverted and non-inverted forms are part of the standard.  So it
> may not be necessary to add "Newari, Classical" where we already have
> "Classical Newari", simply to reflect the official ISO 639-3 name.

On reflection, though, I'm in favor of adding these inverted names,
simply because they provide useful information, namely which names can
be inverted and where to invert them.

I'd be more in favor of merging descriptions that are a prefix of other
descriptions:  if we have both "Foo (Bar)" and "Foo", to eliminate the
latter in favor of the former.  I don't feel strongly about this, however.

On another note, I'm okay with the comment on this:

> Grandfathered tag i-ami
> Add: Preferred-Value: ami
>      Deprecated: 2007-01-01
>      Comments: replaced by ISO code ami

but on this, not so much:

> Grandfathered tag sgn-CH-de
> Add: Preferred-Value: sgn-sgg
>      Deprecated: 2007-01-01
>      Comments: replaced by ISO code sgg

These "replaced by" comments existed in the RFC 3066 registry as a kind
of crude Preferred-Value, and we now have a better mechanism.  I can
easily see someone looking at this entry and not knowing whether to use
"sgn-sgg" or "sgg".

--
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part             http://ccil.org/~cowan
that cooks with olive oil, and the part that            cowan@ccil.org
cooks with butter. -- David Chessler

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

------=_Part_1074_7435162.1159809761438-- --===============1708727771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1708727771==-- From ltru-bounces@ietf.org Mon Oct 02 14:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSN8-0006Vm-B6; Mon, 02 Oct 2006 14:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSN7-0006Vh-Jt for ltru@ietf.org; Mon, 02 Oct 2006 14:18:33 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSN6-0004al-98 for ltru@ietf.org; Mon, 02 Oct 2006 14:18:33 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k92IIK9p004913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Oct 2006 11:18:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=PFulWI90dNZwVlsNmtxpHJRECZhf751lzcvo8J30zw1vfsYClNWunCsEIE5bbrj3 Message-ID: <452157EB.5030203@yahoo-inc.com> Date: Mon, 02 Oct 2006 11:18:19 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Minor error in 4646 Appendix A References: <20061002155616.GF22365@ccil.org> In-Reply-To: <20061002155616.GF22365@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I made it say: Special thanks go to Michael Everson, who served as the Language Tag Reviewer for almost the entire RFC 1766/RFC 3066 period, as well as the Language Subtag Reviewer since the publication of RFC 4646. Addison John Cowan wrote: > "Special thanks must go to Michael Everson, who has served as Language > Subtag Reviewer for almost the complete period since the publication of > RFC 1766" is not technically true, as the LSR role did not exist then. > Change in 4646bis to "Language Tag or Subtag Reviewer". > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 14:26:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSUr-00038o-66; Mon, 02 Oct 2006 14:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSUq-00038j-3v for ltru@ietf.org; Mon, 02 Oct 2006 14:26:32 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSUo-0005pc-NS for ltru@ietf.org; Mon, 02 Oct 2006 14:26:32 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k92IQDRd005337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Oct 2006 11:26:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=ZkrrEEs5ZfUqKKvQgfpB2JaibwjKy6Nw9kMuQfCZOsY7ujF7k4us9ekcrSw2saXs Message-ID: <452159C3.1090802@yahoo-inc.com> Date: Mon, 02 Oct 2006 11:26:11 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Suppress-script considered least harmful References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> <6.0.0.20.2.20061002174846.05f31630@localhost> <20061002125336.GC22365@ccil.org> In-Reply-To: <20061002125336.GC22365@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> Are you saying that we should concentrate on getting Suppress-Script >> information for languages in ISO 639-1/2 first? >> >> Then I'd agree. > > Good. > >> But as in RFC 4646, I would not like to make progress on RFC 4646bis >> depenednt on any degree of Suppress-Script information. >> (chair hat on: we don't want this to take longer than necessary!) > > By no means. I disagree vehemently: 1. I disagree that we should close off this issue. I think that consensus is not yet achieved. I think that a proper proposal for script information in the registry will likely crystallize a very different consensus than preserving Suppress-Script. 2. I disagree that Suppress-Script is least harmful. I think that Suppress-Script is VERY harmful, simply because it seems to beg registrants do (possibly extensive, or possibly sloppy) research in order to pester ietf-languages with a (potentially large) number of registration requests for what is, at best, informative material for which the list is not a good arbitration mechanism. > >> But the "keep confined" sounded as if you would forbid anybody to >> do the necessary research and register a Suppress-Script for an >> ISO 639-3 language. > > By no means. > I agree. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 14:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSYg-00071M-1N; Mon, 02 Oct 2006 14:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSYe-00071G-Ri for ltru@ietf.org; Mon, 02 Oct 2006 14:30:28 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSYa-0006ac-Dr for ltru@ietf.org; Mon, 02 Oct 2006 14:30:28 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k92IUIhL005561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Oct 2006 11:30:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Uaoour0l2eI0XudymRAFsIgCKmBcLmm5o92ErZZsn9GMueaN6+8CzQftZ5kRsxT6 Message-ID: <45215AB9.3020804@yahoo-inc.com> Date: Mon, 02 Oct 2006 11:30:17 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Suppress-Script: fix registration description References: <6.0.0.20.2.20061001103658.0a64d9b0@localhost> In-Reply-To: <6.0.0.20.2.20061001103658.0a64d9b0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have fixed the editor's copy of 4646bis (note that it is not posted online yet). Addison Martin Duerst wrote: > When preparing the proposal to add a Suppress-Script to Japanese, > I discovered the following contradiction in RFC 4646: > > In 3.4., Stability of IANA Registry Entries: > > 8. The field 'Suppress-Script' MAY be added or removed via the > registration process. > > In 3.5., Registration Procedure for Subtags: > > Only subtags of type 'language' and 'variant' will be considered for > independent registration of new subtags. Handling of subtags needed > for stability and subtags necessary to keep the registry synchronized > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits > defined by this document are described in Section 3.3. Stability > provisions are described in Section 3.4. > > This procedure MAY also be used to register or alter the information > for the 'Description', 'Comments', 'Deprecated', or 'Prefix' fields > in a subtag's record as described in Section 3.4. Changes to all > other fields in the IANA registry are NOT permitted. > > This means that 3.4 says that Suppress-Script can be added or removed, > but 3.5 doesn't allow any changes to Suppress-Script. > > My assumption as a technical contributor is that 3.4 is what we wanted, > and the fact that Suppress-Script is missing in 3.5 is an oversight. > > As a co-chair, I think that we have to eliminate this contradiction, > both in RFC 4646bis, and preferably also via an erratum for RFC 4646. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 14:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSi3-0004vs-97; Mon, 02 Oct 2006 14:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSi2-0004vm-DY for ltru@ietf.org; Mon, 02 Oct 2006 14:40:10 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSi1-0007ZK-24 for ltru@ietf.org; Mon, 02 Oct 2006 14:40:10 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k92Ie5Rg006067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Oct 2006 11:40:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=ZGOWfdt7LbX1TpKCmET7K1bOeaJ/KcyH5DVmvlHFslnoLDXC6JX9Hf62jiaN7CpF Message-ID: <45215D03.1050901@yahoo-inc.com> Date: Mon, 02 Oct 2006 11:40:03 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Serbia and Montenegro in example References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'm not sure why the first item would need to be changed? The latter one should be, although it remains valid. Addison Karen_Broome@spe.sony.com wrote: > I suspect the examples section will be significantly revised during the > revision of the draft, but I just wanted to note that these two private > use examples likely need to be changed reflecting the recent change to ISO > 3166-1: > > sr-Latn-QM (Serbian, Latin-script, private region) > sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro) > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 14:42:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSkj-0007mW-Br; Mon, 02 Oct 2006 14:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSkh-0007mG-F4 for ltru@ietf.org; Mon, 02 Oct 2006 14:42:55 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSkg-0007u6-3C for ltru@ietf.org; Mon, 02 Oct 2006 14:42:55 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k92IglfL006187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Oct 2006 11:42:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=0ZZF2G3BuQ/Set6k7CSbtm9t0kDtCh6odzg2yVjJahhUvNmdkZsKqr6/IwlG2E27 Message-ID: <45215DA5.7090406@yahoo-inc.com> Date: Mon, 02 Oct 2006 11:42:45 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Serbia and Montenegro in example References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I should add... I went through and found one or two other instances of 'CS' and changed them. Addison Karen_Broome@spe.sony.com wrote: > I suspect the examples section will be significantly revised during the > revision of the draft, but I just wanted to note that these two private > use examples likely need to be changed reflecting the recent change to ISO > 3166-1: > > sr-Latn-QM (Serbian, Latin-script, private region) > sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro) > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 17:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVYY-0002sH-3q; Mon, 02 Oct 2006 17:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVYX-0002sC-HZ for ltru@ietf.org; Mon, 02 Oct 2006 17:42:33 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUVYW-00083S-Ac for ltru@ietf.org; Mon, 02 Oct 2006 17:42:33 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUVYV-0000fr-Vy for ltru@ietf.org; Mon, 02 Oct 2006 17:42:32 -0400 Date: Mon, 2 Oct 2006 17:42:31 -0400 To: ltru@ietf.org Message-ID: <20061002214231.GD2278@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] OT: Managing the big list of subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org How are we going to offer people a choice of language subtags in the RFC 4646bis regime? A simple dropdown list is barely usable for RFC 4646, and definitely isn't going to cut it for 4646bis. This is off-topic, as it doesn't contribute to the document any, but the right people to discuss it are on this list. Ethnologue provides information on which languages are spoken in which countries, not necessarily 100% reliable, of course, and assigns a single "home country" for each language (UK for English, e.g.). Still, it would be more than annoying to pick "US" from a country list, and then scroll through 238 language subtags for languages spoken there, not even counting immigrant languages! (English is indeed one of them.) I think an exchange of ideas would be useful. Ethnologue and ISO 639-6 also provide language classification information that might also be useful, though only a small fraction of people who use English would think of it as "Germanic" or "Indo-European". -- John Cowan cowan@ccil.org http://ccil.org/~cowan Linguistics is arguably the most hotly contested property in the academic realm. It is soaked with the blood of poets, theologians, philosophers, philologists, psychologists, biologists and neurologists, along with whatever blood can be got out of grammarians. - Russ Rymer _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 17:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVf9-0006KV-2X; Mon, 02 Oct 2006 17:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVf7-0006KN-D8 for ltru@ietf.org; Mon, 02 Oct 2006 17:49:21 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUVf6-0000IH-6H for ltru@ietf.org; Mon, 02 Oct 2006 17:49:21 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUVf3-0000wa-5o; Mon, 02 Oct 2006 17:49:17 -0400 Date: Mon, 2 Oct 2006 17:49:17 -0400 To: Addison Phillips Subject: Re: [Ltru] Suppress-script considered least harmful Message-ID: <20061002214916.GE2278@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> <6.0.0.20.2.20061002174846.05f31630@localhost> <20061002125336.GC22365@ccil.org> <452159C3.1090802@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452159C3.1090802@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > 1. I disagree that we should close off this issue. I think that > consensus is not yet achieved. I think that a proper proposal for script > information in the registry will likely crystallize a very different > consensus than preserving Suppress-Script. Okay, propose something. And if it turns out to be an Accept-Script scheme, it had better be able to survive my scathing criticisms! Or if it turns out to be a Don't-Do-Anything scheme, you'd better figure out a way to fend off the attacks of the IETF protocol weenies. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 18:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUW06-0006JT-Vm; Mon, 02 Oct 2006 18:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUW04-0006Fy-IY; Mon, 02 Oct 2006 18:11:00 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUVzz-0002fX-7h; Mon, 02 Oct 2006 18:11:00 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004838611.msg; Mon, 02 Oct 2006 23:12:50 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Mon, 02 Oct 2006 23:11:02 +0100 From: "Debbie Garside" To: , Subject: RE: [Ltru] OT: Managing the big list of subtags Date: Mon, 2 Oct 2006 23:10:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acbma/acTlzY8pyRQVO7WlAxpN3jdQAA0X/g In-Reply-To: <20061002214231.GD2278@ccil.org> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Mon, 02 Oct 2006 23:12:50 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDAV-Processed: mx1.nexbyte.net, Mon, 02 Oct 2006 23:12:51 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > How are we going to offer people a choice of language subtags > in the RFC 4646bis regime? A simple dropdown list is barely > usable for RFC 4646, and definitely isn't going to cut it for > 4646bis. This is off-topic, as it doesn't contribute to the > document any, but the right people to discuss it are on this list. A pick list is required... > > Ethnologue provides information on which languages are spoken > in which countries, not necessarily 100% reliable, of course, > and assigns a single "home country" for each language (UK for > English, e.g.). Still, it would be more than annoying to > pick "US" from a country list, and then scroll through 238 > language subtags for languages spoken there, not even > counting immigrant languages! (English is indeed one of them.) Based on regions and/or... > > I think an exchange of ideas would be useful. Ethnologue and ISO > 639-6 also provide language classification information that > might also be useful, though only a small fraction of people > who use English would think of it as "Germanic" or "Indo-European". Language classification... Otherwise known as... a faceted approach! Debbie > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > Linguistics is arguably the most hotly contested property in > the academic realm. It is soaked with the blood of poets, > theologians, philosophers, philologists, psychologists, > biologists and neurologists, along with whatever blood can be > got out of grammarians. - Russ Rymer > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 02 19:05:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWr2-00067w-HQ; Mon, 02 Oct 2006 19:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWr0-00065E-Iy for ltru@ietf.org; Mon, 02 Oct 2006 19:05:42 -0400 Received: from hu-out-0506.google.com ([72.14.214.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUWg1-00025O-3Z for ltru@ietf.org; Mon, 02 Oct 2006 18:54:22 -0400 Received: by hu-out-0506.google.com with SMTP id 34so957419hui for ; Mon, 02 Oct 2006 15:54:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fkhMl4JutvtCJTjwwGlHyExPUxQiyNA3XImj/dKmClttvc7yxobwkSf7+ze3XAA0cNtC4JJ+qlEQUc417AdzOHg17j78Zd9eBke63M1bE0DvFibJ4zHloq8tOBC9uvwz9/WVFMF9Eb+mgG56Xtr0VVghDl7Qes0VRxr8Z8zL4pI= Received: by 10.49.29.3 with SMTP id g3mr216556nfj; Mon, 02 Oct 2006 15:54:19 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Mon, 2 Oct 2006 15:54:19 -0700 (PDT) Message-ID: <30b660a20610021554r5b82086eleceef1b2693611d8@mail.gmail.com> Date: Mon, 2 Oct 2006 15:54:19 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] OT: Managing the big list of subtags In-Reply-To: <20061002214231.GD2278@ccil.org> MIME-Version: 1.0 References: <20061002214231.GD2278@ccil.org> X-Google-Sender-Auth: b1d263397cbd811a X-Spam-Score: 2.2 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0094434573==" Errors-To: ltru-bounces@ietf.org --===============0094434573== Content-Type: multipart/alternative; boundary="----=_Part_9061_9526454.1159829659366" ------=_Part_9061_9526454.1159829659366 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a good topic. A very useful technical is to make the common choices the easiest. I'd guess having the top X languages in a pulldown, and an Other... choice. The Other... can then go to a full-fledged dialog box, with more choices. I think your idea of selecting by regions would be useful; again listing the top languages first for each country, probably with an Other... to get the long tails, the languages spoken by a small percentage of people. (Of course, even a list of 200+ regions is a pain to navigate, so maybe organizing them by UN macroregion would be useful.) So what do I mean by "top"? If you have lots of users with known language choices, then that information can be used to get a list covering the most common choices based on available data. In the absence of that, other rankings can be made based on the kind of application you are looking at, such as a ranking of languages by population, or by population * average GDP, perhaps also skewed by target markets. That is, if you're targetting Eastern Europe, then you'd weigh the top list differently than if your principal markets were in Latin America. (By 'market' I'm speaking in a broad, not necessarily commercial, sense.) I strongly suspect that using a linguistic analysis in a UI would be pointless and counterproductive, since the average person would be unfamiliar with such classifications Debbie, I didn't understand your comment about facets. Mark On 10/2/06, John Cowan wrote: > > How are we going to offer people a choice of language subtags in the RFC > 4646bis regime? A simple dropdown list is barely usable for RFC 4646, > and definitely isn't going to cut it for 4646bis. This is off-topic, > as it doesn't contribute to the document any, but the right people to > discuss it are on this list. > > Ethnologue provides information on which languages are spoken in which > countries, not necessarily 100% reliable, of course, and assigns a > single "home country" for each language (UK for English, e.g.). Still, > it would be more than annoying to pick "US" from a country list, and > then scroll through 238 language subtags for languages spoken there, > not even counting immigrant languages! (English is indeed one of them.) > > I think an exchange of ideas would be useful. Ethnologue and ISO > 639-6 also provide language classification information that might also > be useful, though only a small fraction of people who use English would > think of it as "Germanic" or "Indo-European". > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > Linguistics is arguably the most hotly contested property in the academic > realm. It is soaked with the blood of poets, theologians, philosophers, > philologists, psychologists, biologists and neurologists, along with > whatever blood can be got out of grammarians. - Russ Rymer > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_9061_9526454.1159829659366 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a good topic. A very useful technical is to make the common choices the easiest. I'd guess having the top X languages in a pulldown, and an Other... choice.

The Other... can then go to a full-fledged dialog box, with more choices. I think your idea of selecting by regions would be useful; again listing the top languages first for each country, probably with an Other... to get the long tails, the languages spoken by a small percentage of people. (Of course, even a list of 200+ regions is a pain to navigate, so maybe organizing them by UN macroregion would be useful.)

So what do I mean by "top"? If you have lots of users with known language choices, then that information can be used to get a list covering the most common choices based on available data. In the absence of that, other rankings can be made based on the kind of application you are looking at, such as a ranking of languages by population, or by population * average GDP, perhaps also skewed by target markets. That is, if you're targetting Eastern Europe, then you'd weigh the top list differently than if your principal markets were in Latin America. (By 'market' I'm speaking in a broad, not necessarily commercial, sense.)

I strongly suspect that using a linguistic analysis in a UI would be pointless and counterproductive, since the average person would be unfamiliar with such classifications

Debbie, I didn't understand your comment about facets.

Mark

On 10/2/06, John Cowan <cowan@ccil.org> wrote:
How are we going to offer people a choice of language subtags in the RFC
4646bis regime?  A simple dropdown list is barely usable for RFC 4646,
and definitely isn't going to cut it for 4646bis.  This is off-topic,
as it doesn't contribute to the document any, but the right people to
discuss it are on this list.

Ethnologue provides information on which languages are spoken in which
countries, not necessarily 100% reliable, of course, and assigns a
single "home country" for each language (UK for English, e.g.).  Still,
it would be more than annoying to pick "US" from a country list, and
then scroll through 238 language subtags for languages spoken there,
not even counting immigrant languages!  (English is indeed one of them.)

I think an exchange of ideas would be useful.  Ethnologue and ISO
639-6 also provide language classification information that might also
be useful, though only a small fraction of people who use English would
think of it as "Germanic" or "Indo-European".

--
John Cowan  cowan@ccil.org   http://ccil.org/~cowan
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer

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

------=_Part_9061_9526454.1159829659366-- --===============0094434573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0094434573==-- From ltru-bounces@ietf.org Mon Oct 02 20:57:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYb7-0001oR-0t; Mon, 02 Oct 2006 20:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYb5-0001oM-4y for ltru@ietf.org; Mon, 02 Oct 2006 20:57:23 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYb1-0001i1-7X for ltru@ietf.org; Mon, 02 Oct 2006 20:57:23 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004839113.msg for ; Tue, 03 Oct 2006 01:59:24 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Tue, 03 Oct 2006 01:57:36 +0100 From: "Debbie Garside" To: "'John Cowan'" , "'Mark Davis'" Subject: RE: [Ltru] OT: Managing the big list of subtags Date: Tue, 3 Oct 2006 01:57:13 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acbmd5+cbuIiXV/fTNmsUYmquL9jWQAB31bQ In-Reply-To: <30b660a20610021554r5b82086eleceef1b2693611d8@mail.gmail.com> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Tue, 03 Oct 2006 01:59:24 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 03 Oct 2006 01:59:25 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1416654064==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1416654064== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07B3_01C6E68F.3ED9F0E0" This is a multi-part message in MIME format. ------=_NextPart_000_07B3_01C6E68F.3ED9F0E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mark wrote: > Debbie, I didn't understand your comment about facets. A faceted approach is more or less what you have described... various ways of accessing the data e.g. by region, language, language family, population, script, anglonym, franconym etc. But you choose the facet that is most relevant to your search. Thus if you know your language is spoken in the US you choose a pick list based on region and/or region collections. Or, if you know the language you require is part of say Western Germanic, choose to generate the pick list by language family. With ISO 639-6 you will be able to further refine pick lists according to whether the language you are searching for is written or spoken or, maybe, transliterated. I would want to do parameter queries with wild cards as well. Thus if I wanted the tag for Romanized Southern Pashto... The question is can I remember whether it is Pakhtu or Pashto or even Pashtu (and any number of other transliterations/spellings - although ISO 639-3 lists them all as Pashto+). Within ISO 639-6 I can go into the data via the Mode facet, select written from the pick list (currently 5 options) and enter "Pa* Southern" or even "PA* South*" in the Language Reference Name Box. I think data presented by region/region collection/population will be very useful. But I don't think any application designed to present this data should be limited in design by rigid facets if alternatives are available. I have to say in looking at the Ethnologue data now... I have become totally confused... I was looking at the data alphabetically and searching for Dari as spoken in Afghanistan... I couldn't find it. It was listed under Eastern Farsi! But there is another, totally unrelated, Dari (Zoroastrian). Now, supposedly, I knew what I was looking for. The Region facet may have helped here, but only if you know that Dari is related to Farsi. The problems are not just in navigating around 7,000+ languages, but also guessing the chosen language name; which is not, necessarily, obvious. And this was just searching for an anglonym... you can, most likely double that problem with franconyms. In order to navigate this list properly, alternative reference names will be required. Sorry for waffling Best regards Debbie _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 02 October 2006 23:54 To: John Cowan Cc: ltru@ietf.org Subject: Re: [Ltru] OT: Managing the big list of subtags This is a good topic. A very useful technical is to make the common choices the easiest. I'd guess having the top X languages in a pulldown, and an Other... choice. The Other... can then go to a full-fledged dialog box, with more choices. I think your idea of selecting by regions would be useful; again listing the top languages first for each country, probably with an Other... to get the long tails, the languages spoken by a small percentage of people. (Of course, even a list of 200+ regions is a pain to navigate, so maybe organizing them by UN macroregion would be useful.) So what do I mean by "top"? If you have lots of users with known language choices, then that information can be used to get a list covering the most common choices based on available data. In the absence of that, other rankings can be made based on the kind of application you are looking at, such as a ranking of languages by population, or by population * average GDP, perhaps also skewed by target markets. That is, if you're targetting Eastern Europe, then you'd weigh the top list differently than if your principal markets were in Latin America. (By 'market' I'm speaking in a broad, not necessarily commercial, sense.) I strongly suspect that using a linguistic analysis in a UI would be pointless and counterproductive, since the average person would be unfamiliar with such classifications Debbie, I didn't understand your comment about facets. Mark On 10/2/06, John Cowan wrote: How are we going to offer people a choice of language subtags in the RFC 4646bis regime? A simple dropdown list is barely usable for RFC 4646, and definitely isn't going to cut it for 4646bis. This is off-topic, as it doesn't contribute to the document any, but the right people to discuss it are on this list. Ethnologue provides information on which languages are spoken in which countries, not necessarily 100% reliable, of course, and assigns a single "home country" for each language (UK for English, e.g.). Still, it would be more than annoying to pick "US" from a country list, and then scroll through 238 language subtags for languages spoken there, not even counting immigrant languages! (English is indeed one of them.) I think an exchange of ideas would be useful. Ethnologue and ISO 639-6 also provide language classification information that might also be useful, though only a small fraction of people who use English would think of it as "Germanic" or "Indo-European". -- John Cowan cowan@ccil.org http://ccil.org/~cowan Linguistics is arguably the most hotly contested property in the academic realm. It is soaked with the blood of poets, theologians, philosophers, philologists, psychologists, biologists and neurologists, along with whatever blood can be got out of grammarians. - Russ Rymer _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_07B3_01C6E68F.3ED9F0E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Mark=20 wrote:
 
> Debbie, I didn't = understand your=20 comment about facets.
 
A=20 faceted approach is more or less what you have described... various ways = of=20 accessing the data e.g. by region, language, language family, = population,=20 script, anglonym, franconym etc.   But you choose the facet = that is=20 most relevant to your search.  Thus if you know your language is = spoken in=20 the US you choose a pick list based on region and/or region = collections. =20 Or, if you know the language you require is part of say Western = Germanic, choose=20 to generate the pick list by language family. With ISO 639-6 you = will be=20 able to further refine pick lists according to whether the language you = are=20 searching for is written or spoken or, maybe, transliterated.  = I would=20 want to do parameter queries with wild cards as well.  Thus if I = wanted the=20 tag for Romanized Southern Pashto... The question is can I remember = whether it=20 is Pakhtu or Pashto or even Pashtu (and any number of other=20 transliterations/spellings - although ISO 639-3 lists them all as=20 Pashto+).  Within ISO 639-6 I can go into the data via = the Mode=20 facet, select written from the pick list (currently 5 options) = and=20 enter "Pa* Southern" or even "PA* South*" in the Language Reference Name = Box.=20
 
I=20 think data presented by region/region collection/population will be very = useful.=20 But I don't think any application designed to present this data should = be=20 limited in design by rigid facets if alternatives are=20 available. 
 
I have=20 to say in looking at the Ethnologue data now... I have become totally=20 confused... I was looking at the data alphabetically and searching = for Dari=20 as spoken in Afghanistan... I couldn't find it.  It was listed = under=20 Eastern Farsi!  But there is another, totally unrelated, Dari=20 (Zoroastrian).  Now, supposedly, I knew what I was looking = for. The=20 Region facet may have helped here, but only if you know that Dari is = related to=20 Farsi.
 
The=20 problems are not just in navigating around 7,000+ languages, but also = guessing=20 the chosen language name; which is not, necessarily, obvious.  And = this was=20 just searching for an anglonym... you can, most likely double that = problem with=20 franconyms.  In order to navigate this list properly, alternative = reference=20 names will be required.
 
Sorry=20 for waffling
 
Best=20 regards
 
Debbie
 
 
 
 
 
 

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 02 October 2006=20 23:54
To: John Cowan
Cc: = ltru@ietf.org
Subject:=20 Re: [Ltru] OT: Managing the big list of subtags

This is a good topic. A very useful technical is to make = the common=20 choices the easiest. I'd guess having the top X languages in a = pulldown, and=20 an Other... choice.

The Other... can then go to a full-fledged = dialog=20 box, with more choices. I think your idea of selecting by regions = would be=20 useful; again listing the top languages first for each country, = probably with=20 an Other... to get the long tails, the languages spoken by a small = percentage=20 of people. (Of course, even a list of 200+ regions is a pain to = navigate, so=20 maybe organizing them by UN macroregion would be useful.)

So = what do I=20 mean by "top"? If you have lots of users with known language choices, = then=20 that information can be used to get a list covering the most common = choices=20 based on available data. In the absence of that, other rankings can be = made=20 based on the kind of application you are looking at, such as a ranking = of=20 languages by population, or by population * average GDP, perhaps also = skewed=20 by target markets. That is, if you're targetting Eastern Europe, then = you'd=20 weigh the top list differently than if your principal markets were in = Latin=20 America. (By 'market' I'm speaking in a broad, not necessarily = commercial,=20 sense.)

I strongly suspect that using a linguistic analysis in = a UI=20 would be pointless and counterproductive, since the average person = would be=20 unfamiliar with such classifications

Debbie, I didn't = understand your=20 comment about facets.

Mark

On 10/2/06, John=20 Cowan <cowan@ccil.org> = wrote:
How=20 are we going to offer people a choice of language subtags in the=20 RFC
4646bis regime?  A simple dropdown list is barely = usable=20 for RFC 4646,
and definitely isn't going to cut it for=20 4646bis.  This is off-topic,
as it doesn't contribute = to the=20 document any, but the right people to
discuss it are on this=20 list.

Ethnologue provides information on which languages are = spoken=20 in which
countries, not necessarily 100% reliable, of course, and = assigns=20 a
single "home country" for each language (UK for English,=20 e.g.).  Still,
it would be more than annoying to pick = "US" from=20 a country list, and
then scroll through 238 language subtags for=20 languages spoken there,
not even counting immigrant=20 languages!  (English is indeed one of them.)

I = think an=20 exchange of ideas would be useful.  Ethnologue and = ISO
639-6=20 also provide language classification information that might also =
be=20 useful, though only a small fraction of people who use English=20 would
think of it as "Germanic" or = "Indo-European".

--
John=20 Cowan  cowan@ccil.org   http://ccil.org/~cowan
Linguistics= is=20 arguably the most hotly contested property in the academic
realm. = It is=20 soaked with the blood of poets, theologians, = philosophers,
philologists,=20 psychologists, biologists and neurologists, along with
whatever = blood=20 can be got out of grammarians. - Russ=20 Rymer

_______________________________________________
Ltru = mailing=20 list
Ltru@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ltru

------=_NextPart_000_07B3_01C6E68F.3ED9F0E0-- --===============1416654064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1416654064==-- From ltru-bounces@ietf.org Tue Oct 03 02:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdss-0003kV-ML; Tue, 03 Oct 2006 02:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdsr-0003ix-Cx for ltru@ietf.org; Tue, 03 Oct 2006 02:36:05 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdsp-0004oJ-1w for ltru@ietf.org; Tue, 03 Oct 2006 02:36:05 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061003063602.WUHN7818.mta10.adelphia.net@DGBP7M81>; Tue, 3 Oct 2006 02:36:02 -0400 Message-ID: <006c01c6e6b6$31c3f500$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> Subject: Re: [Ltru] Re: Registry deltas Date: Mon, 2 Oct 2006 23:36:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I'd be more in favor of merging descriptions that are a prefix of > other descriptions: if we have both "Foo (Bar)" and "Foo", to > eliminate the latter in favor of the former. I don't feel strongly > about this, however. There's some fairly strong aopposition to that, from Debbie and (I believe) others who feel at least one Description field needs to match the name in each of the corresponding standards. That's why "bas" is listed as both "Basa" (from 639-2) and "Basa (Cameroon)" (from 639-3), and "bzw" is listed only as "Basa (Nigeria)" since it appears only in 639-3 and not in 639-2. I'm not at all happy with having one of the Basas be listed as just "Basa", but I suppose I can't argue with the logic. We do say that the purpose of the Description is "to indicate the meaning of that identifier [subtag] as defined in the source standard." If we point back to the source standard for meaning, the names do have to match. >> Grandfathered tag sgn-CH-de >> Add: Preferred-Value: sgn-sgg >> Deprecated: 2007-01-01 >> Comments: replaced by ISO code sgg > > These "replaced by" comments existed in the RFC 3066 registry as a > kind of crude Preferred-Value, and we now have a better mechanism. I > can easily see someone looking at this entry and not knowing whether > to use "sgn-sgg" or "sgg". I did some spelunking and found where the "requirement" came from to add these bogus comments. Early copies of draft-ietf-ltru-registry, the document that became RFC 4646, included a section 3.7 called "Initialization of the Registry" (note, singular -- there was no extensions registry yet) that contains a good deal of text that was later moved into draft-ietf-ltru-initial (RFC 4645). That section included this passage: "All other tags in the RFC 3066 registry that are deprecated will be maintained as grandfathered entries... The 'Comments' field will contain the reason for the deprecation." By that time we already had invented Preferred-Value, a much better mechanism (as John points out), but the passage was there. I never liked it -- for example, in http://www1.ietf.org/mail-archive/web/ltru/current/msg02481.html from June 2005 (search for the word "mindless") -- but decided to live with it. In the meantime, the "will" clause became "SHOULD" and then "may optionally" but the comments remained. I am 100% in favor of deleting, as part of the RFC 4645bis Registry reload, every Comments field of the form "replaced by ISO code xxx" where at best the same information can be gleaned from the Preferred-Value, and at worst the comment may add confusion. That is to say, all of them. RFC 4646 allows Comments fields to be added or deleted with impunity; if we can do this as part of the update instead of taking it to ietf-languages I am all for it. Comments that add no real information do not need to clutter up the Registry. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtQ-00056X-0R; Tue, 03 Oct 2006 02:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtO-00056E-Pl for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdtK-0004ws-Vd for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aXR8029066 for ; Tue, 3 Oct 2006 15:36:33 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 3163_83089bfa_52a9_11db_9fad_0014221f2a2d; Tue, 03 Oct 2006 15:36:33 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:27 +0900 Message-Id: <6.0.0.20.2.20061003144145.08795ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:42:17 +0900 To: Addison Phillips , John Cowan From: Martin Duerst Subject: Re: [Ltru] Minor error in 4646 Appendix A In-Reply-To: <452157EB.5030203@yahoo-inc.com> References: <20061002155616.GF22365@ccil.org> <452157EB.5030203@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I seem to remember that I mentioned this point in one of my reviews. But maybe that was for RFC 4647? Regards, Martin. At 03:18 06/10/03, Addison Phillips wrote: >I made it say: > >Special thanks go to Michael Everson, who served as the Language Tag Reviewer for almost the entire RFC 1766/RFC 3066 period, as well as the Language Subtag Reviewer since the publication of RFC 4646. > >Addison > >John Cowan wrote: >> "Special thanks must go to Michael Everson, who has served as Language >> Subtag Reviewer for almost the complete period since the publication of >> RFC 1766" is not technically true, as the LSR role did not exist then. >> Change in 4646bis to "Language Tag or Subtag Reviewer". >> > >-- >Addison Phillips >Globalization Architect -- Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtQ-00057M-4F; Tue, 03 Oct 2006 02:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtO-00056O-R1 for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdtK-0004wp-U6 for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aWZ3029059 for ; Tue, 3 Oct 2006 15:36:32 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4aa3_824ce39c_52a9_11db_97b5_0014221fa3c9; Tue, 03 Oct 2006 15:36:32 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:25 +0900 Message-Id: <6.0.0.20.2.20061003143805.08791d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:40:30 +0900 To: John Cowan , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] OT: Managing the big list of subtags In-Reply-To: <20061002214231.GD2278@ccil.org> References: <20061002214231.GD2278@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just brainstorming: I think a multifaceted approach, as Debbie has described it, is very useful. But integrating all this into an interface in an application is close to overkill. I think a pointer to a Web site providing the same would be much more useful. That should be combined with confirmation information (name/region where spoken, languages with similar names that are different,...) when entering the code. Regards, Martin. At 06:42 06/10/03, John Cowan wrote: >How are we going to offer people a choice of language subtags in the RFC >4646bis regime? A simple dropdown list is barely usable for RFC 4646, >and definitely isn't going to cut it for 4646bis. This is off-topic, >as it doesn't contribute to the document any, but the right people to >discuss it are on this list. > >Ethnologue provides information on which languages are spoken in which >countries, not necessarily 100% reliable, of course, and assigns a >single "home country" for each language (UK for English, e.g.). Still, >it would be more than annoying to pick "US" from a country list, and >then scroll through 238 language subtags for languages spoken there, >not even counting immigrant languages! (English is indeed one of them.) > >I think an exchange of ideas would be useful. Ethnologue and ISO >639-6 also provide language classification information that might also >be useful, though only a small fraction of people who use English would >think of it as "Germanic" or "Indo-European". > >-- >John Cowan cowan@ccil.org http://ccil.org/~cowan >Linguistics is arguably the most hotly contested property in the academic >realm. It is soaked with the blood of poets, theologians, philosophers, >philologists, psychologists, biologists and neurologists, along with >whatever blood can be got out of grammarians. - Russ Rymer > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtS-00059W-Cc; Tue, 03 Oct 2006 02:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtR-00059G-77 for ltru@lists.ietf.org; Tue, 03 Oct 2006 02:36:41 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdtO-0004y7-IP for ltru@lists.ietf.org; Tue, 03 Oct 2006 02:36:41 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aYaC029069 for ; Tue, 3 Oct 2006 15:36:35 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4aa2_83a490d2_52a9_11db_9362_0014221fa3c9; Tue, 03 Oct 2006 15:36:34 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:28 +0900 Message-Id: <6.0.0.20.2.20061003145000.089125c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:52:44 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Registry deltas In-Reply-To: <4520FFAA.AFD@xyzzy.claranet.de> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <4520FFAA.AFD@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 21:01 06/10/02, Frank Ellermann wrote: >(deprecated | (preferred, deprecated))? That can also be written something like: (preferred?, deprecated)? >Multi-descriptions (and in theory multi-comments) also >didn't work as expected, replaced by more black magic: > > > > Separators are in general a bad idea. If we have multiple description entries in the current format, the most straight- forward way to deal with them is description*, i.e. multiple elements. Anything else would be strange. >Same idea as
, certainly not pretty, but "works" >is more important. What about multiple description elements doesn't work? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtP-00056T-Tm; Tue, 03 Oct 2006 02:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtO-00056F-Px for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdtN-0004wq-4G for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aV1D023949 for ; Tue, 3 Oct 2006 15:36:31 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4a50_818fd932_52a9_11db_8217_0014221fa3c9; Tue, 03 Oct 2006 15:36:31 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:24 +0900 Message-Id: <6.0.0.20.2.20061003142608.08793850@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:31:37 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <452134F3.6010408@yahoo-inc.com> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> <452134F3.6010408@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This, as far as I'm concerned, covers some of the issue with the sentence: "Registrations that are in process under the rules defined in [RFC4646] when this document is adopted MUST be completed under the rules contained in this document." But what I'm concerned about are not Registrations that are in process (e.g. submitted to ietf-languages but not approved yet, or sent over to IANA but not yet in the registry,...), but Registrations that have been completed and are in the Registry, but have not been considered for the latest draft of rfc4645bis. Regards, Martin. At 00:49 06/10/03, Addison Phillips wrote: > > >Martin Duerst wrote: >> One point I'm wondering are registrations accepted on ietf-languages between the >> final internet draft and the point in time when IANA does the update. > >Already thought of it. > >See: > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.html#ianaconversion > >Addison > >-- >Addison Phillips >Globalization Architect -- Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtS-00059W-Cc; Tue, 03 Oct 2006 02:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtR-00059G-77 for ltru@lists.ietf.org; Tue, 03 Oct 2006 02:36:41 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdtO-0004y7-IP for ltru@lists.ietf.org; Tue, 03 Oct 2006 02:36:41 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aYaC029069 for ; Tue, 3 Oct 2006 15:36:35 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4aa2_83a490d2_52a9_11db_9362_0014221fa3c9; Tue, 03 Oct 2006 15:36:34 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:28 +0900 Message-Id: <6.0.0.20.2.20061003145000.089125c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:52:44 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Registry deltas In-Reply-To: <4520FFAA.AFD@xyzzy.claranet.de> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <4520FFAA.AFD@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 21:01 06/10/02, Frank Ellermann wrote: >(deprecated | (preferred, deprecated))? That can also be written something like: (preferred?, deprecated)? >Multi-descriptions (and in theory multi-comments) also >didn't work as expected, replaced by more black magic: > > > > Separators are in general a bad idea. If we have multiple description entries in the current format, the most straight- forward way to deal with them is description*, i.e. multiple elements. Anything else would be strange. >Same idea as
, certainly not pretty, but "works" >is more important. What about multiple description elements doesn't work? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtP-00056T-Tm; Tue, 03 Oct 2006 02:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUdtO-00056F-Px for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUdtN-0004wq-4G for ltru@ietf.org; Tue, 03 Oct 2006 02:36:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aV1D023949 for ; Tue, 3 Oct 2006 15:36:31 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4a50_818fd932_52a9_11db_8217_0014221fa3c9; Tue, 03 Oct 2006 15:36:31 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:24 +0900 Message-Id: <6.0.0.20.2.20061003142608.08793850@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:31:37 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <452134F3.6010408@yahoo-inc.com> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> <452134F3.6010408@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This, as far as I'm concerned, covers some of the issue with the sentence: "Registrations that are in process under the rules defined in [RFC4646] when this document is adopted MUST be completed under the rules contained in this document." But what I'm concerned about are not Registrations that are in process (e.g. submitted to ietf-languages but not approved yet, or sent over to IANA but not yet in the registry,...), but Registrations that have been completed and are in the Registry, but have not been considered for the latest draft of rfc4645bis. Regards, Martin. At 00:49 06/10/03, Addison Phillips wrote: > > >Martin Duerst wrote: >> One point I'm wondering are registrations accepted on ietf-languages between the >> final internet draft and the point in time when IANA does the update. > >Already thought of it. > >See: > > http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01alpha.html#ianaconversion > >Addison > >-- >Addison Phillips >Globalization Architect -- Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 02:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUe8v-0007n5-OY; Tue, 03 Oct 2006 02:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUe8u-0007mZ-M6 for ltru@ietf.org; Tue, 03 Oct 2006 02:52:40 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUe8t-0007te-DQ for ltru@ietf.org; Tue, 03 Oct 2006 02:52:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061003065238.UERI8494.mta9.adelphia.net@DGBP7M81> for ; Tue, 3 Oct 2006 02:52:38 -0400 Message-ID: <007201c6e6b8$83adbc50$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 2 Oct 2006 23:52:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: Registry deltas X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Okay, my first impression is "nothing special or unexpected" - > there's no A -> C shortcut for A -> B -> C yet, because that's > not yet in the rules (4646bis), correct ? "Yet" is an understatement. There is no consensus for making this destabilizing change. > The script still won't work for collisions of language > and variant subtags with 5..8 letters (of course there's > no such collision without any non-ISO language subtag). I assume everything from this point on refers to your particular XML conversion process, not to a perceived problem with the Registry. In particular, there is no "collision" between 5- to 8-letter language subtags (if any existed) and 5- to 8-letter variant subtags, any more than there is a collision between "ar" for Arabic and "AR" for Argentina. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 03:05:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeKu-00072K-8f; Tue, 03 Oct 2006 03:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeKs-000729-V9 for ltru@ietf.org; Tue, 03 Oct 2006 03:05:02 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUeKr-00040f-LZ for ltru@ietf.org; Tue, 03 Oct 2006 03:05:02 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061003070501.UJQG8494.mta9.adelphia.net@DGBP7M81> for ; Tue, 3 Oct 2006 03:05:01 -0400 Message-ID: <007e01c6e6ba$3e34c8b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 3 Oct 2006 00:05:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: OT: Managing the big list of subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > How are we going to offer people a choice of language subtags in the > RFC 4646bis regime? A simple dropdown list is barely usable for RFC > 4646, and definitely isn't going to cut it for 4646bis. It's all I've got in my application. I agree that an alphabetical list of 7,000 items isn't the most efficient way to look up this sort of information, but I couldn't think of anything better offhand and nothing was handed to me on a silver platter. Regional categorization may not be worth much; I hear Vietnamese every day at work and I am 8,000 miles from Vietnam. For ISO 639-6 it will be quite a bit different, because that data will apparently be organized in a hierarchical fashion, with each code element listed with its "parent." That practically begs for a tree-view control. But John is also right that not everyone who uses this data will think like a linguist and associate "English" with "Germanic" or "Indo-European." The problem is how to define "meaningful" categories, however one chooses to define that. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 03:14:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeUP-0007Fb-T8; Tue, 03 Oct 2006 03:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeUO-0007FW-8M for ltru@ietf.org; Tue, 03 Oct 2006 03:14:52 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUeUM-0006uz-VP for ltru@ietf.org; Tue, 03 Oct 2006 03:14:52 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061003071450.XIKB7818.mta10.adelphia.net@DGBP7M81>; Tue, 3 Oct 2006 03:14:50 -0400 Message-ID: <008401c6e6bb$9d6877e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> <452134F3.6010408@yahoo-inc.com> <6.0.0.20.2.20061003142608.08793850@localhost> Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 Date: Tue, 3 Oct 2006 00:14:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > But what I'm concerned about are not Registrations that are in process > (e.g. submitted to ietf-languages but not approved yet, or sent over > to IANA but not yet in the registry,...), but Registrations that have > been completed and are in the Registry, but have not been considered > for the latest draft of rfc4645bis. That is my concern as well. I have no solution except: 1. ask IETF's and IESG's indulgence in allowing minor updates to the draft during LC to account for such changes 2. ask ietf-languages' indulgence in imposing a brief moratorium on optional registrations during that time 3. pray that the ISO MAs are on holiday during that time 4. pray for a speedy trip through LC and the RFC Editor queue As you might guess, items 3 and 4 which require divine intervention have me the most concerned. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 04:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfZd-0005GS-9V; Tue, 03 Oct 2006 04:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfZc-0005BT-2m for ltru@ietf.org; Tue, 03 Oct 2006 04:24:20 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfZa-0006pJ-PF for ltru@ietf.org; Tue, 03 Oct 2006 04:24:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id E093726C216; Tue, 3 Oct 2006 10:24:01 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2EF5726C1D8; Tue, 3 Oct 2006 10:23:56 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2C26758ED14; Tue, 3 Oct 2006 10:23:56 +0200 (CEST) Date: Tue, 3 Oct 2006 10:23:56 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20061003082356.GA16525@nic.fr> References: <007e01c6e6ba$3e34c8b0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007e01c6e6ba$3e34c8b0$6401a8c0@DGBP7M81> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: LTRU Working Group Subject: [Ltru] Re: OT: Managing the big list of subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, Oct 03, 2006 at 12:05:00AM -0700, Doug Ewell wrote a message of 32 lines which said: > I agree that an alphabetical list of 7,000 items isn't the most > efficient way to look up this sort of information, but I couldn't > think of anything better offhand and nothing was handed to me on a > silver platter. This is indeed very offtopic (it is an UI issue and every interface which allows a language choice already tackled it) and I suggest to focalize on what LTRU can do to help the UI designers. Not to do their jobs but to provide them with information which *may* be useful. For instance, providing a Description is useful: the UI may allow the user to *type* a language name and then fuzzy-search it in descriptions. Not every UI will do so but we provide the data, just in case. Providing categories as in ISO 639-6 is useful: I agree that not everyone thinks like a linguist but we (LTRU) do not care. We provide information, UI designers use it is they see fit. > Regional categorization may not be worth much; I hear Vietnamese > every day at work and I am 8,000 miles from Vietnam. Bad example because your co-workers probably think of Vietnamese as a "foreign" language in the country where they work. I hear Arabic every day at work but my neighbors will not be surprised if Arabic is not listed if they choose France for their location. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 10:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkui-00047E-9G; Tue, 03 Oct 2006 10:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkuh-00046F-Uq for ltru@ietf.org; Tue, 03 Oct 2006 10:06:27 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkug-0003Dk-Jp for ltru@ietf.org; Tue, 03 Oct 2006 10:06:27 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061003140625.RLTI437.mta13.adelphia.net@DGBP7M81>; Tue, 3 Oct 2006 10:06:25 -0400 Message-ID: <00b001c6e6f5$1d12b8a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <007e01c6e6ba$3e34c8b0$6401a8c0@DGBP7M81> <20061003082356.GA16525@nic.fr> Date: Tue, 3 Oct 2006 07:06:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ltru] Re: OT: Managing the big list of subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > This is indeed very offtopic (it is an UI issue and every interface > which allows a language choice already tackled it) and I suggest to > focalize on what LTRU can do to help the UI designers. Not to do their > jobs but to provide them with information which *may* be useful. I wouldn't go so far as "very" off-topic. User interface issues may be relevant to some implementers of language tags. One of the points we have tried to make is that the Description fields in the Registry are just identifiers, not normative names, and it is perfectly OK for an application to translate or otherwise modify the names as long as they mean the same thing. For example, an application might choose "North Korea" and "South Korea" instead of the official names we got from ISO. John's question about how to organize 7,200 data items, or even 500, in a user-comprehensible way falls into this category also. >> Regional categorization may not be worth much; I hear Vietnamese >> every day at work and I am 8,000 miles from Vietnam. > > Bad example because your co-workers probably think of Vietnamese as a > "foreign" language in the country where they work. I hear Arabic every > day at work but my neighbors will not be surprised if Arabic is not > listed if they choose France for their location. The whole realm of "foreign language" is a bit fuzzy, and subject to change over time. Spanish is spoken by over 7% of the U.S. population and is an official language of the state of New Mexico. Here in Southern California we have voter materials in Spanish, Chinese, Vietnamese, and Korean. My point is that categorizing language by region works in the big picture, but eventually people will raise questions about fine details, and that's where the problems begin. I'm not saying I have a better option. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 10:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUl1H-0000Mz-1K; Tue, 03 Oct 2006 10:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUl1F-0000Mu-Fg for ltru@ietf.org; Tue, 03 Oct 2006 10:13:13 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUl1C-0004CG-8z for ltru@ietf.org; Tue, 03 Oct 2006 10:13:13 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUl19-00056A-U2; Tue, 03 Oct 2006 10:13:07 -0400 Date: Tue, 3 Oct 2006 10:13:07 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: OT: Managing the big list of subtags Message-ID: <20061003141307.GB23211@ccil.org> References: <007e01c6e6ba$3e34c8b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007e01c6e6ba$3e34c8b0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Regional categorization may not be worth much; I hear Vietnamese every > day at work and I am 8,000 miles from Vietnam. The Ethnologue indeed lists Vietnamese as one of the non-native languages of the U.S., with an estimated 859,000 speakers. Indeed, it is the 14th most widely spoken language in the U.S., after English, Spanish, German, Arabic, Korean, Chinese, Czech, Portuguese, Eastern Yiddish, French, Armenian, Italian, and Western Farsi. (Of these, only English and Spanish are considered indigenous.) -- Do what you will, John Cowan this Life's a Fiction cowan@ccil.org And is made up of http://www.ccil.org/~cowan Contradiction. --William Blake _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 12:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmog-0003TN-9a; Tue, 03 Oct 2006 12:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmof-0003TI-QJ for ltru@ietf.org; Tue, 03 Oct 2006 12:08:21 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmoe-0006Pz-Jr for ltru@ietf.org; Tue, 03 Oct 2006 12:08:21 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GUmoe-0001Yc-54; Tue, 03 Oct 2006 12:08:20 -0400 Date: Tue, 3 Oct 2006 12:08:20 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Registry deltas Message-ID: <20061003160820.GF23211@ccil.org> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> <006c01c6e6b6$31c3f500$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006c01c6e6b6$31c3f500$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I am 100% in favor of deleting, as part of the RFC 4645bis Registry > reload, every Comments field of the form "replaced by ISO code xxx" > where at best the same information can be gleaned from the > Preferred-Value, and at worst the comment may add confusion. That is to > say, all of them. RFC 4646 allows Comments fields to be added or > deleted with impunity; if we can do this as part of the update instead > of taking it to ietf-languages I am all for it. Comments that add no > real information do not need to clutter up the Registry. +1 -- John Cowan http://ccil.org/~cowan cowan@ccil.org All "isms" should be "wasms". --Abbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 03 12:18:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmyL-0001K1-LK; Tue, 03 Oct 2006 12:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmyJ-0001Jr-NR for ltru@ietf.org; Tue, 03 Oct 2006 12:18:19 -0400 Received: from hu-out-0506.google.com ([72.14.214.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmyI-0008Kq-BL for ltru@ietf.org; Tue, 03 Oct 2006 12:18:19 -0400 Received: by hu-out-0506.google.com with SMTP id 34so1195328hui for ; Tue, 03 Oct 2006 09:18:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=poJ1kbr1KKDDib667LAXZu13ucznxDaKiOpAgefyT2O60CFqiT/w5tRUA/ZeygCI3EVF9YPH6Wkg3HfaFnieUN+gnj+9cUMCtbBuTOtRO0SCIzAspt9rJjFV5AHGr/+dxjwkErsTw8hNaMHMYUGN67DxtbpePnNJHw+Aj6mlhdE= Received: by 10.49.41.18 with SMTP id t18mr1008149nfj; Tue, 03 Oct 2006 09:18:15 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Tue, 3 Oct 2006 09:18:14 -0700 (PDT) Message-ID: <30b660a20610030918q3a91e9ek627531f8988b986e@mail.gmail.com> Date: Tue, 3 Oct 2006 09:18:14 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Registry deltas In-Reply-To: <20061003160820.GF23211@ccil.org> MIME-Version: 1.0 References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> <006c01c6e6b6$31c3f500$6401a8c0@DGBP7M81> <20061003160820.GF23211@ccil.org> X-Google-Sender-Auth: 989589e822cb73fb X-Spam-Score: 1.9 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1563423003==" Errors-To: ltru-bounces@ietf.org --===============1563423003== Content-Type: multipart/alternative; boundary="----=_Part_28148_24248261.1159892294790" ------=_Part_28148_24248261.1159892294790 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 On 10/3/06, John Cowan wrote: > > Doug Ewell scripsit: > > > I am 100% in favor of deleting, as part of the RFC 4645bis Registry > > reload, every Comments field of the form "replaced by ISO code xxx" > > where at best the same information can be gleaned from the > > Preferred-Value, and at worst the comment may add confusion. That is to > > say, all of them. RFC 4646 allows Comments fields to be added or > > deleted with impunity; if we can do this as part of the update instead > > of taking it to ietf-languages I am all for it. Comments that add no > > real information do not need to clutter up the Registry. > > +1 > > -- > John Cowan http://ccil.org/~cowan cowan@ccil.org > All "isms" should be "wasms". --Abbie > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_28148_24248261.1159892294790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline +1

On 10/3/06, John Cowan <cowan@ccil.org> wrote:
Doug Ewell scripsit:

> I am 100% in favor of deleting, as part of the RFC 4645bis Registry
> reload, every Comments field of the form "replaced by ISO code xxx"
> where at best the same information can be gleaned from the
> Preferred-Value, and at worst the comment may add confusion.  That is to
> say, all of them.  RFC 4646 allows Comments fields to be added or
> deleted with impunity; if we can do this as part of the update instead
> of taking it to ietf-languages I am all for it.  Comments that add no
> real information do not need to clutter up the Registry.

+1

--
John Cowan  http://ccil.org/~cowan   cowan@ccil.org
All "isms" should be "wasms".   --Abbie

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

------=_Part_28148_24248261.1159892294790-- --===============1563423003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1563423003==-- From ltru-bounces@ietf.org Wed Oct 04 02:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzpn-0005Yz-KL; Wed, 04 Oct 2006 02:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzpm-0005Yu-9E for ltru@ietf.org; Wed, 04 Oct 2006 02:02:22 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUzpl-0004ph-0K for ltru@ietf.org; Wed, 04 Oct 2006 02:02:22 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061004060220.FHFP360.mta11.adelphia.net@DGBP7M81> for ; Wed, 4 Oct 2006 02:02:20 -0400 Message-ID: <002f01c6e77a$a6f68d00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 3 Oct 2006 23:02:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Consensus X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy and Martin, So far two members have agreed with my proposal to get rid of the vacuous "replaced by ISO code xxx" comments in the RFC 4646bis Registry. While two is hardly a majority of the WG membership, it makes me wonder what mechanism is going to be used to gauge consensus. So far I haven't seen any pronouncements of rough consensus from either co-chair, on either draft, and since we aren't using an issue tracker this time I really don't know if issues like this are even being recorded. I'm starting to prepare draft-4645bis-01 based on John Cowan's suggested changes, and I'd like to know what to do about these comments. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 02:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0JM-0000kx-F0; Wed, 04 Oct 2006 02:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0JK-0000ks-Um for ltru@ietf.org; Wed, 04 Oct 2006 02:32:54 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0JJ-0005Ge-LJ for ltru@ietf.org; Wed, 04 Oct 2006 02:32:54 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061004063248.TCSB7818.mta10.adelphia.net@DGBP7M81> for ; Wed, 4 Oct 2006 02:32:48 -0400 Message-ID: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 3 Oct 2006 23:32:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] CS, ME, RS in 4645bis X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I should point out that in draft-4645bis-00, region subtags ME and RS have been added, and CS is listed as deprecated, all with a date of 2006-10-01. This was actually an oversight; I had made the changes in my prototype 4645bis Registry after submitting the registration forms, before a controversy over the lack of a Preferred-Value for CS caused them to be withdrawn, and I forgot to undo the changes. Draft-4645bis-01 will reflect whatever is current in the 4646 Registry with respect to these subtags. I suppose I should also ask whether that controversy has been resolved to everyone's satisfaction -- that no Preferred-Value was given to CS because neither Serbia nor Montenegro is a complete replacement for "Serbia and Montenegro". I'd like to get a resolution so I can have the Reviewer resubmit those forms. The controversy over CS has caused the (supposedly automatic) registration of ME and RS to be delayed as well, which means we don't currently have a way to tag dialectical differences between the two countries. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 09:46:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV75K-0000GD-0S; Wed, 04 Oct 2006 09:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV75G-00008Y-EC for ltru@ietf.org; Wed, 04 Oct 2006 09:46:50 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV70m-0008Fw-5q for ltru@ietf.org; Wed, 04 Oct 2006 09:42:13 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GV70a-0000Ob-K1 for ltru@ietf.org; Wed, 04 Oct 2006 09:42:00 -0400 Date: Wed, 4 Oct 2006 09:42:00 -0400 To: ltru@ietf.org Message-ID: <20061004134200.GC15633@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ltru] Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org A proposal: The 4646bis registry should capture the language type information from ISO 639-3. Each language, including macrolanguages, is labeled in -3 as either living, extinct, ancient, historic, or constructed. These terms are defined precisely at http://www.sil.org/iso639-3/types.asp . Though informative rather than normative, this is very useful to help shrink the large number of languages to a more manageable size. The current draft of 639-3 contains 6989 living languages, 417 extinct languages, 114 ancient languages, 53 historic languages, and 24 constructed languages. The codes 'mul', 'und', and 'zxx' are special cases. The registry should also capture the individual language vs. language collection information from ISO 639-2. If a code element appears in -2 but not in -3, it is a language collection; there are 68 such code elements. Now that we have 639-3 code elements for essentially every language on the planet, language-collection subtags are extremely vague and provide little guidance to the recipient. (I'm not really happy with the vagueness of "Language-Type", and would prefer "Language-Status", but it's the term used in the FDIS.) I propose the following language for 4646bis section 3.1.2: o Language-Type o Language-Type's field-body contains one of the values 'collection', 'extinct', 'ancient', 'historic', 'constructed', or 'special'. This field MUST NOT appear except in records of type 'language'. And here's a draft of the new section 3.1.3.8: 3.1.3.8. Language-Type field The field 'Language-Type' MUST only appear in records whose 'Type' field-body is 'language'. This field MUST NOT appear more than once in a record. Most of the language records in the registry represent individual living languages. This field indicates those which are not. The value 'collection' indicates a language collection appearing in ISO 639-2 but not ISO 639-3. The values 'extinct', 'ancient', 'historic', and 'constructed' indicate languages which are so designated in ISO 639-3; precise definitions of these terms can be found in that standard. The value 'special' is used for the three subtags 'mul', 'und', and 'zxx', which do not actually designate languages at all. Finally, here's a rule for section 4.1: 8. Language subtags with a 'Language-Type' field of 'collection' do not represent specific languages, and SHOULD NOT be used unless more specific information is unavailable. Appropriate adjustments would be needed to 3.3, 3.4, and 3.5 as well. We should be able to set this field if and when we ever register a language subtag directly, and change it when 639-3 changes. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 11:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8kV-0004Wz-C7; Wed, 04 Oct 2006 11:33:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8kU-0004Wo-6b for ltru@ietf.org; Wed, 04 Oct 2006 11:33:30 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8kQ-0006Ou-OR for ltru@ietf.org; Wed, 04 Oct 2006 11:33:30 -0400 Received: from [10.72.77.34] (snvvpn2-10-72-77-c34.corp.yahoo.com [10.72.77.34]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k94FXFqD012300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Oct 2006 08:33:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Q7UJ4tMELt1g9moTPcYAcOXwllqObimpToTbnnGp1SL8XjvZLExN7TTgn9JdR6KW Message-ID: <4523D43B.8050608@yahoo-inc.com> Date: Wed, 04 Oct 2006 08:33:15 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Proposal: include new "Language-Type:" field References: <20061004134200.GC15633@ccil.org> In-Reply-To: <20061004134200.GC15633@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This sounds like a reasonable proposal and a good way to deal with providing information related to subtag choice (especially for the vexing and vague collections). Addison John Cowan wrote: > A proposal: > > The 4646bis registry should capture the language type information from > ISO 639-3. Each language, including macrolanguages, is labeled in -3 > as either living, extinct, ancient, historic, or constructed. These > terms are defined precisely at http://www.sil.org/iso639-3/types.asp . > Though informative rather than normative, this is very useful to help > shrink the large number of languages to a more manageable size. > > The current draft of 639-3 contains 6989 living languages, 417 > extinct languages, 114 ancient languages, 53 historic languages, > and 24 constructed languages. The codes 'mul', 'und', and 'zxx' are > special cases. > > The registry should also capture the individual language vs. language > collection information from ISO 639-2. If a code element appears in > -2 but not in -3, it is a language collection; there are 68 such code > elements. Now that we have 639-3 code elements for essentially every > language on the planet, language-collection subtags are extremely vague > and provide little guidance to the recipient. > > (I'm not really happy with the vagueness of "Language-Type", and would > prefer "Language-Status", but it's the term used in the FDIS.) > > > I propose the following language for 4646bis section 3.1.2: > > o Language-Type > o Language-Type's field-body contains one of the values > 'collection', 'extinct', 'ancient', 'historic', 'constructed', > or 'special'. This field MUST NOT appear except in records > of type 'language'. > > > And here's a draft of the new section 3.1.3.8: > > 3.1.3.8. Language-Type field > > The field 'Language-Type' MUST only appear in records whose > 'Type' field-body is 'language'. This field MUST NOT appear > more than once in a record. Most of the language records in > the registry represent individual living languages. This field > indicates those which are not. > > The value 'collection' indicates a language collection appearing > in ISO 639-2 but not ISO 639-3. The values 'extinct', 'ancient', > 'historic', and 'constructed' indicate languages which are so > designated in ISO 639-3; precise definitions of these terms can > be found in that standard. The value 'special' is used for the > three subtags 'mul', 'und', and 'zxx', which do not actually > designate languages at all. > > > Finally, here's a rule for section 4.1: > > 8. Language subtags with a 'Language-Type' field of 'collection' > do not represent specific languages, and SHOULD NOT be used > unless more specific information is unavailable. > > Appropriate adjustments would be needed to 3.3, 3.4, and 3.5 as well. > We should be able to set this field if and when we ever register > a language subtag directly, and change it when 639-3 changes. > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 11:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8rl-0001n0-Lc; Wed, 04 Oct 2006 11:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8rk-0001mt-HH for ltru@ietf.org; Wed, 04 Oct 2006 11:41:00 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8rj-0000QM-S6 for ltru@ietf.org; Wed, 04 Oct 2006 11:41:00 -0400 Received: by nf-out-0910.google.com with SMTP id l23so540281nfc for ; Wed, 04 Oct 2006 08:40:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=dnQhW+NjD7KVM/Vi73JVIcJ6vsvqDiX2QBgCfpFwGEMnWshczRzy5PnxUyHdtTWVptWXJpxs3OZ5JC1a6vaQcSDI+2QhsGOAirv8ck9Uh30yC0JxBn/4gavqw0rlfAMmIUfmN9cGPrVzJqcZQiZcSlLyVo5rADUy/9n5RjGOu5I= Received: by 10.49.93.13 with SMTP id v13mr2483379nfl; Wed, 04 Oct 2006 08:40:58 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Wed, 4 Oct 2006 08:40:57 -0700 (PDT) Message-ID: <30b660a20610040840l570c5a6cv852aaa6faf14cb94@mail.gmail.com> Date: Wed, 4 Oct 2006 08:40:57 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Proposal: include new "Language-Type:" field In-Reply-To: <20061004134200.GC15633@ccil.org> MIME-Version: 1.0 References: <20061004134200.GC15633@ccil.org> X-Google-Sender-Auth: 5501db1f9c352bd3 X-Spam-Score: 0.4 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0539489717==" Errors-To: ltru-bounces@ietf.org --===============0539489717== Content-Type: multipart/alternative; boundary="----=_Part_10046_2647942.1159976457990" ------=_Part_10046_2647942.1159976457990 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this is out of scope for the registry; our goal should be to have sufficient description to identify the language (that is, to distinguish it from others), and no more -- not to be the kitchen sink of information about languages. In addition, I don't see much of a need to duplicate information that is in 639, and I doubt that this additional information is "very useful to help shrink the large number of languages to a more manageable size". Most people will be picking among living languages, and this classification only separates out 8% of those. Making a list of 7K languages 8% smaller is not the key to an effective UI ;-). Those who need this information can go to 639 for it. living 6989 92.0% extinct 417 5.5% ancient 114 1.5% historic 53 0.7% constructed 24 0.3% oddball 3 0.0% total 7600 Mark On 10/4/06, John Cowan wrote: > > A proposal: > > The 4646bis registry should capture the language type information from > ISO 639-3. Each language, including macrolanguages, is labeled in -3 > as either living, extinct, ancient, historic, or constructed. These > terms are defined precisely at http://www.sil.org/iso639-3/types.asp . > Though informative rather than normative, this is very useful to help > shrink the large number of languages to a more manageable size. > > The current draft of 639-3 contains 6989 living languages, 417 > extinct languages, 114 ancient languages, 53 historic languages, > and 24 constructed languages. The codes 'mul', 'und', and 'zxx' are > special cases. > > The registry should also capture the individual language vs. language > collection information from ISO 639-2. If a code element appears in > -2 but not in -3, it is a language collection; there are 68 such code > elements. Now that we have 639-3 code elements for essentially every > language on the planet, language-collection subtags are extremely vague > and provide little guidance to the recipient. > > (I'm not really happy with the vagueness of "Language-Type", and would > prefer "Language-Status", but it's the term used in the FDIS.) > > > I propose the following language for 4646bis section 3.1.2: > > o Language-Type > o Language-Type's field-body contains one of the values > 'collection', 'extinct', 'ancient', 'historic', 'constructed', > or 'special'. This field MUST NOT appear except in records > of type 'language'. > > > And here's a draft of the new section 3.1.3.8: > > 3.1.3.8. Language-Type field > > The field 'Language-Type' MUST only appear in records whose > 'Type' field-body is 'language'. This field MUST NOT appear > more than once in a record. Most of the language records in > the registry represent individual living languages. This field > indicates those which are not. > > The value 'collection' indicates a language collection appearing > in ISO 639-2 but not ISO 639-3. The values 'extinct', 'ancient', > 'historic', and 'constructed' indicate languages which are so > designated in ISO 639-3; precise definitions of these terms can > be found in that standard. The value 'special' is used for the > three subtags 'mul', 'und', and 'zxx', which do not actually > designate languages at all. > > > Finally, here's a rule for section 4.1: > > 8. Language subtags with a 'Language-Type' field of 'collection' > do not represent specific languages, and SHOULD NOT be used > unless more specific information is unavailable. > > Appropriate adjustments would be needed to 3.3, 3.4, and 3.5 as well. > We should be able to set this field if and when we ever register > a language subtag directly, and change it when 639-3 changes. > > -- > John Cowan > cowan@ccil.org > I am a member of a civilization. --David Brin > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_10046_2647942.1159976457990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this is out of scope for the registry; our goal should be to have sufficient description to identify the language (that is, to distinguish it from others), and no more -- not to be the kitchen sink of information about languages.

In addition, I don't see much of a need to duplicate information that is in 639, and I doubt that this additional information is "very useful to help shrink the large number of languages to a more manageable size". Most people will be picking among living languages, and this classification only separates out 8% of those. Making a list of 7K languages 8% smaller is not the key to an effective UI ;-). Those who need this information can go to 639 for it.

living 6989 92.0%
extinct 417 5.5%
ancient 114 1.5%
historic 53 0.7%
constructed 24 0.3%
oddball 3 0.0%
total 7600

Mark

On 10/4/06, John Cowan <cowan@ccil.org> wrote:
A proposal:

The 4646bis registry should capture the language type information from
ISO 639-3.  Each language, including macrolanguages, is labeled in -3
as either living, extinct, ancient, historic, or constructed.  These
terms are defined precisely at http://www.sil.org/iso639-3/types.asp .
Though informative rather than normative, this is very useful to help
shrink the large number of languages to a more manageable size.

The current draft of 639-3 contains 6989 living languages, 417
extinct languages, 114 ancient languages, 53 historic languages,
and 24 constructed languages.  The codes 'mul', 'und', and 'zxx' are
special cases.

The registry should also capture the individual language vs.  language
collection information from ISO 639-2.  If a code element appears in
-2 but not in -3, it is a language collection; there are 68 such code
elements.  Now that we have 639-3 code elements for essentially every
language on the planet, language-collection subtags are extremely vague
and provide little guidance to the recipient.

(I'm not really happy with the vagueness of "Language-Type", and would
prefer "Language-Status", but it's the term used in the FDIS.)


I propose the following language for 4646bis section 3.1.2:

o Language-Type
        o Language-Type's field-body contains one of the values
          'collection', 'extinct', 'ancient', 'historic', 'constructed',
          or 'special'.  This field MUST NOT appear except in records
          of type 'language'.


And here's a draft of the new section 3.1.3.8:

3.1.3.8.  Language-Type field

        The field 'Language-Type' MUST only appear in records whose
        'Type' field-body is 'language'. This field MUST NOT appear
        more than once in a record.  Most of the language records in
        the registry represent individual living languages.  This field
        indicates those which are not.

        The value 'collection' indicates a language collection appearing
        in ISO 639-2 but not ISO 639-3.  The values 'extinct', 'ancient',
        'historic', and 'constructed' indicate languages which are so
        designated in ISO 639-3; precise definitions of these terms can
        be found in that standard.  The value 'special' is used for the
        three subtags 'mul', 'und', and 'zxx', which do not actually
        designate languages at all.


Finally, here's a rule for section 4.1:

        8.  Language subtags with a 'Language-Type' field of 'collection'
        do not represent specific languages, and SHOULD NOT be used
        unless more specific information is unavailable.

Appropriate adjustments would be needed to 3.3, 3.4, and 3.5 as well.
We should be able to set this field if and when we ever register
a language subtag directly, and change it when 639-3 changes.

--
John Cowan
        cowan@ccil.org
                I am a member of a civilization. --David Brin

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

------=_Part_10046_2647942.1159976457990-- --===============0539489717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0539489717==-- From ltru-bounces@ietf.org Wed Oct 04 12:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9CC-0007xA-AI; Wed, 04 Oct 2006 12:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9CB-0007oO-7b for ltru@ietf.org; Wed, 04 Oct 2006 12:02:07 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8zw-0001nM-5G for ltru@ietf.org; Wed, 04 Oct 2006 11:49:31 -0400 Received: by nf-out-0910.google.com with SMTP id l23so542771nfc for ; Wed, 04 Oct 2006 08:49:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YKccduelECZT14azaxxkYKLOeJ/aXAolnJyYtkZ9eG1npTQq5aBdSy70OvLyctU3VXrOJzI1VGWZGbffHgLt4Qgebbbfvn6lBe+mwKmR6+OzQklN7NncCGCbWuscOv3rthY5zDDw64SMIs/mGVVbXw5KkZHnAD/M/Zzxw+ZKZxo= Received: by 10.49.90.4 with SMTP id s4mr2505538nfl; Wed, 04 Oct 2006 08:49:26 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Wed, 4 Oct 2006 08:49:26 -0700 (PDT) Message-ID: <30b660a20610040849g173db67fnafb9c4af39fb220f@mail.gmail.com> Date: Wed, 4 Oct 2006 08:49:26 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] CS, ME, RS in 4645bis In-Reply-To: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 3a4fbc7a9c37b1e7 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1978477669==" Errors-To: ltru-bounces@ietf.org --===============1978477669== Content-Type: multipart/alternative; boundary="----=_Part_10266_15452699.1159976966401" ------=_Part_10266_15452699.1159976966401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with "that no Preferred-Value was given to CS because neither Serbia nor Montenegro is a complete replacement for "Serbia and Montenegro". We need to move more quickly on these. Mark On 10/3/06, Doug Ewell wrote: > > I should point out that in draft-4645bis-00, region subtags ME and RS > have been added, and CS is listed as deprecated, all with a date of > 2006-10-01. > > This was actually an oversight; I had made the changes in my prototype > 4645bis Registry after submitting the registration forms, before a > controversy over the lack of a Preferred-Value for CS caused them to be > withdrawn, and I forgot to undo the changes. Draft-4645bis-01 will > reflect whatever is current in the 4646 Registry with respect to these > subtags. > > I suppose I should also ask whether that controversy has been resolved > to everyone's satisfaction -- that no Preferred-Value was given to CS > because neither Serbia nor Montenegro is a complete replacement for > "Serbia and Montenegro". I'd like to get a resolution so I can have the > Reviewer resubmit those forms. The controversy over CS has caused the > (supposedly automatic) registration of ME and RS to be delayed as well, > which means we don't currently have a way to tag dialectical differences > between the two countries. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_10266_15452699.1159976966401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with "that no Preferred-Value was given to CS
because neither Serbia nor Montenegro is a complete replacement for
"Serbia and Montenegro".

We need to move more quickly on these.

Mark

On 10/3/06, Doug Ewell <dewell@adelphia.net> wrote:
I should point out that in draft-4645bis-00, region subtags ME and RS
have been added, and CS is listed as deprecated, all with a date of
2006-10-01.

This was actually an oversight; I had made the changes in my prototype
4645bis Registry after submitting the registration forms, before a
controversy over the lack of a Preferred-Value for CS caused them to be
withdrawn, and I forgot to undo the changes.  Draft-4645bis-01 will
reflect whatever is current in the 4646 Registry with respect to these
subtags.

I suppose I should also ask whether that controversy has been resolved
to everyone's satisfaction -- that no Preferred-Value was given to CS
because neither Serbia nor Montenegro is a complete replacement for
"Serbia and Montenegro".  I'd like to get a resolution so I can have the
Reviewer resubmit those forms.  The controversy over CS has caused the
(supposedly automatic) registration of ME and RS to be delayed as well,
which means we don't currently have a way to tag dialectical differences
between the two countries.

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


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

------=_Part_10266_15452699.1159976966401-- --===============1978477669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1978477669==-- From ltru-bounces@ietf.org Wed Oct 04 12:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9Zv-0000Na-N7; Wed, 04 Oct 2006 12:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9Zu-0000MJ-46 for ltru@ietf.org; Wed, 04 Oct 2006 12:26:38 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9Tn-0007Hh-SH for ltru@ietf.org; Wed, 04 Oct 2006 12:20:22 -0400 Received: by nf-out-0910.google.com with SMTP id l23so551863nfc for ; Wed, 04 Oct 2006 09:20:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=n2pmCKZfCoPZx5kl/JB6ViGMLCjVwHq7er2BePscz3ZhZUaAreHwQuX3UWSo0admeP7bOlJ+c9ZSsbOCbqDAY396C23chqTEQ9jVmDfTDNz0H24kId9s2bfTqVWlplPfvtRQ8At35fgwkmtCnKPEi+pw+ciOA1j/kQZhZlrJxNM= Received: by 10.48.242.19 with SMTP id p19mr2569742nfh; Wed, 04 Oct 2006 09:20:18 -0700 (PDT) Received: by 10.49.93.18 with HTTP; Wed, 4 Oct 2006 09:20:18 -0700 (PDT) Message-ID: <30b660a20610040920m47b59f39h24dbc3a420d5fe3d@mail.gmail.com> Date: Wed, 4 Oct 2006 09:20:18 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] CS, ME, RS in 4645bis In-Reply-To: <20061004161528.GF15633@ccil.org> MIME-Version: 1.0 References: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> <30b660a20610040849g173db67fnafb9c4af39fb220f@mail.gmail.com> <20061004161528.GF15633@ccil.org> X-Google-Sender-Auth: db4e54aa6d0ea628 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688386253==" Errors-To: ltru-bounces@ietf.org --===============0688386253== Content-Type: multipart/alternative; boundary="----=_Part_11226_30136799.1159978818810" ------=_Part_11226_30136799.1159978818810 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sadly, I suspect you aren't kidding. What's the story? Mark On 10/4/06, John Cowan wrote: > > Mark Davis scripsit: > > > I agree with "that no Preferred-Value was given to CS > > because neither Serbia nor Montenegro is a complete replacement for > > "Serbia and Montenegro". > > > > We need to move more quickly on these. > > I understand that it is very likely that ISO 3166/MA will reconsider, > and perhaps reverse, its assignment of 'RS' to Serbia. Therefore > I urge caution: festina lente. > > -- > On the Semantic Web, it's too hard to prove John Cowan > cowan@ccil.org > you're not a dog. --Bill de hOra http://www.ccil.org/~cowan > ------=_Part_11226_30136799.1159978818810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sadly, I suspect you aren't kidding. What's the story?

Mark

On 10/4/06, John Cowan <cowan@ccil.org> wrote:
Mark Davis scripsit:

> I agree with "that no Preferred-Value was given to CS
> because neither Serbia nor Montenegro is a complete replacement for
> "Serbia and Montenegro".
>
> We need to move more quickly on these.

I understand that it is very likely that ISO 3166/MA will reconsider,
and perhaps reverse, its assignment of 'RS' to Serbia.  Therefore
I urge caution:  festina lente.

--
On the Semantic Web, it's too hard to prove     John Cowan    cowan@ccil.org
you're not a dog.  --Bill de hOra               http://www.ccil.org/~cowan

------=_Part_11226_30136799.1159978818810-- --===============0688386253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0688386253==-- From ltru-bounces@ietf.org Wed Oct 04 12:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9a6-0000jD-UU; Wed, 04 Oct 2006 12:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9a5-0000i4-2v for ltru@ietf.org; Wed, 04 Oct 2006 12:26:49 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9P6-0006Zy-Im for ltru@ietf.org; Wed, 04 Oct 2006 12:15:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GV9P6-0005hu-5k; Wed, 04 Oct 2006 12:15:28 -0400 Date: Wed, 4 Oct 2006 12:15:28 -0400 To: Mark Davis Subject: Re: [Ltru] CS, ME, RS in 4645bis Message-ID: <20061004161528.GF15633@ccil.org> References: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> <30b660a20610040849g173db67fnafb9c4af39fb220f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610040849g173db67fnafb9c4af39fb220f@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I agree with "that no Preferred-Value was given to CS > because neither Serbia nor Montenegro is a complete replacement for > "Serbia and Montenegro". > > We need to move more quickly on these. I understand that it is very likely that ISO 3166/MA will reconsider, and perhaps reverse, its assignment of 'RS' to Serbia. Therefore I urge caution: festina lente. -- On the Semantic Web, it's too hard to prove John Cowan cowan@ccil.org you're not a dog. --Bill de hOra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 12:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9ur-00067R-Pz; Wed, 04 Oct 2006 12:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9uq-00064o-Ur for ltru@ietf.org; Wed, 04 Oct 2006 12:48:16 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9gO-00026H-C2 for ltru@ietf.org; Wed, 04 Oct 2006 12:33:21 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GV9gN-0006K1-WE; Wed, 04 Oct 2006 12:33:20 -0400 Date: Wed, 4 Oct 2006 12:33:19 -0400 To: Mark Davis Subject: Re: [Ltru] Proposal: include new "Language-Type:" field Message-ID: <20061004163319.GG15633@ccil.org> References: <20061004134200.GC15633@ccil.org> <30b660a20610040840l570c5a6cv852aaa6faf14cb94@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610040840l570c5a6cv852aaa6faf14cb94@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Most people will be picking among living languages, and this > classification only separates out 8% of those. Making a list of 7K > languages 8% smaller is not the key to an effective UI ;-). I agree. However, eliminating non-living languages from a listing of languages indigenous to the U.S. (according to Ethnologue) reduces the list from 238 to 162, a 32% reduction. Using the Ethnologue "nearly extinct" category allows a further reduction to only 92 languages, a full 62% reduction. Unfortunately, 639-3 does not use this type. Peter C, could you enlighten us on what the language type information in 639-3 is intended for? -- Ambassador Trentino: I've said enough. I'm a man of few words. Rufus T. Firefly: I'm a man of one word: scram! --Duck Soup John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 12:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9wc-0006jA-AM; Wed, 04 Oct 2006 12:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9wb-0006j5-Aa for ltru@ietf.org; Wed, 04 Oct 2006 12:50:05 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9wY-0006fi-Vu for ltru@ietf.org; Wed, 04 Oct 2006 12:50:05 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CKY3/mUxSnPfNQR71UalqDP1YXVY78xdQpI3nWjEDfMxgnGRNHp8M76hrfTfqfXy; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.167] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GV9wY-0007bU-DJ for ltru@ietf.org; Wed, 04 Oct 2006 12:50:02 -0400 Message-ID: <005b01c6e7d5$bb6a6440$6501a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20061004134200.GC15633@ccil.org> <30b660a20610040840l570c5a6cv852aaa6faf14cb94@mail.gmail.com> Subject: Re: [Ltru] Proposal: include new "Language-Type:" field Date: Wed, 4 Oct 2006 09:54:17 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7afbd0bea510399fd93a8dcdb9be8614aaf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.167 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Mark Davis" > To: "John Cowan" > Cc: > Sent: Wednesday, October 04, 2006 8:40 AM > Subject: Re: [Ltru] Proposal: include new "Language-Type:" field > > I think this is out of scope for the registry; our goal should be to have > sufficient description to identify the language (that is, to distinguish it > from others), and no more -- not to be the kitchen sink of information about > languages. ... As a technical contributor, I heartily agree. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 12:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9wv-0006pk-FH; Wed, 04 Oct 2006 12:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9wu-0006pf-36 for ltru@ietf.org; Wed, 04 Oct 2006 12:50:24 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9wr-0006hk-HO for ltru@ietf.org; Wed, 04 Oct 2006 12:50:24 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id BA6291E134B; Wed, 4 Oct 2006 09:50:18 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Oct 2006 09:50:18 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF28@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'John Cowan' , ltru@ietf.org Subject: RE: [Ltru] Proposal: include new "Language-Type:" field Date: Wed, 4 Oct 2006 09:50:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 While I agree with Mark that this won't help much with reducing the size of the "pick list", the Language Subtag Registry is intended to be a _free-standing_ and comprehensive source of language tag elements and the distinction of 'collection' seems important. Despite the FDIS usage of the thoroughly opaque term 'Language-Type', I'd suggest that this field (if added) be called 'Language-Status' (as John speculated below). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Wednesday, October 04, 2006 9:42 AM > To: ltru@ietf.org > Subject: [Ltru] Proposal: include new "Language-Type:" field > > > A proposal: > > The 4646bis registry should capture the language type information from > ISO 639-3. Each language, including macrolanguages, is labeled in -3 > as either living, extinct, ancient, historic, or constructed. These > terms are defined precisely at http://www.sil.org/iso639-3/types.asp . > Though informative rather than normative, this is very useful to help > shrink the large number of languages to a more manageable size. > > The current draft of 639-3 contains 6989 living languages, 417 > extinct languages, 114 ancient languages, 53 historic languages, > and 24 constructed languages. The codes 'mul', 'und', and 'zxx' are > special cases. > > The registry should also capture the individual language vs. language > collection information from ISO 639-2. If a code element appears in > -2 but not in -3, it is a language collection; there are 68 such code > elements. Now that we have 639-3 code elements for essentially every > language on the planet, language-collection subtags are > extremely vague > and provide little guidance to the recipient. > > (I'm not really happy with the vagueness of "Language-Type", and would > prefer "Language-Status", but it's the term used in the FDIS.) > > > I propose the following language for 4646bis section 3.1.2: > > o Language-Type > o Language-Type's field-body contains one of the values > 'collection', 'extinct', 'ancient', 'historic', > 'constructed', > or 'special'. This field MUST NOT appear except in records > of type 'language'. > > > And here's a draft of the new section 3.1.3.8: > > 3.1.3.8. Language-Type field > > The field 'Language-Type' MUST only appear in records whose > 'Type' field-body is 'language'. This field MUST NOT appear > more than once in a record. Most of the language records in > the registry represent individual living languages. > This field > indicates those which are not. > > The value 'collection' indicates a language > collection appearing > in ISO 639-2 but not ISO 639-3. The values > 'extinct', 'ancient', > 'historic', and 'constructed' indicate languages which are so > designated in ISO 639-3; precise definitions of these > terms can > be found in that standard. The value 'special' is > used for the > three subtags 'mul', 'und', and 'zxx', which do not actually > designate languages at all. > > > Finally, here's a rule for section 4.1: > > 8. Language subtags with a 'Language-Type' field of > 'collection' > do not represent specific languages, and SHOULD NOT be used > unless more specific information is unavailable. > > Appropriate adjustments would be needed to 3.3, 3.4, and 3.5 as well. > We should be able to set this field if and when we ever register > a language subtag directly, and change it when 639-3 changes. > > -- > John Cowan > cowan@ccil.org > I am a member of a civilization. --David Brin > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.12/462 - Release Date: 10/3/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 12:51:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9xc-0007Ci-Iq; Wed, 04 Oct 2006 12:51:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9u4-0005kY-BU for ltru@ietf.org; Wed, 04 Oct 2006 12:47:28 -0400 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9rY-0004oD-FT for ltru@ietf.org; Wed, 04 Oct 2006 12:44:54 -0400 Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id k94GikWx015714 for ; Wed, 4 Oct 2006 17:44:46 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=Kw3UyKLehxI14PemNRpUACbEWcyScv+KC/0e86iTflgRZ5qTKIZ6ncQ2OPOdPYvmW 9JX54GDTkohhG5cY3VisQ== Received: from wx-out-0506.google.com (wxdh29.prod.google.com [10.70.134.29]) by spaceape7.eur.corp.google.com with ESMTP id k94GiX98003639 for ; Wed, 4 Oct 2006 17:44:36 +0100 Received: by wx-out-0506.google.com with SMTP id h29so215948wxd for ; Wed, 04 Oct 2006 09:44:33 -0700 (PDT) Received: by 10.90.63.16 with SMTP id l16mr353846aga; Wed, 04 Oct 2006 09:44:33 -0700 (PDT) Received: by 10.90.99.19 with HTTP; Wed, 4 Oct 2006 09:44:32 -0700 (PDT) Message-ID: <1eb989310610040944i4a06dc29y2a3b2e98f0e49e07@mail.gmail.com> Date: Wed, 4 Oct 2006 09:44:32 -0700 From: "Vladimir Weinstein" To: "Mark Davis" Subject: Re: [Ltru] CS, ME, RS in 4645bis In-Reply-To: <30b660a20610040920m47b59f39h24dbc3a420d5fe3d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> <30b660a20610040849g173db67fnafb9c4af39fb220f@mail.gmail.com> <20061004161528.GF15633@ccil.org> <30b660a20610040920m47b59f39h24dbc3a420d5fe3d@mail.gmail.com> X-Spam-Score: -4.3 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Wed, 04 Oct 2006 12:51:06 -0400 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I just looked at the iso site again, and there is a press release from Friday: http://www.iso.org/iso/en/commcentre/pressreleases/2006/Ref1031.html But I agree - we should wait. Regards, v. On 10/4/06, Mark Davis wrote: > Sadly, I suspect you aren't kidding. What's the story? > > Mark > > On 10/4/06, John Cowan wrote: > > Mark Davis scripsit: > > > > > I agree with "that no Preferred-Value was given to CS > > > because neither Serbia nor Montenegro is a complete replacement for > > > "Serbia and Montenegro". > > > > > > We need to move more quickly on these. > > > > I understand that it is very likely that ISO 3166/MA will reconsider, > > and perhaps reverse, its assignment of 'RS' to Serbia. Therefore > > I urge caution: festina lente. > > > > -- > > On the Semantic Web, it's too hard to prove John Cowan > cowan@ccil.org > > you're not a dog. --Bill de hOra http://www.ccil.org/~cowan > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 16:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDUh-0006qK-S7; Wed, 04 Oct 2006 16:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDUh-0006p5-2Z for ltru@ietf.org; Wed, 04 Oct 2006 16:37:31 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDUf-00019J-Hw for ltru@ietf.org; Wed, 04 Oct 2006 16:37:31 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004862522.msg for ; Wed, 04 Oct 2006 21:39:37 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Wed, 04 Oct 2006 21:37:44 +0100 From: "Debbie Garside" To: Subject: RE: [Ltru] CS, ME, RS in 4645bis Date: Wed, 4 Oct 2006 21:37:20 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbnzpvP3L6COPetQqCYu0Y36tNP+AAJjt+A In-Reply-To: <30b660a20610040849g173db67fnafb9c4af39fb220f@mail.gmail.com> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Wed, 04 Oct 2006 21:39:37 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Wed, 04 Oct 2006 21:39:38 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277356521==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1277356521== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0957_01C6E7FD.45AFA940" This is a multi-part message in MIME format. ------=_NextPart_000_0957_01C6E7FD.45AFA940 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit +1 _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 04 October 2006 16:49 To: Doug Ewell Cc: LTRU Working Group Subject: Re: [Ltru] CS, ME, RS in 4645bis I agree with "that no Preferred-Value was given to CS because neither Serbia nor Montenegro is a complete replacement for "Serbia and Montenegro". We need to move more quickly on these. Mark On 10/3/06, Doug Ewell wrote: I should point out that in draft-4645bis-00, region subtags ME and RS have been added, and CS is listed as deprecated, all with a date of 2006-10-01. This was actually an oversight; I had made the changes in my prototype 4645bis Registry after submitting the registration forms, before a controversy over the lack of a Preferred-Value for CS caused them to be withdrawn, and I forgot to undo the changes. Draft-4645bis-01 will reflect whatever is current in the 4646 Registry with respect to these subtags. I suppose I should also ask whether that controversy has been resolved to everyone's satisfaction -- that no Preferred-Value was given to CS because neither Serbia nor Montenegro is a complete replacement for "Serbia and Montenegro". I'd like to get a resolution so I can have the Reviewer resubmit those forms. The controversy over CS has caused the (supposedly automatic) registration of ME and RS to be delayed as well, which means we don't currently have a way to tag dialectical differences between the two countries. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_0957_01C6E7FD.45AFA940 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
+1

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 04 October 2006=20 16:49
To: Doug Ewell
Cc: LTRU Working=20 Group
Subject: Re: [Ltru] CS, ME, RS in = 4645bis

I agree with "that no Preferred-Value was given to = CS
because=20 neither Serbia nor Montenegro is a complete replacement for
"Serbia = and=20 Montenegro".

We need to move more quickly on these.

Mark =

On 10/3/06, Doug=20 Ewell <dewell@adelphia.net>=20 wrote:
I=20 should point out that in draft-4645bis-00, region subtags ME and = RS
have=20 been added, and CS is listed as deprecated, all with a date=20 of
2006-10-01.

This was actually an oversight; I had made = the=20 changes in my prototype
4645bis Registry after submitting the=20 registration forms, before a
controversy over the lack of a=20 Preferred-Value for CS caused them to be
withdrawn, and I forgot = to undo=20 the changes.  Draft-4645bis-01 will
reflect whatever is = current=20 in the 4646 Registry with respect to these
subtags.

I = suppose I=20 should also ask whether that controversy has been resolved
to = everyone's=20 satisfaction -- that no Preferred-Value was given to CS
because = neither=20 Serbia nor Montenegro is a complete replacement for
"Serbia and=20 Montenegro".  I'd like to get a resolution so I can have=20 the
Reviewer resubmit those forms.  The controversy = over CS has=20 caused the
(supposedly automatic) registration of ME and RS to be = delayed=20 as well,
which means we don't currently have a way to tag = dialectical=20 differences
between the two countries.

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


________= _______________________________________
Ltru=20 mailing list
Ltru@ietf.org
https://www1.ietf.or= g/mailman/listinfo/ltru

------=_NextPart_000_0957_01C6E7FD.45AFA940-- --===============1277356521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1277356521==-- From ltru-bounces@ietf.org Wed Oct 04 17:01:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDrN-0005vx-0p; Wed, 04 Oct 2006 17:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDrL-0005vq-KW for ltru@ietf.org; Wed, 04 Oct 2006 17:00:55 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDrK-00057T-EH for ltru@ietf.org; Wed, 04 Oct 2006 17:00:55 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GVDrJ-0007GA-HE; Wed, 04 Oct 2006 17:00:53 -0400 Date: Wed, 4 Oct 2006 17:00:53 -0400 To: ietf-languages@iana.org, ltru@ietf.org Message-ID: <20061004210053.GA24151@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Registering RS and ME X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Scripsi: > I understand that it is very likely that ISO 3166/MA will reconsider, > and perhaps reverse, its assignment of 'RS' to Serbia. Therefore > I urge caution: festina lente. That was the result of a misunderstanding on my part. I now think it very *unlikely* that RS will be changed, and agree that we should move on with deprecating CS (without Preferred-Value) and registering RS and ME (and a fortiori putting them into 4645bis). -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 04 19:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVFmy-0007Aj-CU; Wed, 04 Oct 2006 19:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVFmx-0007Ab-0n for ltru@ietf.org; Wed, 04 Oct 2006 19:04:31 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVFmt-0006xD-M5 for ltru@ietf.org; Wed, 04 Oct 2006 19:04:30 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.647.8; Wed, 4 Oct 2006 16:04:27 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 16:04:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Proposal: include new "Language-Type:" field Date: Wed, 4 Oct 2006 16:04:07 -0700 Message-ID: In-Reply-To: <20061004163319.GG15633@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Proposal: include new "Language-Type:" field thread-index: Acbn1On41YeBFOeoTD6JAeZ0lDpRXAAM54rw References: <20061004134200.GC15633@ccil.org><30b660a20610040840l570c5a6cv852aaa6faf14cb94@mail.gmail.com> <20061004163319.GG15633@ccil.org> From: Peter Constable To: John Cowan , Mark Davis X-OriginalArrivalTime: 04 Oct 2006 23:04:11.0963 (UTC) FILETIME=[67C018B0:01C6E809] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The types and scopes grew out of Gary Simons and I analyzing the existing 639 set as we tried to sort out what was in/out of scope for 639-3 and how things in 639-1/-2 related to things in Ethnologue 14. Also, it was helpful for us in identifying which agency -- SIL or Linguist List -- was the primary source. It was clearly necessary to include scopes as they are used in normative ways, but we also thought it was useful to include the types as that seemed helpful for users in working out what the denotee is -- keep in mind that the only semantics provided by the standard itself are in these attributes: name, type, scope. Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: Wednesday, October 04, 2006 9:33 AM To: Mark Davis Cc: ltru@ietf.org Subject: Re: [Ltru] Proposal: include new "Language-Type:" field Mark Davis scripsit: > Most people will be picking among living languages, and this > classification only separates out 8% of those. Making a list of 7K > languages 8% smaller is not the key to an effective UI ;-). I agree. However, eliminating non-living languages from a listing of languages indigenous to the U.S. (according to Ethnologue) reduces the list from 238 to 162, a 32% reduction. Using the Ethnologue "nearly extinct" category allows a further reduction to only 92 languages, a full 62% reduction. Unfortunately, 639-3 does not use this type. Peter C, could you enlighten us on what the language type information in 639-3 is intended for? --=20 Ambassador Trentino: I've said enough. I'm a man of few words. Rufus T. Firefly: I'm a man of one word: scram! --Duck Soup John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 02:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhb-0006UL-8h; Thu, 05 Oct 2006 02:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhZ-0006U0-Bb for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVMhV-0007Pa-GH for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k956RH8P007777 for ; Thu, 5 Oct 2006 15:27:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7ea4_8c325d50_543a_11db_8453_0014221fa3c9; Thu, 05 Oct 2006 15:27:17 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39360) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Oct 2006 15:27:09 +0900 Message-Id: <6.0.0.20.2.20061003191809.023c9bd0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 19:20:50 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20061002214916.GE2278@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> <6.0.0.20.2.20061002174846.05f31630@localhost> <20061002125336.GC22365@ccil.org> <452159C3.1090802@yahoo-inc.com> <20061002214916.GE2278@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 06:49 06/10/03, John Cowan wrote: >Addison Phillips scripsit: > >> 1. I disagree that we should close off this issue. I think that >> consensus is not yet achieved. I think that a proper proposal for script >> information in the registry will likely crystallize a very different >> consensus than preserving Suppress-Script. > >Okay, propose something. [co-chair hat on] Yes, please. For the moment, better in an independent mail than directly in the draft. Given that this is in many ways a backwards- incompatible change, starting with a problem statement that refers to the language in the charter would be good. Regards, Martin. >And if it turns out to be an Accept-Script >scheme, it had better be able to survive my scathing criticisms! Or if >it turns out to be a Don't-Do-Anything scheme, you'd better figure out >a way to fend off the attacks of the IETF protocol weenies. > >-- >John Cowan http://ccil.org/~cowan cowan@ccil.org >Monday we watch-a Firefly's house, but he no come out. He wasn't home. >Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he >go to the ball game, and we fool him. We no show up. Thursday was a >double-header. Nobody show up. Friday it rained all day. There was no ball >game, so we stayed home and we listened to it on-a the radio. --Chicolini #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.From ltru-bounces@ietf.org Thu Oct 05 02:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhb-0006UL-8h; Thu, 05 Oct 2006 02:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhZ-0006U0-Bb for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVMhV-0007Pa-GH for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k956RH8P007777 for ; Thu, 5 Oct 2006 15:27:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7ea4_8c325d50_543a_11db_8453_0014221fa3c9; Thu, 05 Oct 2006 15:27:17 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39360) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Oct 2006 15:27:09 +0900 Message-Id: <6.0.0.20.2.20061003191809.023c9bd0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 19:20:50 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Suppress-script considered least harmful In-Reply-To: <20061002214916.GE2278@ccil.org> References: <031101c6e25f$b4d7f460$6401a8c0@DGBP7M81> <451ACCC5.6010609@yahoo-inc.com> <20060929213924.GG28837@ccil.org> <6.0.0.20.2.20060930180719.07033ec0@localhost> <20061002023958.GB22365@ccil.org> <6.0.0.20.2.20061002174846.05f31630@localhost> <20061002125336.GC22365@ccil.org> <452159C3.1090802@yahoo-inc.com> <20061002214916.GE2278@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 06:49 06/10/03, John Cowan wrote: >Addison Phillips scripsit: > >> 1. I disagree that we should close off this issue. I think that >> consensus is not yet achieved. I think that a proper proposal for script >> information in the registry will likely crystallize a very different >> consensus than preserving Suppress-Script. > >Okay, propose something. [co-chair hat on] Yes, please. For the moment, better in an independent mail than directly in the draft. Given that this is in many ways a backwards- incompatible change, starting with a problem statement that refers to the language in the charter would be good. Regards, Martin. >And if it turns out to be an Accept-Script >scheme, it had better be able to survive my scathing criticisms! Or if >it turns out to be a Don't-Do-Anything scheme, you'd better figure out >a way to fend off the attacks of the IETF protocol weenies. > >-- >John Cowan http://ccil.org/~cowan cowan@ccil.org >Monday we watch-a Firefly's house, but he no come out. He wasn't home. >Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he >go to the ball game, and we fool him. We no show up. Thursday was a >double-header. Nobody show up. Friday it rained all day. There was no ball >game, so we stayed home and we listened to it on-a the radio. --Chicolini #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 02:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhb-0006UP-Dk; Thu, 05 Oct 2006 02:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhZ-0006U5-DJ for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVMhV-0007Pc-GH for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k956RIjL007784 for ; Thu, 5 Oct 2006 15:27:18 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7e83_8cef041e_543a_11db_87c2_0014221fa3c9; Thu, 05 Oct 2006 15:27:18 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39360) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Oct 2006 15:27:10 +0900 Message-Id: <6.0.0.20.2.20061003192458.05f5bec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 19:31:53 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <008401c6e6bb$9d6877e0$6401a8c0@DGBP7M81> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> <452134F3.6010408@yahoo-inc.com> <6.0.0.20.2.20061003142608.08793850@localhost> <008401c6e6bb$9d6877e0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I see the following two solutions: a) Have registration discussions proceed, but put the actual updates on hold. b) Have updates proceed, but when 4645bis is approved, do a global replace and then redo the updates, more or less in bulk fashion (i.e. there is no material discussion anymore, just a check of field values to make sure the stuff fits with the new registry.) For a), the problem is that we have to tell ietf-languages and IANA before 4645bis is approved, which raises the question of what will happen in case it's not approved, and with what right we would stop updates. For b), the problem is that the registry is not progressing in a linear fashion, which is against our stability guarantees. I could immagine a variant of b), as follows: c) Updates proceed. Once 4645bis is approved, the ietf-languages list discusses how express the updates they have made since the last version of the 4645bis draft as an addition to that draft. This addition is then sent to IANA, which combines them with the draft before publication. Regards, Martin. At 16:14 06/10/03, Doug Ewell wrote: >Martin Duerst wrote: > >> But what I'm concerned about are not Registrations that are in process (e.g. submitted to ietf-languages but not approved yet, or sent over to IANA but not yet in the registry,...), but Registrjp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 02:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhb-0006UP-Dk; Thu, 05 Oct 2006 02:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMhZ-0006U5-DJ for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVMhV-0007Pc-GH for ltru@ietf.org; Thu, 05 Oct 2006 02:27:25 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k956RIjL007784 for ; Thu, 5 Oct 2006 15:27:18 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7e83_8cef041e_543a_11db_87c2_0014221fa3c9; Thu, 05 Oct 2006 15:27:18 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39360) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Oct 2006 15:27:10 +0900 Message-Id: <6.0.0.20.2.20061003192458.05f5bec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 19:31:53 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-4645bis-00 In-Reply-To: <008401c6e6bb$9d6877e0$6401a8c0@DGBP7M81> References: <00f901c6e399$643dc8f0$6401a8c0@DGBP7M81> <20060929193738.GD28837@ccil.org> <004f01c6e456$da197660$6401a8c0@DGBP7M81> <6.0.0.20.2.20060930164637.09942840@localhost> <452134F3.6010408@yahoo-inc.com> <6.0.0.20.2.20061003142608.08793850@localhost> <008401c6e6bb$9d6877e0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I see the following two solutions: a) Have registration discussions proceed, but put the actual updates on hold. b) Have updates proceed, but when 4645bis is approved, do a global replace and then redo the updates, more or less in bulk fashion (i.e. there is no material discussion anymore, just a check of field values to make sure the stuff fits with the new registry.) For a), the problem is that we have to tell ietf-languages and IANA before 4645bis is approved, which raises the question of what will happen in case it's not approved, and with what right we would stop updates. For b), the problem is that the registry is not progressing in a linear fashion, which is against our stability guarantees. I could immagine a variant of b), as follows: c) Updates proceed. Once 4645bis is approved, the ietf-languages list discusses how express the updates they have made since the last version of the 4645bis draft as an addition to that draft. This addition is then sent to IANA, which combines them with the draft before publication. Regards, Martin. At 16:14 06/10/03, Doug Ewell wrote: >Martin Duerst wrote: > >> But what I'm concerned about are not Registrations that are in process (e.g. submitted to ietf-languages but not approved yet, or sent over to IANA but not yet in the registry,...), but Registrations that have been completed and are in the Registry, but have not been considered for the latest draft of rfc4645bis. > >That is my concern as well. I have no solution except: > >1. ask IETF's and IESG's indulgence in allowing minor updates to the draft during LC to account for such changes > >2. ask ietf-languages' indulgence in imposing a brief moratorium on optional registrations during that time > >3. pray that the ISO MAs are on holiday during that time > >4. pray for a speedy trip through LC and the RFC Editor queue > >As you might guess, items 3 and 4 which require divine intervention have me the most concerned. > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://users.adelphia.net/~dewell/ >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ations that have been completed and are in the Registry, but have not been considered for the latest draft of rfc4645bis. > >That is my concern as well. I have no solution except: > >1. ask IETF's and IESG's indulgence in allowing minor updates to the draft during LC to account for such changes > >2. ask ietf-languages' indulgence in imposing a brief moratorium on optional registrations during that time > >3. pray that the ISO MAs are on holiday during that time > >4. pray for a speedy trip through LC and the RFC Editor queue > >As you might guess, items 3 and 4 which require divine intervention have me the most concerned. > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://users.adelphia.net/~dewell/ >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 02:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMl6-000058-IN; Thu, 05 Oct 2006 02:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVMl5-000053-A6 for ltru@ietf.org; Thu, 05 Oct 2006 02:31:03 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVMl3-0007kV-WF for ltru@ietf.org; Thu, 05 Oct 2006 02:31:03 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061005063057.URSL8494.mta9.adelphia.net@DGBP7M81> for ; Thu, 5 Oct 2006 02:30:57 -0400 Message-ID: <004301c6e847$d0e3f440$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 4 Oct 2006 23:30:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > The 4646bis registry should capture the language type information from > ISO 639-3. Each language, including macrolanguages, is labeled in -3 > as either living, extinct, ancient, historic, or constructed. These > terms are defined precisely at http://www.sil.org/iso639-3/types.asp . > Though informative rather than normative, this is very useful to help > shrink the large number of languages to a more manageable size. I support this proposal of John's. I don't agree that it makes the Registry into a "kitchen sink" compendium of irrelevant information -- it is directly related to tagging. We have text in Section 4.1 of 4646bis that tells users not to use "subtags for language collections," but those are not clearly defined anywhere except by reference to ISO 639 (and by a rather puzzling passage involving "xxx" and "yyy", which I guess are space-fillers). One of the major reasons for having a Registry was so users would not have to go back to the ISO standards to find out what to use and what not to use. Likewise, instead of having separate notes about (not) using "und" and "mul", it might make sense to include a broad usage note about type "special" and then list the specific cases. Note that by hard-coding "und" and "mul" into 4646 and 4646bis, we have missed talking about "zxx", which should have similar usage constraints. Trying to correlate languages to countries or group them into families (beyond what the core standard provides) would be examples of adding information that isn't needed for tagging. It would be easy to add these Language-Type fields to the 4645bis Registry based on the 639-3 data -- not to say that should be a determining factor in whether we do it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 04:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOiU-0008TC-Ed; Thu, 05 Oct 2006 04:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVOiT-0008Ia-PJ for ltru@ietf.org; Thu, 05 Oct 2006 04:36:29 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVOgn-00056U-Nt for ltru@ietf.org; Thu, 05 Oct 2006 04:34:49 -0400 Received: from chalmers95a69n (83.248.26.72) by pne-smtpout1-sn1.fre.skanova.net (7.2.076) id 4523CB570002F326 for ltru@ietf.org; Thu, 5 Oct 2006 10:34:44 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Thu, 5 Oct 2006 10:31:09 +0200 Message-ID: <000801c6e858$9bc9af50$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <004301c6e847$d0e3f440$6401a8c0@DGBP7M81> Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1. In addition I would prefer to have "Deprecated: ..." for those of type "Collection", on the grounds that they are "Collection"s, and indeed the "(Other)" portion in many (most) of them does not make sense in relation to 639-3. /kent k > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Thursday, October 05, 2006 8:31 AM > To: LTRU Working Group > Subject: [Ltru] Re: Proposal: include new "Language-Type:" field > > > John Cowan wrote: > > > The 4646bis registry should capture the language type > information from > > ISO 639-3. Each language, including macrolanguages, is > labeled in -3 > > as either living, extinct, ancient, historic, or > constructed. These > > terms are defined precisely at > http://www.sil.org/iso639-3/types.asp . > > Though informative rather than normative, this is very > useful to help > > shrink the large number of languages to a more manageable size. > > I support this proposal of John's. I don't agree that it makes the > Registry into a "kitchen sink" compendium of irrelevant > information -- > it is directly related to tagging. > > We have text in Section 4.1 of 4646bis that tells users not to use > "subtags for language collections," but those are not clearly defined > anywhere except by reference to ISO 639 (and by a rather puzzling > passage involving "xxx" and "yyy", which I guess are space-fillers). > One of the major reasons for having a Registry was so users would not > have to go back to the ISO standards to find out what to use and what > not to use. > > Likewise, instead of having separate notes about (not) using > "und" and > "mul", it might make sense to include a broad usage note about type > "special" and then list the specific cases. Note that by hard-coding > "und" and "mul" into 4646 and 4646bis, we have missed talking about > "zxx", which should have similar usage constraints. > > Trying to correlate languages to countries or group them into > families > (beyond what the core standard provides) would be examples of adding > information that isn't needed for tagging. > > It would be easy to add these Language-Type fields to the 4645bis > Registry based on the 639-3 data -- not to say that should be a > determining factor in whether we do it. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 05:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPHm-0002n4-1j; Thu, 05 Oct 2006 05:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPHk-0002mz-EC for ltru@ietf.org; Thu, 05 Oct 2006 05:12:56 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVPHj-0004tq-28 for ltru@ietf.org; Thu, 05 Oct 2006 05:12:56 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004866327.msg for ; Thu, 05 Oct 2006 10:14:50 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 05 Oct 2006 10:12:58 +0100 From: "Debbie Garside" To: Subject: RE: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Thu, 5 Oct 2006 10:12:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcboSBXwceAmsWloTnyOUp3WVwlGmQAFj98g In-Reply-To: <004301c6e847$d0e3f440$6401a8c0@DGBP7M81> Message-ID: <4CB5D901212D4EA6AC14672C4FA76335.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 05 Oct 2006 10:14:50 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 05 Oct 2006 10:14:52 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 05 October 2006 07:31 > To: LTRU Working Group > Subject: [Ltru] Re: Proposal: include new "Language-Type:" field > > John Cowan wrote: > > > The 4646bis registry should capture the language type > information from > > ISO 639-3. Each language, including macrolanguages, is > labeled in -3 > > as either living, extinct, ancient, historic, or > constructed. These > > terms are defined precisely at > http://www.sil.org/iso639-3/types.asp . > > Though informative rather than normative, this is very > useful to help > > shrink the large number of languages to a more manageable size. > > I support this proposal of John's. I don't agree that it > makes the Registry into a "kitchen sink" compendium of > irrelevant information -- it is directly related to tagging. > > We have text in Section 4.1 of 4646bis that tells users not > to use "subtags for language collections," but those are not > clearly defined anywhere except by reference to ISO 639 (and > by a rather puzzling passage involving "xxx" and "yyy", which > I guess are space-fillers). > One of the major reasons for having a Registry was so users > would not have to go back to the ISO standards to find out > what to use and what not to use. > > Likewise, instead of having separate notes about (not) using > "und" and "mul", it might make sense to include a broad usage > note about type "special" and then list the specific cases. > Note that by hard-coding "und" and "mul" into 4646 and > 4646bis, we have missed talking about "zxx", which should > have similar usage constraints. > > Trying to correlate languages to countries or group them into > families (beyond what the core standard provides) would be > examples of adding information that isn't needed for tagging. > > It would be easy to add these Language-Type fields to the > 4645bis Registry based on the 639-3 data -- not to say that > should be a determining factor in whether we do it. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 09:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSpZ-0001Cz-4Y; Thu, 05 Oct 2006 09:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSpX-0001CE-Dv for ltru@ietf.org; Thu, 05 Oct 2006 09:00:03 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSpV-0001gS-66 for ltru@ietf.org; Thu, 05 Oct 2006 09:00:03 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GVSpU-0002cf-0T; Thu, 05 Oct 2006 09:00:00 -0400 Date: Thu, 5 Oct 2006 08:59:59 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field Message-ID: <20061005125959.GA8062@ccil.org> References: <004301c6e847$d0e3f440$6401a8c0@DGBP7M81> <000801c6e858$9bc9af50$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c6e858$9bc9af50$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > In addition I would prefer to have "Deprecated: ..." for those of type > "Collection", on the grounds that they are "Collection"s, and indeed > the "(Other)" portion in many (most) of them does not make sense in > relation to 639-3. I thought about deprecating them, but if they are to be deprecated, it is in a sense quite different from the deprecation of 'CS' or 'he'. It's not that they are obsolete or nonsensical, but that they are vague. However, sometimes vagueness can't be avoided. The 639-2 codes came out of library practice, and sometimes the only thing you know about a document is that it's in some North American Indian language or other -- your records aren't complete. On the whole, then, I would rather label them as collections directly, and then say that using collection subtags is discouraged unless no better information is available. As for "(Other)", I hope to see its demise; it only makes sense on the assumption that 639-2 is a closed collection, which it has not been up to now. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 09:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTkG-0000q5-5Z; Thu, 05 Oct 2006 09:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTkE-0000q0-Vw for ltru@lists.ietf.org; Thu, 05 Oct 2006 09:58:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVTkB-0005C3-IW for ltru@lists.ietf.org; Thu, 05 Oct 2006 09:58:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVTjK-0002ex-EQ for ltru@lists.ietf.org; Thu, 05 Oct 2006 15:57:42 +0200 Received: from pd9fba984.dip0.t-ipconnect.de ([217.251.169.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 15:57:42 +0200 Received: from nobody by pd9fba984.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 15:57:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 05 Oct 2006 15:11:02 +0200 Organization: Lines: 42 Message-ID: <45250466.379@freenet.de> References: <002f01c6e77a$a6f68d00$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba984.dip0.t-ipconnect.de X-Mailer: Mozilla 2.02 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Ltru] Re: Consensus X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > So far two members have agreed with my proposal to get rid of the > vacuous "replaced by ISO code xxx" comments in the RFC 4646bis Registry. Two = John and Mark. Add me, these comments aren't very interesting, and in the cases where grandfathered or redundant tags were replaced by extlangs as in... %% Type: redundant Tag: sgn-ZA Description: South African Sign Language Added: 2001-11-11 Preferred-Value: sgn-sfs Deprecated: 2007-01-01 Comments: replaced by ISO code sfs %% ...it's almost confusing, because sgn-ZA was replaced by sgn-sfs, not only sfs. > While two is hardly a majority of the WG membership, it makes me > wonder what mechanism is going to be used to gauge consensus. My personal view: We're not "voting" unless a Co-chair decides that a poll or "hum" is a good idea. If you propose something, and all you get is one or more "+1" and no objection, then it's apparently fine for "us". Or they say later that they don't like it. In other words just do it, it's only a draft, we can discuss and change it if we don't like the outcome. Apparently "we" (= some including you) don't like these redundant comments, get rid of them. > I really don't know if issues like this are even being recorded. Just record it in a document history appendix, to be removed in the final RFC. We're not obliged to bother Martin or Randy with _all_ non-controversial nits. You owe me two cents... :-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 12:18:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVv7-0001ax-Pd; Thu, 05 Oct 2006 12:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVv6-0001ag-32 for ltru@lists.ietf.org; Thu, 05 Oct 2006 12:18:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVv3-0000XX-On for ltru@lists.ietf.org; Thu, 05 Oct 2006 12:18:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVVo7-0000vJ-4Z for ltru@lists.ietf.org; Thu, 05 Oct 2006 18:10:48 +0200 Received: from pd9fba984.dip0.t-ipconnect.de ([217.251.169.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 18:10:47 +0200 Received: from nobody by pd9fba984.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 18:10:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 05 Oct 2006 18:07:31 +0200 Organization: Lines: 12 Message-ID: <45252DC3.4F78@xyzzy.claranet.de> References: <20061002155616.GF22365@ccil.org> <452157EB.5030203@yahoo-inc.com> <6.0.0.20.2.20061003144145.08795ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba984.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Minor error in 4646 Appendix A X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I seem to remember that I mentioned this point in one of > my reviews. But maybe that was for RFC 4647? It was in . I found it with the GMaNe search form, third hit with http://search.gmane.org/?query=Subtag+reviewer&author=Martin+Duerst&group=gmane.ietf.ltru&sort=date Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 12:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWXq-0007B2-Oz; Thu, 05 Oct 2006 12:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWXn-00077t-Ur for ltru@ietf.org; Thu, 05 Oct 2006 12:57:59 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWXO-00085T-74 for ltru@ietf.org; Thu, 05 Oct 2006 12:57:59 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.647.8; Thu, 5 Oct 2006 09:57:34 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Thu, 5 Oct 2006 09:57:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Thu, 5 Oct 2006 09:57:07 -0700 Message-ID: In-Reply-To: <20061005125959.GA8062@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Proposal: include new "Language-Type:" field thread-index: AcbofjYQD584dEnhR5uIzCvgesoyIAAIPQJA References: <004301c6e847$d0e3f440$6401a8c0@DGBP7M81><000801c6e858$9bc9af50$6500a8c0@chalmers95a69n> <20061005125959.GA8062@ccil.org> From: Peter Constable To: John Cowan , Kent Karlsson X-OriginalArrivalTime: 05 Oct 2006 16:57:32.0765 (UTC) FILETIME=[599EA0D0:01C6E89F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have proposed to the JAC that we remove "(other)" from any collections that have them. That is an open issue pending JAC discussion. Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: Thursday, October 05, 2006 6:00 AM To: Kent Karlsson Cc: 'LTRU Working Group' Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field Kent Karlsson scripsit: > In addition I would prefer to have "Deprecated: ..." for those of type > "Collection", on the grounds that they are "Collection"s, and indeed > the "(Other)" portion in many (most) of them does not make sense in > relation to 639-3. I thought about deprecating them, but if they are to be deprecated, it is in a sense quite different from the deprecation of 'CS' or 'he'. It's not that they are obsolete or nonsensical, but that they are vague. However, sometimes vagueness can't be avoided. The 639-2 codes came out of library practice, and sometimes the only thing you know about a document is that it's in some North American Indian language or other -- your records aren't complete. On the whole, then, I would rather label them as collections directly, and then say that using collection subtags is discouraged unless no better information is available. As for "(Other)", I hope to see its demise; it only makes sense on the assumption that 639-2 is a closed collection, which it has not been up to now. --=20 John Cowan cowan@ccil.org http://ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 13:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXId-0003XT-MZ; Thu, 05 Oct 2006 13:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXHn-00039q-AF for ltru@lists.ietf.org; Thu, 05 Oct 2006 13:45:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXBq-0001tg-7o for ltru@lists.ietf.org; Thu, 05 Oct 2006 13:39:23 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVX9k-0002Fx-5L for ltru@lists.ietf.org; Thu, 05 Oct 2006 19:37:12 +0200 Received: from pd9fba984.dip0.t-ipconnect.de ([217.251.169.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 19:37:12 +0200 Received: from nobody by pd9fba984.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 19:37:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 05 Oct 2006 19:31:01 +0200 Organization: Lines: 25 Message-ID: <45254155.7EBE@xyzzy.claranet.de> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <4520FFAA.AFD@xyzzy.claranet.de> <6.0.0.20.2.20061003145000.089125c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba984.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] OT: XML converter (was: Registry deltas) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > (preferred?, deprecated)? Thanks, much better. > Separators are in general a bad idea. Indeed, but if that's working for Debbie's application it's okay. It's possible to implement it as option in the script, either output or with a corresponding DTD. The day before yestderday I could test the behaviour with MS Excel, apparently that works - I've no clue how to get rid of some bogus columns, but Excel users should know how that's supposed to work. > What about multiple description elements doesn't work? I can't tell, Debbie is experimenting with XML imports into a database. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 14:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXfC-0007jC-Ei; Thu, 05 Oct 2006 14:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXfA-0007j6-VO for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:09:40 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXf9-00019U-Me for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:09:40 -0400 Received: from chalmers95a69n (83.248.26.72) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 451BA3C7001DBC2B for ltru@lists.ietf.org; Thu, 5 Oct 2006 20:09:38 +0200 From: "Kent Karlsson" To: Subject: RE: [Ltru] Re: Consensus Date: Thu, 5 Oct 2006 20:06:00 +0200 Message-ID: <000601c6e8a8$ea720ad0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <45250466.379@freenet.de> Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 > > So far two members have agreed with my proposal to get rid of the > > vacuous "replaced by ISO code xxx" comments in the RFC > 4646bis Registry. > > Two = John and Mark. Add me, these comments aren't very interesting, > and in the cases where grandfathered or redundant tags were replaced > by extlangs as in... > > %% > Type: redundant > Tag: sgn-ZA > Description: South African Sign Language > Added: 2001-11-11 > Preferred-Value: sgn-sfs > Deprecated: 2007-01-01 > Comments: replaced by ISO code sfs > %% > > ...it's almost confusing, because sgn-ZA was replaced by sgn-sfs, not > only sfs. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 14:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXsL-00071y-JL; Thu, 05 Oct 2006 14:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXsL-00071q-0p for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:23:17 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXsJ-000692-IJ for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:23:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVXqb-0007g4-Bt for ltru@lists.ietf.org; Thu, 05 Oct 2006 20:21:29 +0200 Received: from pd9fba984.dip0.t-ipconnect.de ([217.251.169.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 20:21:29 +0200 Received: from nobody by pd9fba984.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 20:21:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 05 Oct 2006 20:07:20 +0200 Organization: Lines: 73 Message-ID: <452549D8.683@xyzzy.claranet.de> References: <007201c6e6b8$83adbc50$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba984.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [Ltru] Preferred-Value cycles (was: Registry deltas) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: >> Okay, my first impression is "nothing special or unexpected" - >> there's no A -> C shortcut for A -> B -> C yet, because that's >> not yet in the rules (4646bis), correct ? > "Yet" is an understatement. There is no consensus for making this > destabilizing change. The version without shortcuts is worse, applications are forced to follow Preferred-Value chains until they (hopefully) arrive at a tag or subtag without Preferred-Value. Or if the registry is in a dubious state with cycles they have to implement their own sanity check. Of course we don't expect that the registry is ever in a dubious state, we have "registry validators" for this purpose. But then it's again simpler to verify that Preferred-Value always arrives at a tag or subtag that has no further Preferred-Value. Last but not least it would eliminate the "hakka" reference in a Preferred-Value, where "hakka" is the only "non-subtag" in any reference. > there is no "collision" between 5- to 8-letter language subtags > (if any existed) and 5- to 8-letter variant subtags, any more > than there is a collision between "ar" for Arabic and "AR" for > Argentina. Of course there is for naive implementations, the theory of the 4646 structure is that you can decompose a tag into subtags, and still tell what's what based alone on its length. 3 digits => UN number 3 alpha => language (for 4646) 4 alpha at begin => language (reserved) 4 alpha later => script 4 alnum starting with a digit => variant 2 alpha at begin => language 2 alpha later => region 5..8 alpha at begin => language 5..8 alnum later => variant For that a 4646 decomposer only needs to note "at begin" for the disambiguation of 2 alpha or 4..8 alpha. For 4646bis it's in essence the same idea adding: 3 alpha at begin => language (for 4646bis) 3 alpha later => extlang In my old 4646 validator I've implemented this by adding a dummy hyphen for anything that's not "at begin", and after that it was as you said obvious that "AR" (case insensitive) is not "-AR". For 4646bis that isn't good enough anymore, because language and extlang share the same namespace, as soon as there is a language "ang" there can't be an extlang "-ang". Therefore I took the canonical case without adding a dummy hyphen. With that I'd catch an erroneous extlang "ang", and case-sensitive "ar" and "AR" are different. That's of course how I found the old yi-latn instead of yi-Latn. But that's not yet enough for a registered language "abcde" and a registered variant "abcde", I've to implement some logic for the variants (and references to variants). With a registry validator anybody including IANA can check that a registry is in a plausible state. Or verify that a proper subset is complete (all references resolved). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 14:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXyd-0001qU-OK; Thu, 05 Oct 2006 14:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXyc-0001qO-Rl for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:29:46 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXya-0007tg-Fd for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:29:46 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k95ITXKP078769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Oct 2006 11:29:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=h3+fXJd7vvIjWB0h62t7z67cLgaGWWf7RzTrXKFSvQkOKsHcUg8o1lt3/lMPR5aN Message-ID: <45254F0D.1050909@yahoo-inc.com> Date: Thu, 05 Oct 2006 11:29:33 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kent Karlsson Subject: [Ltru] fixing "replaced by" comments ( was Consensus) References: <000601c6e8a8$ea720ad0$6500a8c0@chalmers95a69n> In-Reply-To: <000601c6e8a8$ea720ad0$6500a8c0@chalmers95a69n> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Kent Karlsson wrote: > +1 > >>> So far two members have agreed with my proposal to get rid of the >>> vacuous "replaced by ISO code xxx" comments in the RFC >> 4646bis Registry. >> >> Two = John and Mark. Add me, these comments aren't very interesting, >> and in the cases where grandfathered or redundant tags were replaced >> by extlangs as in... >> >> %% >> Type: redundant >> Tag: sgn-ZA >> Description: South African Sign Language >> Added: 2001-11-11 >> Preferred-Value: sgn-sfs >> Deprecated: 2007-01-01 >> Comments: replaced by ISO code sfs >> %% >> >> ...it's almost confusing, because sgn-ZA was replaced by sgn-sfs, not >> only sfs. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 14:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVY4B-0004tB-3q; Thu, 05 Oct 2006 14:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVY49-0004t6-QN for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:35:29 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVY48-0002TH-CA for ltru@lists.ietf.org; Thu, 05 Oct 2006 14:35:29 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k95IZQbP079123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Oct 2006 11:35:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=MKAhPJhxmrdgjY/hSjcRHdee4c2Ck8NL01ksLuQrs0zGAfVChnZ7fIJTelKWkn+m Message-ID: <4525506D.4050400@yahoo-inc.com> Date: Thu, 05 Oct 2006 11:35:25 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Preferred-Value cycles References: <007201c6e6b8$83adbc50$6401a8c0@DGBP7M81> <452549D8.683@xyzzy.claranet.de> In-Reply-To: <452549D8.683@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 generally Frank Ellermann wrote: > Doug Ewell wrote: > >>> Okay, my first impression is "nothing special or unexpected" - >>> there's no A -> C shortcut for A -> B -> C yet, because that's >>> not yet in the rules (4646bis), correct ? > >> "Yet" is an understatement. There is no consensus for making this >> destabilizing change. > > The version without shortcuts is worse, applications are forced to > follow Preferred-Value chains until they (hopefully) arrive at a > tag or subtag without Preferred-Value. Or if the registry is in a > dubious state with cycles they have to implement their own sanity > check. I think it a useful policy to administer the registry such that A -> C is always the case rather than A -> B -> C. But forbidding it might not make sense in some cases. In particular, maintaining "stale" pointers allows implementations to see the progression of mappings. This allows a registry processor to reconstruct (within some limits) the state of the registry at various intervening dates. That is: on Date A: xx-AA is the canonical tag on Date B: xx-BB is the canonical tag on Date C: xx-CC is the canonical tag Addison > > Of course we don't expect that the registry is ever in a dubious > state, we have "registry validators" for this purpose. But then > it's again simpler to verify that Preferred-Value always arrives > at a tag or subtag that has no further Preferred-Value. > > Last but not least it would eliminate the "hakka" reference in a > Preferred-Value, where "hakka" is the only "non-subtag" in any > reference. > >> there is no "collision" between 5- to 8-letter language subtags >> (if any existed) and 5- to 8-letter variant subtags, any more >> than there is a collision between "ar" for Arabic and "AR" for >> Argentina. > > Of course there is for naive implementations, the theory of the > 4646 structure is that you can decompose a tag into subtags, and > still tell what's what based alone on its length. > > 3 digits => UN number > 3 alpha => language (for 4646) > 4 alpha at begin => language (reserved) > 4 alpha later => script > 4 alnum starting with a digit => variant > 2 alpha at begin => language > 2 alpha later => region > 5..8 alpha at begin => language > 5..8 alnum later => variant > > For that a 4646 decomposer only needs to note "at begin" for the > disambiguation of 2 alpha or 4..8 alpha. For 4646bis it's in > essence the same idea adding: > > 3 alpha at begin => language (for 4646bis) > 3 alpha later => extlang > > In my old 4646 validator I've implemented this by adding a dummy > hyphen for anything that's not "at begin", and after that it was > as you said obvious that "AR" (case insensitive) is not "-AR". > > For 4646bis that isn't good enough anymore, because language and > extlang share the same namespace, as soon as there is a language > "ang" there can't be an extlang "-ang". > > Therefore I took the canonical case without adding a dummy hyphen. > With that I'd catch an erroneous extlang "ang", and case-sensitive > "ar" and "AR" are different. That's of course how I found the > old yi-latn instead of yi-Latn. > > But that's not yet enough for a registered language "abcde" and a > registered variant "abcde", I've to implement some logic for the > variants (and references to variants). > > With a registry validator anybody including IANA can check that a > registry is in a plausible state. Or verify that a proper subset > is complete (all references resolved). > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 14:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYQ8-0008GU-6f; Thu, 05 Oct 2006 14:58:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYQ7-0008GI-28 for ltru@ietf.org; Thu, 05 Oct 2006 14:58:11 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYQ5-00006m-F2 for ltru@ietf.org; Thu, 05 Oct 2006 14:58:11 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k95Iw29O080151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Oct 2006 11:58:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=q8+Ot1AyXMwGAsqmFxpojVfsxPkvpKDnWd0A0haSgTHEZ2aPpUWy/pP5UjE5VRVV Message-ID: <452555BA.2040601@yahoo-inc.com> Date: Thu, 05 Oct 2006 11:58:02 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Ltru] Great Script Debate "the Next Generation"... (long) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, Taking up the gauntlet flung down by John Cowan :-), herewith my proposal for fixing Suppress-Scripts ---- First, some recap of the problem. Suppress-Scripts are meant to identify languages that are written predominantly in a single script. This is to warn users and implementers not to form language tags using a script subtag that is usually redundant, for compatibility with tagging practices prior to RFC 4646. S-S poses a number of interesting problems. I've cited previously the registration problems. Mainly the problem here is that most languages fit the pattern of "wanting" some form of S-S field. Even languages that might not have a clear relationship to a specific script subtag (cf. Doug's research on Korean) probably should not use a script subtag. In particular, creating accurate values for even the ISO 639-1 and ISO 639-2 set of languages would require significant knowledge about the current and recent historical writing traditions of each given language, plus, possibly, some knowledge of public policy and/or potential suppression or abuse of minority tradition in regard to that language. S-S indicates that a given language is written predominantly in a specific script, so the burden of proof for a less common language might be very difficult to achieve, since the presence of many texts in a specific script does not "prove the negative", that is, that a significant body of texts or a specific writing tradition does not exist that uses a separate script. The main alternative we've dealt with in the past would be an "Accept-Script" or "Recommend-Script" approach. That design, which was not adopted in RFC 4646, involves documenting the known cases in which a script subtag *should* be used, and, in effect, recommending that languages that do not have an "A-S" field not use a script subtag except when indicating a specific difference important within a given group of information items. A-S avoids the "proving the negative" problem of S-S. Since it applies to a much smaller set of languages, it probably requires less registration overhead. The burden of proof may be just as difficult to achieve and is encumbered with essentially the same problems that attend S-S, since assertions about multiple script usage are just as potentially disruptive as assertions about the "single scriptness" of a language. Removing script information from the registry altogether is appealing as an alternative. As Mark points out, script subtags are entirely voluntary and entirely valid. The informational nature of the S-S field is merely to help guide implementers and users to try and do the right things. If maintenance is a nightmare, why persist in maintaining somewhat fictional information? I do think that guidance for users/implementers is a valid goal here. My experience as an "eminence grise" for language tags over the past couple of years is that the level of ill-informedness and mythology surrounding language tags is pretty deep. Anything we can do to help speed proper implementation of language tags will help. The problem here is that I think we're miscasting the role of the script advisory field or fields in the registry. If we only document the "do not use" case, users and implementers will remain ignorant of what to do for languages without the S-S field. Having explained the Chinese issue several times, it's clear to me that many implementers will not stumble over the right subtags by accident... and certainly not for languages such as Serbian, Uzbek, or Azerbaijani. If we only document the "do use" cases, though, users and implementers may not notice the warnings against use of scripts elsewhere. Leading to the problem we initially sought to prevent. Thus, my proposal for solving the problem: 1. Include the strongest possible warnings about not using script subtags in 4646bis. This is probably embodied in Karen Broome's suggested texts. 2. Replace "Suppress-Script" with "Script". If no script field is supplied, language tags/ranges should still not use a script subtag unless one is warranted by the information item or request. If the script field is present and contains a single item, the language is known to use that script predominantly. If two or more items are present, the language is commonly written in more than one script. Users are advised *not* to use a script subtag unless the language has more than one item in the Script field. Potential issues: 1. zero or one script subtag have the same behavior. Acquiring a second script, however, requires extra scrutiny by ietf-languages because it changes the potential default behavior for tag formation for that language. Reactions? -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 05 16:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZgW-0004ER-Vt; Thu, 05 Oct 2006 16:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZgV-0004EB-Nr for ltru@ietf.org; Thu, 05 Oct 2006 16:19:11 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZgV-0006nq-2i for ltru@ietf.org; Thu, 05 Oct 2006 16:19:11 -0400 Received: by wx-out-0506.google.com with SMTP id t4so662229wxc for ; Thu, 05 Oct 2006 13:19:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=EC+dpqbyn5vsRPP2gjIHaHgHVj3gSF+OvKyZF+c4BYaTFIuulmgIVTQSWAC9+b/AfGffieEL9hNDVAFQkLo1zK0b3A2RhUwdREvPsM86LlgJg+HK0LIGBtMacjCMcAufrHfDI/X4MAEnXBoOXIc/q2MANIbJ8oINGq/XUq3Am2o= Received: by 10.90.105.20 with SMTP id d20mr1274825agc; Thu, 05 Oct 2006 13:19:09 -0700 (PDT) Received: by 10.90.32.3 with HTTP; Thu, 5 Oct 2006 13:19:09 -0700 (PDT) Message-ID: <30b660a20610051319n73670394l4a269d8d50e813b5@mail.gmail.com> Date: Thu, 5 Oct 2006 13:19:09 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Great Script Debate "the Next Generation"... (long) In-Reply-To: <452555BA.2040601@yahoo-inc.com> MIME-Version: 1.0 References: <452555BA.2040601@yahoo-inc.com> X-Google-Sender-Auth: a1b89c1eb6464ecd X-Spam-Score: 0.3 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0832492858==" Errors-To: ltru-bounces@ietf.org --===============0832492858== Content-Type: multipart/alternative; boundary="----=_Part_23131_19160012.1160079549498" ------=_Part_23131_19160012.1160079549498 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I am in favor of this approach; it would be much more useful, and more maintainable. I would add that it would be useful information to say that the order of the scripts is a rough indication of the volume of text in the language in that script. Mark On 10/5/06, Addison Phillips wrote: > > All, > > Taking up the gauntlet flung down by John Cowan :-), herewith my > proposal for fixing Suppress-Scripts > > ---- > First, some recap of the problem. Suppress-Scripts are meant to identify > languages that are written predominantly in a single script. This is to > warn users and implementers not to form language tags using a script > subtag that is usually redundant, for compatibility with tagging > practices prior to RFC 4646. > > S-S poses a number of interesting problems. > > I've cited previously the registration problems. Mainly the problem here > is that most languages fit the pattern of "wanting" some form of S-S > field. Even languages that might not have a clear relationship to a > specific script subtag (cf. Doug's research on Korean) probably should > not use a script subtag. > > In particular, creating accurate values for even the ISO 639-1 and ISO > 639-2 set of languages would require significant knowledge about the > current and recent historical writing traditions of each given language, > plus, possibly, some knowledge of public policy and/or potential > suppression or abuse of minority tradition in regard to that language. > > S-S indicates that a given language is written predominantly in a > specific script, so the burden of proof for a less common language might > be very difficult to achieve, since the presence of many texts in a > specific script does not "prove the negative", that is, that a > significant body of texts or a specific writing tradition does not exist > that uses a separate script. > > The main alternative we've dealt with in the past would be an > "Accept-Script" or "Recommend-Script" approach. That design, which was > not adopted in RFC 4646, involves documenting the known cases in which a > script subtag *should* be used, and, in effect, recommending that > languages that do not have an "A-S" field not use a script subtag except > when indicating a specific difference important within a given group of > information items. > > A-S avoids the "proving the negative" problem of S-S. Since it applies > to a much smaller set of languages, it probably requires less > registration overhead. The burden of proof may be just as difficult to > achieve and is encumbered with essentially the same problems that attend > S-S, since assertions about multiple script usage are just as > potentially disruptive as assertions about the "single scriptness" of a > language. > > Removing script information from the registry altogether is appealing as > an alternative. As Mark points out, script subtags are entirely > voluntary and entirely valid. The informational nature of the S-S field > is merely to help guide implementers and users to try and do the right > things. If maintenance is a nightmare, why persist in maintaining > somewhat fictional information? > > I do think that guidance for users/implementers is a valid goal here. My > experience as an "eminence grise" for language tags over the past couple > of years is that the level of ill-informedness and mythology surrounding > language tags is pretty deep. Anything we can do to help speed proper > implementation of language tags will help. > > The problem here is that I think we're miscasting the role of the script > advisory field or fields in the registry. If we only document the "do > not use" case, users and implementers will remain ignorant of what to do > for languages without the S-S field. Having explained the Chinese issue > several times, it's clear to me that many implementers will not stumble > over the right subtags by accident... and certainly not for languages > such as Serbian, Uzbek, or Azerbaijani. > > If we only document the "do use" cases, though, users and implementers > may not notice the warnings against use of scripts elsewhere. Leading to > the problem we initially sought to prevent. > > Thus, my proposal for solving the problem: > > 1. Include the strongest possible warnings about not using script > subtags in 4646bis. This is probably embodied in Karen Broome's > suggested texts. > > 2. Replace "Suppress-Script" with "Script". If no script field is > supplied, language tags/ranges should still not use a script subtag > unless one is warranted by the information item or request. If the > script field is present and contains a single item, the language is > known to use that script predominantly. If two or more items are > present, the language is commonly written in more than one script. Users > are advised *not* to use a script subtag unless the language has more > than one item in the Script field. > > Potential issues: > > 1. zero or one script subtag have the same behavior. Acquiring a second > script, however, requires extra scrutiny by ietf-languages because it > changes the potential default behavior for tag formation for that > language. > > > Reactions? > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_23131_19160012.1160079549498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am in favor of this approach; it would be much more useful, and more maintainable. I would add that it would be useful information to say that the order of the scripts is a rough indication of the volume of text in the language in that script.

Mark

On 10/5/06, Addison Phillips <addison@yahoo-inc.com> wrote:
All,

Taking up the gauntlet flung down by John Cowan :-), herewith my
proposal for fixing Suppress-Scripts

----
First, some recap of the problem. Suppress-Scripts are meant to identify
languages that are written predominantly in a single script. This is to
warn users and implementers not to form language tags using a script
subtag that is usually redundant, for compatibility with tagging
practices prior to RFC 4646.

S-S poses a number of interesting problems.

I've cited previously the registration problems. Mainly the problem here
is that most languages fit the pattern of "wanting" some form of S-S
field. Even languages that might not have a clear relationship to a
specific script subtag (cf. Doug's research on Korean) probably should
not use a script subtag.

In particular, creating accurate values for even the ISO 639-1 and ISO
639-2 set of languages would require significant knowledge about the
current and recent historical writing traditions of each given language,
plus, possibly, some knowledge of public policy and/or potential
suppression or abuse of minority tradition in regard to that language.

S-S indicates that a given language is written predominantly in a
specific script, so the burden of proof for a less common language might
be very difficult to achieve, since the presence of many texts in a
specific script does not "prove the negative", that is, that a
significant body of texts or a specific writing tradition does not exist
that uses a separate script.

The main alternative we've dealt with in the past would be an
"Accept-Script" or "Recommend-Script" approach. That design, which was
not adopted in RFC 4646, involves documenting the known cases in which a
script subtag *should* be used, and, in effect, recommending that
languages that do not have an "A-S" field not use a script subtag except
when indicating a specific difference important within a given group of
information items.

A-S avoids the "proving the negative" problem of S-S. Since it applies
to a much smaller set of languages, it probably requires less
registration overhead. The burden of proof may be just as difficult to
achieve and is encumbered with essentially the same problems that attend
S-S, since assertions about multiple script usage are just as
potentially disruptive as assertions about the "single scriptness" of a
language.

Removing script information from the registry altogether is appealing as
an alternative. As Mark points out, script subtags are entirely
voluntary and entirely valid. The informational nature of the S-S field
is merely to help guide implementers and users to try and do the right
things. If maintenance is a nightmare, why persist in maintaining
somewhat fictional information?

I do think that guidance for users/implementers is a valid goal here. My
experience as an "eminence grise" for language tags over the past couple
of years is that the level of ill-informedness and mythology surrounding
language tags is pretty deep. Anything we can do to help speed proper
implementation of language tags will help.

The problem here is that I think we're miscasting the role of the script
advisory field or fields in the registry. If we only document the "do
not use" case, users and implementers will remain ignorant of what to do
for languages without the S-S field. Having explained the Chinese issue
several times, it's clear to me that many implementers will not stumble
over the right subtags by accident... and certainly not for languages
such as Serbian, Uzbek, or Azerbaijani.

If we only document the "do use" cases, though, users and implementers
may not notice the warnings against use of scripts elsewhere. Leading to
the problem we initially sought to prevent.

Thus, my proposal for solving the problem:

1. Include the strongest possible warnings about not using script
subtags in 4646bis. This is probably embodied in Karen Broome's
suggested texts.

2. Replace "Suppress-Script" with "Script". If no script field is
supplied, language tags/ranges should still not use a script subtag
unless one is warranted by the information item or request. If the
script field is present and contains a single item, the language is
known to use that script predominantly. If two or more items are
present, the language is commonly written in more than one script. Users
are advised *not* to use a script subtag unless the language has more
than one item in the Script field.

Potential issues:

1. zero or one script subtag have the same behavior. Acquiring a second
script, however, requires extra scrutiny by ietf-languages because it
changes the potential default behavior for tag formation for that language.


Reactions?



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

Internationalization is an architecture.
It is not a feature.


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

------=_Part_23131_19160012.1160079549498-- --===============0832492858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0832492858==-- From ltru-bounces@ietf.org Thu Oct 05 16:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZgm-0004Gw-4K; Thu, 05 Oct 2006 16:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZgl-0004Gr-8Z for ltru@ietf.org; Thu, 05 Oct 2006 16:19:27 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound1-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZgi-0006yi-Cn for ltru@ietf.org; Thu, 05 Oct 2006 16:19:27 -0400 Received: from outbound1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-res-R.bigfish.com (Postfix) with ESMTP id D4A39FC43CC; Thu, 5 Oct 2006 20:19:20 +0000 (UTC) Received: from mail25-res-R.bigfish.com (unknown [172.18.16.1]) by outbound1-res.bigfish.com (Postfix) with ESMTP id C97B9FC4199; Thu, 5 Oct 2006 20:19:20 +0000 (UTC) Received: from mail25-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail25-res-R.bigfish.com (Postfix) with ESMTP id BC98C6B2DD3; Thu, 5 Oct 2006 20:19:20 +0000 (UTC) X-BigFish: VP Received: by mail25-res (MessageSwitch) id 1160079560656317_13419; Thu, 5 Oct 2006 20:19:20 +0000 (UCT) Received: from mail65-fra.bigfish.com (mail-fra.bigfish.com [62.209.45.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail25-res.bigfish.com (Postfix) with ESMTP id 2C9D16B2CE0; Thu, 5 Oct 2006 20:19:20 +0000 (UTC) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail65-fra.bigfish.com (Postfix) with ESMTP id B0E40A32346; Thu, 5 Oct 2006 19:49:24 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2006100512563110-1887553 ; Thu, 5 Oct 2006 12:56:31 -0700 In-Reply-To: <452555BA.2040601@yahoo-inc.com> To: Addison Phillips Subject: Re: [Ltru] Great Script Debate "the Next Generation"... (long) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH1 March 07, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Thu, 5 Oct 2006 12:52:16 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/05/2006 12:52:17, Serialize complete at 10/05/2006 12:52:17, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/05/2006 12:56:31 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/05/2006 12:56:32 PM, Serialize complete at 10/05/2006 12:56:32 PM X-Spam-Score: 0.7 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1598418035==" Errors-To: ltru-bounces@ietf.org This is a multipart message in MIME format. --===============1598418035== Content-Type: multipart/alternative; boundary="=_alternative 006D4373882571FE_=" This is a multipart message in MIME format. --=_alternative 006D4373882571FE_= Content-Type: text/plain; charset="US-ASCII" Thoughts: I wonder if in assigning only commonly used scripts to a "script" designator -- as opposed to a "suppress-script" designator -- it might be assumed that other more obscure scripts not entered into the registry are invalid. (Granted, this problem may exist with today's suppress-script field as well, but adding more than one option might present new problems.) If a user had a Somali document written in Osmanya and didn't find Osma as a choice for "script" because it's not as commonly used (today), would the classifier assume that so-Osma and so-Arab were invalid or deprecated under RFC 4646bis? To avoid this confusion, I fear the theoretical Army of Charitable Linguists might be required to do the script research to populate the registry with additional script variations. On the other hand, it would be very useful to be able to see all common script options for a particular language in the registry when setting up systems. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Addison Phillips 10/05/2006 11:58 AM To "'LTRU Working Group'" cc Subject [Ltru] Great Script Debate "the Next Generation"... (long) All, Taking up the gauntlet flung down by John Cowan :-), herewith my proposal for fixing Suppress-Scripts ---- First, some recap of the problem. Suppress-Scripts are meant to identify languages that are written predominantly in a single script. This is to warn users and implementers not to form language tags using a script subtag that is usually redundant, for compatibility with tagging practices prior to RFC 4646. S-S poses a number of interesting problems. I've cited previously the registration problems. Mainly the problem here is that most languages fit the pattern of "wanting" some form of S-S field. Even languages that might not have a clear relationship to a specific script subtag (cf. Doug's research on Korean) probably should not use a script subtag. In particular, creating accurate values for even the ISO 639-1 and ISO 639-2 set of languages would require significant knowledge about the current and recent historical writing traditions of each given language, plus, possibly, some knowledge of public policy and/or potential suppression or abuse of minority tradition in regard to that language. S-S indicates that a given language is written predominantly in a specific script, so the burden of proof for a less common language might be very difficult to achieve, since the presence of many texts in a specific script does not "prove the negative", that is, that a significant body of texts or a specific writing tradition does not exist that uses a separate script. The main alternative we've dealt with in the past would be an "Accept-Script" or "Recommend-Script" approach. That design, which was not adopted in RFC 4646, involves documenting the known cases in which a script subtag *should* be used, and, in effect, recommending that languages that do not have an "A-S" field not use a script subtag except when indicating a specific difference important within a given group of information items. A-S avoids the "proving the negative" problem of S-S. Since it applies to a much smaller set of languages, it probably requires less registration overhead. The burden of proof may be just as difficult to achieve and is encumbered with essentially the same problems that attend S-S, since assertions about multiple script usage are just as potentially disruptive as assertions about the "single scriptness" of a language. Removing script information from the registry altogether is appealing as an alternative. As Mark points out, script subtags are entirely voluntary and entirely valid. The informational nature of the S-S field is merely to help guide implementers and users to try and do the right things. If maintenance is a nightmare, why persist in maintaining somewhat fictional information? I do think that guidance for users/implementers is a valid goal here. My experience as an "eminence grise" for language tags over the past couple of years is that the level of ill-informedness and mythology surrounding language tags is pretty deep. Anything we can do to help speed proper implementation of language tags will help. The problem here is that I think we're miscasting the role of the script advisory field or fields in the registry. If we only document the "do not use" case, users and implementers will remain ignorant of what to do for languages without the S-S field. Having explained the Chinese issue several times, it's clear to me that many implementers will not stumble over the right subtags by accident... and certainly not for languages such as Serbian, Uzbek, or Azerbaijani. If we only document the "do use" cases, though, users and implementers may not notice the warnings against use of scripts elsewhere. Leading to the problem we initially sought to prevent. Thus, my proposal for solving the problem: 1. Include the strongest possible warnings about not using script subtags in 4646bis. This is probably embodied in Karen Broome's suggested texts. 2. Replace "Suppress-Script" with "Script". If no script field is supplied, language tags/ranges should still not use a script subtag unless one is warranted by the information item or request. If the script field is present and contains a single item, the language is known to use that script predominantly. If two or more items are present, the language is commonly written in more than one script. Users are advised *not* to use a script subtag unless the language has more than one item in the Script field. Potential issues: 1. zero or one script subtag have the same behavior. Acquiring a second script, however, requires extra scrutiny by ietf-languages because it changes the potential default behavior for tag formation for that language. Reactions? -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --=_alternative 006D4373882571FE_= Content-Type: text/html; charset="US-ASCII"
Thoughts:

I wonder if in assigning only commonly used scripts to a "script" designator -- as opposed to a "suppress-script" designator -- it might be assumed that other more obscure scripts not entered into the registry are invalid.  (Granted, this problem may exist with today's suppress-script field as well, but adding more than one option might present new problems.)

If a user had a Somali document written in Osmanya and didn't find Osma as a choice for "script" because it's not as commonly used (today), would the classifier assume that so-Osma and so-Arab were invalid or deprecated under RFC 4646bis? To avoid this confusion, I fear the theoretical Army of Charitable Linguists might be required to do the script research to populate the registry with additional script variations.

On the other hand, it would be very useful to be able to see all common script options for a particular language in the registry when setting up systems.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


Addison Phillips <addison@yahoo-inc.com>

10/05/2006 11:58 AM

To
"'LTRU Working Group'" <ltru@ietf.org>
cc
Subject
[Ltru] Great Script Debate "the Next Generation"... (long)





All,

Taking up the gauntlet flung down by John Cowan :-), herewith my
proposal for fixing Suppress-Scripts

----
First, some recap of the problem. Suppress-Scripts are meant to identify
languages that are written predominantly in a single script. This is to
warn users and implementers not to form language tags using a script
subtag that is usually redundant, for compatibility with tagging
practices prior to RFC 4646.

S-S poses a number of interesting problems.

I've cited previously the registration problems. Mainly the problem here
is that most languages fit the pattern of "wanting" some form of S-S
field. Even languages that might not have a clear relationship to a
specific script subtag (cf. Doug's research on Korean) probably should
not use a script subtag.

In particular, creating accurate values for even the ISO 639-1 and ISO
639-2 set of languages would require significant knowledge about the
current and recent historical writing traditions of each given language,
plus, possibly, some knowledge of public policy and/or potential
suppression or abuse of minority tradition in regard to that language.

S-S indicates that a given language is written predominantly in a
specific script, so the burden of proof for a less common language might
be very difficult to achieve, since the presence of many texts in a
specific script does not "prove the negative", that is, that a
significant body of texts or a specific writing tradition does not exist
that uses a separate script.

The main alternative we've dealt with in the past would be an
"Accept-Script" or "Recommend-Script" approach. That design, which was
not adopted in RFC 4646, involves documenting the known cases in which a
script subtag *should* be used, and, in effect, recommending that
languages that do not have an "A-S" field not use a script subtag except
when indicating a specific difference important within a given group of
information items.

A-S avoids the "proving the negative" problem of S-S. Since it applies
to a much smaller set of languages, it probably requires less
registration overhead. The burden of proof may be just as difficult to
achieve and is encumbered with essentially the same problems that attend
S-S, since assertions about multiple script usage are just as
potentially disruptive as assertions about the "single scriptness" of a
language.

Removing script information from the registry altogether is appealing as
an alternative. As Mark points out, script subtags are entirely
voluntary and entirely valid. The informational nature of the S-S field
is merely to help guide implementers and users to try and do the right
things. If maintenance is a nightmare, why persist in maintaining
somewhat fictional information?

I do think that guidance for users/implementers is a valid goal here. My
experience as an "eminence grise" for language tags over the past couple
of years is that the level of ill-informedness and mythology surrounding
language tags is pretty deep. Anything we can do to help speed proper
implementation of language tags will help.

The problem here is that I think we're miscasting the role of the script
advisory field or fields in the registry. If we only document the "do
not use" case, users and implementers will remain ignorant of what to do
for languages without the S-S field. Having explained the Chinese issue
several times, it's clear to me that many implementers will not stumble
over the right subtags by accident... and certainly not for languages
such as Serbian, Uzbek, or Azerbaijani.

If we only document the "do use" cases, though, users and implementers
may not notice the warnings against use of scripts elsewhere. Leading to
the problem we initially sought to prevent.

Thus, my proposal for solving the problem:

1. Include the strongest possible warnings about not using script
subtags in 4646bis. This is probably embodied in Karen Broome's
suggested texts.

2. Replace "Suppress-Script" with "Script". If no script field is
supplied, language tags/ranges should still not use a script subtag
unless one is warranted by the information item or request. If the
script field is present and contains a single item, the language is
known to use that script predominantly. If two or more items are
present, the language is commonly written in more than one script. Users
are advised *not* to use a script subtag unless the language has more
than one item in the Script field.

Potential issues:

1. zero or one script subtag have the same behavior. Acquiring a second
script, however, requires extra scrutiny by ietf-languages because it
changes the potential default behavior for tag formation for that language.


Reactions?



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

Internationalization is an architecture.
It is not a feature.


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
--=_alternative 006D4373882571FE_=-- --===============1598418035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1598418035==-- From ltru-bounces@ietf.org Thu Oct 05 17:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb14-0007u5-Mt; Thu, 05 Oct 2006 17:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb12-0007tK-B5 for ltru@lists.ietf.org; Thu, 05 Oct 2006 17:44:28 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVavk-0002Ol-Bp for ltru@lists.ietf.org; Thu, 05 Oct 2006 17:39:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVav9-0000RY-UR for ltru@lists.ietf.org; Thu, 05 Oct 2006 23:38:24 +0200 Received: from pd9fba8c4.dip0.t-ipconnect.de ([217.251.168.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 23:38:23 +0200 Received: from nobody by pd9fba8c4.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 23:38:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 05 Oct 2006 23:34:38 +0200 Organization: Lines: 57 Message-ID: <45257A6E.475D@xyzzy.claranet.de> References: <452555BA.2040601@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8c4.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Ltru] Re: Great Script Debate "the Next Generation"... (long) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > A-S avoids the "proving the negative" problem of S-S. [...] > The burden of proof may be just as difficult to achieve and is > encumbered with essentially the same problems that attend S-S, > since assertions about multiple script usage are just as > potentially disruptive as assertions about the "single > scriptness" of a language. I pick the latter, A-S does not avoid the "proving of a negative" problem. > Removing script information from the registry altogether is > appealing as an alternative. As Mark points out, script subtags > are entirely voluntary and entirely valid. The informational > nature of the S-S field is merely to help guide implementers > and users to try and do the right things. It was and is _not_ "merely informational", it was and is a sine qua non for the concept of script subtags: | the script subtag SHOULD be omitted when it adds no | distinguishing value to the tag or when the primary language | subtag's record includes a Suppress-Script field listing the | applicable script subtag. A SHOULD is normative, not informative. It's also not a MAY. > the level of ill-informedness and mythology surrounding > language tags is pretty deep. Anything we can do to help speed > proper implementation of language tags will help. Yes, that's what among others the Suppress-Scripts do. > If the script field is present and contains a single item, the > language is known to use that script predominantly. In other words the same as a Suppress-Script today. > If two or more items are present, the language is commonly > written in more than one script. That might be very near to what CLDR tries. Excluding cases like Latn+Arab for tr, or (only) Cyrl for tt, where CLDR might have different goals. > Reactions? That won't change much for the known frr, frs, fy, ngo, jp, etc. cases. I don't see that we're entitled to rewrite 4646 from scratch by introducing new fields or modifying existing fields. We're also not entitled to return to 3066, otherwise I'd think about that as another option. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 01:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViC1-0001GO-Ef; Fri, 06 Oct 2006 01:24:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViC0-0001Fj-Rj for ltru@ietf.org; Fri, 06 Oct 2006 01:24:16 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVi6e-0000qD-Ka for ltru@ietf.org; Fri, 06 Oct 2006 01:18:45 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061006051839.JPEL7818.mta10.adelphia.net@DGBP7M81> for ; Fri, 6 Oct 2006 01:18:39 -0400 Message-ID: <003501c6e906$e2021260$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 5 Oct 2006 22:18:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ltru] Re: Consensus X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Draft-4645bis-01 will have the "replaced by ISO code xxx" comments removed. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 01:42:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViTx-0008K7-Po; Fri, 06 Oct 2006 01:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViTv-0008Jy-QI for ltru@ietf.org; Fri, 06 Oct 2006 01:42:47 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GViTu-0004kT-Jf for ltru@ietf.org; Fri, 06 Oct 2006 01:42:47 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GViTt-0007vI-ON; Fri, 06 Oct 2006 01:42:45 -0400 Date: Fri, 6 Oct 2006 01:42:45 -0400 To: ltru@ietf.org, ietf-languages@iana.org Message-ID: <20061006054245.GA19459@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] OT: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Well, here's the idea I came up with. Feel free to pick holes in it. First, a list of countries to choose from. This list is long, but people are used to it, so it shouldn't be a big problem. Next, a couple of lists to choose one of (using radio buttons, say): the home languages (English for the U.K., e.g.), the indigenous living languages, the dead languages, the immigrant languages. That nails down the language. Then some more lists to choose one of; the generic form of the language (no country code), the form used in the country you picked in the first place, other countries where the language is used, other countries where supposedly it isn't used. So you pick US, find English in the indigenous living languages, and then you can pick en, en-us, en-* for likely countries, and then oddities like en-fr, en-dk, etc. -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Allen Brown cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 01:47:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViYs-00024I-5u; Fri, 06 Oct 2006 01:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViYq-00023t-Q5 for ltru@ietf.org; Fri, 06 Oct 2006 01:47:52 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GViYp-0005CI-FN for ltru@ietf.org; Fri, 06 Oct 2006 01:47:52 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061006054750.PRZO437.mta13.adelphia.net@DGBP7M81> for ; Fri, 6 Oct 2006 01:47:50 -0400 Message-ID: <004901c6e90a$f5b67cc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 5 Oct 2006 22:47:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Ltru] Re: Preferred-Value cycles (was: Registry deltas) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Last but not least it would eliminate the "hakka" reference in a > Preferred-Value, where "hakka" is the only "non-subtag" in any > reference. You are presuming a rule where none exists. A grandfathered tag may have another grandfathered tag as its Preferred-Value. There is no restriction against this , no reason it should not be possible, and the fact there is only one such situation -- because two people independently happened to register tags for Hakka under RFC 1766 -- does not change any of that. >> there is no "collision" between 5- to 8-letter language subtags (if >> any existed) and 5- to 8-letter variant subtags, any more than there >> is a collision between "ar" for Arabic and "AR" for Argentina. > > Of course there is for naive implementations, the theory of the 4646 > structure is that you can decompose a tag into subtags, and still tell > what's what based alone on its length. The theory is "length plus position" where position is relative to other subtags. > 3 digits => UN number > 3 alpha => language (for 4646) > 4 alpha at begin => language (reserved) > 4 alpha later => script > 4 alnum starting with a digit => variant > 2 alpha at begin => language > 2 alpha later => region > 5..8 alpha at begin => language > 5..8 alnum later => variant You have created a slightly simplified, almost 100% accurate version of the real rules, described in RFC 4646 Section 2.2 ff. It is not 100% accurate, though. > In my old 4646 validator I've implemented this by adding a dummy > hyphen for anything that's not "at begin", and after that it was as > you said obvious that "AR" (case insensitive) is not "-AR". > > For 4646bis that isn't good enough anymore, because language and > extlang share the same namespace, as soon as there is a language "ang" > there can't be an extlang "-ang". You don't need to do this. If you are truly "validating," as opposed to checking well-formedness, you have to be using the Registry -- so you can simply look there to see whether a language "ang" exists and whether an extlang "ang" exists. In my validator I used the real rules, and everything works just as well for 4646bis as for 4646. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 02:03:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVinm-0005c0-B7; Fri, 06 Oct 2006 02:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVinl-0005bv-1L for ltru@ietf.org; Fri, 06 Oct 2006 02:03:17 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVinj-0007Ar-NT for ltru@ietf.org; Fri, 06 Oct 2006 02:03:17 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061006060315.PVXG437.mta13.adelphia.net@DGBP7M81> for ; Fri, 6 Oct 2006 02:03:15 -0400 Message-ID: <004d01c6e90d$1cce0bf0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 5 Oct 2006 23:03:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] Re: Great Script Debate "the Next Generation"... (long) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I don't plan to keep fighting this battle over Suppress-Script. My views on that are well known -- I don't like the S-S mechanism, don't feel we needed to solve the problem it solves and don't feel this was the best way to solve it -- but we have it now, and we have gone the route of "invent something, then deprecate it" too many times already. Just a couple of comments: > 1. zero or one script subtag have the same behavior. Acquiring a > second script, however, requires extra scrutiny by ietf-languages > because it changes the potential default behavior for tag formation > for that language. First, if "zero" and "one" mean the same thing, there is a fundamental flaw in the scheme. The "one" case is what we have now with Suppress-Script, but it would be purely informative, to the point of superficiality. It would have no impact on tagging -- exactly what Mark said he didn't want in the Registry. Best to disallow this and have either no values, or else two or more. Second, the whole purpose of this proposed new mechanism is to indicate the two-or-more situation. If meaningless transitions between "zero" and "one" are easily handled, but adding a second script is a difficult or contentious process for ietf-languages, the mechanism has failed. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 02:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViqW-0007Rg-1t; Fri, 06 Oct 2006 02:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViqV-0007RY-9Z for ltru@ietf.org; Fri, 06 Oct 2006 02:06:07 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GViqU-0007Z0-0o for ltru@ietf.org; Fri, 06 Oct 2006 02:06:07 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061006060605.KRQM7818.mta10.adelphia.net@DGBP7M81> for ; Fri, 6 Oct 2006 02:06:05 -0400 Message-ID: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 5 Oct 2006 23:06:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Great Script Debate "the Next Generation"... (long) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I am in favor of this approach; it would be much more useful, and more > maintainable. I would add that it would be useful information to say > that the order of the scripts is a rough indication of the volume of > text in the language in that script. Nope. Several people have already stated that order is not relevant in the Registry or in record-jar generally. I asked about this with regard to the relative order of Description fields, and this was the answer I got. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 06:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVnEn-0003kZ-Nt; Fri, 06 Oct 2006 06:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVnEm-0003kO-1A for ltru@ietf.org; Fri, 06 Oct 2006 06:47:28 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVnEf-00008b-Lp for ltru@ietf.org; Fri, 06 Oct 2006 06:47:28 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004881639.msg for ; Fri, 06 Oct 2006 11:49:20 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Fri, 06 Oct 2006 11:47:27 +0100 From: "Debbie Garside" To: , , "'John Cowan'" Date: Fri, 6 Oct 2006 11:47:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbpCoskmTsR+1jYST6u15VEzTR1xwAKLPIQ In-Reply-To: <20061006054245.GA19459@ccil.org> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Fri, 06 Oct 2006 11:49:20 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 06 Oct 2006 11:49:21 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Ltru] RE: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Not bad :-) But, in this instance, I would add... Display the top 10 languages by population/speakers followed by others in alphabetical order. I think it would be useful to discuss the various uses. In other words, look at the end product first. Which industries do we think will be using this data and in what way? For instance, pick lists on web sites for Joe Public to navigate, the needs of archivists and libraries who may well need a more linguistic/relational style approach, web designers, software designers who are interested in ascertaining the locale, etc. etc. Each may have different priorities. Best Debbie > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of John Cowan > Sent: 06 October 2006 06:43 > To: ltru@ietf.org; ietf-languages@iana.org > Subject: OT: Language picking > > Well, here's the idea I came up with. Feel free to pick holes in it. > > First, a list of countries to choose from. This list is > long, but people are used to it, so it shouldn't be a big problem. > > Next, a couple of lists to choose one of (using radio buttons, say): > the home languages (English for the U.K., e.g.), the > indigenous living languages, the dead languages, the > immigrant languages. That nails down the language. > > Then some more lists to choose one of; the generic form of > the language (no country code), the form used in the country > you picked in the first place, other countries where the > language is used, other countries where supposedly it isn't used. > > So you pick US, find English in the indigenous living > languages, and then you can pick en, en-us, en-* for likely > countries, and then oddities like en-fr, en-dk, etc. > > -- > Real FORTRAN programmers can program FORTRAN John Cowan > in any language. --Allen Brown cowan@ccil.org > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 10:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVr6j-00046L-UO; Fri, 06 Oct 2006 10:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVr6h-00046B-Vd for ltru@ietf.org; Fri, 06 Oct 2006 10:55:23 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVr6h-0006TU-IF for ltru@ietf.org; Fri, 06 Oct 2006 10:55:23 -0400 Received: by wx-out-0506.google.com with SMTP id t4so918619wxc for ; Fri, 06 Oct 2006 07:55:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=G0kE9jCXo1GHz+Zp63UniyY3P0HShksVCbQVEwbcFaurr8Y+TYUCRsKZr780GLiNyWtJUf4pi1fu6tDPfzg1KVr0fS/GoewGnCsCTZay1OZe3j2sCoLoPgZgU1pbMhozqF9Poc4MGZjmVYk3ffiER22tktQ59G9n8IxTffg1/j0= Received: by 10.90.116.6 with SMTP id o6mr1758528agc; Fri, 06 Oct 2006 07:55:22 -0700 (PDT) Received: by 10.90.32.3 with HTTP; Fri, 6 Oct 2006 07:55:22 -0700 (PDT) Message-ID: <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com> Date: Fri, 6 Oct 2006 07:55:22 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... (long) In-Reply-To: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: c6418aa834ba0659 X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0987055296==" Errors-To: ltru-bounces@ietf.org --===============0987055296== Content-Type: multipart/alternative; boundary="----=_Part_26913_23402794.1160146522865" ------=_Part_26913_23402794.1160146522865 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline "Nope" is a bit too simple. a) we don't say in the spec that the fields in a record must be considered to be unordered (unless I've missed something). b) even if that were the case, we could have Script: Hans, Hant === Zero and One don't mean the same thing in the Script (S) proposal. S: Zero means: there isn't any information in the registry about the use of script. One means: as far as we know, the language tag is only customarily used with this script. >=2 means: as far as we know, the language tag is customarily used with all of these scripts, and no others. So this provides more infomation that the structure with the SS, which has: SS: Zero means: either there isn't any information in the registry about the use of the script, or as far as we know, the language tag is customarily used with multiple scripts (but we're not going to tell you which ones). One means: as far as we know, the language tag is only customarily used with this script. In terms of usage, the recomendations would be: SS: Zero: we can't tell you much, but if you know that the script is only customarily used with a single script, do like the Zero case, and if you know it is customarily used with more scripts, do like the >=2 case. One: unless you have a good reason, or your script actually differs from this one, don't use a script. >=2: unless you have a good reason, don't use a script that isn't in this list. And don't use a script at all: a) in tagging content or in lookup unless it applies (eg written material only in that script), or b) in filtering, unless you want to restrict yourself to only one script. === Stability. Our guarantee is that the language tags themselves are stable, not the precise format of the registry. And by stable, that doesn't mean unchanging, either. We can add valid language tags, and we can broaden the semantics of existing language tags. Mark On 10/5/06, Doug Ewell wrote: > > Mark Davis wrote: > > > I am in favor of this approach; it would be much more useful, and more > > maintainable. I would add that it would be useful information to say > > that the order of the scripts is a rough indication of the volume of > > text in the language in that script. > > Nope. Several people have already stated that order is not relevant in > the Registry or in record-jar generally. I asked about this with regard > to the relative order of Description fields, and this was the answer I > got. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_26913_23402794.1160146522865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline "Nope" is a bit too simple.

a) we don't say in the spec that the fields in a record must be considered to be unordered (unless I've missed something).

b) even if that were the case, we could have

   Script: Hans, Hant

===

Zero and One don't mean the same thing in the Script (S) proposal.

S:
Zero means: there isn't any information in the registry about the use of script.
One means: as far as we know, the language tag is only customarily used with this script.
>=2 means: as far as we know, the language tag is customarily used with all of these scripts, and no others.

So this provides more infomation that the structure with the SS, which has:

SS:
Zero means: either there isn't any information in the registry about the use of the script, or as far as we know, the language tag is customarily used with multiple scripts (but we're not going to tell you which ones).
One means: as far as we know, the language tag is only customarily used with this script.

In terms of usage, the recomendations would be:

SS:
Zero: we can't tell you much, but if you know that the script is only customarily used with a single script, do like the Zero case, and if you know it is customarily used with more scripts, do like the >=2 case.

One: unless you have a good reason, or your script actually differs from this one, don't use a script.

>=2: unless you have a good reason, don't use a script that isn't in this list. And don't use a script at all:
a) in tagging content or in lookup unless it applies (eg written material only in that script), or
b) in filtering, unless you want to restrict yourself to only one script.

===

Stability. Our guarantee is that the language tags themselves are stable, not the precise format of the registry. And by stable, that doesn't mean unchanging, either. We can add valid language tags, and we can broaden the semantics of existing language tags.

Mark

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

> I am in favor of this approach; it would be much more useful, and more
> maintainable. I would add that it would be useful information to say
> that the order of the scripts is a rough indication of the volume of
> text in the language in that script.

Nope.  Several people have already stated that order is not relevant in
the Registry or in record-jar generally.  I asked about this with regard
to the relative order of Description fields, and this was the answer I
got.

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


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

------=_Part_26913_23402794.1160146522865-- --===============0987055296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0987055296==-- From ltru-bounces@ietf.org Fri Oct 06 11:27:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrbI-0004UZ-HZ; Fri, 06 Oct 2006 11:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrbH-0004UU-Kp for ltru@ietf.org; Fri, 06 Oct 2006 11:26:59 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrbG-0006vy-Cp for ltru@ietf.org; Fri, 06 Oct 2006 11:26:59 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GVrbD-00021P-VA; Fri, 06 Oct 2006 11:26:55 -0400 Date: Fri, 6 Oct 2006 11:26:55 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... (long) Message-ID: <20061006152655.GC19459@ccil.org> References: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > b) even if that were the case, we could have > > Script: Hans, Hant I think we'd have to go with this style (though perhaps without the commas) if we wanted to impose ordering. > >=2 means: as far as we know, the language tag is customarily used with > >all of these scripts, and no others. Unfortunately, this interpretation breaks down because of Braille. There are hundreds of languages that can be written in Braille script, not one of which is written solely in that script. So to specify Braille alone would be misleading, to specify Braille and other scripts would be as hard as Suppress-Script, and to omit Braille would be to say that it should not be used with (otherwise) multiscript languages. > Stability. Our guarantee is that the language tags themselves are stable, > not the precise format of the registry. And by stable, that doesn't mean > unchanging, either. We can add valid language tags, and we can broaden > the semantics of existing language tags. +1, except to note that existing language tags can be narrowed as well, provided they are not narrowed too much. If it is learned that Upper and Lower Slobbovian are really separate languages, not just divergent dialects of Slobbovian, we might expect ISO 639-3/RA to create a macrolanguage; but if it turns out that a few isolated villages in the little-known North Central district of Gibberistan speak something distinct enough from Gibberish to warrant being called a separate language, there will probably simply be a new code for it, and the code for Gibberish will be left alone. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The known is finite, the unknown infinite; intellectually we stand on an islet in the midst of an illimitable ocean of inexplicability. Our business in every generation is to reclaim a little more land, to add something to the extent and the solidity of our possessions. --Thomas Henry Huxley _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 11:46:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVruT-0005VM-97; Fri, 06 Oct 2006 11:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVruS-0005VC-9Y for ltru@ietf.org; Fri, 06 Oct 2006 11:46:48 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVruQ-0004MH-U4 for ltru@ietf.org; Fri, 06 Oct 2006 11:46:48 -0400 Received: by wx-out-0506.google.com with SMTP id t4so932973wxc for ; Fri, 06 Oct 2006 08:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=BTTqce1kYA5R01HaOo3XCbF2rwy3cNwDqxuyaJvqKxX7mJZY+qKlmGqf/BF69LgmcsmAyFOvUkgUNDmYxBa7M6MlMkIc4MAuzvj5dXV2YvO0vK40hevKibdM6OH4Ydv1T8EFibTuD8lI6Az4HlebTS45aYw+SIxA84q0JDQcytg= Received: by 10.90.113.20 with SMTP id l20mr1824082agc; Fri, 06 Oct 2006 08:46:46 -0700 (PDT) Received: by 10.90.32.3 with HTTP; Fri, 6 Oct 2006 08:46:46 -0700 (PDT) Message-ID: <30b660a20610060846q2603cf73x91981f5c751d5bc1@mail.gmail.com> Date: Fri, 6 Oct 2006 08:46:46 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... (long) In-Reply-To: <20061006152655.GC19459@ccil.org> MIME-Version: 1.0 References: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com> <20061006152655.GC19459@ccil.org> X-Google-Sender-Auth: 74c833ac71a69cf9 X-Spam-Score: 0.5 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1960333606==" Errors-To: ltru-bounces@ietf.org --===============1960333606== Content-Type: multipart/alternative; boundary="----=_Part_27133_30778782.1160149606060" ------=_Part_27133_30778782.1160149606060 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Braille, Zxxx (unwritten), etc. are exceptional cases, and need to be called out as not being governed by SS. Mark On 10/6/06, John Cowan wrote: > > Mark Davis scripsit: > > > b) even if that were the case, we could have > > > > Script: Hans, Hant > > I think we'd have to go with this style (though perhaps without > the commas) if we wanted to impose ordering. > > > >=2 means: as far as we know, the language tag is customarily used with > > >all of these scripts, and no others. > > Unfortunately, this interpretation breaks down because of Braille. > There are hundreds of languages that can be written in Braille script, > not one of which is written solely in that script. So to specify Braille > alone would be misleading, to specify Braille and other scripts would > be as hard as Suppress-Script, and to omit Braille would be to say that > it should not be used with (otherwise) multiscript languages. > > > Stability. Our guarantee is that the language tags themselves are > stable, > > not the precise format of the registry. And by stable, that doesn't mean > > unchanging, either. We can add valid language tags, and we can broaden > > the semantics of existing language tags. > > +1, except to note that existing language tags can be narrowed as > well, provided they are not narrowed too much. If it is learned > that Upper and Lower Slobbovian are really separate languages, not > just divergent dialects of Slobbovian, we might expect ISO 639-3/RA > to create a macrolanguage; but if it turns out that a few isolated > villages in the little-known North Central district of Gibberistan > speak something distinct enough from Gibberish to warrant being called > a separate language, there will probably simply be a new code for it, > and the code for Gibberish will be left alone. > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > The known is finite, the unknown infinite; intellectually we stand > on an islet in the midst of an illimitable ocean of inexplicability. > Our business in every generation is to reclaim a little more land, > to add something to the extent and the solidity of our possessions. > --Thomas Henry Huxley > ------=_Part_27133_30778782.1160149606060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Braille, Zxxx (unwritten), etc. are exceptional cases, and need to be called out as not being governed by SS.

Mark

On 10/6/06, John Cowan < cowan@ccil.org> wrote:
Mark Davis scripsit:

> b) even if that were the case, we could have
>
>   Script: Hans, Hant

I think we'd have to go with this style (though perhaps without
the commas) if we wanted to impose ordering.

> >=2 means: as far as we know, the language tag is customarily used with
> >all of these scripts, and no others.

Unfortunately, this interpretation breaks down because of Braille.
There are hundreds of languages that can be written in Braille script,
not one of which is written solely in that script.  So to specify Braille
alone would be misleading, to specify Braille and other scripts would
be as hard as Suppress-Script, and to omit Braille would be to say that
it should not be used with (otherwise) multiscript languages.

> Stability. Our guarantee is that the language tags themselves are stable,
> not the precise format of the registry. And by stable, that doesn't mean
> unchanging, either. We can add valid language tags, and we can broaden
> the semantics of existing language tags.

+1, except to note that existing language tags can be narrowed as
well, provided they are not narrowed too much.  If it is learned
that Upper and Lower Slobbovian are really separate languages, not
just divergent dialects of Slobbovian, we might expect ISO 639-3/RA
to create a macrolanguage; but if it turns out that a few isolated
villages in the little-known North Central district of Gibberistan
speak something distinct enough from Gibberish to warrant being called
a separate language, there will probably simply be a new code for it,
and the code for Gibberish will be left alone.

--
John Cowan   cowan@ccil.org     http://ccil.org/~cowan
The known is finite, the unknown infinite; intellectually we stand
on an islet in the midst of an illimitable ocean of inexplicability.
Our business in every generation is to reclaim a little more land,
to add something to the extent and the solidity of our possessions.
        --Thomas Henry Huxley

------=_Part_27133_30778782.1160149606060-- --===============1960333606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1960333606==-- From ltru-bounces@ietf.org Fri Oct 06 12:00:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVs7U-0004G0-0K; Fri, 06 Oct 2006 12:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVs7T-0004Fn-DU for ltru@ietf.org; Fri, 06 Oct 2006 12:00:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVs7S-0007Uh-5L for ltru@ietf.org; Fri, 06 Oct 2006 12:00:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GVs7R-00037A-N1; Fri, 06 Oct 2006 12:00:13 -0400 Date: Fri, 6 Oct 2006 12:00:13 -0400 To: Don Osborn Message-ID: <20061006160013.GB10761@ccil.org> References: <20061006054245.GA19459@ccil.org> <01f401c6e95f$1b86c5a0$529450e0$@net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f401c6e95f$1b86c5a0$529450e0$@net> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Don Osborn scripsit: > The Locale Generator - http://www.it46.se/localegen/ (list of languages > for creation of locales from ISO/FDIS 636-3 - needs to be amended IMO; > country is selected after language) This is a fine example of what's wrong with just using the bare list of languages. The list is here broken up by first letter of the alphabet into 27 sublists, but when I look for Dari under "D", I don't find it and go away in disgust (see my earlier posting). -- John Cowan http://www.ccil.org/~cowan Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 12:03:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsAE-0007IT-9F; Fri, 06 Oct 2006 12:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsAC-0007IN-Em for ltru@ietf.org; Fri, 06 Oct 2006 12:03:04 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsAB-0000Ku-3B for ltru@ietf.org; Fri, 06 Oct 2006 12:03:04 -0400 Received: from [10.72.72.197] (snvvpn1-10-72-72-c197.corp.yahoo.com [10.72.72.197]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k96G2Zs2030564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Oct 2006 09:02:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=kkt1hYgh01BrSXtRVIX4SEYwwoJ7nfhM3aM0eDKHaCxFAIB6fwsFrMeIl24pu8D7 Message-ID: <45267E1B.9030300@yahoo-inc.com> Date: Fri, 06 Oct 2006 09:02:35 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... (long) References: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com> <20061006152655.GC19459@ccil.org> In-Reply-To: <20061006152655.GC19459@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >>> =2 means: as far as we know, the language tag is customarily used with >>> all of these scripts, and no others. > > Unfortunately, this interpretation breaks down because of Braille. > There are hundreds of languages that can be written in Braille script, > not one of which is written solely in that script. So to specify Braille > alone would be misleading, to specify Braille and other scripts would > be as hard as Suppress-Script, and to omit Braille would be to say that > it should not be used with (otherwise) multiscript languages. Braille is an example of a script you would always have to identify. That is, it represents *exactly* the sort of "distinguishing value" that requires a script subtag. It is useful to note that *no* languages are "natively written" in Braille. There are hundreds of languages that are transcribed into Braille, and, while there is no doubt that some--even many--texts are authored natively in Braille, there is also no doubt in my mind that no language claims it as a primary script (i.e. documents are not "customarily" written in it, they are always *exceptionally* written in it). It's non-listing in the registry means exactly the foregoing: if you have a document in Braille, then you, by all rights, really SHOULD tag the content as being in Braille, as it will most probably be inaccessible to native speakers of the language. Just as if, when I find an English document written in the Arabic script, I would naturally feel compelled to identify that fact: "en-Arab". The "two or more" rule for Script would mean, basically: yes, this language (say Serbian) is customarily written in the script you are using (say Cyrillic). You still need to identify the script because there are other common scripts for this particular language. addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 12:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsCT-00086O-Vk; Fri, 06 Oct 2006 12:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsCS-000866-HG for ltru@ietf.org; Fri, 06 Oct 2006 12:05:24 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsCR-0000lR-9W for ltru@ietf.org; Fri, 06 Oct 2006 12:05:24 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GVsCQ-0003NN-Ue; Fri, 06 Oct 2006 12:05:22 -0400 Date: Fri, 6 Oct 2006 12:05:22 -0400 To: Debbie Garside Message-ID: <20061006160522.GC10761@ccil.org> References: <20061006054245.GA19459@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf-languages@iana.org, ltru@ietf.org Subject: [Ltru] Re: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > Not bad :-) > > But, in this instance, I would add... Display the top 10 languages by > population/speakers followed by others in alphabetical order. Fair enough. I was trying to handle only the generic case, where we don't know anything about what's probable. > I think it would be useful to discuss the various uses. In other > words, look at the end product first. Which industries do we think > will be using this data and in what way? For instance, pick lists > on web sites for Joe Public to navigate, the needs of archivists and > libraries who may well need a more linguistic/relational style approach, > web designers, software designers who are interested in ascertaining > the locale, etc. etc. Each may have different priorities. I think the archivists and librarians, who in principle may have to deal with anything (especially when dealing with audio) will be the ones who need the full power and generality of this. No web site is going to be localized in 7000 languages or even 700, so the problem doesn't arise. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 06 12:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVszR-00038N-Dq; Fri, 06 Oct 2006 12:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVszR-00038I-3Y for ltru@ietf.org; Fri, 06 Oct 2006 12:56:01 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVszN-0003Ju-Pz for ltru@ietf.org; Fri, 06 Oct 2006 12:56:01 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Fri, 6 Oct 2006 09:55:57 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 6 Oct 2006 09:53:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... (long) Date: Fri, 6 Oct 2006 09:53:17 -0700 Message-ID: In-Reply-To: <45267E1B.9030300@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Great Script Debate "the Next Generation"... (long) thread-index: AcbpYO0RB0BsbC7SSRWK69qLDnvd+AAAwlKg References: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com><20061006152655.GC19459@ccil.org> <45267E1B.9030300@yahoo-inc.com> From: Peter Constable To: X-OriginalArrivalTime: 06 Oct 2006 16:53:20.0679 (UTC) FILETIME=[EDC71B70:01C6E967] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1736741981==" Errors-To: ltru-bounces@ietf.org --===============1736741981== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHByb2JsZW0gd2l0aCBzY3JpcHRzIGlzIHRoYXQgc2NlbmFyaW9zIGZhbGwgYWxvbmcgb25l IG9yIG1vcmUgY29udGludWEgcmF0aGVyIHRoYW4gZmFsbGluZyBpbnRvIGEgZmV3IGRpc3RpbmN0 IGJ1Y2tldHM6IA0KDQpFbmdsaXNoIGlzIDk5Ljk5JSBvZiB0aGUgdGltZSB3cml0dGVuIGluIExh dGluIHNjcmlwdCB3aXRoIGNlcnRhaW4gbGltaXRlZCBvcnRob2dyYXBoaWMgdmFyaWF0aW9ucy4g QXJhYmljIGlzIHNpbWlsYXIuIEF0IHRoZSBvdGhlciBleHRyZW1lLCB3ZSBrbm93IHRoYXQgSGFu cyBhbmQgSGFudCBhcmUgYm90aCB2aWFibGUgYW5kIHdpZGVseS11c2VkIHdyaXR0ZW4gZm9ybXMg Zm9yIHpoLiANCg0KTm93IGNvbnNpZGVyIFNvbWFsaTogYW55IG5ldyB0ZXh0IGlzIHdyaXR0ZW4g aW4gTGF0aW4sIGJ1dCBqdXN0IGEgZmV3IGRlY2FkZXMgYWdvIHRoaXMgd2FzIHRyYW5zaXRpb25h bC4gT3IgY29uc2lkZXIgQmFsa2FuIGxhbmd1YWdlczogYSBsYW5ndWFnZSBtaWdodCBiZSB3cml0 dGVuIGluIG1vcmUgdGhhbiBvbmUgc2NyaXB0LCB3aXRoIG9uZSBjbGVhcmx5IHRoZSBtYWpvcml0 eSBjYXNlIHRob3VnaCB0aGUgb3RoZXIgY2FuJ3QgYmUgZGlzcmVnYXJkZWQgYXMgcmFyZS4gVGhl c2UgYW5kIG90aGVyIGNhc2VzIGZhbGwgc29tZXdoZXJlIGJldHdlZW4gdGhlIHR3byBleHRyZW1l cy4NCg0KRm9yIHRoZSBjYXNlcyBhdCB0aGUgdHdvIGV4dHJlbWVzLCB3aGV0aGVyIHdlIGRlY2xh cmUgYSBrbm93biBzY3JpcHQgKGVuIHVzZXMgTGF0bjsgemggdXNlcyBIYW5zLCBIYW50LCBIYW5p KSBvciBkZWNsYXJlIHNjcmlwdHMgdG8gYmUgc3VwcHJlc3NlZCAoZG9uJ3QgdXNlIExhdG4gd2l0 aCBlbikgbWlnaHQgbm90IGJlIGEgaHVnZSBkaWZmZXJlbmNlLiBJdCdzIHRoZSBpbi1iZXR3ZWVu IGNhc2VzIHRoYXQgcHJlc2VudCB0aGUgYmlnZ2VzdCBwcm9ibGVtcy4gDQoNCkFsdGhvdWdoLCBl dmVuIGluIHRoZSBjYXNlcyBhdCB0aGUgdHdvIGV4dHJlbWVzLCB3ZSBuZWVkIHRvIGNvbnNpZGVy IGhvdyB0byBkZWFsIHdpdGggdGhlIGxlc3MgY29tbW9uIHVzYWdlczogZS5nLiBFbmdsaXNoIGlu IHNob3J0aGFuZCwgQ2hpbmVzZSBpbiBCb3BvbW9mby4gQ2xlYXJseSB0YWdzIGZvciB0aGVzZSBz aG91bGQgaGF2ZSBhIHNjcmlwdCB0YWc7IGl0J3MganVzdCBub3QgY2xlYXIgd2hhdCB3ZSBvdWdo dCB0byBkZWNsYXJlIGFib3V0IHRoZSBsYW5ndWFnZXMgaW4gdGhlIHJlZ2lzdHJ5LiBJZiB3ZSdy ZSBkZWNsYXJpbmcgc2NyaXB0cywgdGhlbiBmb3IgZW4gZG8gd2UganVzdCBsaXN0IExhdG4/IElm IHNvLCB0aGVuIHdlJ3JlIG5vdCByZWFsbHkgZGVjbGFyaW5nIGFsbCBzY3JpcHRzIHVzZWQgZm9y IHRoYXQgbGFuZ3VhZ2U7IHdlJ3JlIG9ubHkgZGVjbGFyaW5nIGNvbW1vbmx5LXVzZWQgc2NyaXB0 cy4NCg0KTWF5YmUgdGhhdCdzIGFub3RoZXIgYWx0ZXJuYXRpdmUgdG8gY29uc2lkZXI6IHdlIGhh dmUgdHdvIGRhdGEgZmllbGRzIHRoYXQgY2FuIGJlIHVzZWQsIG9uZSB0byBkZWNsYXJlIHNjcmlw dHMgaW4gY29tbW9uIHVzYWdlIGZvciBtb2Rlcm4gb3J0aG9ncmFwaGllcywgYW5kIGFub3RoZXIg dG8gZGVjbGFyZSBvdGhlciBzY3JpcHRzIHRoYXQgYXJlIGtub3duIHRvIGJlIHVzZWQgKGJ1dCBv bmx5IGluIGxpbWl0ZWQsIHVuY29tbW9uIHNjZW5hcmlvcykuIElmIHRoZSBmb3JtZXIgZmllbGQg aGFzIG9ubHkgb25lIHZhbHVlLCB0aGVuIHdlIGNhbiBhc3N1bWUgaXQgaXMgc2FmZSB0byBzdXBw cmVzcyB0aGF0Lg0KDQoNCkp1c3QgdGhpbmtpbmcgb3V0IGxvdWQuLi4NCg0KDQpQZXRlciBDb25z dGFibGUNCg== --===============1736741981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1736741981==-- From ltru-bounces@ietf.org Fri Oct 06 23:32:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW2vI-0002rP-Ow; Fri, 06 Oct 2006 23:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW2vH-0002rK-SF for ltru@lists.ietf.org; Fri, 06 Oct 2006 23:32:23 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW2vG-0006CO-FL for ltru@lists.ietf.org; Fri, 06 Oct 2006 23:32:23 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GW2v9-0004J0-Kw for ltru@lists.ietf.org; Sat, 07 Oct 2006 05:32:15 +0200 Received: from pd9fbadb5.dip0.t-ipconnect.de ([217.251.173.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Oct 2006 05:32:15 +0200 Received: from nobody by pd9fbadb5.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Oct 2006 05:32:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 07 Oct 2006 05:31:38 +0200 Organization: Lines: 34 Message-ID: <45271F9A.1479@xyzzy.claranet.de> References: <004901c6e90a$f5b67cc0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadb5.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] Re: Preferred-Value cycles X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > You are presuming a rule where none exists. The "dangling pointers are evil" rule is universal. The one exception ("hakka" misinterpreted as variant) in 4645bis could be eliminated by registry without multiple indirections. It's not allowed to create another exception under 4646 or similar rules. > If you are truly "validating," as opposed to checking > well-formedness, you have to be using the Registry A registry converter isn't the same as a tag validator, it just reads stuff top down producing output in a form needed by other tools, in that case an SGML validator abused as XML validator. > you can simply look there to see whether a language > "ang" exists and whether an extlang "ang" exists. Sure, it's possible to check anything directly in the converter, it could reject extlang "ang" if it already has language "ang". And so on, note "Latn" as needed if seen in a Suppress-Script, and later as "okay" if a Script "Latn" is registered. That's possible, and I did that for 4646 registries. For 4645bis registries I use xml:id for this purpose, i.e. ID, IDREF, and IDREFS attribute types. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 07 03:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW6R1-0001ZK-2B; Sat, 07 Oct 2006 03:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW6R0-0001ZF-6g for ltru@ietf.org; Sat, 07 Oct 2006 03:17:22 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW6Qy-0003G7-SS for ltru@ietf.org; Sat, 07 Oct 2006 03:17:22 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061007071719.UNZS7818.mta10.adelphia.net@DGBP7M81>; Sat, 7 Oct 2006 03:17:19 -0400 Message-ID: <008c01c6e9e0$a0bf1020$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <004f01c6e90d$823c14a0$6401a8c0@DGBP7M81> <30b660a20610060755s6b42677u26a03cf07bef456c@mail.gmail.com> Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... (long) Date: Sat, 7 Oct 2006 00:17:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > a) we don't say in the spec that the fields in a record must be > considered to be unordered (unless I've missed something). Well, I can't find it either, in RFC 4646 or Addison's record-jar draft or in the Art of Unix Programming. But I know people have been telling me for at least a year that the order of Description fields is meaningless, and we can't make it meaningful, because: a) record-jar says order is meaningless b) RFC 4646 saysorder is meaningless c) (a) and (b) above > b) even if that were the case, we could have > > Script: Hans, Hant You could certainly do this. I don't know, however, if trying to order the scripts in this way is pertinent to the main goal of improving script subtag practice is in line. If the Registry included either of these two Script fields for the Mongolian language: Script: Mong, Cyrl Script: Cyrl, Mong it would have exactly the same meaning that you stated: don't use a script that isn't in this list. Trying to order the entries by usage statistics would cause controversy, and would be perceived by some as expressing a preference for one script over another, which is not our job. > S: > Zero means: there isn't any information in the registry about the use > of script. Just like the absence of Suppress-Script. Fine so far. > One means: as far as we know, the language tag is only customarily > used with this script. Just like the presence of Suppress-Script. Fine so far. > >=2 means: as far as we know, the language tag is customarily used > >with all of these scripts, and no others. This is where it gets better: sort of like an Accept-Script for just those two (or whatever). OK, I'm convinced that this solution might be better than S-S. The question is whether it is "better enough" to justify changing the mechanism. Also, we had better try hard (and fail) to poke holes in this mechanism, from all perspectives: ease of understanding, usability by tag producers and consumers, ease of administration by ietf-languages. If there are flaws in this mechanism, we'd better find out about them and address them before making a change to the system, because we (read: "I") don't want to end up scrapping yet another of our own inventions in favor of something "better." > Stability. Our guarantee is that the language tags themselves are > stable, not the precise format of the registry. And by stable, that > doesn't mean unchanging, either. We can add valid language tags, and > we can broaden the semantics of existing language tags. That kind of instability doesn't bother me half as much as inventing a feature one year and getting rid of it the next, or creating "deprecated at birth" subtags, or creating mechanisms that we don't really want to see used, like extensions. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 07 13:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWGMt-0007iH-DS; Sat, 07 Oct 2006 13:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVry9-0008T4-EG for ltru@ietf.org; Fri, 06 Oct 2006 11:50:37 -0400 Received: from [64.39.15.8] (helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVry5-00050a-1z for ltru@ietf.org; Fri, 06 Oct 2006 11:50:37 -0400 Received: (qmail 5749 invoked from network); 6 Oct 2006 10:50:16 -0500 Received: from 67.sui208.atln.attga31ur.dsl.att.net (HELO IBM92AA25595C4) (12.134.208.67) by kabissa.org with SMTP; 6 Oct 2006 10:50:16 -0500 From: "Don Osborn" To: , , , "'John Cowan'" References: <20061006054245.GA19459@ccil.org> In-Reply-To: Date: Fri, 6 Oct 2006 11:49:31 -0400 Message-ID: <01f401c6e95f$1b86c5a0$529450e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcbpCoskmTsR+1jYST6u15VEzTR1xwAKLPIQAAi2VHA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Sat, 07 Oct 2006 13:53:46 -0400 Cc: Subject: [Ltru] RE: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I missed the context on this, but fwiw, I agree with Debbie that the context of use is important. If you set up a database you might also be able to present the list dynamically to suit the preference - top 10, alpha, regional and some ranking or alpha, endangered, etc. Question of time & money to set up and "populate" the dbase, but once it is, the rest should be easier and more fun. Here are three examples of particular approaches that may be of interest for comparison or discussion (or maybe not, but here they are anyway): The Locale Generator - http://www.it46.se/localegen/ (list of languages for creation of locales from ISO/FDIS 636-3 - needs to be amended IMO; country is selected after language) Wikipedia - http://www.wikipedia.org/ (obviously not a database but they have classed the language pages by number of articles; one could of course list languages in classes like this by speakership, region, language family, ...) Wiki on African localization with pages on Countries and Major Languages - http://www.panafril10n.org/wikidoc/pmwiki.php/PanAfrLoc/ (there is a page for other languages too, but the main list is limited; this is not a dbase, but a format that permits access to and collection of info in different ways) Don -----Original Message----- From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Debbie Garside Sent: Friday, October 06, 2006 6:47 AM To: ltru@ietf.org; ietf-languages@iana.org; 'John Cowan' Subject: RE: Language picking Not bad :-) But, in this instance, I would add... Display the top 10 languages by population/speakers followed by others in alphabetical order. I think it would be useful to discuss the various uses. In other words, look at the end product first. Which industries do we think will be using this data and in what way? For instance, pick lists on web sites for Joe Public to navigate, the needs of archivists and libraries who may well need a more linguistic/relational style approach, web designers, software designers who are interested in ascertaining the locale, etc. etc. Each may have different priorities. Best Debbie > -----Original Message----- > From: ietf-languages-bounces@alvestrand.no > [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of John Cowan > Sent: 06 October 2006 06:43 > To: ltru@ietf.org; ietf-languages@iana.org > Subject: OT: Language picking > > Well, here's the idea I came up with. Feel free to pick holes in it. > > First, a list of countries to choose from. This list is long, but > people are used to it, so it shouldn't be a big problem. > > Next, a couple of lists to choose one of (using radio buttons, say): > the home languages (English for the U.K., e.g.), the indigenous living > languages, the dead languages, the immigrant languages. That nails > down the language. > > Then some more lists to choose one of; the generic form of the > language (no country code), the form used in the country you picked in > the first place, other countries where the language is used, other > countries where supposedly it isn't used. > > So you pick US, find English in the indigenous living languages, and > then you can pick en, en-us, en-* for likely countries, and then > oddities like en-fr, en-dk, etc. > > -- > Real FORTRAN programmers can program FORTRAN John Cowan > in any language. --Allen Brown cowan@ccil.org > _______________________________________________ > 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://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 07 13:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWGNz-0007uw-0b; Sat, 07 Oct 2006 13:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVtDL-00033b-IT for ltru@ietf.org; Fri, 06 Oct 2006 13:10:23 -0400 Received: from [64.39.15.8] (helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVtDH-0004vv-6f for ltru@ietf.org; Fri, 06 Oct 2006 13:10:23 -0400 Received: (qmail 18669 invoked from network); 6 Oct 2006 12:10:03 -0500 Received: from 67.sui208.atln.attga31ur.dsl.att.net (HELO IBM92AA25595C4) (12.134.208.67) by kabissa.org with SMTP; 6 Oct 2006 12:10:03 -0500 From: "Don Osborn" To: "'John Cowan'" References: <20061006054245.GA19459@ccil.org> <01f401c6e95f$1b86c5a0$529450e0$@net> <20061006160013.GB10761@ccil.org> In-Reply-To: <20061006160013.GB10761@ccil.org> Date: Fri, 6 Oct 2006 13:09:28 -0400 Message-ID: <020a01c6e96a$413bc880$c3b35980$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcbpYIL3GCC8hce8RDmsvrsJUGoMcAABMkCg Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Sat, 07 Oct 2006 13:54:54 -0400 Cc: ietf-languages@iana.org, aep@it46.se, ltru@ietf.org, louise@it46.se Subject: [Ltru] RE: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks, John, I think the Locale Generator as such was a first cut. I'll cc this to Alberto and Louise (who created the Generator earlier this year) for their info (see archives via http://www.alvestrand.no/mailman/listinfo/ietf-languages ). Two issues: you and they base the list on 639-3, which is okay if "macrolanguages," are included and better yet if 639-1 code categories are also there. I think the level of precision of language picking for locales and localization depends a lot on the use. If it's localizing a software, it makes no sense to look at separate versions for 8 varieties of Fulfulde/Pulaar, or a dozen or so Manding tongues, but if you are talking about text it might even be helpful in some cases to have a finer distinction. There are lots of such examples in Africa, for instance. This need for flexibility almost seems to require a more "artisanal" approach that lets real people who are more or less familiar with the languages, countries, needs, etc. access information to make the choices based on their perceived specific needs. This is the sense of the PAL African language wiki I also mentioned. Where I think lists such as those you and Alberto and Louise are working on fitting in this process is in providing a range of information and options on the way to producing some output - and that that output be explicitly part of an iterative process. That is to say, it is not the final word in itself, but an aid in reaching an appropriate solution. The products of Locale Generator, for example, indeed are reviewed before submission. Ultimately an interactive search option might be a good feature for such lists (which I guess requires a database or an advanced search facility). It might also alert users to language synonym issues - unrelated languages with the same or similar names that might be confused. Hope this helps. Don -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: Friday, October 06, 2006 12:00 PM To: Don Osborn Cc: debbie@ictmarketing.co.uk; ltru@ietf.org; ietf-languages@iana.org Subject: Re: Language picking Don Osborn scripsit: > The Locale Generator - http://www.it46.se/localegen/ (list of > languages for creation of locales from ISO/FDIS 636-3 - needs to be > amended IMO; country is selected after language) This is a fine example of what's wrong with just using the bare list of languages. The list is here broken up by first letter of the alphabet into 27 sublists, but when I look for Dari under "D", I don't find it and go away in disgust (see my earlier posting). -- John Cowan http://www.ccil.org/~cowan Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 08 15:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWdxF-0004EF-MA; Sun, 08 Oct 2006 15:04:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWdxD-0004EA-4U for ltru@ietf.org; Sun, 08 Oct 2006 15:04:51 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWdxB-00026l-SB for ltru@ietf.org; Sun, 08 Oct 2006 15:04:51 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061008190443.EFPK7818.mta10.adelphia.net@DGBP7M81> for ; Sun, 8 Oct 2006 15:04:43 -0400 Message-ID: <000d01c6eb0c$9d8a76b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 8 Oct 2006 12:04:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Is there any sort of consensus for or against John Cowan's proposal to add a "Language-Type" field that captures the ISO 639-3 classifications (extinct, historic, etc.)? I've added this data to the Registry contents in draft-4645bis-01, and I'm writing text that explains the exact process for populating these fields; this can easily be removed if the WG ends up rejecting the proposal. But since I'm getting ready to release draft-01, I'd like to know which way the wind is blowing on this. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 08 15:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeXf-0002mC-Oo; Sun, 08 Oct 2006 15:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeXe-0002m7-Cg for ltru@ietf.org; Sun, 08 Oct 2006 15:42:30 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWeXc-0003Ox-Va for ltru@ietf.org; Sun, 08 Oct 2006 15:42:30 -0400 Received: from [10.72.76.80] (snvvpn2-10-72-76-c80.corp.yahoo.com [10.72.76.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k98JgBeK039726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Oct 2006 12:42:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=xTqgH8T0g5PAzHlk4Cx6i7HrnAluGmjYSm5bR5fSUv6ZwBOEooIxe1MnyIJB8zhm Message-ID: <45295495.3020205@yahoo-inc.com> Date: Sun, 08 Oct 2006 12:42:13 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field References: <000d01c6eb0c$9d8a76b0$6401a8c0@DGBP7M81> In-Reply-To: <000d01c6eb0c$9d8a76b0$6401a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I would not add anything to 4645bis until you see it in 4646bis. Addison Doug Ewell wrote: > Is there any sort of consensus for or against John Cowan's proposal to > add a "Language-Type" field that captures the ISO 639-3 classifications > (extinct, historic, etc.)? > > I've added this data to the Registry contents in draft-4645bis-01, and > I'm writing text that explains the exact process for populating these > fields; this can easily be removed if the WG ends up rejecting the > proposal. But since I'm getting ready to release draft-01, I'd like to > know which way the wind is blowing on this. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 08 18:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWghE-0000y3-00; Sun, 08 Oct 2006 18:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWghC-0000xt-Lj for ltru@lists.ietf.org; Sun, 08 Oct 2006 18:00:30 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWghB-0005mK-4C for ltru@lists.ietf.org; Sun, 08 Oct 2006 18:00:30 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWggx-0007MI-W7 for ltru@lists.ietf.org; Mon, 09 Oct 2006 00:00:15 +0200 Received: from du-001-203.access.de.clara.net ([212.82.227.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 00:00:15 +0200 Received: from nobody by du-001-203.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 00:00:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 08 Oct 2006 23:59:41 +0200 Organization: Lines: 9 Message-ID: <452974CD.4E4D@xyzzy.claranet.de> References: <000d01c6eb0c$9d8a76b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-203.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'd like to know which way the wind is blowing on this. Weather report Hamburg: Stick to the 4646 ABNF, maybe put interesting details found in the new source into comments. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 08 19:53:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWiST-0007bc-Na; Sun, 08 Oct 2006 19:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWiST-0007bX-7o for ltru@ietf.org; Sun, 08 Oct 2006 19:53:25 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWiSR-0004s5-Um for ltru@ietf.org; Sun, 08 Oct 2006 19:53:25 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061008235319.QFJK7818.mta10.adelphia.net@DGBP7M81> for ; Sun, 8 Oct 2006 19:53:19 -0400 Message-ID: <003201c6eb34$ee47d6b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 8 Oct 2006 16:53:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ltru] Draft-4645bis-01 posted to Web site X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've uploaded draft-ietf-ltru-4645bis-01 to my Web site in all three formats: http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.html http://users.adelphia.net/~dewell/draft-ietf-ltru-4645bis-01.xml Included is a new Changes section, reproduced below: This memo is a new work, not an incremental update. The procedure for populating the original Language Subtag Registry, specified by the earlier [RFC4646], is included by reference to [RFC4645]. Therefore, no changes from [RFC4645] are listed in this section. Changes between draft-ietf-ltru-4645bis-00 and this version are: o Removed Comments fields of the form "replaced by ISO code xxx", which provided no additional information beyond the Preferred- Value field. o Clarified that the included Registry contents are a complete replacement for the existing Registry, not a set of deltas. (J. Cowan) o Changed "included within" a macrolanguage to use "encompassed by" throughout. (J. Cowan) o Added explanation of special handling of subtag for Western Frisian. o Provided better explanation for deprecation of "zh-min" in Section 2.4. (J. Cowan) o Added Changes and Acknowledgements sections. I will post the whole draft (minus Registry contents) to the list if anyone wants it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 08 22:35:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWkz6-0003jG-6i; Sun, 08 Oct 2006 22:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWkz4-0003jB-Id for ltru@lists.ietf.org; Sun, 08 Oct 2006 22:35:14 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWkz3-0006Te-2u for ltru@lists.ietf.org; Sun, 08 Oct 2006 22:35:14 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GWkyt-0000f8-6E for ltru@lists.ietf.org; Mon, 09 Oct 2006 04:35:03 +0200 Received: from pd9fba903.dip0.t-ipconnect.de ([217.251.169.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 04:35:03 +0200 Received: from nobody by pd9fba903.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 04:35:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 09 Oct 2006 04:22:40 +0200 Organization: Lines: 77 Message-ID: <4529B270.2B8D@xyzzy.claranet.de> References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <45083F66.7E6E@xyzzy.claranet.de> <45085EDF.9020600@levkowetz.com> <4508693E.1ECA@xyzzy.claranet.de> <45086D7C.9040208@levkowetz.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------483D59C833B6" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba903.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tools-discuss@ietf.org Subject: [Ltru] Re: Tiny URLs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --------------483D59C833B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: > I actually shortened it a little bit further just after > I sent off the previous : > http://tools.ietf.org/rfcdiff?url2=http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-01.txt&difftype=--hwdiff Today I played again with it using the worst case input, an LTRU draft with about 870 pages. While that worked without problems my browser managed to crash my box with the resulting 2 MB html diff. No issue with an abdiff or hwdiff. After that I tested two other tricks: Removing http://tools.ietf.org/id/ for "local" (your POV) drafts ran into problems on your side, you probably got an error log somewhere. The second test was to remove ...-02.txt from a "local" I-D draft-carpenter-rescind-3683-02.txt (as an example): is okay, this automatically finds the last ...-02.txt But it failed as rfcdiff?url2= value. This could be a nice feature if open lists or WGs discuss "official" I-Ds, and need a diff between "this" (the last) and the prior version. The diff-URL (e.g. a tiny URL) would be constant for "official" (= "local") I-Ds. Just an idea, maybe it's bogus, for LTRU we often talk about "private" versions (editor's copy + predecessor). I've added a simple url2-form below, maybe you can use it on the rfcdiff page. Frank --------------483D59C833B6 Content-Type: text/html; charset=us-ascii; name="rfcdiff.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rfcdiff.htm" rfcdiff url2-form

rfcdiff url2-form

--------------483D59C833B6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --------------483D59C833B6-- From ltru-bounces@ietf.org Sun Oct 08 23:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWm16-0007kF-KN; Sun, 08 Oct 2006 23:41:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWm15-0007fD-UL for ltru@lists.ietf.org; Sun, 08 Oct 2006 23:41:23 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWlpF-0005xD-3h for ltru@lists.ietf.org; Sun, 08 Oct 2006 23:29:10 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWlp9-00029j-5n for ltru@lists.ietf.org; Mon, 09 Oct 2006 05:29:03 +0200 Received: from pd9fba903.dip0.t-ipconnect.de ([217.251.169.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 05:29:03 +0200 Received: from nobody by pd9fba903.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 05:29:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 09 Oct 2006 05:28:08 +0200 Organization: Lines: 7 Message-ID: <4529C1C8.6E21@xyzzy.claranet.de> References: <20060913153749.GL10145@ccil.org> <450836B0.4010008@yahoo-inc.com> <45083F66.7E6E@xyzzy.claranet.de> <45085EDF.9020600@levkowetz.com> <4508693E.1ECA@xyzzy.claranet.de> <45086D7C.9040208@levkowetz.com> <4529B270.2B8D@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba903.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ltru] Re: Tiny URLs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Sorry, that wasn't supposed to go to LTRU. Here's the URL for a "hwdiff" of Doug's -01pre (of course it's huge): http://tools.ietf.org/rfcdiff?url2=http%3A%2F%2Fusers.adelphia.net%2F%7Edewell%2Fdraft-ietf-ltru-4645bis-01.txt&difftype=--hwdiff Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 00:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWmTa-0000hW-Pf; Mon, 09 Oct 2006 00:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWmTZ-0000hO-Mh for ltru@lists.ietf.org; Mon, 09 Oct 2006 00:10:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWmTW-0002Sw-Vu for ltru@lists.ietf.org; Mon, 09 Oct 2006 00:10:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWmTH-0002mp-Gx for ltru@lists.ietf.org; Mon, 09 Oct 2006 06:10:31 +0200 Received: from pd9fba903.dip0.t-ipconnect.de ([217.251.169.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 06:10:31 +0200 Received: from nobody by pd9fba903.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 06:10:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 09 Oct 2006 06:09:27 +0200 Organization: Lines: 17 Message-ID: <4529CB77.592D@xyzzy.claranet.de> References: <003201c6eb34$ee47d6b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba903.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Draft-4645bis-01 posted to Web site X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Changes between draft-ietf-ltru-4645bis-00 and this version are: [...] Apparently you've removed ME and RS, please re-insert these codes. Is still up to date ? It's rather old, oddities like zza-diq and zza-kiu might be already obsolete (i.e. you'd remove the prose about it). Why did you keep frr near fy, but move frs ? You wanted to sort the language tags by length (of course that makes only sense for lengths 2, 3, and 4), with that order I'd expect frr near frs. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 01:18:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWnX2-00068x-0d; Mon, 09 Oct 2006 01:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWnX1-00067S-3n for ltru@ietf.org; Mon, 09 Oct 2006 01:18:27 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWnWx-0008Hs-OC for ltru@ietf.org; Mon, 09 Oct 2006 01:18:27 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061009051821.VXYD23918.mta9.adelphia.net@DGBP7M81>; Mon, 9 Oct 2006 01:18:21 -0400 Message-ID: <004001c6eb62$56445900$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 8 Oct 2006 22:18:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Frank Ellermann Subject: [Ltru] Re: Draft-4645bis-01 posted to Web site X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Apparently you've removed ME and RS, please re-insert these codes. I'm supposed to wait until these additions (and the deprecation of CS) are reflected in the current Registry. As I pointed out in http://www1.ietf.org/mail-archive/web/ltru/current/msg06019.html, it was actually presumptuous and a mistake for me to have included these "pending" changes in draft-4645bis-00. The changes have been sent off to IANA, but they aren't official until IANA posts a new Registry. This is different from including the various "pending" changes in ISO/FDIS 639-3, such as the addition of "nqo" and "zza", the correction of the Frisian "fri"/"fy" problem, and the name change from "(generic)" and "(specific)" to "(macrolanguage)" and blank. Each of these has been mentioned by Peter Constable as a change that either has been made in the FDIS already, or will be made the next time ISO 639 RA/JAC meets. Since 639-3 is not released yet, its contents are unofficial and we can treat them in the drafts with some flexibility. > Is still up > to date ? It's rather old, oddities like zza-diq and zza-kiu might be > already obsolete (i.e. you'd remove the prose about it). It is the version still available for download at http://www.sil.org/iso639-3/download.asp, which is why I'm still referencing it. If there is a newer version, it hasn't been made available to me. > Why did you keep frr near fy, but move frs ? You wanted to sort the > language tags by length (of course that makes only sense for lengths > 2, 3, and 4), with that order I'd expect frr near frs. I didn't do that. IANA put "frr" between "fr" and "fy" as part of the 2006-03-08 update. They also put "anp" between "an" and "ar", but there were several other new language subtags in that update ("frr", "gsw", "krl", "zxx") and those were all placed in the logical location. I've criticized that strange ordering many times as being counterintuitive, and most recently proposed to "fix" it in draft-4645bis, but it's been pointed out to me that RFC 4646 Section 5.1 does not require any particular order to the subtags in the Registry, except that all records of a given type must be together (and I don't even think that is necessary, if visual readability doesn't matter). So I don't worry about it any more. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 02:57:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWp4n-0006G0-RJ; Mon, 09 Oct 2006 02:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWp4m-0006Fo-OU for ltru@lists.ietf.org; Mon, 09 Oct 2006 02:57:24 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWp4l-0000pu-Eh for ltru@lists.ietf.org; Mon, 09 Oct 2006 02:57:24 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWp4j-0007zC-39 for ltru@lists.ietf.org; Mon, 09 Oct 2006 08:57:21 +0200 Received: from pd9fba903.dip0.t-ipconnect.de ([217.251.169.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 08:57:21 +0200 Received: from nobody by pd9fba903.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Oct 2006 08:57:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 09 Oct 2006 08:56:54 +0200 Organization: Lines: 31 Message-ID: <4529F2B6.34ED@xyzzy.claranet.de> References: <004001c6eb62$56445900$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba903.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] Re: Draft-4645bis-01 posted to Web site X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: [ME + RS] > The changes have been sent off to IANA, but they aren't official > until IANA posts a new Registry. Okay. > IANA put "frr" between "fr" and "fy" as part of the 2006-03-08 > update. Odd, why did they use another logic for frs ? They can pick any style they like, alphabetically, chronologically, "input order" (= 4645 style), or something else, but using different styles for subtags frr and frs submitted simultaneously is surprising. > RFC 4646 Section 5.1 does not require any particular order to > the subtags in the Registry, except that all records of a given > type must be together Yes, but didn't you want to use the same "input order" as for 4645 again, length before alphabetical ? Keeping the old subtags in whatever order you found is also okay, and changing it would screw up "diffs". But IMO you're also free to sort the subtags per section, because it's a replacement registry, not an update. If you don't want that anymore it's fine, I was just curious why frr and frs ended up in different parts. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 04:49:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqpA-0005sx-Pe; Mon, 09 Oct 2006 04:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqp9-0005rE-Um for ltru@ietf.org; Mon, 09 Oct 2006 04:49:24 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWqp8-0003Vr-Lw for ltru@ietf.org; Mon, 09 Oct 2006 04:49:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id CD09926C12C; Mon, 9 Oct 2006 10:49:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5416D26C0D0; Mon, 9 Oct 2006 10:49:00 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 5137758ED1B; Mon, 9 Oct 2006 10:49:00 +0200 (CEST) Date: Mon, 9 Oct 2006 10:49:00 +0200 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20061009084900.GA19453@nic.fr> References: <20061004134200.GC15633@ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061004134200.GC15633@ccil.org> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, Oct 04, 2006 at 09:42:00AM -0400, John Cowan wrote a message of 72 lines which said: > A proposal: +1 > The 4646bis registry should capture the language type information > from ISO 639-3. Each language, including macrolanguages, is labeled > in -3 as either living, extinct, ancient, historic, or constructed. I think the more information, the better (*), IF AND ONLY IF: ** this new information does not require a new source when building the registry, (because such a new source would complicate the building process and would add one more dependency, would add one more standard to track, etc), ** this new tag does not bother the existing parsers. To me, this proposal comply with these two rules, so I agree with. (*) : I let the UI people decide if this is useful for the specific issue of trimming the language list ; but, even if they do not use it, others may be. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 09:44:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvQH-0001Eb-5P; Mon, 09 Oct 2006 09:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvQG-0001EW-G5 for ltru@ietf.org; Mon, 09 Oct 2006 09:44:00 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWvQE-0003XY-6N for ltru@ietf.org; Mon, 09 Oct 2006 09:44:00 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061009134357.REUG7818.mta10.adelphia.net@DGBP7M81>; Mon, 9 Oct 2006 09:43:57 -0400 Message-ID: <020001c6eba8$f8b6cb00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 9 Oct 2006 06:43:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Frank Ellermann Subject: [Ltru] Re: Draft-4645bis-01 posted to Web site X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> IANA put "frr" between "fr" and "fy" as part of the 2006-03-08 >> update. > > Odd, why did they use another logic for frs ? They can pick any style > they like, alphabetically, chronologically, "input order" (= 4645 > style), or something else, but using different styles for subtags frr > and frs submitted simultaneously is surprising. I'm sure it was an error. Everyone seems sure it was an error. >> RFC 4646 Section 5.1 does not require any particular order to the >> subtags in the Registry, except that all records of a given type must >> be together > > Yes, but didn't you want to use the same "input order" as for 4645 > again, length before alphabetical ? Keeping the old subtags in > whatever order you found is also okay, and changing it would screw up > "diffs". But IMO you're also free to sort the subtags per section, > because it's a replacement registry, not an update. Last month when I asked about it again, in preparation for writing draft-4645bis-00, I was told that I should not try to correct these. John Cowan pointed out that a process can load the entire Registry into memory and sort it however it sees fit. I think this was in the September 20 time frame. > If you don't want that anymore it's fine, I was just curious why frr > and frs ended up in different parts. It isn't what I want, but it's what the group agreed to, and it wasn't important enough to me to continue fighting about it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 11:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwju-0003MZ-Li; Mon, 09 Oct 2006 11:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwjt-0003MU-EQ for ltru@ietf.org; Mon, 09 Oct 2006 11:08:21 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwjs-0000jx-5C for ltru@ietf.org; Mon, 09 Oct 2006 11:08:21 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1633990wxc for ; Mon, 09 Oct 2006 08:08:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=m2YUrStHLUvmI1tQZGWoFzFbYrrbk3UodvhFQtgU/J/4Ix9VhFJesQMHQPfjG6QIQSMZKMJDrFvZhTpDzVJcZrFc/tcTv4Yj+ZgOfygPv73ZrPGubSqEyGCb5jpt4QIhNsAvSONeNn9lUHKxSiRKzrF3s1Z6S8Dl835F/p+EEKg= Received: by 10.90.83.14 with SMTP id g14mr2663301agb; Mon, 09 Oct 2006 08:08:19 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Mon, 9 Oct 2006 08:08:19 -0700 (PDT) Message-ID: <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> Date: Mon, 9 Oct 2006 08:08:19 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field In-Reply-To: <20061009084900.GA19453@nic.fr> MIME-Version: 1.0 References: <20061004134200.GC15633@ccil.org> <20061009084900.GA19453@nic.fr> X-Google-Sender-Auth: cf0d8b698cea407e X-Spam-Score: 0.5 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0731164529==" Errors-To: ltru-bounces@ietf.org --===============0731164529== Content-Type: multipart/alternative; boundary="----=_Part_45105_17151324.1160406499811" ------=_Part_45105_17151324.1160406499811 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline -1 I think this is outside of the scope of the registry. Where will this stop? Population of languages? Geographic area spoken? Population density? ..... The purpose of the registry is to distinguish one language from another. No more, no less. Mark On 10/9/06, Stephane Bortzmeyer wrote: > > On Wed, Oct 04, 2006 at 09:42:00AM -0400, > John Cowan wrote > a message of 72 lines which said: > > > A proposal: > > +1 > > > The 4646bis registry should capture the language type information > > from ISO 639-3. Each language, including macrolanguages, is labeled > > in -3 as either living, extinct, ancient, historic, or constructed. > > I think the more information, the better (*), IF AND ONLY IF: > > ** this new information does not require a new source when building > the registry, (because such a new source would complicate the building > process and would add one more dependency, would add one more standard > to track, etc), > > ** this new tag does not bother the existing parsers. > > To me, this proposal comply with these two rules, so I agree with. > > (*) : I let the UI people decide if this is useful for the specific > issue of trimming the language list ; but, even if they do not use it, > others may be. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_45105_17151324.1160406499811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline -1

I think this is outside of the scope of the registry. Where will this stop? Population of languages? Geographic area spoken? Population density? .....

The purpose of the registry is to distinguish one language from another. No more, no less.

Mark

On 10/9/06, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Wed, Oct 04, 2006 at 09:42:00AM -0400,
John Cowan <cowan@ccil.org> wrote
a message of 72 lines which said:

> A proposal:

+1

> The 4646bis registry should capture the language type information
> from ISO 639-3.  Each language, including macrolanguages, is labeled
> in -3 as either living, extinct, ancient, historic, or constructed.

I think the more information, the better (*), IF AND ONLY IF:

** this new information does not require a new source when building
the registry, (because such a new source would complicate the building
process and would add one more dependency, would add one more standard
to track, etc),

** this new tag does not bother the existing parsers.

To me, this proposal comply with these two rules, so I agree with.

(*) : I let the UI people decide if this is useful for the specific
issue of trimming the language list ; but, even if they do not use it,
others may be.


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

------=_Part_45105_17151324.1160406499811-- --===============0731164529== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0731164529==-- From ltru-bounces@ietf.org Mon Oct 09 11:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwpe-0005Ml-R5; Mon, 09 Oct 2006 11:14:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwpd-0005Mg-CY for ltru@ietf.org; Mon, 09 Oct 2006 11:14:17 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwpb-0001Od-3Y for ltru@ietf.org; Mon, 09 Oct 2006 11:14:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7AE0826C205; Mon, 9 Oct 2006 17:14:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CC0CE26C203; Mon, 9 Oct 2006 17:13:58 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C8F9B58ED26; Mon, 9 Oct 2006 17:13:58 +0200 (CEST) Date: Mon, 9 Oct 2006 17:13:58 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20061009151358.GA29503@nic.fr> References: <20061004134200.GC15633@ccil.org> <20061009084900.GA19453@nic.fr> <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Oct 09, 2006 at 08:08:19AM -0700, Mark Davis wrote a message of 66 lines which said: > Where will this stop? Where I said: > > IF AND ONLY IF: > > > >** this new information does not require a new source when building > >the registry, > Population of languages? Geographic area spoken? Population density? > ..... They are not in ISO 639, nor in any other "source standard" of the language tag registry. But I can add another criterium: ** this new information is "stable" (yes, I know that "stable" is fuzzy but there is no doubt that the actual population figure is less stable than the fact that it is a living language or not) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 12:15:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxn7-0008Hi-PY; Mon, 09 Oct 2006 12:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxkJ-0006N6-Or for ltru@ietf.org; Mon, 09 Oct 2006 12:12:51 -0400 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWxa3-0007aX-Kp for ltru@ietf.org; Mon, 09 Oct 2006 12:02:18 -0400 Received: (qmail 5627 messnum 11068992 invoked from network[194.125.174.105/ts09-105.dublin.indigo.ie]); 9 Oct 2006 16:02:13 -0000 Received: from ts09-105.dublin.indigo.ie (HELO ?194.125.174.105?) (194.125.174.105) by mail11.svc.cra.dublin.eircom.net (qp 5627) with SMTP; 9 Oct 2006 16:02:13 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> References: <20061004134200.GC15633@ccil.org> <20061009084900.GA19453@nic.fr> <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Mon, 9 Oct 2006 16:59:53 +0000 To: ltru@ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org To you and to me (and all other fully-employed persons) yes, it is, =20 but to hobbyists it may well be an interesting activity to be =20 perpetuated for ever/as long as gamers exist with more idle time on =20 their hands than the likes of us. :-( mg On 9 Oct 2006, at 15:08, scr=EDobh Mark Davis: > -1 > > I think this is outside of the scope of the registry. Where will =20 > this stop? Population of languages? Geographic area spoken? =20 > Population density? ..... > > The purpose of the registry is to distinguish one language from =20 > another. No more, no less. > > Mark - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 15:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0wh-000339-Og; Mon, 09 Oct 2006 15:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0wg-000334-AT for ltru@ietf.org; Mon, 09 Oct 2006 15:37:50 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX0we-0003WD-1Q for ltru@ietf.org; Mon, 09 Oct 2006 15:37:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 703DA26C158; Mon, 9 Oct 2006 21:37:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CE64A26C038; Mon, 9 Oct 2006 21:37:31 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id B1A0A58ED26; Mon, 9 Oct 2006 21:37:31 +0200 (CEST) Date: Mon, 9 Oct 2006 21:37:31 +0200 From: Stephane Bortzmeyer To: Marion Gunn Message-ID: <20061009193731.GA2247@nic.fr> References: <20061004134200.GC15633@ccil.org> <20061009084900.GA19453@nic.fr> <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Mon, Oct 09, 2006 at 04:59:53PM +0000, Marion Gunn wrote a message of 31 lines which said: > To you and to me (and all other fully-employed persons) yes, it is, > but to hobbyists it may well be an interesting activity to be > perpetuated for ever/as long as gamers exist with more idle time on > their hands than the likes of us. :-( May be my english is too limited, but it seems quite insulting to people who disagree with you? I suggest to *not* imply that disagreement == lack of a real job and time to kill. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 16:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1Gi-0002cZ-5A; Mon, 09 Oct 2006 15:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1GJ-0001kK-NW for ltru@ietf.org; Mon, 09 Oct 2006 15:58:08 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX1Fl-0007gk-0V for ltru@ietf.org; Mon, 09 Oct 2006 15:58:07 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GX1Fk-0005IU-KN; Mon, 09 Oct 2006 15:57:32 -0400 Date: Mon, 9 Oct 2006 15:57:32 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field Message-ID: <20061009195732.GD31563@ccil.org> References: <20061004134200.GC15633@ccil.org> <20061009084900.GA19453@nic.fr> <30b660a20610090808q11a159d9lc37c8a7b4dd18cd1@mail.gmail.com> <20061009193731.GA2247@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061009193731.GA2247@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > May be my english is too limited, but it seems quite insulting to > people who disagree with you? I suggest to *not* imply that > disagreement == lack of a real job and time to kill. My apologies for hijacking the list, but an attempt to send a private reply to you bounced from the address bortzmeyer@nic.fr with "No route to host: retry timeout exceeded". Can you provide a working address on your outgoing email, at least in the signature line? -- John Cowan http://ccil.org/~cowan cowan@ccil.org Lope de Vega: "It wonders me I can speak at all. Some caitiff rogue did rudely yerk me on the knob, wherefrom my wits still wander." An Englishman: "Ay, a filchman to the nab betimes 'll leave a man crank for a spell." --Harry Turtledove, Ruled Britannia _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 18:01:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3Bc-0002Bz-1H; Mon, 09 Oct 2006 18:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3Bb-00028k-4L for ltru@ietf.org; Mon, 09 Oct 2006 18:01:23 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX32i-0006qd-Gp for ltru@ietf.org; Mon, 09 Oct 2006 17:52:14 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 68A471E14AB for ; Mon, 9 Oct 2006 14:52:09 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <4S786VD0>; Mon, 9 Oct 2006 14:52:09 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: ltru@ietf.org Subject: RE: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Mon, 9 Oct 2006 14:52:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, How about attacking this proposal based on facts, rather than unrelated topics or grumpiness (not in good taste, Marion)? draft-ietf-ltru-4646bis-00.txt gives advice based on the type of the ISO 639-3 language code. What possible reason is there to say "that's the problem of the user to research", when it's fundamental to the rationale behind every code in ISO 639-3? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: Monday, October 09, 2006 11:08 AM To: Stephane Bortzmeyer Cc: ltru@ietf.org Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field -1 I think this is outside of the scope of the registry. Where will this stop? Population of languages? Geographic area spoken? Population density? ..... The purpose of the registry is to distinguish one language from another. No more, no less. Mark On 10/9/06, Stephane Bortzmeyer wrote: On Wed, Oct 04, 2006 at 09:42:00AM -0400, John Cowan wrote a message of 72 lines which said: > A proposal: +1 > The 4646bis registry should capture the language type information > from ISO 639-3. Each language, including macrolanguages, is labeled > in -3 as either living, extinct, ancient, historic, or constructed. I think the more information, the better (*), IF AND ONLY IF: ** this new information does not require a new source when building the registry, (because such a new source would complicate the building process and would add one more dependency, would add one more standard to track, etc), ** this new tag does not bother the existing parsers. To me, this proposal comply with these two rules, so I agree with. (*) : I let the UI people decide if this is useful for the specific issue of trimming the language list ; but, even if they do not use it, others may be. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date: 10/7/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 19:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX4RV-0003cY-KM; Mon, 09 Oct 2006 19:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX4RU-0003bG-D7 for ltru@ietf.org; Mon, 09 Oct 2006 19:21:52 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX4RT-0007z6-1M for ltru@ietf.org; Mon, 09 Oct 2006 19:21:52 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k99NLaEQ005859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Oct 2006 16:21:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=tIZf/dJWYWXTnNPLAqgE1hFZP1We1eTmF7NnsdnlnuszM3Hlnr+TwRnaiUSTELMw Message-ID: <452AD980.8050301@yahoo-inc.com> Date: Mon, 09 Oct 2006 16:21:36 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "McDonald, Ira" Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field References: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > > draft-ietf-ltru-4646bis-00.txt gives advice based on the type > of the ISO 639-3 language code. What possible reason is > there to say "that's the problem of the user to research", > when it's fundamental to the rationale behind every code > in ISO 639-3? > Upon further review, I find that I'm more of Mark's persuasion. John's proposal appeared, at first, to me to provide some way to distinguish "collective" languages and "macro-languages", but, in fact, it only distinguishes the former and not the latter. It then goes on to distinguish a number of other language characteristics (most of which are inherent in the language itself: users of the respective languages know that Middle English is "ancient" or "extinct", or that Klingon is constructed) At present, it would be useful to identify which language codes are macro-languages, i.e. which ones can "bear" an extlang (and which ones cannot) and reflect that in the registry. The information about extinct, ancient, historic, or constructedness of languages is "interesting", but not really necessary to the functions of the registry. The ILSR is not a replacement for ISO 639. I would support John's proposal fully if and only if it distinguished collective and macro languages for use in the registration process. Otherwise, as written: -1 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 21:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX5zn-0004SW-R9; Mon, 09 Oct 2006 21:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX5zm-0004RZ-Fb for ltru@ietf.org; Mon, 09 Oct 2006 21:01:22 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX5rc-0007Nq-5A for ltru@ietf.org; Mon, 09 Oct 2006 20:52:57 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9A0qtOc007942 for ; Tue, 10 Oct 2006 09:52:55 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7cbb_aa297f9c_57f9_11db_921c_0014221f2a2d; Tue, 10 Oct 2006 09:52:54 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35357) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 10 Oct 2006 09:52:43 +0900 Message-Id: <6.0.0.20.2.20061009180149.06995380@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 09 Oct 2006 18:05:06 +0900 To: "Mark Davis" , "John Cowan" From: Martin Duerst Subject: Re: [Ltru] Re: Registry deltas In-Reply-To: <30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.co m> References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> <30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat off] At 02:22 06/10/03, Mark Davis wrote: >Overall, I think inverted names are a bad idea. They are rather anglocentric, and we find that translators often do the wrong thing with them. They are also hugely inconsistent in the current registry. > >I think they are tolerable if (a) every single instance of a comma indicates an inverted name, and (b) all names are consistently inverted. Because of (a) one could programmatically fix the names to the correct value. I don't think creating artificial syntax rules or some kind of restricted (English) grammar for Description fields is appropriate. What I can immagine is that we use semicolons rather than commas to indicate boundaries between input from different origins. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 09 23:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX84J-00012y-D0; Mon, 09 Oct 2006 23:14:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX84H-00012t-PE for ltru@ietf.org; Mon, 09 Oct 2006 23:14:09 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX84G-0006gL-Ik for ltru@ietf.org; Mon, 09 Oct 2006 23:14:09 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GX84F-0004QC-Bn; Mon, 09 Oct 2006 23:14:07 -0400 Date: Mon, 9 Oct 2006 23:14:07 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field Message-ID: <20061010031407.GE31563@ccil.org> References: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> <452AD980.8050301@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452AD980.8050301@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > I would support John's proposal fully if and only if it > distinguished collective and macro languages for use in the > registration process. I have no problem with adding "macrolanguage" as an additional type; it's a fine idea. The information is technically redundant (a language is a macrolanguage if and only if it appears in the Prefix field of an extlang), but handy to have on the spot. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck cowan@ccil.org soup the rest of your life. --Groucho _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 02:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXAgN-0005KG-A1; Tue, 10 Oct 2006 02:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXAgL-0005HN-Mg for ltru@ietf.org; Tue, 10 Oct 2006 02:01:37 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXAfO-0003Lw-CM for ltru@ietf.org; Tue, 10 Oct 2006 02:00:43 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.647.8; Mon, 9 Oct 2006 23:00:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 9 Oct 2006 23:00:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Mon, 9 Oct 2006 22:55:11 -0700 Message-ID: In-Reply-To: <452AD980.8050301@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Proposal: include new "Language-Type:" field thread-index: Acbr+butH4RBKxc+StGXRhYmNQDPSwANW0dA References: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> <452AD980.8050301@yahoo-inc.com> From: Peter Constable To: Addison Phillips , "McDonald, Ira" X-OriginalArrivalTime: 10 Oct 2006 06:00:11.0382 (UTC) FILETIME=[58C9F160:01C6EC31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1017998157==" Errors-To: ltru-bounces@ietf.org --===============1017998157== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBZGRpc29uIFBoaWxsaXBzIFtt YWlsdG86YWRkaXNvbkB5YWhvby1pbmMuY29tXSANCg0KPiBVcG9uIGZ1cnRoZXIgcmV2aWV3LCBJ IGZpbmQgdGhhdCBJJ20gbW9yZSBvZiBNYXJrJ3MgcGVyc3Vhc2lvbi4gSm9obidzIA0KPiBwcm9w b3NhbCBhcHBlYXJlZCwgYXQgZmlyc3QsIHRvIG1lIHRvIHByb3ZpZGUgc29tZSB3YXkgdG8gZGlz dGluZ3Vpc2ggDQo+ICJjb2xsZWN0aXZlIiBsYW5ndWFnZXMgYW5kICJtYWNyby1sYW5ndWFnZXMi LCBidXQsIGluIGZhY3QsIGl0IG9ubHkgDQo+IGRpc3Rpbmd1aXNoZXMgdGhlIGZvcm1lciBhbmQg bm90IHRoZSBsYXR0ZXIuDQoNCkkga2luZCBvZiBleHBlY3QgeW91J2xsIHNlZSB0aGVzZSBhdHRy aWJ1dGVzIGNhcnJpZWQgb3ZlciBpbnRvIG90aGVyIHBhcnRzIG9mIElTTyA2MzkgaW4gdGhlIGZ1 dHVyZS4NCg0KDQo+IEl0IHRoZW4gZ29lcyBvbiB0byANCj4gZGlzdGluZ3Vpc2ggYSBudW1iZXIg b2Ygb3RoZXIgbGFuZ3VhZ2UgY2hhcmFjdGVyaXN0aWNzIChtb3N0IG9mIHdoaWNoIA0KPiBhcmUg aW5oZXJlbnQgaW4gdGhlIGxhbmd1YWdlIGl0c2VsZjogdXNlcnMgb2YgdGhlIHJlc3BlY3RpdmUg bGFuZ3VhZ2VzIA0KPiBrbm93IHRoYXQgTWlkZGxlIEVuZ2xpc2ggaXMgImFuY2llbnQiIG9yICJl eHRpbmN0Iiwgb3IgdGhhdCBLbGluZ29uIGlzIA0KPiBjb25zdHJ1Y3RlZCkNCg0KQnV0IHRoYXQn cyBub3QgdGhlIG9ubHkgcG9pbnQuIElmIHNvbWVvbmUgaXMgbG9va2luZyBhdCBhbiBlbnRyeSAi Rm9vIiBhbmQgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaWYgaXQncyByZWZlcnJpbmcgdG8gdGhlIHNh bWUgbGFuZ3VhZ2UgdGhleSBrbm93IGFzICJQaHUiLCB3aGljaCBpcyBzcG9rZW4gaW4gTmV3IFBo dWluZWEsIHNlZWluZyB0aGF0IGl0J3MgdHlwZSBpcyBDb25zdHJ1Y3RlZCAoc2F5KSwgb3IgQW5j aWVudCAoc2F5KSB3b3VsZCBnaXZlIHRoZW0gYSBzdHJvbmcgY2x1ZSB0aGF0IGl0J3Mgbm90Lg0K DQoNCg0KPiBJIHdvdWxkIHN1cHBvcnQgSm9obidzIHByb3Bvc2FsIGZ1bGx5IGlmIGFuZCBvbmx5 IGlmIGl0IGRpc3Rpbmd1aXNoZWQgDQo+IGNvbGxlY3RpdmUgYW5kIG1hY3JvIGxhbmd1YWdlcyBm b3IgdXNlIGluIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KSSBjZXJ0YWlubHkgdGhpbmsg d2Ugc2hvdWxkIGlkZW50aWZ5IGNhdGVnb3JpZXMgd2l0aCBib3RoIG9mIHRoZXNlIHNjb3BlcyBj bGVhcmx5Lg0KDQoNCg0KUGV0ZXIgQ29uc3RhYmxlDQo= --===============1017998157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1017998157==-- From ltru-bounces@ietf.org Tue Oct 10 02:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXB8f-0000tY-Cf; Tue, 10 Oct 2006 02:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXB8e-0000tI-49 for ltru@ietf.org; Tue, 10 Oct 2006 02:30:52 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXB8b-0000AW-Qu for ltru@ietf.org; Tue, 10 Oct 2006 02:30:52 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061010063049.WKRN23918.mta9.adelphia.net@DGBP7M81>; Tue, 10 Oct 2006 02:30:49 -0400 Message-ID: <004a01c6ec35$a0e06480$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <003501c6e77e$e8f6ecf0$6401a8c0@DGBP7M81> <6.0.0.20.2.20061009170804.023ab930@localhost> Subject: Re: [Ltru] CS, ME, RS in 4645bis Date: Mon, 9 Oct 2006 23:30:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I'm a bit surprised this comes to the LTRU list. How exactly > to register ME and RS, and what exactly to do with CS, is > a registration issue and therefore belongs to ietf-languages. > If and when it's sorted out, you can just reflect it in > the 4645bis draft. If it's not sorted out by the time we > are finished with the current two drafts, it just will > get updated later. I apologize for sending half of that message to the wrong list. The issue with registering the region subtags, which belonged on ietf-languages, has run its course by now. I sent Michael the registration forms and he forwarded them to IANA last Thursday, and now we're just waiting for IANA to post the new Registry. The part that was on-topic was whether they belong in draft-4645bis, and the answer is, they don't -- not until they appear in the live Registry. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 02:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBNt-0006t8-Dy; Tue, 10 Oct 2006 02:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBNs-0006t3-Fs for ltru@ietf.org; Tue, 10 Oct 2006 02:46:36 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXBNr-00032d-7B for ltru@ietf.org; Tue, 10 Oct 2006 02:46:36 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061010064634.WTDC23918.mta9.adelphia.net@DGBP7M81> for ; Tue, 10 Oct 2006 02:46:34 -0400 Message-ID: <005101c6ec37$d485c210$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 9 Oct 2006 23:46:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > I think the more information, the better (*), IF AND ONLY IF: > > ** this new information does not require a new source when building > the registry, (because such a new source would complicate the building > process and would add one more dependency, would add one more standard > to track, etc), It comes from the same ISO 639-3 data file as the other data. > ** this new tag does not bother the existing parsers. Existing parsers could be designed in one of two ways: either they could ignore an unknown field, or they could abort with an error. My guess is that most parsers will fall into the second category (my Registry-to-DLL converter does). This is true for any other possible change to the Registry structure, including the proposed Script field that would replace Suppress-Script. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 02:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBSm-0001l6-RR; Tue, 10 Oct 2006 02:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBSm-0001ks-1e for ltru@ietf.org; Tue, 10 Oct 2006 02:51:40 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXBSk-0003hi-P8 for ltru@ietf.org; Tue, 10 Oct 2006 02:51:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061010065138.BWAF7818.mta10.adelphia.net@DGBP7M81> for ; Tue, 10 Oct 2006 02:51:38 -0400 Message-ID: <005501c6ec38$89591c00$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 9 Oct 2006 23:51:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: Proposal: include new "Language-Type:" field X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I think this is outside of the scope of the registry. Where will this > stop? Population of languages? Geographic area spoken? Population > density? ..... The proposal requires only what is present in the existing ISO/FDIS 639-3 data files. > The purpose of the registry is to distinguish one language from > another. No more, no less. In that case, we should get rid of all script-suggestion mechanisms; those don't distinguish languages either. I expressed my views in http://www1.ietf.org/mail-archive/web/ltru/current/msg06035.html. That is the last I'll have to say about it. Martin has placed me in the correct column. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 03:53:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCQa-0004Nd-GA; Tue, 10 Oct 2006 03:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCQZ-0004NX-5z for ltru@lists.ietf.org; Tue, 10 Oct 2006 03:53:27 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXCQW-0005c9-Ai for ltru@lists.ietf.org; Tue, 10 Oct 2006 03:53:27 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9A7r9ch007803 for ; Tue, 10 Oct 2006 16:53:12 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7c9b_5f481ad4_5834_11db_9c26_0014221f2a2d; Tue, 10 Oct 2006 16:53:09 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46543) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 10 Oct 2006 16:52:58 +0900 Message-Id: <6.0.0.20.2.20061010161256.04c3f290@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 10 Oct 2006 16:13:24 +0900 To: ltru@lists.ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Ltru] Fwd: Internet-Drafts Submission Cutoff Dates for the 67th IETF Meeting in San Diego, California, USA X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org FYI. >To: ietf-announce@ietf.org >From: ietf-secretariat@ietf.org >Date: Mon, 09 Oct 2006 12:20:02 -0400 >Subject: Internet-Drafts Submission Cutoff Dates for the 67th IETF Meeting >in San Diego, California, USA >There are two (2) Internet-Draft cutoff dates for the 67th >IETF Meeting in San Diego, California, USA: > >October 16th: Cutoff Date for Initial (i.e., version -00) >Internet-Draft Submissions > >All initial Internet-Drafts (version -00) must be submitted by Monday, >October 16th at 9:00 AM ET. As always, all initial submissions with a >filename beginning with "draft-ietf" must be approved by the >appropriate WG Chair before they can be processed or announced. The >Secretariat would appreciate receiving WG Chair approval by Monday, >October 9th at 9:00 AM ET. > >October 23rd: Cutoff Date for Revised (i.e., version -01 and higher) >Internet-Draft Submissions > >All revised Internet-Drafts (version -01 and higher) must be submitted >by Monday, October 23rd at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their respective >cutoff dates will not be made available in the Internet-Drafts >directory or announced until on or after Monday, November 6th at 9:00 >AM ET, when Internet-Draft posting resumes. Please do not wait until >the last minute to submit. > >Thank you for your understanding and cooperation. If you have any >questions or concerns, then please send a message to >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 67th IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_67.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 04:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD3e-0004WF-5d; Tue, 10 Oct 2006 04:33:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD3c-0004Vq-QX for ltru@ietf.org; Tue, 10 Oct 2006 04:33:48 -0400 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXD3b-0006Ac-G1 for ltru@ietf.org; Tue, 10 Oct 2006 04:33:48 -0400 Received: (qmail 50782 messnum 6387261 invoked from network[194.125.174.37/ts09-037.dublin.indigo.ie]); 10 Oct 2006 08:33:45 -0000 Received: from ts09-037.dublin.indigo.ie (HELO ?194.125.174.37?) (194.125.174.37) by mail00.svc.cra.dublin.eircom.net (qp 50782) with SMTP; 10 Oct 2006 08:33:45 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> References: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1D86C7D2-40DD-4A34-8B9D-27E017672FE0@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Proposal: include new "Language-Type:" field Date: Tue, 10 Oct 2006 09:31:24 +0000 To: ltru@ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 9 Oct 2006, at 21:52, scr=EDobh McDonald, Ira: > Hi, > > How about attacking this proposal based on facts, rather than > unrelated topics or grumpiness... Dismiss it as Monday grumps, if you will.:-) On 9 Oct 2006, at 23:21, scr=EDobh Addison Phillips: > > Upon further review, I find that I'm more of Mark's persuasion. =20 > John's proposal appeared, at first, to me to provide some way to =20 > distinguish "collective" languages and "macro-languages", but, in =20 > fact, it only distinguishes the former and not the latter... > > The information about extinct, ancient, historic, or =20 > constructedness of languages is "interesting", but not really =20 > necessary to the functions of the registry. The ILSR is not a =20 > replacement for ISO 639. Exactly. On 10 Oct 2006, at 06:51, scr=EDobh Doug Ewell: > ... > The proposal requires only what is present in the existing ISO/FDIS =20= > 639-3 data files. It came across to me as a proposal to push closure further away by =20 moving the goalposts (in ISO parlance, by changing the agreed scope), =20= but if enough people think otherwise, then work away, if time =20 permits, with my blessing. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 09:01:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHEo-0001AZ-4K; Tue, 10 Oct 2006 09:01:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHEm-0001AO-Iy for ltru@lists.ietf.org; Tue, 10 Oct 2006 09:01:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHEj-0006um-5q for ltru@lists.ietf.org; Tue, 10 Oct 2006 09:01:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXHEQ-0007o5-VH for ltru@lists.ietf.org; Tue, 10 Oct 2006 15:01:14 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 15:01:14 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 15:01:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 15:00:11 +0200 Organization: Lines: 20 Message-ID: <452B995B.92F@xyzzy.claranet.de> References: <789E617C880666438EDEE30C2A3E8D10EF2F@mailsrvnt05.enet.sharplabs.com> <452AD980.8050301@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Is 639-3 bogus ? (was: Proposal: include new "Language-Type:" field) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > that's not the only point. If someone is looking at an entry "Foo" > and trying to figure out if it's referring to the same language they > know as "Phu", which is spoken in New Phuinea, seeing that it's type > is Constructed (say), or Ancient (say) would give them a strong clue > that it's not. That's the job of a comment or description. For "orq" I found that it is "colloquial blackspeech" spoken in "no man's land". Now does that cover Yrch as spoken by the Uruk Hai in Morannon or not, and why would anybody look into a IANA registry for such details ? Maybe "orq" should get Shavian as Suppress-Script and proclaim Sealand as their micronation. Seriously, does 639-3 allow to register almost anything ? What's the justification to list "orq" except from the fun aspect ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 11:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJUl-0002au-FQ; Tue, 10 Oct 2006 11:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJUj-0002ap-Rs for ltru@lists.ietf.org; Tue, 10 Oct 2006 11:26:13 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJUe-0003Gc-Ec for ltru@lists.ietf.org; Tue, 10 Oct 2006 11:26:13 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 08:26:07 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 08:25:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Is 639-3 bogus ? (was: Proposal: include new"Language-Type:" field) Date: Tue, 10 Oct 2006 08:25:23 -0700 Message-ID: In-Reply-To: <452B995B.92F@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Is 639-3 bogus ? (was: Proposal: include new"Language-Type:" field) thread-index: AcbsbEvT952dCgGBQDCMX6Eqpex0EQAEZYJw From: Peter Constable To: X-OriginalArrivalTime: 10 Oct 2006 15:25:47.0780 (UTC) FILETIME=[5C755440:01C6EC80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org One can read all my thoughts on this that have been published elsewhere = (see http://www.sil.org/silewp/2000/001/). It takes encyclopaedic = information to determine with certainty the denotation of a language = identifier. But a standard like ISO 639 doesn't have means to provide = encyclopaedic information; it just has a table consisting of entries = with an ID and one or more names. In 639-3, we extended that with two = additional pieces of info, scope and type, in order to help clarify what = the intended denotation is for each identifier. That's all I was saying. Now, we could add comments to entries in the LSR to clarify their = denotation. Some questions are immediately raised, though: What should = the source for comments be? What determines when comments are added? The = source standard isn't going to provide answers to the first question = unless what is being added are type or scope values, and John's proposal = answers the second by saying, "It's done consistently for all; we don't = cherry pick." I'm not saying I think the type info is needed; I am inclined to think = it would be good to include the scope values, though. And as for the = source not identifying collections, actually it does: every alpha-3 in = 639-2 that is not in 639-3 is a collection. Peter > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Tuesday, October 10, 2006 6:00 AM > To: ltru@lists.ietf.org > Subject: [Ltru] Is 639-3 bogus ? (was: Proposal: include = new"Language-Type:" field) >=20 > Peter Constable wrote: >=20 > > that's not the only point. If someone is looking at an entry "Foo" > > and trying to figure out if it's referring to the same language they > > know as "Phu", which is spoken in New Phuinea, seeing that it's type > > is Constructed (say), or Ancient (say) would give them a strong clue > > that it's not. >=20 > That's the job of a comment or description. For "orq" I found that it > is "colloquial blackspeech" spoken in "no man's land". Now does that > cover Yrch as spoken by the Uruk Hai in Morannon or not, and why would > anybody look into a IANA registry for such details ? >=20 > Maybe "orq" should get Shavian as Suppress-Script and proclaim Sealand > as their micronation. Seriously, does 639-3 allow to register almost > anything ? What's the justification to list "orq" except from the fun > aspect ? >=20 > Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 11:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJfv-0003lS-AS; Tue, 10 Oct 2006 11:37:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJfu-0003ki-8c for ltru@lists.ietf.org; Tue, 10 Oct 2006 11:37:46 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJfs-0006MC-Tz for ltru@lists.ietf.org; Tue, 10 Oct 2006 11:37:46 -0400 Received: from [10.72.72.226] (snvvpn1-10-72-72-c226.corp.yahoo.com [10.72.72.226]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9AFbXU6041930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 08:37:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=VPFfJV7FgF9tIHgg/qyZ8FFivkj/zR8+8JhrZIlE11q4+HIAXloojoGutzHZ43kq Message-ID: <452BBE3E.1060100@yahoo-inc.com> Date: Tue, 10 Oct 2006 08:37:34 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Is 639-3 bogus ? (was: Proposal: include new"Language-Type:" field) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > > I'm not saying I think the type info is needed; > I am inclined to think it would be good to include > the scope values, though. And as for the source not > identifying collections, actually it does: every > alpha-3 in 639-2 that is not in 639-3 is a collection. > The LSR doesn't indicate which alpha3 codes are ISO 639-2 vs. ISO 639-3, so collections won't be clear in the registry unless we label them somehow, which this proposal does provide. On the other hand, "collection" codes are just language subtags that someone may choose or not. I was hoping that 639-3 would provide the information on what is or is not considered a macro-language. But this information isn't it. I'm against replicating information just to replicate it. It would be simpler and more efficient to provide a link to ISO 639-3 and point out that there is more information there. Oh. Wait. We already do that. ;-) Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 12:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKbo-0001CI-T0; Tue, 10 Oct 2006 12:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKbn-0001CC-C6 for ltru@lists.ietf.org; Tue, 10 Oct 2006 12:37:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKbl-0004g8-1T for ltru@lists.ietf.org; Tue, 10 Oct 2006 12:37:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXKbE-0006Sq-2w for ltru@lists.ietf.org; Tue, 10 Oct 2006 18:37:00 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 18:37:00 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 18:37:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 18:35:53 +0200 Organization: Lines: 23 Message-ID: <452BCBE9.56D0@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > One can read all my thoughts on this that have been published > elsewhere (see http://www.sil.org/silewp/2000/001/). That doesn't explain "orq". And the ethnologue site claims that "orq" is no SIL code. So how did it get added to a 639-3 draft ? There must be some procedure, and if that procedure is broken it needs to be fixed before nonsense is added to a registry designed for stability. There's no way to get rid of "orq" later, at best it could be deprecated. Of course one "orq" is harmless and not worse than say "tlh", but if that's only the tip of an iceberg spammers and criminals will abuse it as fast as 1-2-3 to create their virtual "Cesidian root" or "Dominion of Melchizedek" realities. We can't have IANA servers confiscated in criminal investigations about DOM. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 14:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMFZ-0003lC-7t; Tue, 10 Oct 2006 14:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMFY-0003l5-4E for ltru@ietf.org; Tue, 10 Oct 2006 14:22:44 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMFV-0000mP-TA for ltru@ietf.org; Tue, 10 Oct 2006 14:22:44 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXMFT-00066V-1S; Tue, 10 Oct 2006 14:22:39 -0400 Date: Tue, 10 Oct 2006 14:22:39 -0400 To: Addison Phillips Subject: Re: [Ltru] Is 639-3 bogus ? (was: Proposal: include new"Language-Type:" field) Message-ID: <20061010182238.GF31563@ccil.org> References: <452BBE3E.1060100@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452BBE3E.1060100@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > I was hoping that 639-3 would provide the information on what is > or is not considered a macro-language. But this information isn't > it. "Scope" means "individual language or macrolanguage". You can deduce from the registry which are which; a macrolanguage is one that appears as the Prefix of some extlangs. But I'm not against including this information at all. -- John Cowan http://ccil.org/~cowan cowan@ccil.org [T]here is a Darwinian explanation for the refusal to accept Darwin. Given the very pessimistic conclusions about moral purpose to which his theory drives us, and given the importance of a sense of moral purpose in helping us cope with life, a refusal to believe Darwin's theory may have important survival value. --Ian Johnston _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 14:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMHK-0004cw-2k; Tue, 10 Oct 2006 14:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMHJ-0004cq-Gs for ltru@ietf.org; Tue, 10 Oct 2006 14:24:33 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMHI-00018Q-9j for ltru@ietf.org; Tue, 10 Oct 2006 14:24:33 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXMHH-0006Ba-8f; Tue, 10 Oct 2006 14:24:31 -0400 Date: Tue, 10 Oct 2006 14:24:31 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Is 639-3 bogus ? Message-ID: <20061010182431.GG31563@ccil.org> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452BCBE9.56D0@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > That doesn't explain "orq". And the ethnologue site claims that > "orq" is no SIL code. So how did it get added to a 639-3 draft ? Conlangs come from Language List. If you go to http://www.sil.org/iso639-3/documentation.asp?id=orq you can see the link to the LL page. That said, I think "orq" doesn't belong there: not a single word is extant. -- I don't know half of you half as well John Cowan as I should like, and I like less than half cowan@ccil.org of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 14:46:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMcq-0007Px-5x; Tue, 10 Oct 2006 14:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMco-0007Pm-MP for ltru@lists.ietf.org; Tue, 10 Oct 2006 14:46:46 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMcl-0005qr-D5 for ltru@lists.ietf.org; Tue, 10 Oct 2006 14:46:46 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 11:46:42 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 11:46:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Is 639-3 bogus ? (was: Proposal: include new"Language-Type:" field) Date: Tue, 10 Oct 2006 11:46:17 -0700 Message-ID: In-Reply-To: <452BBE3E.1060100@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Is 639-3 bogus ? (was: Proposal: include new"Language-Type:" field) thread-index: AcbsgglujEkBgPqySS6wOebWpSVI4wAGjLtA References: <452BBE3E.1060100@yahoo-inc.com> From: Peter Constable To: Addison Phillips X-OriginalArrivalTime: 10 Oct 2006 18:46:41.0455 (UTC) FILETIME=[6D022BF0:01C6EC9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0893008544==" Errors-To: ltru-bounces@ietf.org --===============0893008544== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SVNPIDYzOS0zIGlzIHZlcnkgY2xlYXIgYWJvdXQgd2hpY2ggaXRlbXMgYXJlIG1hY3JvbGFuZ3Vh Z2VzOiBpdCBpcyBjbGVhciBib3RoIGZyb20gdGhlIG5vcm1hdGl2ZSBzY29wZSBhdHRyaWJ1dGUg YW5kIGZyb20gdGhlIG1hY3JvbGFuZ3VhZ2UgbWFwcGluZyB0YWJsZS4NCg0KDQpQZXRlcg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRkaXNvbiBQaGlsbGlwcyBbbWFpbHRv OmFkZGlzb25AeWFob28taW5jLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEwLCAyMDA2 IDg6MzggQU0NClRvOiBQZXRlciBDb25zdGFibGUNCkNjOiBsdHJ1QGxpc3RzLmlldGYub3JnDQpT dWJqZWN0OiBSZTogW0x0cnVdIElzIDYzOS0zIGJvZ3VzID8gKHdhczogUHJvcG9zYWw6IGluY2x1 ZGUgbmV3Ikxhbmd1YWdlLVR5cGU6IiBmaWVsZCkNCg0KUGV0ZXIgQ29uc3RhYmxlIHdyb3RlOg0K PiANCj4gSSdtIG5vdCBzYXlpbmcgSSB0aGluayB0aGUgdHlwZSBpbmZvIGlzIG5lZWRlZDsgDQog PiBJIGFtIGluY2xpbmVkIHRvIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaW5jbHVkZQ0KID4g dGhlIHNjb3BlIHZhbHVlcywgdGhvdWdoLiBBbmQgYXMgZm9yIHRoZSBzb3VyY2Ugbm90DQogPiBp ZGVudGlmeWluZyBjb2xsZWN0aW9ucywgYWN0dWFsbHkgaXQgZG9lczogZXZlcnkNCiA+IGFscGhh LTMgaW4gNjM5LTIgdGhhdCBpcyBub3QgaW4gNjM5LTMgaXMgYSBjb2xsZWN0aW9uLg0KPiANCg0K VGhlIExTUiBkb2Vzbid0IGluZGljYXRlIHdoaWNoIGFscGhhMyBjb2RlcyBhcmUgSVNPIDYzOS0y IHZzLiBJU08gNjM5LTMsIA0Kc28gY29sbGVjdGlvbnMgd29uJ3QgYmUgY2xlYXIgaW4gdGhlIHJl Z2lzdHJ5IHVubGVzcyB3ZSBsYWJlbCB0aGVtIA0Kc29tZWhvdywgd2hpY2ggdGhpcyBwcm9wb3Nh bCBkb2VzIHByb3ZpZGUuIE9uIHRoZSBvdGhlciBoYW5kLCANCiJjb2xsZWN0aW9uIiBjb2RlcyBh cmUganVzdCBsYW5ndWFnZSBzdWJ0YWdzIHRoYXQgc29tZW9uZSBtYXkgY2hvb3NlIG9yIG5vdC4N Cg0KSSB3YXMgaG9waW5nIHRoYXQgNjM5LTMgd291bGQgcHJvdmlkZSB0aGUgaW5mb3JtYXRpb24g b24gd2hhdCBpcyBvciBpcyANCm5vdCBjb25zaWRlcmVkIGEgbWFjcm8tbGFuZ3VhZ2UuIEJ1dCB0 aGlzIGluZm9ybWF0aW9uIGlzbid0IGl0Lg0KDQpJJ20gYWdhaW5zdCByZXBsaWNhdGluZyBpbmZv cm1hdGlvbiBqdXN0IHRvIHJlcGxpY2F0ZSBpdC4gSXQgd291bGQgYmUgDQpzaW1wbGVyIGFuZCBt b3JlIGVmZmljaWVudCB0byBwcm92aWRlIGEgbGluayB0byBJU08gNjM5LTMgYW5kIHBvaW50IG91 dCANCnRoYXQgdGhlcmUgaXMgbW9yZSBpbmZvcm1hdGlvbiB0aGVyZS4gT2guIFdhaXQuIFdlIGFs cmVhZHkgZG8gdGhhdC4gOy0pDQoNCkFkZGlzb24NCg0KLS0gDQpBZGRpc29uIFBoaWxsaXBzDQpH bG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBZYWhvbyEgSW5jLg0KDQpJbnRlcm5hdGlvbmFsaXph dGlvbiBpcyBhbiBhcmNoaXRlY3R1cmUuDQpJdCBpcyBub3QgYSBmZWF0dXJlLg0K --===============0893008544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0893008544==-- From ltru-bounces@ietf.org Tue Oct 10 14:52:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMhx-0001QK-BO; Tue, 10 Oct 2006 14:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMhv-0001MB-HZ for ltru@lists.ietf.org; Tue, 10 Oct 2006 14:52:03 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMhu-0006r5-7U for ltru@lists.ietf.org; Tue, 10 Oct 2006 14:52:03 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 11:52:01 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 10 Oct 2006 11:51:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Tue, 10 Oct 2006 11:51:04 -0700 Message-ID: In-Reply-To: <452BCBE9.56D0@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: AcbsimxDT/TNa/BwTFqWstHaV5Z8IwAEk0bA References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 10 Oct 2006 18:51:43.0578 (UTC) FILETIME=[21167BA0:01C6EC9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Whatever on earth does the source of orq in the draft table for 639-3 have to do with how the type attribute of entries in 639-3 are useful? What point are you getting at? (I really haven't a clue.) Peter -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 Sent: Tuesday, October 10, 2006 9:36 AM To: ltru@lists.ietf.org Subject: [Ltru] Re: Is 639-3 bogus ? Peter Constable wrote: > One can read all my thoughts on this that have been published > elsewhere (see http://www.sil.org/silewp/2000/001/). That doesn't explain "orq". And the ethnologue site claims that "orq" is no SIL code. So how did it get added to a 639-3 draft ? There must be some procedure, and if that procedure is broken it needs to be fixed before nonsense is added to a registry designed for stability. There's no way to get rid of "orq" later, at best it could be deprecated. Of course one "orq" is harmless and not worse than say "tlh", but if that's only the tip of an iceberg spammers and criminals will abuse it as fast as 1-2-3 to create their virtual "Cesidian root" or "Dominion of Melchizedek" realities. We can't have IANA servers confiscated in criminal investigations about DOM. =20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 14:54:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMk1-000376-9p; Tue, 10 Oct 2006 14:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMk0-00036y-GI for ltru@lists.ietf.org; Tue, 10 Oct 2006 14:54:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMjy-0007SY-0U for ltru@lists.ietf.org; Tue, 10 Oct 2006 14:54:12 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXMjG-00026H-8t for ltru@lists.ietf.org; Tue, 10 Oct 2006 20:53:27 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 20:53:26 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 20:53:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 20:49:34 +0200 Organization: Lines: 63 Message-ID: <452BEB3E.1C58@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <20061010182431.GG31563@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: = > Conlangs come from Language List. If you go to > http://www.sil.org/iso639-3/documentation.asp?id=3Dorq you can > see the link to the LL page. Yes, I found that yesterday, that's where it says "No man's land" and "Colloquial blackspeech". = > I think "orq" doesn't belong there: not a single word is extant. says: | The following is an excerpt from a Tolkien Linguistics site: | Our sole example of pure Black Speech, then, is the inscription on the | Ring: Ash nazg durbatul=FBk, ash nazg gimbatul, ash nazg thrakatul=FBk = agh | burzum-ishi krimpatul. "One Ring to rule them all, One Ring to find = them, | One Ring to bring them all and in the Darkness bind them." (LotR1/II = ch. | 2) Nazg is "ring", also seen in Nazg=FBl "Ring-wraith(s)". Ash is the = number | "one", agh is the conjuction "and", disturbingly similar to = Scandinavian | og, och. Burzum is "darkness", evidently incorporating the same = element | b=FArz, burz- "dark" as in Lugb=FArz "Tower-dark", the Black Speech nam= e that | Sindarin Barad-d=FBr translates. Hence, the -um of burzum must be an | abstract suffix like the "-ness" of the corresponding English word | "darkness". Burzum has a suffix ishi "in". In the transcription it is | separated from burzum by a hyphen, but there is nothing corresponding = in | the Tengwar inscription on the Ring, so this may be considered either = a | postposition or a locative ending. (It is remarkably similar to Quenya | -ss=EB and may support the theory advanced by Robert Foster in his = Complete | Guide to Middle-earth, that the Black Speech was to some extent based = on | Quenya and a perversion of it. The element burz- "dark" is also = vaguely | similar to the Elvish stem for "black", MOR.) Though burzum-ishi is | translated "in the darkness", there does not seem to be anything | corresponding to the article "the", unless it is somehow incorporated = in | ishi. But the evidence is that the Black Speech does not mark the | distinction between definite and indefinite nouns; see below. For more on that see , I miss "Yrch" on that page, otherwise it's apparently complete, about 30 words. The IANA registry cannot list all made-up languages with about 30 words, for some time any decent science fiction had a glossary with words in some made-up language(s). And 26*26*26 is far too limited to waste it for such constructs in 639. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 15:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8a-0006II-9T; Tue, 10 Oct 2006 15:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8X-0006EK-Bh for ltru@lists.ietf.org; Tue, 10 Oct 2006 15:19:33 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXN40-0002ZZ-BW for ltru@lists.ietf.org; Tue, 10 Oct 2006 15:14:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXN3W-0006xK-LO for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:14:23 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 21:14:22 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 21:14:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 21:13:05 +0200 Organization: Lines: 20 Message-ID: <452BF0C1.731E@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > What point are you getting at? (I really haven't a clue.) How reliable and useful is the info, and should the registry contain a source indication for alpha-3 language subtags if there are major differences between 639-2 and 639-3. Maybe it's possible to delete "orq" from 639-3 later, but it's not possible to remove it from the LSR. The guarantee in RFC 4646 2.2.1 covers only 639-2 and 639-1, not 639-3. If "orq" could be _reassigned_ we've dropped the ball. I think the statement in 2.2.1 needs to be extended to cover ISO 639-3 like it covers 639-2 today. For that I'd propose that we request an official statement to be added to 4646bis (replacing the old 3066 statement). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 15:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNOV-0004bo-Hr; Tue, 10 Oct 2006 15:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNOU-0004aS-Dh for ltru@ietf.org; Tue, 10 Oct 2006 15:36:02 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXNOT-0005nV-1v for ltru@ietf.org; Tue, 10 Oct 2006 15:36:02 -0400 Received: from [172.21.148.255] (wlanvpn-mc2e-246-255.corp.yahoo.com [172.21.148.255]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9AJZgCV054127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 12:35:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=x60zTJo5y/SzPfx/8h44zfIS+oIVT93Pvv0aziyo6wQQE7igL5jxiXQcAJvJDx0l Message-ID: <452BF610.7040800@yahoo-inc.com> Date: Tue, 10 Oct 2006 12:35:44 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Is 639-3 bogus ? References: <452BBE3E.1060100@yahoo-inc.com> <20061010182238.GF31563@ccil.org> In-Reply-To: <20061010182238.GF31563@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Addison Phillips scripsit: > >> I was hoping that 639-3 would provide the information on what is >> or is not considered a macro-language. But this information isn't >> it. > > "Scope" means "individual language or macrolanguage". You can > deduce from the registry which are which; a macrolanguage is one > that appears as the Prefix of some extlangs. What I was looking for was: http://www.sil.org/iso639%2D3/macrolanguages.asp And: http://www.sil.org/iso639%2D3/scope.asp#M Ideally, extended language subtags would be restricted to the list in the first link above and 4646bis would reflect that fact. I don't want to construct that list from the registry: I would prefer something much more cut-and-dried, i.e. getting it from ISO 639-3. I can see at least one problem with the macro languages list: there are at least some languages (the "Serbo-Croatian" family) that will be grandfathered into language subtags rather than extlangs. Now, all that said, I think it would be useful to include a "type" field for "collective" languages (with the warnings about their suitability proposed by John) and for "macro" languages (defining what can be used as a prefix value in an extlang). However, I can also see that this information does not necessarily need to occur in the registry. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 16:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOYN-0000gJ-2q; Tue, 10 Oct 2006 16:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOYL-0000gE-LI for ltru@lists.ietf.org; Tue, 10 Oct 2006 16:50:17 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOYK-0005SA-BD for ltru@lists.ietf.org; Tue, 10 Oct 2006 16:50:17 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 13:50:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 10 Oct 2006 13:50:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Tue, 10 Oct 2006 13:50:11 -0700 Message-ID: In-Reply-To: <452BF0C1.731E@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: AcbsoQiCP+JOkLYeQLOFX2/B2H1xQAAC4PAw References: <452B995B.92F@xyzzy.claranet.de><452BCBE9.56D0@xyzzy.claranet.de> <452BF0C1.731E@xyzzy.claranet.de> From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 10 Oct 2006 20:50:14.0159 (UTC) FILETIME=[AF5309F0:01C6ECAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org How reliable and useful in what sense? Is it reliable that orq denotes Orcish? Modulo that the published table is a *draft* code table, yes. Is it reliable that orq denotes an individual, constructed language? Yes. Is it useful to know that orq is an individual, constructed language and that that language is Orcish? Yes. Is it useful to have an entry for orq in the first place? That depends on the user, just as it does for all the other 7000+ entries. Again, what is the point of these questions? (And explain to me how this is not a random attack on 639-3, since that is certainly how it appears to me.) Items in 639-3 will never be deleted, nor will they be reassigned. It has a fairly strict stability policy. If this WG feels that is inadequate for RFC 4646bis, then we can revise 2.2.1 to say whatever we think is needed. Peter -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 Sent: Tuesday, October 10, 2006 12:13 PM To: ltru@lists.ietf.org Subject: [Ltru] Re: Is 639-3 bogus ? Peter Constable wrote: =20 > What point are you getting at? (I really haven't a clue.) How reliable and useful is the info, and should the registry contain a source indication for alpha-3 language subtags if there are major differences between 639-2 and 639-3. Maybe it's possible to delete "orq" from 639-3 later, but it's not possible to remove it from the LSR. The guarantee in RFC 4646 2.2.1 covers only 639-2 and 639-1, not 639-3. If "orq" could be _reassigned_ we've dropped the ball. I think the statement in 2.2.1 needs to be extended to cover ISO 639-3 like it covers 639-2 today. For that I'd propose that we request an official statement to be added to 4646bis (replacing the old 3066 statement). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 17:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOxr-0005ia-EY; Tue, 10 Oct 2006 17:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOxq-0005iV-GB for ltru@ietf.org; Tue, 10 Oct 2006 17:16:38 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOxp-0008Tv-4s for ltru@ietf.org; Tue, 10 Oct 2006 17:16:38 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 14:16:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 10 Oct 2006 14:16:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Is 639-3 bogus ? Date: Tue, 10 Oct 2006 14:15:35 -0700 Message-ID: In-Reply-To: <452BF610.7040800@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Is 639-3 bogus ? thread-index: Acbso1sUZDyKEjMvR52JmF11BqGetgAC59jA References: <452BBE3E.1060100@yahoo-inc.com> <20061010182238.GF31563@ccil.org> <452BF610.7040800@yahoo-inc.com> From: Peter Constable To: Addison Phillips , John Cowan X-OriginalArrivalTime: 10 Oct 2006 21:16:36.0358 (UTC) FILETIME=[5E637260:01C6ECB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1404774160==" Errors-To: ltru-bounces@ietf.org --===============1404774160== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gSVNPIDYzOS0zIHRlcm1zICJjb2xsZWN0aW9uIiBpcyBhIHNjb3BlLCBub3QgYSB0eXBlLg0K DQpfU2NvcGVfIHJlZmVycyB0byBob3cgYnJvYWQgaXMgdGhlIHJhbmdlIG9mIGxpbmd1aXN0aWMg dmFyaWV0aWVzIGVuY29tcGFzc2VkIGluIHRoZSBkZW5vdGF0aW9uIG9mIGFuIElELCB3aXRoIGZv dXIgcG9zc2libGUgdmFsdWVzIGNvbnNpZGVyZWQgaW4gNjM5LTM6IGluZGl2aWR1YWwgbGFuZ3Vh Z2UsIG1hY3JvbGFuZ3VhZ2UsIGNvbGxlY3Rpb24gYW5kIHNwZWNpYWwgcHVycG9zZS4gKEEgZmlm dGggdmFsdWUsIGRpYWxlY3QsIG1pZ2h0IGJlIHJlbGV2YW50IHRvIGFub3RoZXIgcGFydCBvZiBJ U08gNjM5LikgVGhlIHNjb3BlIGF0dHJpYnV0ZSBpcyBhIG5vcm1hdGl2ZSBhdHRyaWJ1dGUgaW4g SVNPIDYzOS0zLg0KDQpfVHlwZV8gcmVmZXJzIHRvIHRoZSBjdXJyZW5jeSBhbmQgZ2VuZXRpYyBu YXR1cmUgb2YgdGhlIGxhbmd1YWdlOiBsaXZpbmcsIChyZWNlbnRseSkgZXh0aW5jdCwgaGlzdG9y aWMgKHByZWN1cnNvciBvZiBhIG1vZGVybiBsYW5ndWFnZSksIGFuY2llbnQgKHdlbnQgZXh0aW5j dCBpbiBub24tcmVjZW50IHBhc3QpLCBjb25zdHJ1Y3RlZC4gRW50cmllcyB3aXRoIGEgc3BlY2lh bC1wdXJwb3NlIHNjb3BlIGRvIG5vdCBoYXZlIGEgdHlwZSB2YWx1ZS4gVHlwZSBpcyBhbiBpbmZv cm1hdGl2ZSBhdHRyaWJ1dGUuDQoNClRoZSBzY29wZSBhdHRyaWJ1dGUgaXMgZGlyZWN0bHkgcmVs ZXZhbnQgdG8gdGhlIExTUiBpZiAoaSkgbWFjcm8tbGFuZ3VhZ2Ugc2NvcGUgb2YgYW4gSUQgaXMg cmVsZXZhbnQgZm9yIGNvbnRydWN0aW5nIHRhZ3Mgd2l0aCBleHRsYW5nIHN1YnRhZ3MsIGFuZCBp ZiAoaWkpIHVzZSBpZiBjb2xsZWN0aW9uIG9yIHNwZWNpYWwtcHVycG9zZSBJRHMgaXMgaW4gYW55 IHdheSBkaXNjb3VyYWdlZC4NCg0KDQpQZXRlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBBZGRpc29uIFBoaWxsaXBzIFttYWlsdG86YWRkaXNvbkB5YWhvby1pbmMuY29t XSANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMDYgMTI6MzYgUE0NClRvOiBKb2huIENv d2FuDQpDYzogbHRydUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMdHJ1XSBJcyA2MzktMyBib2d1 cyA/DQoNCg0KDQpKb2huIENvd2FuIHdyb3RlOg0KPiBBZGRpc29uIFBoaWxsaXBzIHNjcmlwc2l0 Og0KPiANCj4+IEkgd2FzIGhvcGluZyB0aGF0IDYzOS0zIHdvdWxkIHByb3ZpZGUgdGhlIGluZm9y bWF0aW9uIG9uIHdoYXQgaXMgDQo+PiBvciBpcyBub3QgY29uc2lkZXJlZCBhIG1hY3JvLWxhbmd1 YWdlLiBCdXQgdGhpcyBpbmZvcm1hdGlvbiBpc24ndCANCj4+IGl0Lg0KPiANCj4gIlNjb3BlIiBt ZWFucyAiaW5kaXZpZHVhbCBsYW5ndWFnZSBvciBtYWNyb2xhbmd1YWdlIi4gIFlvdSBjYW4NCj4g ZGVkdWNlIGZyb20gdGhlIHJlZ2lzdHJ5IHdoaWNoIGFyZSB3aGljaDsgYSBtYWNyb2xhbmd1YWdl IGlzIG9uZQ0KPiB0aGF0IGFwcGVhcnMgYXMgdGhlIFByZWZpeCBvZiBzb21lIGV4dGxhbmdzLg0K DQpXaGF0IEkgd2FzIGxvb2tpbmcgZm9yIHdhczoNCg0KICAgaHR0cDovL3d3dy5zaWwub3JnL2lz bzYzOSUyRDMvbWFjcm9sYW5ndWFnZXMuYXNwDQoNCkFuZDoNCg0KICAgaHR0cDovL3d3dy5zaWwu b3JnL2lzbzYzOSUyRDMvc2NvcGUuYXNwI00NCg0KSWRlYWxseSwgZXh0ZW5kZWQgbGFuZ3VhZ2Ug c3VidGFncyB3b3VsZCBiZSByZXN0cmljdGVkIHRvIHRoZSBsaXN0IGluIA0KdGhlIGZpcnN0IGxp bmsgYWJvdmUgYW5kIDQ2NDZiaXMgd291bGQgcmVmbGVjdCB0aGF0IGZhY3QuIEkgZG9uJ3Qgd2Fu dCANCnRvIGNvbnN0cnVjdCB0aGF0IGxpc3QgZnJvbSB0aGUgcmVnaXN0cnk6IEkgd291bGQgcHJl ZmVyIHNvbWV0aGluZyBtdWNoIA0KbW9yZSBjdXQtYW5kLWRyaWVkLCBpLmUuIGdldHRpbmcgaXQg ZnJvbSBJU08gNjM5LTMuDQoNCkkgY2FuIHNlZSBhdCBsZWFzdCBvbmUgcHJvYmxlbSB3aXRoIHRo ZSBtYWNybyBsYW5ndWFnZXMgbGlzdDogdGhlcmUgYXJlIA0KYXQgbGVhc3Qgc29tZSBsYW5ndWFn ZXMgKHRoZSAiU2VyYm8tQ3JvYXRpYW4iIGZhbWlseSkgdGhhdCB3aWxsIGJlIA0KZ3JhbmRmYXRo ZXJlZCBpbnRvIGxhbmd1YWdlIHN1YnRhZ3MgcmF0aGVyIHRoYW4gZXh0bGFuZ3MuDQoNCk5vdywg YWxsIHRoYXQgc2FpZCwgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaW5jbHVkZSBhICJ0 eXBlIiBmaWVsZCANCmZvciAiY29sbGVjdGl2ZSIgbGFuZ3VhZ2VzICh3aXRoIHRoZSB3YXJuaW5n cyBhYm91dCB0aGVpciBzdWl0YWJpbGl0eSANCnByb3Bvc2VkIGJ5IEpvaG4pIGFuZCBmb3IgIm1h Y3JvIiBsYW5ndWFnZXMgKGRlZmluaW5nIHdoYXQgY2FuIGJlIHVzZWQgDQphcyBhIHByZWZpeCB2 YWx1ZSBpbiBhbiBleHRsYW5nKS4NCg0KSG93ZXZlciwgSSBjYW4gYWxzbyBzZWUgdGhhdCB0aGlz IGluZm9ybWF0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IG5lZWQgDQp0byBvY2N1ciBpbiB0aGUg cmVnaXN0cnkuDQoNCkFkZGlzb24NCg0KLS0gDQpBZGRpc29uIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCAtLSBZYWhvbyEgSW5jLg0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBh biBhcmNoaXRlY3R1cmUuDQpJdCBpcyBub3QgYSBmZWF0dXJlLg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBtYWlsaW5nIGxpc3QNCkx0cnVA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============1404774160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1404774160==-- From ltru-bounces@ietf.org Tue Oct 10 18:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXPht-0002wA-QM; Tue, 10 Oct 2006 18:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXPhs-0002w4-3E for ltru@lists.ietf.org; Tue, 10 Oct 2006 18:04:12 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXPhq-0006ou-ME for ltru@lists.ietf.org; Tue, 10 Oct 2006 18:04:12 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXPgH-0003sH-2b for ltru@lists.ietf.org; Wed, 11 Oct 2006 00:02:34 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 00:02:33 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 00:02:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 23:59:27 +0200 Organization: Lines: 37 Message-ID: <452C17BF.50A8@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de><452BCBE9.56D0@xyzzy.claranet.de> <452BF0C1.731E@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Is it useful to know that orq is an individual, constructed language > and that that language is Orcish? Yes. alpha-3 is a finite set, if any language of 30 words gets its own code 639-3 is in trouble, and the subtag registry with it. > Again, what is the point of these questions? Protecting the subtag registry from bogus entries while it's on a one way street (nothing ever removed) with a known end (26*26*26). > And explain to me how this is not a random attack on 639-3, since > that is certainly how it appears to me. Of course it's a random attack, I looked into the source, because John proposed to preserve its Language-Type info, and the "C" attracted my attention. There are not many "C", and "orq" is one, and as it happens I thought (yesterday) I know what "orq" is about. And today I'm sure. I can't judge anything else, e.g. why "bet" offers B=E9te and "bev" B=E9t= =E9, it could be a typo, it could as well be completely unrelated languages. The source for the draft is Latin-1 (another detail I didn't know, and I checked that it's really Latin-1 and not windows-1252). In some cases like "aue" =3D/Kx'au//'ein or "gnk" //Gana I'm not sure if that's as it should be, it appears to be odd. Or maybe "//" has a well-known meaning, and I just don't know what it is. > we can revise 2.2.1 to say whatever we think is needed. What the quoted promise already says just adding ISO 639-3 would do it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 21:32:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXSxY-0000zz-Aq; Tue, 10 Oct 2006 21:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXSxY-0000zr-1C for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:32:36 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXSxW-00070S-O6 for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:32:36 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXSxT-0002Oz-J1; Tue, 10 Oct 2006 21:32:31 -0400 Date: Tue, 10 Oct 2006 21:32:31 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Is 639-3 bogus ? Message-ID: <20061011013231.GB23580@ccil.org> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <20061010182431.GG31563@ccil.org> <452BEB3E.1C58@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <452BEB3E.1C58@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Yes, I found that yesterday, that's where it says "No man's land" > and "Colloquial blackspeech". > > > I think "orq" doesn't belong there: not a single word is extant. Well, checking, there is no code for classical Black Speech (spoken by the Ringwraiths and by Sauron himself), so presumably "orq" is meant to cover both. There is a poem in classical Black Speech, the Ringverse ("ash nazg durbatuluk" etc.), so it marginally counts as having "a literature", the requirement for conlangs to appear in 639-3. > For more on that see , I miss > "Yrch" on that page, otherwise it's apparently complete, about 30 words. "Yrch" is in fact the Sindarin word for "orcs", the plural of "orch"; not Black Speech at all. > The IANA registry cannot list all made-up languages with about 30 words, > for some time any decent science fiction had a glossary with words in > some made-up language(s). And 26*26*26 is far too limited to waste it > for such constructs in 639. I agree in general. > Protecting the subtag registry from bogus entries while it's on a one > way street (nothing ever removed) with a known end (26*26*26). I have to agree. What's the right procedure for getting conlangs removed from the list, Peter? 639/RA-JAC? Anthony Aristar? I think Orkish, Delason, Jakelimotu, Linga, and perhaps Tceqli (aka Ceqli) should be removed. The last four are essentially private languages, and all but Orkish and Tceqli don't even have a live Web presence, just dead pages. > I can't judge anything else, e.g. why "bet" offers Béte and "bev" Bété, > it could be a typo, it could as well be completely unrelated languages. They are in fact very closely related languages, belonging to the Bete family (no accents). Beyond that I can't say. > The source for the draft is Latin-1 (another detail I didn't know, and > I checked that it's really Latin-1 and not windows-1252). In some > cases like "aue" =/Kx'au//'ein or "gnk" //Gana I'm not sure if that's > as it should be, it appears to be odd. Or maybe "//" has a well-known > meaning, and I just don't know what it is. /, //, and ! are letters representing various clicks in languages of South Africa and Namibia. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 21:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXT7q-0005O8-Oq; Tue, 10 Oct 2006 21:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXT7p-0005Nw-3g for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:43:13 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXT7k-0000Gd-Mu for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:43:13 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 18:43:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 18:43:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Tue, 10 Oct 2006 18:42:59 -0700 Message-ID: In-Reply-To: <452C17BF.50A8@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: AcbsuC7dzgL2RBCKR5CBMmzUiQtYDgAHCNAQ References: <452B995B.92F@xyzzy.claranet.de><452BCBE9.56D0@xyzzy.claranet.de><452BF0C1.731E@xyzzy.claranet.de> <452C17BF.50A8@xyzzy.claranet.de> From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 11 Oct 2006 01:43:05.0990 (UTC) FILETIME=[98F3AA60:01C6ECD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Can I suggest that, next time, it would help if you stated clearly at = the outset what your concerns are. It's taken me several rounds going = back and forth with you to drag out what it is you're going on about. Re entries in the 639-3 draft code table for ancient and constructed = languages, the Linguist List was the source for those, and presumably = they had a reason why each of these was deemed to have a need. If you = have a question about the usefulness of orq or any other entry, you can = contact Anthony Aristar or Debbie Anderson. Re the characters used in the names, the source for the large inventory = of entries of modern and recently-extinct languages came from a database = that has a history going back several decades. By the time 639-3 is = published, some of the spellings may be revised, or some may be revised = over the life of maintenance for the code set. It was not considered a = prerequisite to normalize the spellings to conform to any particular = expectations prior to initial publication. If you see two entries -- two distinct IDs -- then the language = varieties denoted are deemed to be distinct languages. The fact that = they have similar spellings is coincidental. The language names = connected with "byj" and "bmn" are even more similar than the pair you = cited; that doesn't mean that the entries are suspect. The source for the majority of new entries in 639-3 has been published = for many years -- it's in its fifteenth edition -- and has been widely = used and reviewed by linguists throughout the world.=20 IMO, there's no particular reason for members of this WG to be second = guessing whether the content of ISO 639-3 is good enough for use in the = LSR. Going back to where this started, you responded to comments I made about = how the type information in 639-3 may be useful to a user. "That's the = job of a comment or description," you said. It's still not clear to me = if you had a comment to make wrt John's proposal or not. Peter -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 Sent: Tuesday, October 10, 2006 2:59 PM To: ltru@lists.ietf.org Subject: [Ltru] Re: Is 639-3 bogus ? Peter Constable wrote: > Is it useful to know that orq is an individual, constructed language > and that that language is Orcish? Yes. alpha-3 is a finite set, if any language of 30 words gets its own code 639-3 is in trouble, and the subtag registry with it. > Again, what is the point of these questions? Protecting the subtag registry from bogus entries while it's on a one way street (nothing ever removed) with a known end (26*26*26). > And explain to me how this is not a random attack on 639-3, since > that is certainly how it appears to me. Of course it's a random attack, I looked into the source, because John proposed to preserve its Language-Type info, and the "C" attracted my attention. There are not many "C", and "orq" is one, and as it happens I thought (yesterday) I know what "orq" is about. And today I'm sure. I can't judge anything else, e.g. why "bet" offers B=E9te and "bev" = B=E9t=E9, it could be a typo, it could as well be completely unrelated languages. The source for the draft is Latin-1 (another detail I didn't know, and I checked that it's really Latin-1 and not windows-1252). In some cases like "aue" =3D/Kx'au//'ein or "gnk" //Gana I'm not sure if that's as it should be, it appears to be odd. Or maybe "//" has a well-known meaning, and I just don't know what it is. > we can revise 2.2.1 to say whatever we think is needed. What the quoted promise already says just adding ISO 639-3 would do it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 21:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTFb-0001mk-K7; Tue, 10 Oct 2006 21:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTFa-0001mV-1J for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:51:14 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXTFW-00040q-Oe for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:51:14 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 18:51:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 10 Oct 2006 18:51:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Tue, 10 Oct 2006 18:50:34 -0700 Message-ID: In-Reply-To: <20061011013231.GB23580@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: Acbs1StUIKApJ0YjRP2cAB9M5d+hTgAAZhvA References: <452B995B.92F@xyzzy.claranet.de><452BCBE9.56D0@xyzzy.claranet.de> <20061010182431.GG31563@ccil.org><452BEB3E.1C58@xyzzy.claranet.de> <20061011013231.GB23580@ccil.org> From: Peter Constable To: John Cowan , Frank Ellermann X-OriginalArrivalTime: 11 Oct 2006 01:51:08.0865 (UTC) FILETIME=[B8C48B10:01C6ECD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Anderson, Deborah (), Anthony Aristar , ltru@lists.ietf.org, ISO639-3@sil.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: John Cowan [mailto:cowan@ccil.org]=20 > What's the right procedure for getting conlangs removed > from the list, Peter? 639/RA-JAC? Anthony Aristar? If experts in constructed language feel there are entries in the draft code table for 639-3 that do not warrant inclusion, it would probably be best if they submitted feedback to Joan Spanne at the 639-3 RA (ISO639-3@sil.org), and also to the relevant people connected with Linguist List: Anthony Aristar (aristar@linguistlist.org) and Debbie Anderson (dwanders@sonic.net). Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 21:53:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTI7-0002xd-GA; Tue, 10 Oct 2006 21:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTI6-0002u7-L0 for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:53:50 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXTI5-0006ae-Cf for ltru@lists.ietf.org; Tue, 10 Oct 2006 21:53:50 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 18:51:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 10 Oct 2006 18:51:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Tue, 10 Oct 2006 18:50:34 -0700 Message-ID: In-Reply-To: <20061011013231.GB23580@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: Acbs1StUIKApJ0YjRP2cAB9M5d+hTgAAZhvA References: <452B995B.92F@xyzzy.claranet.de><452BCBE9.56D0@xyzzy.claranet.de> <20061010182431.GG31563@ccil.org><452BEB3E.1C58@xyzzy.claranet.de> <20061011013231.GB23580@ccil.org> From: Peter Constable To: John Cowan , Frank Ellermann X-OriginalArrivalTime: 11 Oct 2006 01:51:08.0865 (UTC) FILETIME=[B8C48B10:01C6ECD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Anderson, Deborah (), Anthony Aristar , ltru@lists.ietf.org, ISO639-3@sil.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: John Cowan [mailto:cowan@ccil.org]=20 > What's the right procedure for getting conlangs removed > from the list, Peter? 639/RA-JAC? Anthony Aristar? If experts in constructed language feel there are entries in the draft code table for 639-3 that do not warrant inclusion, it would probably be best if they submitted feedback to Joan Spanne at the 639-3 RA (ISO639-3@sil.org), and also to the relevant people connected with Linguist List: Anthony Aristar (aristar@linguistlist.org) and Debbie Anderson (dwanders@sonic.net). Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 22:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTXe-0001MN-9M; Tue, 10 Oct 2006 22:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXTXd-0001MI-Kl for ltru@lists.ietf.org; Tue, 10 Oct 2006 22:09:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXTXc-000487-BZ for ltru@lists.ietf.org; Tue, 10 Oct 2006 22:09:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXTXB-0006Aq-Ei for ltru@lists.ietf.org; Wed, 11 Oct 2006 04:09:25 +0200 Received: from pd9fbad9d.dip0.t-ipconnect.de ([217.251.173.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 04:09:25 +0200 Received: from nobody by pd9fbad9d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 04:09:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 11 Oct 2006 04:07:44 +0200 Organization: Lines: 18 Message-ID: <452C51F0.681F@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <20061010182431.GG31563@ccil.org> <452BEB3E.1C58@xyzzy.claranet.de> <20061011013231.GB23580@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad9d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > "Yrch" is in fact the Sindarin word for "orcs", the plural of "orch"; > not Black Speech at all. Oops, I should read it again, I missed that, thanks. >> In some cases like "aue" =/Kx'au//'ein or "gnk" //Gana I'm not sure >> if that's as it should be, it appears to be odd. Or maybe "//" has >> a well-known meaning, and I just don't know what it is. > /, //, and ! are letters representing various clicks in languages of > South Africa and Namibia. Is that ! related to u+01C3 ? Then the others might be u+01C0..u+10C2. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 22:44:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXU4g-000179-I0; Tue, 10 Oct 2006 22:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXU4f-000174-JE for ltru@lists.ietf.org; Tue, 10 Oct 2006 22:44:01 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXU4e-00027m-8b for ltru@lists.ietf.org; Tue, 10 Oct 2006 22:44:01 -0400 Received: from [10.72.72.163] (snvvpn1-10-72-72-c163.corp.yahoo.com [10.72.72.163]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9B2hicE071433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 19:43:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=dcbpIvJ5AcHt0c1OqgEMr6xUPprMOlOI/fp2aYKWfdnld1O+hzJPI6MLw1EbJk7V Message-ID: <452C5A60.7010207@yahoo-inc.com> Date: Tue, 10 Oct 2006 19:43:44 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Is 639-3 bogus ? References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <20061010182431.GG31563@ccil.org> <452BEB3E.1C58@xyzzy.claranet.de> <20061011013231.GB23580@ccil.org> <452C51F0.681F@xyzzy.claranet.de> In-Reply-To: <452C51F0.681F@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> /, //, and ! are letters representing various clicks in languages of >> South Africa and Namibia. > > Is that ! related to u+01C3 ? Then the others might be u+01C0..u+10C2. > Exactly so. The Unicode characters represent the specific "click" characters from those languages and are distinct from the ASCII punctuation commonly used to transcribe those languages in the Latin script. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 10 23:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXV9p-0006uO-PZ; Tue, 10 Oct 2006 23:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXV9o-0006pK-M3 for ltru@lists.ietf.org; Tue, 10 Oct 2006 23:53:24 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXV9m-0003mg-6M for ltru@lists.ietf.org; Tue, 10 Oct 2006 23:53:24 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXV9Y-0000UM-CQ for ltru@lists.ietf.org; Wed, 11 Oct 2006 05:53:09 +0200 Received: from pd9fbad9d.dip0.t-ipconnect.de ([217.251.173.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 05:53:08 +0200 Received: from nobody by pd9fbad9d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 05:53:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 11 Oct 2006 05:50:01 +0200 Organization: Lines: 93 Message-ID: <452C69E9.58B2@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de><452BCBE9.56D0@xyzzy.claranet.de><452BF0C1.731E@xyzzy.claranet.de> <452C17BF.50A8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad9d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: = > it would help if you stated clearly at the outset what your > concerns are. Protecting the registry from bogus subtags, a variation of > If you have a question about the usefulness of orq or any = > other entry, you can contact Anthony Aristar or Debbie Anderson. =46rom my POV John already answered that, "orq" doesn't make much sense in an *_Internet_* registry of language subtags. We'll see if it's removed from the final version, and can pull the emergency break before an IETF Last Call. If all fails we could limit the bulk update to type "L", and allow = individual registrations of subtags with other types under the review of the language subtag list, or a similar rule. > By the time 639-3 is published, some of the spellings may > be revised Maybe use Unicode for the descriptions, the reasons why we didn't limit the registry to Latn (or even Latin-1) should also be okay for the source standards. = The B=E9t=E9 vs. B=E9te question is obvious if you try to sort the source table by its "inverted name" column. > If you see two entries -- two distinct IDs -- then the > language varieties denoted are deemed to be distinct = > languages. Yes, that's clear, three languages bet, bev, and btg. Maybe two others byf and btt, with three variants of "bete" in the description. I stumbled over it because my default codepage is not windows-1252 (and of course not Latin-1). > that doesn't mean that the entries are suspect. As I said I can't judge it, and you asked why I attacked the one subtag I recognized (=3D "orq"). > there's no particular reason for members of this WG to be = > second guessing whether the content of ISO 639-3 is good > enough for use in the LSR. IBTD. If it appears to list "anything" it would hurt the deployment of 4646bis. If we ask folks to download 640 KB the content has to be as good as possible. = We're operating under a "get it right at the first attempt" doctrine, we can't change our minds later and remove "orq". > "That's the job of a comment or description," you said. = > It's still not clear to me if you had a comment to make wrt > John's proposal or not. The "interesting" types A, C, E, H, and S (what's H ?) could be added to the description, e.g. Subtag: xzh Description: Zhang-Zhung (A) Or preserved as a comment: Subtag: xzh Description: Zhang-Zhung Comment: Ancient There are only 617 entries with "interesting" types, anything else is L (living). The scopes could be handled in the same way, all 56 M are L, with that we would get at most one marker per description or comment for now: A, C, E, H, S, or M. If later one of the Ms gets type E adding (M,E) to a description (or saying Macrolanguage, Extinct in a comment) is no problem. Changing the 4646 syntax adding a completely new field however is IMNSHO a very bad idea. We more or less promised that that won't happen. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 00:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVI9-00031W-6a; Wed, 11 Oct 2006 00:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVI7-00031Q-Qj for ltru@ietf.org; Wed, 11 Oct 2006 00:01:59 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXVI6-0004uK-KC for ltru@ietf.org; Wed, 11 Oct 2006 00:01:59 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXVI6-0005OP-2N; Wed, 11 Oct 2006 00:01:58 -0400 Date: Wed, 11 Oct 2006 00:01:58 -0400 To: Addison Phillips Subject: Re: [Ltru] Is 639-3 bogus ? Message-ID: <20061011040157.GC23580@ccil.org> References: <452BBE3E.1060100@yahoo-inc.com> <20061010182238.GF31563@ccil.org> <452BF610.7040800@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452BF610.7040800@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Ideally, extended language subtags would be restricted to the list in > the first link above and 4646bis would reflect that fact. Just so, except that "sgn" (not in 639-3) is treated as a macrolanguage encompassing the sign languages, and an encompassed language that has its own 639-2 or 639-1 tag is not converted to an extlang. > I can see at least one problem with the macro languages list: there are > at least some languages (the "Serbo-Croatian" family) that will be > grandfathered into language subtags rather than extlangs. I'm not sure what you are calling for here: should Serbo-Croatian be marked as a macrolanguage in the LSR or not? -- John Cowan http://ccil.org/~cowan cowan@ccil.org In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 00:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVYW-0002Ew-4Q; Wed, 11 Oct 2006 00:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVYV-0002Er-HN for ltru@ietf.org; Wed, 11 Oct 2006 00:18:55 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXVYU-0007rh-7r for ltru@ietf.org; Wed, 11 Oct 2006 00:18:55 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061011041851.PDES5003.mta9.adelphia.net@DGBP7M81> for ; Wed, 11 Oct 2006 00:18:51 -0400 Message-ID: <003a01c6ecec$5c9f7970$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 10 Oct 2006 21:18:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> What point are you getting at? (I really haven't a clue.) > > How reliable and useful is the info, and should the registry > contain a source indication for alpha-3 language subtags if > there are major differences between 639-2 and 639-3. Maybe > it's possible to delete "orq" from 639-3 later, but it's not > possible to remove it from the LSR. Even if Orcish is goofy and fake, it is part of the Final Draft Standard, every bit as much as German. We don't have any justification for picking the code elements we like from any ISO standard and discarding the others. One of my personal "least favorites" in ISO 639-3 is Yinglish ("yib"), which is really just a smattering of Yiddish-based and -inspired words embedded in normal English. It's not even as much of a dialect as Boontling. The description in Ethnologue calls it "a variety of English influenced by Yiddish (lexically, particularly, but also grammatically and phonetically)" but no evidence is given for differences other than vocabulary. The Wikipedia article focuses entirely on vocabulary. Nevertheless, there it is in ISO/FDIS 639-3, and so there it is in draft-4645bis. Orcish and its 30 words do give me renewed hope for Unilingua and its 187-page textbook: http://upload.wikimedia.org/wikibooks/en/c/c7/Unilingua.pdf -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 00:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVkc-00005v-A3; Wed, 11 Oct 2006 00:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVka-00005l-Qm for ltru@ietf.org; Wed, 11 Oct 2006 00:31:24 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXVkZ-0003jF-Gu for ltru@ietf.org; Wed, 11 Oct 2006 00:31:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061011043122.ORME20629.mta11.adelphia.net@DGBP7M81> for ; Wed, 11 Oct 2006 00:31:22 -0400 Message-ID: <004001c6ecee$1c672090$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 10 Oct 2006 21:31:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > What I was looking for was: > > http://www.sil.org/iso639%2D3/macrolanguages.asp > > And: > > http://www.sil.org/iso639%2D3/scope.asp#M > > Ideally, extended language subtags would be restricted to the list in > the first link above and 4646bis would reflect that fact. I don't want > to construct that list from the registry: I would prefer something > much more cut-and-dried, i.e. getting it from ISO 639-3. Just in case that was confusing to anyone: Extended language subtags are for languages encompassed by macrolanguages, not for the macrolanguages themselves. I know Addison knows that. > Now, all that said, I think it would be useful to include a "type" > field for "collective" languages (with the warnings about their > suitability proposed by John) and for "macro" languages (defining what > can be used as a prefix value in an extlang). In his reply, Peter is of course correct that "Type" and "Scope" are two different things in 639-3. But if it would help anyone, they could be combined into a single informational field in the Registry. All macrolanguages ("M") are living languages ("L"), so there would be no need for compound Language-Type values glued together by commas. If we want to discourage tag producers from using subtags based on "collective codes," but don't want to indicate them in the Registry, I hope we have some alternative plan. Looking for the word "languages" or "(Other)" in the Description does not tell the whole story. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 00:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXW6J-0001FI-03; Wed, 11 Oct 2006 00:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXW6I-0001FD-GJ for ltru@ietf.org; Wed, 11 Oct 2006 00:53:50 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXW6H-0007fQ-7l for ltru@ietf.org; Wed, 11 Oct 2006 00:53:50 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061011045348.OCQY23343.mta10.adelphia.net@DGBP7M81> for ; Wed, 11 Oct 2006 00:53:48 -0400 Message-ID: <004801c6ecf1$3e777f10$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 10 Oct 2006 21:53:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > IMO, there's no particular reason for members of this WG to be second > guessing whether the content of ISO 639-3 is good enough for use in > the LSR. +1 I would add that asking, rhetorically or otherwise, whether 639-3 is bogus because it contains Orcish is akin to asking whether 639-2 is bogus because it encodes Klingon, or 15924 because it encodes Tengwar, or 3166-1 because it encodes Bouvet Island. It takes a lot more than one or two questionable entries to make an entire standard bogus. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 02:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXHP-0000pB-Ni; Wed, 11 Oct 2006 02:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXHN-0000oH-O6 for ltru@lists.ietf.org; Wed, 11 Oct 2006 02:09:21 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXXGP-0003NW-An for ltru@lists.ietf.org; Wed, 11 Oct 2006 02:08:24 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.647.8; Tue, 10 Oct 2006 23:08:18 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 23:08:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Tue, 10 Oct 2006 23:01:54 -0700 Message-ID: In-Reply-To: <452C69E9.58B2@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: Acbs6NaK15M5s8tnR/GsA2+344QIHgAEUW1A From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 11 Oct 2006 06:08:17.0262 (UTC) FILETIME=[A4CF18E0:01C6ECFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > > there's no particular reason for members of this WG to be > > second guessing whether the content of ISO 639-3 is good > > enough for use in the LSR. >=20 > IBTD. If it appears to list "anything" it would hurt the > deployment of 4646bis.=20 May I suggest that if one is willing to read the FDIS text, it would be = reasonably clear that it doesn't aim to list "anything". > The "interesting" types A, C, E, H, and S (what's H ?)=20 The type "historic" refers to historical precursors to modern languages; = e.g. Middle English. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 02:30:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXbP-0001yd-Sg; Wed, 11 Oct 2006 02:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXbO-0001wR-QU for ltru@lists.ietf.org; Wed, 11 Oct 2006 02:30:02 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXXbJ-0006x5-Ax for ltru@lists.ietf.org; Wed, 11 Oct 2006 02:30:02 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXXb1-0006HC-B3 for ltru@lists.ietf.org; Wed, 11 Oct 2006 08:29:39 +0200 Received: from pd9fbad9d.dip0.t-ipconnect.de ([217.251.173.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 08:29:39 +0200 Received: from nobody by pd9fbad9d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 08:29:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 11 Oct 2006 08:28:08 +0200 Organization: Lines: 43 Message-ID: <452C8EF8.39E5@xyzzy.claranet.de> References: <003a01c6ecec$5c9f7970$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad9d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > We don't have any justification for picking the code elements > we like from any ISO standard and discarding the others. It's our duty to stop it if it's not acceptable as IANA registry. An old draft of what's now RFC 4589 was in a questionable state, it was fixed after the IETF Last Call. > One of my personal "least favorites" in ISO 639-3 is Yinglish > ("yib"), which is really just a smattering of Yiddish-based and > -inspired words embedded in normal English. Sometimes he-who-must-not-be-named is right with his fears, there is a fatal trend to register anything remotely related to English, from Boont over yib and Shavian up to proposals to "unicode" some inverted letters only because they are used in Finnegans Wake. > The description in Ethnologue calls it "a variety of English > influenced by Yiddish (lexically, particularly, but also > grammatically and phonetically)" Maybe it is useful as some kind of mixed language. Over here we have DEnglish (all kinds of bad en as spoken + written in D/A/CH, and more important all kinds of de abusing random English words to emulate some global touch, "handy" for "cell phone", and tons of similar inventions). About a century ago they did the same with French words. More likely yib is a similar case as "Kanak Sprak", a mixture of de, en, and tr. There are certainly more lyrics, literature, and videos in "Kanaksprak" than the 30 words "orq". > Orcish and its 30 words do give me renewed hope for Unilingua > and its 187-page textbook: > http://upload.wikimedia.org/wikibooks/en/c/c7/Unilingua.pdf I found - and an article about the 56 words of Lapine in "Watership down". That's all fascinating, but not the stuff for language subtags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 06:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWw-0003ps-0Y; Wed, 11 Oct 2006 06:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWt-0003ls-HD for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbWp-0001Xk-Df for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9BAfVek013039 for ; Wed, 11 Oct 2006 19:41:31 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1e12_0f0fc774_5915_11db_94c9_0014221f2a2d; Wed, 11 Oct 2006 19:41:31 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35844) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Oct 2006 19:41:19 +0900 Message-Id: <6.0.0.20.2.20061011105129.07600d00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Oct 2006 10:57:48 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Is 639-3 bogus ? In-Reply-To: <452C17BF.50A8@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <452BF0C1.731E@xyzzy.claranet.de> <452C17BF.50A8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Peter, The group was indeed discussing type and scope and so on, but Frank made it clear that he was looking at something else by changing the Subject (the specific term 'bogus' is in my opinion a bit unfortunate). In my personal view, Frank is asking some rather stretched, but in some sense valid question: If entries such as orq, with existing documented texts of 30 words overall, can get into ISO 639-3 (draft), then what guarantee, if any, does ISO 629-3 (and therefore our subtag registry) have against denial of service attacks where people make up new languages with a little bit of text? I'm sure you have a good answer to this question, and I'm looking forward to see it. Regards, Martin. At 06:59 06/10/11, Frank Ellermann wrote: >Peter Constable wrote: > >> Is it useful to know that orq is an individual, constructed language >> and that that language is Orcish? Yes. > >alpha-3 is a finite set, if any language of 30 words gets its own code >639-3 is in trouble, and the subtag registry with it. > >> Again, what is the point of these questions? > >Protecting the subtag registry from bogus entries while it's on a one >way street (nothing ever removed) with a known end (26*26*26). > >> And explain to me how this is not a random attack on 639-3, since >> that is certainly how it appears to me. > >Of course it's a random attack, I looked into the source, because John >proposed to preserve its Language-Type info, and the "C" attracted my >attention. There are not many "C", and "orq" is one, and as it happens >I thought (yesterday) I know what "orq" is about. And today I'm sure. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 06:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWw-0003px-4K; Wed, 11 Oct 2006 06:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWt-0003lr-H8 for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbWp-0001Xq-KG for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9BAfYf4018393 for ; Wed, 11 Oct 2006 19:41:34 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1df5_10733628_5915_11db_820f_0014221f2a2d; Wed, 11 Oct 2006 19:41:33 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35844) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Oct 2006 19:41:21 +0900 Message-Id: <6.0.0.20.2.20061011193946.075c9ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Oct 2006 19:41:17 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Is 639-3 bogus ? In-Reply-To: <452C69E9.58B2@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <452BF0C1.731E@xyzzy.claranet.de> <452C17BF.50A8@xyzzy.claranet.de> <452C69E9.58B2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think adding only the 'interesting' information, in the Description or Comment field, would be a much more unobtrusive change to which I could agree (although still not thrilled). Reagrds, Martin. At 12:50 06/10/11, Frank Ellermann wrote: >Peter Constable wrote: >> "That's the job of a comment or description," you said. >> It's still not clear to me if you had a comment to make wrt >> John's proposal or not. > >The "interesting" types A, C, E, H, and S (what's H ?) could >be added to the description, e.g. > >Subtag: xzh >Description: Zhang-Zhung (A) > >Or preserved as a comment: > >Subtag: xzh >Description: Zhang-Zhung >Comment: Ancient > >There are only 617 entries with "interesting" types, anything >else is L (living). The scopes could be handled in the same >way, all 56 M are L, with that we would get at most one marker >per description or comment for now: A, C, E, H, S, or M. > >If later one of the Ms gets type E adding (M,E) to a description >(or saying Macrolanguage, Extinct in a comment) is no problem. > >Changing the 4646 syntax adding a completely new field however >is IMNSHO a very bad idea. We more or less promised that that >won't happen. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 06:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWw-0003ps-0Y; Wed, 11 Oct 2006 06:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWt-0003ls-HD for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbWp-0001Xk-Df for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9BAfVek013039 for ; Wed, 11 Oct 2006 19:41:31 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1e12_0f0fc774_5915_11db_94c9_0014221f2a2d; Wed, 11 Oct 2006 19:41:31 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35844) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Oct 2006 19:41:19 +0900 Message-Id: <6.0.0.20.2.20061011105129.07600d00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Oct 2006 10:57:48 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Is 639-3 bogus ? In-Reply-To: <452C17BF.50A8@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <452BF0C1.731E@xyzzy.claranet.de> <452C17BF.50A8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Peter, The group was indeed discussing type and scope and so on, but Frank made it clear that he was looking at something else by changing the Subject (the specific term 'bogus' is in my opinion a bit unfortunate). In my personal view, Frank is asking some rather stretched, but in some sense valid question: If entries such as orq, with existing documented texts of 30 words overall, can get into ISO 639-3 (draft), then what guarantee, if any, does ISO 629-3 (and therefore our subtag registry) have against denial of service attacks where people make up new languages with a little bit of text? I'm sure you have a good answer to this question, and I'm looking forward to see it. Regards, Martin. At 06:59 06/10/11, Frank Ellermann wrote: >Peter Constable wrote: > >> Is it useful to know that orq is an individual, constructed language >> and that that language is Orcish? Yes. > >alpha-3 is a finite set, if any language of 30 words gets its own code >639-3 is in trouble, and the subtag registry with it. > >> Again, what is the point of these questions? > >Protecting the subtag registry from bogus entries while it's on a one >way street (nothing ever removed) with a known end (26*26*26). > >> And explain to me how this is not a random attack on 639-3, since >> that is certainly how it appears to me. > >Of course it's a random attack, I looked into the source, because John >proposed to preserve its Language-Type info, and the "C" attracted my >attention. There are not many "C", and "orq" is one, and as it happens >I thought (yesterday) I know what "orq" is about. And today I'm sure. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 06:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWw-0003px-4K; Wed, 11 Oct 2006 06:41:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbWt-0003lr-H8 for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbWp-0001Xq-KG for ltru@lists.ietf.org; Wed, 11 Oct 2006 06:41:39 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9BAfYf4018393 for ; Wed, 11 Oct 2006 19:41:34 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1df5_10733628_5915_11db_820f_0014221f2a2d; Wed, 11 Oct 2006 19:41:33 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35844) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Oct 2006 19:41:21 +0900 Message-Id: <6.0.0.20.2.20061011193946.075c9ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Oct 2006 19:41:17 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Is 639-3 bogus ? In-Reply-To: <452C69E9.58B2@xyzzy.claranet.de> References: <452B995B.92F@xyzzy.claranet.de> <452BCBE9.56D0@xyzzy.claranet.de> <452BF0C1.731E@xyzzy.claranet.de> <452C17BF.50A8@xyzzy.claranet.de> <452C69E9.58B2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think adding only the 'interesting' information, in the Description or Comment field, would be a much more unobtrusive change to which I could agree (although still not thrilled). Reagrds, Martin. At 12:50 06/10/11, Frank Ellermann wrote: >Peter Constable wrote: >> "That's the job of a comment or description," you said. >> It's still not clear to me if you had a comment to make wrt >> John's proposal or not. > >The "interesting" types A, C, E, H, and S (what's H ?) could >be added to the description, e.g. > >Subtag: xzh >Description: Zhang-Zhung (A) > >Or preserved as a comment: > >Subtag: xzh >Description: Zhang-Zhung >Comment: Ancient > >There are only 617 entries with "interesting" types, anything >else is L (living). The scopes could be handled in the same >way, all 56 M are L, with that we would get at most one marker >per description or comment for now: A, C, E, H, S, or M. > >If later one of the Ms gets type E adding (M,E) to a description >(or saying Macrolanguage, Extinct in a comment) is no problem. > >Changing the 4646 syntax adding a completely new field however >is IMNSHO a very bad idea. We more or less promised that that >won't happen. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 08:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdOr-0007Bp-CS; Wed, 11 Oct 2006 08:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdOq-0007Bi-22 for ltru@ietf.org; Wed, 11 Oct 2006 08:41:28 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXdOn-00005h-Qh for ltru@ietf.org; Wed, 11 Oct 2006 08:41:28 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXdOm-0006Yr-Sh; Wed, 11 Oct 2006 08:41:24 -0400 Date: Wed, 11 Oct 2006 08:41:24 -0400 To: Alberto Escudero Pascual Message-ID: <20061011124124.GE23580@ccil.org> References: <20061006054245.GA19459@ccil.org> <01f401c6e95f$1b86c5a0$529450e0$@net> <20061006160013.GB10761@ccil.org> <020a01c6e96a$413bc880$c3b35980$@net> <1160558832.8119.19.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160558832.8119.19.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf-languages@iana.org, ltru@ietf.org, louise@it46.se Subject: [Ltru] Re: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Alberto Escudero Pascual scripsit: > When we worked in the locale generator http://www.it46.se/localegen we > worked with the best resources that were available in that time. The > task is/was not easy and as far as i know the tool has served for its > purpose that is too gather some initial data from languages. We put > together more locales in two weeks that in years of previous work. Indeed. I did not mean to be critical of this particular project, and I grant that having the Big List is much better than nothing. I was just attempting to explore the design space to see if something else is better yet. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. cowan@ccil.org --Susan McCarthy (adapted) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 09:12:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdsY-0005h2-2b; Wed, 11 Oct 2006 09:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdsX-0005gx-7w for ltru@lists.ietf.org; Wed, 11 Oct 2006 09:12:09 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXdsW-00061k-0t for ltru@lists.ietf.org; Wed, 11 Oct 2006 09:12:09 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXdsV-0000Nz-Nn for ltru@lists.ietf.org; Wed, 11 Oct 2006 09:12:07 -0400 Date: Wed, 11 Oct 2006 09:12:07 -0400 To: ltru@lists.ietf.org Subject: [Ltru] Re: Is 639-3 bogus ? Message-ID: <20061011131207.GF23580@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > One of my personal "least favorites" in ISO 639-3 is Yinglish ("yib"), > which is really just a smattering of Yiddish-based and -inspired words > embedded in normal English. It's not even as much of a dialect as > Boontling. The description in Ethnologue calls it "a variety of English > influenced by Yiddish (lexically, particularly, but also grammatically > and phonetically)" but no evidence is given for differences other than > vocabulary. The Wikipedia article focuses entirely on vocabulary. Mnyeh. Believe me, boychik, sentences like *this* you do not find in plain (i.e. goyish) English! Even mere shift in vocabulary can produce something pretty unintelligible, like what I found on a web page on "Yeshivish": Before I knew that he had said it in shiur, I was mechaven to the Rosh Yeshiva's pshat in the Gemara. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 09:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXe2H-0002a1-DB; Wed, 11 Oct 2006 09:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXe2G-0002Zu-73 for ltru@ietf.org; Wed, 11 Oct 2006 09:22:12 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXe2E-0007lA-TN for ltru@ietf.org; Wed, 11 Oct 2006 09:22:12 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061011132210.DVRI20629.mta11.adelphia.net@DGBP7M81> for ; Wed, 11 Oct 2006 09:22:10 -0400 Message-ID: <005d01c6ed38$42228d70$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 11 Oct 2006 06:22:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Click letters (was: Re: Is 639-3 bogus ?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Frank Ellermann wrote: >>> /, //, and ! are letters representing various clicks in languages of >>> South Africa and Namibia. >> >> Is that ! related to u+01C3 ? Then the others might be >> u+01C0..u+10C2. > > Exactly so. The Unicode characters represent the specific "click" > characters from those languages and are distinct from the ASCII > punctuation commonly used to transcribe those languages in the Latin > script. I suppose it's not too early to point out that I would be opposed to any nascent plans to "improve" on the characters used in ISO 639-3, by changing the ASCII slashes and bangs to "real" Unicode click letters. We just went through that with apostrophes and the battle was bloody. Applications are welcome to change these to the "correct" characters for display. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 09:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXeEn-0008VG-AF; Wed, 11 Oct 2006 09:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXeEl-0008VB-UM for ltru@ietf.org; Wed, 11 Oct 2006 09:35:07 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXeEj-0001dV-8e for ltru@ietf.org; Wed, 11 Oct 2006 09:35:07 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXeEj-0001Hy-0o; Wed, 11 Oct 2006 09:35:05 -0400 Date: Wed, 11 Oct 2006 09:35:04 -0400 To: Doug Ewell Subject: Re: [Ltru] Click letters (was: Re: Is 639-3 bogus ?) Message-ID: <20061011133504.GG23580@ccil.org> References: <005d01c6ed38$42228d70$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005d01c6ed38$42228d70$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I suppose it's not too early to point out that I would be opposed to any > nascent plans to "improve" on the characters used in ISO 639-3, by > changing the ASCII slashes and bangs to "real" Unicode click letters. +1 > Applications are welcome to change these to the "correct" characters for > display. Not much point: they'd display the same way in any reasonable font. The point of these letter clones of punctuation marks is so that one can use natural-language identifiers (in programming languages, XML documents, etc.) without straying into the domain of punctuation marks, which are usually forbidden in identifiers. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 09:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXeZk-0001ud-6F; Wed, 11 Oct 2006 09:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXeZi-0001uY-DV for ltru@ietf.org; Wed, 11 Oct 2006 09:56:46 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXeZg-0004OK-2a for ltru@ietf.org; Wed, 11 Oct 2006 09:56:46 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061011135639.GIOO20629.mta11.adelphia.net@DGBP7M81> for ; Wed, 11 Oct 2006 09:56:39 -0400 Message-ID: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 11 Oct 2006 06:56:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > From my POV John already answered that, "orq" doesn't make much sense > in an *_Internet_* registry of language subtags. In a Registry that already has Boontling and Klingon and Yinglish? > We'll see if it's removed from the final version, and can pull the > emergency break before an IETF Last Call. If all fails we could limit > the bulk update to type "L", and allow individual registrations of > subtags with other types under the review of the language subtag list, > or a similar rule. Bad idea. Big -1. There is a demonstrated need to tag things like Middle English and Ancient Egyptian, not to mention Esperanto (which would cause another problem, as existing constructed languages would be grandfathered in, but new ones in 639-3 would be excluded). >> By the time 639-3 is published, some of the spellings may be revised > > Maybe use Unicode for the descriptions, the reasons why we didn't > limit the registry to Latn (or even Latin-1) should also be okay for > the source standards. At least one Description needs to match the source standard, no matter how bad we think the spellings might be. >> there's no particular reason for members of this WG to be second >> guessing whether the content of ISO 639-3 is good enough for use in >> the LSR. > > IBTD. If it appears to list "anything" it would hurt the deployment > of 4646bis. If we ask folks to download 640 KB the content has to be > as good as possible. Excluding about 500 to 600 non-"L" languages would reduce the size of the Registry by less than 8 percent, exclude some ISO-coded languages that people may need, and open us up to charges of arbitrariness. > We're operating under a "get it right at the first attempt" doctrine, > we can't change our minds later and remove "orq". I still don't know why we would want to do that. The Language Subtag Reviewer and ietf-languages list can decide that a language requested for independent registration isn't "good enough," but if it's in an ISO standard, who are they (or we) to say? > Or preserved as a comment: > > Subtag: xzh > Description: Zhang-Zhung > Comment: Ancient I kind of see the writing on the wall here. > If later one of the Ms gets type E adding (M,E) to a description (or > saying Macrolanguage, Extinct in a comment) is no problem. If a currently non-extinct language that is widespread enough to serve as a macrolanguage goes extinct during our lifetime, it would amaze me. > Changing the 4646 syntax adding a completely new field however is > IMNSHO a very bad idea. We more or less promised that that won't > happen. Where did we promise that no new fields would ever be added? This would also affect Addison's proposal to replace Suppress-Script with something new. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 09:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXebX-0002v5-SG; Wed, 11 Oct 2006 09:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXebW-0002sw-N5 for ltru@ietf.org; Wed, 11 Oct 2006 09:58:38 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXebV-0004hJ-Cb for ltru@ietf.org; Wed, 11 Oct 2006 09:58:38 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061011135836.ZONS6711.mta13.adelphia.net@DGBP7M81> for ; Wed, 11 Oct 2006 09:58:36 -0400 Message-ID: <006501c6ed3d$5936a820$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 11 Oct 2006 06:58:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > May I suggest that if one is willing to read the FDIS text, it would > be reasonably clear that it doesn't aim to list "anything". Please provide a link to the FDIS text. I can't find it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 10:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXf7c-0001uE-Rx; Wed, 11 Oct 2006 10:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXf7b-0001u2-El for ltru@ietf.org; Wed, 11 Oct 2006 10:31:47 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXf7a-0008Mw-7y for ltru@ietf.org; Wed, 11 Oct 2006 10:31:47 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXf7Z-0003UL-QF; Wed, 11 Oct 2006 10:31:45 -0400 Date: Wed, 11 Oct 2006 10:31:45 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Is 639-3 bogus ? Message-ID: <20061011143145.GH23580@ccil.org> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I still don't know why we would want to do that. The Language Subtag > Reviewer and ietf-languages list can decide that a language requested > for independent registration isn't "good enough," but if it's in an ISO > standard, who are they (or we) to say? Yesterday, following Peter's suggestion, I petitioned the 639-3/RA and the Linguist List maintainers (who are the sub-registrars for ancient and constructed languages) to remove Ceqli = Tceqli (same language), Delason, Linga, Jakelimota, and Orcish from the list as insufficiently documented or used or both; also Glosa (because it is a dialect of Interglossa). Anthony Aristar of Linguist List wrote back expressing substantial agreement (and using the phrase "slipped through the cracks"), so I think we can expect them to go away. The remaining languages (Afrihili, Brithenig, Dutton World Speedwords, Esperanto, Ido, Interglossa, Interlingue, Interlingua de IALA, Lojban, Laadan, Novial, Occidental, Quenya, Romanova, Sindarin, Klingon, Volapuk) all easily meet the relevant standards for literature and documentation: they have, or have had, communities of use. I think therefore that we should drop the subject. > >Or preserved as a comment: > > > >Subtag: xzh > >Description: Zhang-Zhung > >Comment: Ancient > > I kind of see the writing on the wall here. So do I. If a comment is that structured, make it a field. > If a currently non-extinct language that is widespread enough to serve > as a macrolanguage goes extinct during our lifetime, it would amaze me. +1 > Where did we promise that no new fields would ever be added? This would > also affect Addison's proposal to replace Suppress-Script with something > new. +1 -- "Well, I'm back." --Sam John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 10:33:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXf8t-0002RQ-Ie; Wed, 11 Oct 2006 10:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXf8s-0002RL-85 for ltru@ietf.org; Wed, 11 Oct 2006 10:33:06 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXf8r-0008VS-1P for ltru@ietf.org; Wed, 11 Oct 2006 10:33:06 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXf8q-0003YH-Pq; Wed, 11 Oct 2006 10:33:04 -0400 Date: Wed, 11 Oct 2006 10:33:04 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Is 639-3 bogus ? Message-ID: <20061011143304.GI23580@ccil.org> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> <20061011143145.GH23580@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061011143145.GH23580@ccil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan scripsit: > I think we can expect them to go away. Go away, I hasten to add, *before* the publication of IS 639-3, and therefore before 4645bis. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 11:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgFu-0002Yw-88; Wed, 11 Oct 2006 11:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgFs-0002YI-Oh for ltru@ietf.org; Wed, 11 Oct 2006 11:44:24 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgEs-00008c-9M for ltru@ietf.org; Wed, 11 Oct 2006 11:43:23 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXgEr-0006Vg-Ij; Wed, 11 Oct 2006 11:43:21 -0400 Date: Wed, 11 Oct 2006 11:43:21 -0400 To: Addison Phillips Subject: Re: [Ltru] Is 639-3 bogus ? Message-ID: <20061011154321.GL23580@ccil.org> References: <452BBE3E.1060100@yahoo-inc.com> <20061010182238.GF31563@ccil.org> <452BF610.7040800@yahoo-inc.com> <20061011040157.GC23580@ccil.org> <452D0E40.4060203@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452D0E40.4060203@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > - Serbo-Croatian marked as a macrolanguage. > - Its constituent languages maintained as type 'language' and not > converted to type 'extlang'. +1 -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Humpty Dump Dublin squeaks through his norse Humpty Dump Dublin hath a horrible vorse But for all his kinks English / And his irismanx brogues Humpty Dump Dublin's grandada of all rogues. --Cousin James _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 11:44:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGJ-0002jx-2G; Wed, 11 Oct 2006 11:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGH-0002jE-NG for ltru@ietf.org; Wed, 11 Oct 2006 11:44:49 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXg4j-0007Lh-Iz for ltru@ietf.org; Wed, 11 Oct 2006 11:32:54 -0400 Received: by wr-out-0506.google.com with SMTP id i32so41707wra for ; Wed, 11 Oct 2006 08:32:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RZaey4hby9KWEvsxKAsf3uuuqhPS+a8WuuJ8dDmU/p+wFH/fLFdHKN7ZS52x316J3O/FEU+BPC48qK5eEWOzKDA+dhS+FSHPIEkvkOnQyuLPs5oPk3L1vKYT0rWwqglEVrCUTkr5jrZ02avgnC1LeuMrXJNMk1BYx2q+zolwskU= Received: by 10.90.25.7 with SMTP id 7mr510369agy; Wed, 11 Oct 2006 08:32:53 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Wed, 11 Oct 2006 08:32:53 -0700 (PDT) Message-ID: <30b660a20610110832i394304a9pf8c28ffdc2ce5786@mail.gmail.com> Date: Wed, 11 Oct 2006 08:32:53 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Is 639-3 bogus ? In-Reply-To: <004801c6ecf1$3e777f10$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <004801c6ecf1$3e777f10$6501a8c0@DGBP7M81> X-Google-Sender-Auth: 3883401767f1cf4a X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0481125353==" Errors-To: ltru-bounces@ietf.org --===============0481125353== Content-Type: multipart/alternative; boundary="----=_Part_11474_27546983.1160580773158" ------=_Part_11474_27546983.1160580773158 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Agreed On 10/10/06, Doug Ewell wrote: > > Peter Constable wrote: > > > IMO, there's no particular reason for members of this WG to be second > > guessing whether the content of ISO 639-3 is good enough for use in > > the LSR. > > +1 > > I would add that asking, rhetorically or otherwise, whether 639-3 is > bogus because it contains Orcish is akin to asking whether 639-2 is > bogus because it encodes Klingon, or 15924 because it encodes Tengwar, > or 3166-1 because it encodes Bouvet Island. It takes a lot more than > one or two questionable entries to make an entire standard bogus. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_11474_27546983.1160580773158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Agreed

On 10/10/06, Doug Ewell <dewell@adelphia.net> wrote:
Peter Constable <petercon at microsoft dot com> wrote:

> IMO, there's no particular reason for members of this WG to be second
> guessing whether the content of ISO 639-3 is good enough for use in
> the LSR.

+1

I would add that asking, rhetorically or otherwise, whether 639-3 is
bogus because it contains Orcish is akin to asking whether 639-2 is
bogus because it encodes Klingon, or 15924 because it encodes Tengwar,
or 3166-1 because it encodes Bouvet Island.  It takes a lot more than
one or two questionable entries to make an entire standard bogus.

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


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

------=_Part_11474_27546983.1160580773158-- --===============0481125353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0481125353==-- From ltru-bounces@ietf.org Wed Oct 11 11:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGO-0002sB-K5; Wed, 11 Oct 2006 11:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGL-0002nR-FN for ltru@ietf.org; Wed, 11 Oct 2006 11:44:53 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXg3F-00079A-UN for ltru@ietf.org; Wed, 11 Oct 2006 11:31:23 -0400 Received: from [10.72.72.163] (snvvpn1-10-72-72-c163.corp.yahoo.com [10.72.72.163]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9BFVDOS000790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Oct 2006 08:31:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=wHqA5cIWlAf4FbMfGfaMUAtKO/aHUUyWDVzYw5YJrQXMGB9f6iFKwiLHZ4DWwxSF Message-ID: <452D0E40.4060203@yahoo-inc.com> Date: Wed, 11 Oct 2006 08:31:12 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Is 639-3 bogus ? References: <452BBE3E.1060100@yahoo-inc.com> <20061010182238.GF31563@ccil.org> <452BF610.7040800@yahoo-inc.com> <20061011040157.GC23580@ccil.org> In-Reply-To: <20061011040157.GC23580@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Addison Phillips scripsit: > >> Ideally, extended language subtags would be restricted to the list in >> the first link above and 4646bis would reflect that fact. > > Just so, except that "sgn" (not in 639-3) is treated as a macrolanguage > encompassing the sign languages, and an encompassed language that has > its own 639-2 or 639-1 tag is not converted to an extlang. Yes. > >> I can see at least one problem with the macro languages list: there are >> at least some languages (the "Serbo-Croatian" family) that will be >> grandfathered into language subtags rather than extlangs. > > I'm not sure what you are calling for here: should Serbo-Croatian > be marked as a macrolanguage in the LSR or not? > - Serbo-Croatian marked as a macrolanguage. - Its constituent languages maintained as type 'language' and not converted to type 'extlang'. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 12:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXggm-0001eI-AJ; Wed, 11 Oct 2006 12:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXggl-0001eD-Tv for ltru@lists.ietf.org; Wed, 11 Oct 2006 12:12:11 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXggg-0004aM-G6 for ltru@lists.ietf.org; Wed, 11 Oct 2006 12:12:11 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.647.8; Wed, 11 Oct 2006 09:12:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Wed, 11 Oct 2006 09:11:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Wed, 11 Oct 2006 09:10:53 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20061011105129.07600d00@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: AcbtId0oiQQF4ZduRGatNIn8Wlp9WwAKLfPA From: Peter Constable To: Martin Duerst , Frank Ellermann , X-OriginalArrivalTime: 11 Oct 2006 16:11:48.0952 (UTC) FILETIME=[F4A87D80:01C6ED4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank responded to a comment I made that was clearly to do with John's = proposal, and he did NOT make clear IMO what his concern was until = several msgs had been exchanged. If there are concerns about questionable entries for constructed = languages in the draft code table for 639-3, then it is perfectly = reasonable (i) to ask a general question as to the criteria for = inclusion of such languages or (ii) to submit feedback to the 639-3 RA = regarding those entries.=20 Frank did neither but rather launched into a vague critique of 639-3 = with random potshots: I don't like this entry; those two entries have = similar names so must be suspect... And he chose an inflammatory subject = line. That's got about as much professionalism as someone saying any = project Frank has worked on must be bogus just because they have an = upset stomach and are cranky. The answer to the general question, as John Cowan mentioned, is that = there *are* criteria for inclusion and that not just *anything* is = accepted. A constructed language must have a body of literature read by = members of some community. Requests for an ID from people making up a = few words will not be accepted. Re the second, John Cowan submitted feedback to the RA, and it was = agreed that those should not be included. Peter > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Tuesday, October 10, 2006 6:58 PM > To: Frank Ellermann; ltru@lists.ietf.org > Subject: Re: [Ltru] Re: Is 639-3 bogus ? >=20 > Hello Peter, >=20 > The group was indeed discussing type and scope and so on, but > Frank made it clear that he was looking at something else by > changing the Subject (the specific term 'bogus' is in my opinion > a bit unfortunate). >=20 > In my personal view, Frank is asking some rather stretched, > but in some sense valid question: If entries such as orq, > with existing documented texts of 30 words overall, can get > into ISO 639-3 (draft), then what guarantee, if any, does > ISO 629-3 (and therefore our subtag registry) have against > denial of service attacks where people make up new languages > with a little bit of text? >=20 > I'm sure you have a good answer to this question, and I'm > looking forward to see it. >=20 > Regards, Martin. >=20 > At 06:59 06/10/11, Frank Ellermann wrote: > >Peter Constable wrote: > > > >> Is it useful to know that orq is an individual, constructed = language > >> and that that language is Orcish? Yes. > > > >alpha-3 is a finite set, if any language of 30 words gets its own = code > >639-3 is in trouble, and the subtag registry with it. > > > >> Again, what is the point of these questions? > > > >Protecting the subtag registry from bogus entries while it's on a one > >way street (nothing ever removed) with a known end (26*26*26). > > > >> And explain to me how this is not a random attack on 639-3, since > >> that is certainly how it appears to me. > > > >Of course it's a random attack, I looked into the source, because = John > >proposed to preserve its Language-Type info, and the "C" attracted my > >attention. There are not many "C", and "orq" is one, and as it = happens > >I thought (yesterday) I know what "orq" is about. And today I'm = sure. >=20 >=20 > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp = mailto:duerst@it.aoyama.ac.jp >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 12:19:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgo6-0005ak-IF; Wed, 11 Oct 2006 12:19:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgo4-0005ae-Iv for ltru@ietf.org; Wed, 11 Oct 2006 12:19:44 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgo1-0005Lb-7k for ltru@ietf.org; Wed, 11 Oct 2006 12:19:44 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.647.8; Wed, 11 Oct 2006 09:19:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 09:18:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Is 639-3 bogus ? Date: Wed, 11 Oct 2006 09:18:10 -0700 Message-ID: In-Reply-To: <006501c6ed3d$5936a820$6501a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Is 639-3 bogus ? thread-index: AcbtPVvAy2BFXh/BRS2/l30sAvhjtgAE1WvA From: Peter Constable To: Doug Ewell , LTRU Working Group X-OriginalArrivalTime: 11 Oct 2006 16:18:54.0143 (UTC) FILETIME=[F2177CF0:01C6ED50] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2014522526==" Errors-To: ltru-bounces@ietf.org --===============2014522526== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVvcGxlIGNhbiBjb250YWN0IHRoZWlyIG5hdGlvbmFsIHN0YW5kYXJkcyBib2R5IHRvIHJlcXVl c3QgdGhlIEZESVMgdGV4dC4gWW91IGNhbiBmaW5kIHRoZSBESVMgaGVyZToNCg0KaHR0cDovL3Nj cmlwdHMuc2lsLm9yZy9jbXMvc2NyaXB0cy9wYWdlLnBocD9zaXRlX2lkPW5yc2kmaXRlbV9pZD1Q Q1VuaWNvZGVEb2NzJmhpZ2hsaWdodD02MzkjMzY3ZGI4ODMtYTUwZTVmODANCg0KDQpQZXRlcg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdWcgRXdlbGwgW21haWx0 bzpkZXdlbGxAYWRlbHBoaWEubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTEsIDIw MDYgNjo1OSBBTQ0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBS ZTogSXMgNjM5LTMgYm9ndXMgPw0KPiANCj4gUGV0ZXIgQ29uc3RhYmxlIDxwZXRlcmNvbiBhdCBt aWNyb3NvZnQgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IE1heSBJIHN1Z2dlc3QgdGhhdCBpZiBv bmUgaXMgd2lsbGluZyB0byByZWFkIHRoZSBGRElTIHRleHQsIGl0IHdvdWxkDQo+ID4gYmUgcmVh c29uYWJseSBjbGVhciB0aGF0IGl0IGRvZXNuJ3QgYWltIHRvIGxpc3QgImFueXRoaW5nIi4NCj4g DQo+IFBsZWFzZSBwcm92aWRlIGEgbGluayB0byB0aGUgRkRJUyB0ZXh0LiAgSSBjYW4ndCBmaW5k IGl0Lg0KPiANCj4gLS0NCj4gRG91ZyBFd2VsbCAgKiAgRnVsbGVydG9uLCBDYWxpZm9ybmlhLCBV U0EgICogIFJGQyA0NjQ1ICAqICBVVE4gIzE0DQo+IGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQv fmRld2VsbC8NCj4gaHR0cDovL3d3dzEuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0 ZXIuaHRtbA0KPiBodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vbWFpbG1hbi9saXN0aW5mby9pZXRm LWxhbmd1YWdlcw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============2014522526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2014522526==-- From ltru-bounces@ietf.org Wed Oct 11 13:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXi0U-00057i-7s; Wed, 11 Oct 2006 13:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXi0S-00057d-6W for ltru@ietf.org; Wed, 11 Oct 2006 13:36:36 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXi0Q-0000ET-Cg for ltru@ietf.org; Wed, 11 Oct 2006 13:36:35 -0400 Received: from [172.21.148.31] (wlanvpn-mc2e-246-31.corp.yahoo.com [172.21.148.31]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9BHaVVb004663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Oct 2006 10:36:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=g8wx3vtStuGlrP+vD+rqJktLYvZKiqotcxyJA17MiOANYKQk36hNmrZ9rmc7QGK9 Message-ID: <452D2B9F.3040306@yahoo-inc.com> Date: Wed, 11 Oct 2006 10:36:31 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'LTRU Working Group'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id k9BHaVVb004663 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Ltru] [Fwd: Re: XML 4e and language tags...] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org FYI... Addison -------- Original Message -------- Subject: Re: XML 4e and language tags... Date: Wed, 11 Oct 2006 10:31:04 -0700 From: Fran=C3=A7ois Yergeau To: Addison Phillips References: <44EDEF73.3030101@yahoo-inc.com> Hi Addison, Addison Phillips wrote to the xml-editor list: > I noticed just now the publication of XML 1.0 4th Edition. In it I=20 > notice a few issues with the handling of language tags (a topic in whic= h=20 > I take some interest). >=20 > In particular, I note: >=20 > 1. Section 1.1 contains this paragraph: >=20 > --=20 > This specification, together with associated standards (Unicode=20 > [Unicode] and ISO/IEC 10646 [ISO/IEC 10646] for characters, Internet RF= C=20 > 3066 [IETF RFC 3066] for language identification tags, ISO 639 [ISO 639= ]=20 > for language name codes, and ISO 3166 [ISO 3166] for country name=20 > codes), provides all the information necessary to understand XML Versio= n=20 > 1.0 and construct computer programs to process it. The XML Core WG discussed this today on our telcon. Since 4646 is at long last referenceable, we decided to change the text as follows: "This specification, together with associated standards (Unicode [Unicode] and ISO/IEC 10646 [ISO10646] for characters, Internet RFC 4646 [IETF RFC 4646] and the Language Subtag Registry [IANA-LANGCODES] for language identification tags), provides all the information necessary to understand XML Version [1.0 | 1.1]; and construct computer programs to process it." The reference to 3066 will go away, replaced by 4646, and the [IANA-LANGCODES] bib entry will point to the new registry. This is in a 4-week countdown from today in the WG, so it's time to raise any issue you may have. --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 14:05:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiSM-0003Vd-TO; Wed, 11 Oct 2006 14:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaNE-0002Os-Hp for ltru@ietf.org; Wed, 11 Oct 2006 05:27:36 -0400 Received: from vmail.nodo50.org ([194.109.216.190] helo=revolware.nodo50.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXaNB-0007Po-32 for ltru@ietf.org; Wed, 11 Oct 2006 05:27:36 -0400 Received: from localhost.localdomain (revolware.nodo50.org [194.109.209.218]) by revolware.nodo50.org (Postfix) with ESMTP id E22CA3963B4; Wed, 11 Oct 2006 11:27:05 +0200 (CEST) From: Alberto Escudero Pascual To: Don Osborn In-Reply-To: <020a01c6e96a$413bc880$c3b35980$@net> References: <20061006054245.GA19459@ccil.org> <01f401c6e95f$1b86c5a0$529450e0$@net> <20061006160013.GB10761@ccil.org> <020a01c6e96a$413bc880$c3b35980$@net> Content-Type: text/plain Organization: IT46 Date: Wed, 11 Oct 2006 11:27:11 +0200 Message-Id: <1160558832.8119.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Wed, 11 Oct 2006 14:05:25 -0400 Cc: ietf-languages@iana.org, ltru@ietf.org, louise@it46.se Subject: [Ltru] RE: Language picking X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aep@it46.se List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Don and John, When we worked in the locale generator http://www.it46.se/localegen we worked with the best resources that were available in that time. The task is/was not easy and as far as i know the tool has served for its purpose that is too gather some initial data from languages. We put together more locales in two weeks that in years of previous work. Usability was taken into consideration from the very early stage of the design. If you do not find a language under the list, you can always edit the entries manually (see manual of the application). We are happy to receive feedback, the "interactive search option" is now added to our wish-list. We are also happy to hear if someone wants to move forward with the tool. Alberto On Fri, 2006-10-06 at 13:09 -0400, Don Osborn wrote: > Thanks, John, I think the Locale Generator as such was a first cut. I'll cc > this to Alberto and Louise (who created the Generator earlier this year) for > their info (see archives via > http://www.alvestrand.no/mailman/listinfo/ietf-languages ). > > Two issues: you and they base the list on 639-3, which is okay if > "macrolanguages," are included and better yet if 639-1 code categories are > also there. I think the level of precision of language picking for locales > and localization depends a lot on the use. If it's localizing a software, it > makes no sense to look at separate versions for 8 varieties of > Fulfulde/Pulaar, or a dozen or so Manding tongues, but if you are talking > about text it might even be helpful in some cases to have a finer > distinction. There are lots of such examples in Africa, for instance. > > This need for flexibility almost seems to require a more "artisanal" > approach that lets real people who are more or less familiar with the > languages, countries, needs, etc. access information to make the choices > based on their perceived specific needs. This is the sense of the PAL > African language wiki I also mentioned. > > Where I think lists such as those you and Alberto and Louise are working on > fitting in this process is in providing a range of information and options > on the way to producing some output - and that that output be explicitly > part of an iterative process. That is to say, it is not the final word in > itself, but an aid in reaching an appropriate solution. The products of > Locale Generator, for example, indeed are reviewed before submission. > > Ultimately an interactive search option might be a good feature for such > lists (which I guess requires a database or an advanced search facility). It > might also alert users to language synonym issues - unrelated languages with > the same or similar names that might be confused. > > Hope this helps. > > Don > > > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Friday, October 06, 2006 12:00 PM > To: Don Osborn > Cc: debbie@ictmarketing.co.uk; ltru@ietf.org; ietf-languages@iana.org > Subject: Re: Language picking > > Don Osborn scripsit: > > > The Locale Generator - http://www.it46.se/localegen/ (list of > > languages for creation of locales from ISO/FDIS 636-3 - needs to be > > amended IMO; country is selected after language) > > This is a fine example of what's wrong with just using the bare list of > languages. The list is here broken up by first letter of the alphabet into > 27 sublists, but when I look for Dari under "D", I don't find it and go away > in disgust (see my earlier posting). > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 14:56:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjFn-0004Rs-CO; Wed, 11 Oct 2006 14:56:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjFl-0004Rn-Et for ltru@ietf.org; Wed, 11 Oct 2006 14:56:29 -0400 Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjFk-00038v-UB for ltru@ietf.org; Wed, 11 Oct 2006 14:56:29 -0400 Received: from chalmers95a69n (83.248.26.17) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 452BAD6D0005E53D; Wed, 11 Oct 2006 20:56:11 +0200 From: "Kent Karlsson" To: "'John Cowan'" , "'Doug Ewell'" Subject: RE: [Ltru] Click letters Date: Wed, 11 Oct 2006 20:51:54 +0200 Message-ID: <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20061011133504.GG23580@ccil.org> Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > I suppose it's not too early to point out that I would be=20 > opposed to any=20 > > nascent plans to "improve" on the characters used in ISO 639-3, by=20 > > changing the ASCII slashes and bangs to "real" Unicode=20 > click letters.=20 >=20 > +1 The spelling should of course be fixed in the source standard, in this case preferably before 639-3 is published so that we don't get these ASCII fallbacks in the language subtag registry (not even initially). I have been intending to write to the relevant JAC about this (see = below). > > Applications are welcome to change these to the "correct" characters = for=20 > > display. >=20 > Not much point: they'd display the same way in any reasonable font. No, they do not look like the ASCII fallbacks used at all, except for=20 EXCLAMATION MARK vs. LATIN LETTER RETROFLEX CLICK. > The point of these letter clones of punctuation marks is so that > one can use natural-language identifiers (in programming languages, > XML documents, etc.) without straying into the domain of punctuation > marks, which are usually forbidden in identifiers. No, it most certainly is NOT the point of those characters. While they = (for many programming languages) are *allowed* in identifiers, I hardly = expect them to be used in that way. The point of them, instead, is to use them in ordinary text, mostly in the languages that use click sounds. Some of the language names are, really, in those languages, and should therefore be spelled using the click letters. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Below you fined my draft comment (intended for the JAC) on this issue that I have. (Note that this e-mail was set to be sent in UTF-8. = Hopefully it is still in UTF-8 when you receive it.) Another comment I have is that country names should not be used for disambiguation of same-named but different languages. Country names are not quite as stable as one would want for the langauge names. Rather one should use language group names (at a suitable level). Nor is it = always clear from the country names if one refers to closely related languages, = or to languages that are not at all related (though one can sometimes = guess). ----------------------------------------------- The following language code descriptions (language names) should be spelled with the proper letters, not using ASCII fallbacks. The fallback to proper letter mapping appears to be as follows: / -> =C7=80 01C0;LATIN LETTER DENTAL = CLICK;Lo;0;L;;;;;N;LATIN LETTER PIPE;;;; // -> =C7=81 01C1;LATIN LETTER LATERAL = CLICK;Lo;0;L;;;;;N;LATIN LETTER DOUBLE PIPE;;;; =3D/ -> =C7=82 01C2;LATIN LETTER ALVEOLAR = CLICK;Lo;0;L;;;;;N;LATIN LETTER PIPE DOUBLE BAR;;;; ! -> =C7=83 01C3;LATIN LETTER RETROFLEX = CLICK;Lo;0;L;;;;;N;LATIN LETTER EXCLAMATION MARK;;;; ' -> =CA=BC 02BC;MODIFIER LETTER = APOSTROPHE;Lm;0;L;;;;;N;;;;; In the cases where the ' stands for glottal stop use MODIFIER LETTER = APOSTROPHE. Elision and genitive apostrophes are properly spelled with =E2=80=99 = 2019;RIGHT SINGLE QUOTATION MARK as in the last nine entries listed below. I'm not sure if = some of the other apostrophes really are elision apostrophes too. oun I L !O!ung nmn I L !X=C3=B3=C3=B5 hnh I L //Ani gnk I L //Gana xeg I E //Xegwi gwj I L /Gwi xam I E /Xam huc I L =3D/Hua aue I L =3D/Kx'au//'ein hgm I L Hai//om ktz I L Ju/'hoan ngh I L N/u =20 acq I L Arabic, Ta'izzi-Adeni = Spoken alu I L 'Are'are mtv I L Asaro'o aot I L A'tong kud I L 'Auhelawa bei I L Bekati' byd I L Benyadu' crt I L Chorote, Iyojwa'ja crq I L Chorote, Iyo'wujwa dri I L C'lela ing I L Degexit'an dor I L Dori'o dup I L Duano' fab I L Fa D'ambu fmp I L Fe'fe' gqa I L Ga'anda gdg I L Ga'dang gaq I L Gata' bbj I L Ghom=C3=A1l=C3=A1' gmb I L Gula'alaa hwc I L Hawai'i Creole English hps I L Hawai'i Pidgin Sign = Language haw haw I L Hawaiian = [should this not use a letter apostrophe?] dbj I L Ida'an ilu I L Ili'uun xkk I L Kaco' kzf I L Kaili, Da'a blk I L Karen, Pa'o ksw I L Karen, S'gaw xxk I L Ke'o kuk I L Kepo' xkc I L Kho'ini krr I L Kru'ng 2 [what is = the 2 here? 2? LATIN CAPITAL/SMALL TONE TWO? LATIN LETTER TWO WITH = STROKE? ...] xmp I L Kuku-Mu'inh kuy I L Kuuku-Ya'u bko I L Kwa' wka I E Kw'adza kwf I L Kwara'ae lbi I L La'bi lns I L Lamnso' lra I L Lara' ljl I L Li'o prb I L Lua' mhy I L Ma'anyan mhi I L Ma'di snm I L Ma'di, Southern lva I L Maku'a slz I L Ma'ya yus I L Maya, Chan Santa Cruz = [should this not use a letter apostrophe?] yua I L Maya, Yucat=C3=A1n = [should this not use a letter apostrophe?] xmy I L Mayaguduna emy I E Mayan, Epigraphic = [should this not use a letter apostrophe?] mtk I L Mbe' muc I L Mbu' mym I L Me'en mgo I L Meta' gbn I L Mo'da nae I L Naka'ela nnz I L Nda'nda' nxg I L Ngad'a nea I L Ngad'a, Eastern nbm I L Ngbaka Ma'bo ncg I L Nisga'a num I L Niuafo'ou nyp I E Nyang'i tyh I L O'du lul I L Olu'bo oyy I L Oya'oya pqa I L Pa'a ple I L Palu'e phq I L Phana' qxq I L Qashqa'i apb I L Sa'a snv I L Sa'ban scq I L Sa'och xst I L Silt'e ssq I L So'a rob I L Tae' tln I L Talondo' tto I L Ta'oih, Lower tth I L Ta'oih, Upper tct I L T'en tve I L Te'un mlu I L To'abaita tlz I L Toala' ood I L Tohono O'odham sda I L Toraja-Sa'dan tsl I L Ts'=C3=BCn-Lao ulm I L Ulumanda' urk I L Urak Lawoi' wag I L Wa'ema wmh I L Waima'a wih I L Wik-Me'anha ame I L Yanesha' pto I L Zo'=C3=A9 =20 eot I L Beti (C=C3=B4te d'Ivoire) = [elision apostrophe] crd I L Coeur d'Alene [elision = apostrophe] fla I L Kalispel-Pend d'Oreille = [elision apostrophe] kfo I L Koro (C=C3=B4te d'Ivoire) = [elision apostrophe] loi I L Loma (C=C3=B4te d'Ivoire) = [elision apostrophe] mre I E Martha's Vineyard Sign = Language [elision apostrophe] ngm I L Ngatik Men's Creole = [elision apostrophe] plw I L Palawano, Brooke's Point = [elision apostrophe] neb I L Toura (C=C3=B4te d'Ivoire) = [elision apostrophe] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 15:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjcQ-00073J-0h; Wed, 11 Oct 2006 15:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjcO-000738-Kd for ltru@ietf.org; Wed, 11 Oct 2006 15:19:52 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjcK-0005PP-0R for ltru@ietf.org; Wed, 11 Oct 2006 15:19:52 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.647.8; Wed, 11 Oct 2006 12:19:47 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 12:19:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Click letters Date: Wed, 11 Oct 2006 12:18:20 -0700 Message-ID: In-Reply-To: <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Click letters thread-index: AcbtZvyEEznTqKGiTzCcQ1dAWupiOgAAaF5A References: <20061011133504.GG23580@ccil.org> <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 11 Oct 2006 19:19:09.0771 (UTC) FILETIME=[20B559B0:01C6ED6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1350464279==" Errors-To: ltru-bounces@ietf.org --===============1350464279== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgYW55b25lIHdvdWxkIGxpa2UgdG8gcmV2aWV3IHRoZSBlbnRyaWVzIGluIHRoZSBkcmFmdCBj b2RlIHRhYmxlIGZvciA2MzktMyBhbmQgc3VnZ2VzdCBjaGFyYWN0ZXIgY2hhbmdlcyB0byBnZXQg YmV5b25kIEFTQ0lJIC8gTGF0aW4tMSBsaW1pdGF0aW9ucywgcGxlYXNlIGZlZWwgZnJlZTsgSSdt IHN1cmUgdGhlIFJBIHdvdWxkIHdlbGNvbWUgdGhlIGZlZWRiYWNrLiBCdXQgZG9uJ3QgbmVjZXNz YXJpbHkgZXhwZWN0IGd1YXJhbnRlZXMgdGhhdCBhbGwgb3IgYW55IHN1Y2ggY2hhbmdlcyB3b3Vs ZCBuZWNlc3NhcmlseSBiZSBtYWRlIHByaW9yIHRvIHB1YmxpY2F0aW9uOiB0aGF0IGlzIHBvdGVu dGlhbGx5IGEgbGFyZ2UgYW1vdW50IG9mIGZlZWRiYWNrIHRvIHZldCBhbmQgdGFrZSBhY3Rpb24g b24uIA0KDQpOb3RlIHRoYXQgYSBwcmlvciBpc3N1ZSBmb3IgdGhlIFJBIGFuZCB0aGUgSkFDIHRv IGNvbnNpZGVyIGlzIHdoYXQgY2hhcmFjdGVyIHNldCBzaG91bGQgYmUgYWxsb3dlZCBpbiBsYW5n dWFnZSBuYW1lcyB1c2VkIGluIHRoZSA2Mzkgc3RhbmRhcmRzLiBJZiB5b3Ugd291bGQgbGlrZSB0 byBzdWJtaXQgZmVlZGJhY2sgaW4gdGhhdCByZWdhcmQsIGl0IHNob3VsZCBwcm9iYWJseSBnbyB0 byB0aGUgSkFDIHZpYSBNaWNoYWVsIEV2ZXJzb24gLS0gSUlSQyBoZSBpcyBJRVRGIGxpYWlzb24g dG8gdGhlIEpBQy4NCg0KDQpQZXRlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBLZW50IEthcmxzc29uIFttYWlsdG86a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZV0gDQpT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTEsIDIwMDYgMTE6NTIgQU0NClRvOiAnSm9obiBDb3dh bic7ICdEb3VnIEV3ZWxsJw0KQ2M6ICdMVFJVIFdvcmtpbmcgR3JvdXAnDQpTdWJqZWN0OiBSRTog W0x0cnVdIENsaWNrIGxldHRlcnMNCg0KDQo+ID4gSSBzdXBwb3NlIGl0J3Mgbm90IHRvbyBlYXJs eSB0byBwb2ludCBvdXQgdGhhdCBJIHdvdWxkIGJlIA0KPiBvcHBvc2VkIHRvIGFueSANCj4gPiBu YXNjZW50IHBsYW5zIHRvICJpbXByb3ZlIiBvbiB0aGUgY2hhcmFjdGVycyB1c2VkIGluIElTTyA2 MzktMywgYnkgDQo+ID4gY2hhbmdpbmcgdGhlIEFTQ0lJIHNsYXNoZXMgYW5kIGJhbmdzIHRvICJy ZWFsIiBVbmljb2RlIA0KPiBjbGljayBsZXR0ZXJzLiANCj4gDQo+ICsxDQoNClRoZSBzcGVsbGlu ZyBzaG91bGQgb2YgY291cnNlIGJlIGZpeGVkIGluIHRoZSBzb3VyY2Ugc3RhbmRhcmQsIGluIHRo aXMNCmNhc2UgcHJlZmVyYWJseSBiZWZvcmUgNjM5LTMgaXMgcHVibGlzaGVkIHNvIHRoYXQgd2Ug ZG9uJ3QgZ2V0IHRoZXNlDQpBU0NJSSBmYWxsYmFja3MgaW4gdGhlIGxhbmd1YWdlIHN1YnRhZyBy ZWdpc3RyeSAobm90IGV2ZW4gaW5pdGlhbGx5KS4NCg0KSSBoYXZlIGJlZW4gaW50ZW5kaW5nIHRv IHdyaXRlIHRvIHRoZSByZWxldmFudCBKQUMgYWJvdXQgdGhpcyAoc2VlIGJlbG93KS4NCg0KPiA+ IEFwcGxpY2F0aW9ucyBhcmUgd2VsY29tZSB0byBjaGFuZ2UgdGhlc2UgdG8gdGhlICJjb3JyZWN0 IiBjaGFyYWN0ZXJzIGZvciANCj4gPiBkaXNwbGF5Lg0KPiANCj4gTm90IG11Y2ggcG9pbnQ6IHRo ZXknZCBkaXNwbGF5IHRoZSBzYW1lIHdheSBpbiBhbnkgcmVhc29uYWJsZSBmb250Lg0KDQpObywg dGhleSBkbyBub3QgbG9vayBsaWtlIHRoZSBBU0NJSSBmYWxsYmFja3MgdXNlZCBhdCBhbGwsIGV4 Y2VwdCBmb3IgDQpFWENMQU1BVElPTiBNQVJLIHZzLiBMQVRJTiBMRVRURVIgUkVUUk9GTEVYIENM SUNLLg0KDQo+IFRoZSBwb2ludCBvZiB0aGVzZSBsZXR0ZXIgY2xvbmVzIG9mIHB1bmN0dWF0aW9u IG1hcmtzIGlzIHNvIHRoYXQNCj4gb25lIGNhbiB1c2UgbmF0dXJhbC1sYW5ndWFnZSBpZGVudGlm aWVycyAoaW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLA0KPiBYTUwgZG9jdW1lbnRzLCBldGMuKSB3 aXRob3V0IHN0cmF5aW5nIGludG8gdGhlIGRvbWFpbiBvZiBwdW5jdHVhdGlvbg0KPiBtYXJrcywg d2hpY2ggYXJlIHVzdWFsbHkgZm9yYmlkZGVuIGluIGlkZW50aWZpZXJzLg0KDQpObywgaXQgbW9z dCBjZXJ0YWlubHkgaXMgTk9UIHRoZSBwb2ludCBvZiB0aG9zZSBjaGFyYWN0ZXJzLiBXaGlsZSB0 aGV5IChmb3INCm1hbnkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzKSBhcmUgKmFsbG93ZWQqIGluIGlk ZW50aWZpZXJzLCBJIGhhcmRseSBleHBlY3QNCnRoZW0gdG8gYmUgdXNlZCBpbiB0aGF0IHdheS4g VGhlIHBvaW50IG9mIHRoZW0sIGluc3RlYWQsIGlzIHRvIHVzZSB0aGVtDQppbiBvcmRpbmFyeSB0 ZXh0LCBtb3N0bHkgaW4gdGhlIGxhbmd1YWdlcyB0aGF0IHVzZSBjbGljayBzb3VuZHMuIFNvbWUN Cm9mIHRoZSBsYW5ndWFnZSBuYW1lcyBhcmUsIHJlYWxseSwgaW4gdGhvc2UgbGFuZ3VhZ2VzLCBh bmQgc2hvdWxkDQp0aGVyZWZvcmUgYmUgc3BlbGxlZCB1c2luZyB0aGUgY2xpY2sgbGV0dGVycy4N Cg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpCZWxvdyB5b3UgZmlu ZWQgbXkgZHJhZnQgY29tbWVudCAoaW50ZW5kZWQgZm9yIHRoZSBKQUMpIG9uIHRoaXMgaXNzdWUN CnRoYXQgSSBoYXZlLiAoTm90ZSB0aGF0IHRoaXMgZS1tYWlsIHdhcyBzZXQgdG8gYmUgc2VudCBp biBVVEYtOC4gSG9wZWZ1bGx5DQppdCBpcyBzdGlsbCBpbiBVVEYtOCB3aGVuIHlvdSByZWNlaXZl IGl0LikNCg0KQW5vdGhlciBjb21tZW50IEkgaGF2ZSBpcyB0aGF0IGNvdW50cnkgbmFtZXMgc2hv dWxkIG5vdCBiZSB1c2VkIGZvcg0KZGlzYW1iaWd1YXRpb24gb2Ygc2FtZS1uYW1lZCBidXQgZGlm ZmVyZW50IGxhbmd1YWdlcy4gQ291bnRyeSBuYW1lcw0KYXJlIG5vdCBxdWl0ZSBhcyBzdGFibGUg YXMgb25lIHdvdWxkIHdhbnQgZm9yIHRoZSBsYW5nYXVnZSBuYW1lcy4gUmF0aGVyDQpvbmUgc2hv dWxkIHVzZSBsYW5ndWFnZSBncm91cCBuYW1lcyAoYXQgYSBzdWl0YWJsZSBsZXZlbCkuIE5vciBp cyBpdCBhbHdheXMNCmNsZWFyIGZyb20gdGhlIGNvdW50cnkgbmFtZXMgaWYgb25lIHJlZmVycyB0 byBjbG9zZWx5IHJlbGF0ZWQgbGFuZ3VhZ2VzLCBvcg0KdG8gbGFuZ3VhZ2VzIHRoYXQgYXJlIG5v dCBhdCBhbGwgcmVsYXRlZCAodGhvdWdoIG9uZSBjYW4gc29tZXRpbWVzIGd1ZXNzKS4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIGZvbGxv d2luZyBsYW5ndWFnZSBjb2RlIGRlc2NyaXB0aW9ucyAobGFuZ3VhZ2UgbmFtZXMpIHNob3VsZCBi ZQ0Kc3BlbGxlZCB3aXRoIHRoZSBwcm9wZXIgbGV0dGVycywgbm90IHVzaW5nIEFTQ0lJIGZhbGxi YWNrcy4gVGhlIGZhbGxiYWNrDQp0byBwcm9wZXIgbGV0dGVyIG1hcHBpbmcgYXBwZWFycyB0byBi ZSBhcyBmb2xsb3dzOg0KDQogICAgICAgIC8gIC0+IMeAICAgIDAxQzA7TEFUSU4gTEVUVEVSIERF TlRBTCBDTElDSztMbzswO0w7Ozs7O047TEFUSU4gTEVUVEVSIFBJUEU7Ozs7DQogICAgICAgIC8v IC0+IMeBICAgIDAxQzE7TEFUSU4gTEVUVEVSIExBVEVSQUwgQ0xJQ0s7TG87MDtMOzs7OztOO0xB VElOIExFVFRFUiBET1VCTEUgUElQRTs7OzsNCiAgICAgICAgPS8gLT4gx4IgICAgMDFDMjtMQVRJ TiBMRVRURVIgQUxWRU9MQVIgQ0xJQ0s7TG87MDtMOzs7OztOO0xBVElOIExFVFRFUiBQSVBFIERP VUJMRSBCQVI7Ozs7DQogICAgICAgICEgIC0+IMeDICAgIDAxQzM7TEFUSU4gTEVUVEVSIFJFVFJP RkxFWCBDTElDSztMbzswO0w7Ozs7O047TEFUSU4gTEVUVEVSIEVYQ0xBTUFUSU9OIE1BUks7Ozs7 DQogICAgICAgICcgIC0+IMq8ICAgIDAyQkM7TU9ESUZJRVIgTEVUVEVSIEFQT1NUUk9QSEU7TG07 MDtMOzs7OztOOzs7OzsNCg0KSW4gdGhlIGNhc2VzIHdoZXJlIHRoZSAnIHN0YW5kcyBmb3IgZ2xv dHRhbCBzdG9wIHVzZSBNT0RJRklFUiBMRVRURVIgQVBPU1RST1BIRS4NCkVsaXNpb24gYW5kIGdl bml0aXZlIGFwb3N0cm9waGVzIGFyZSBwcm9wZXJseSBzcGVsbGVkIHdpdGgg4oCZIDIwMTk7UklH SFQgU0lOR0xFDQpRVU9UQVRJT04gTUFSSyBhcyBpbiB0aGUgbGFzdCBuaW5lIGVudHJpZXMgbGlz dGVkIGJlbG93LiBJJ20gbm90IHN1cmUgaWYgc29tZQ0Kb2YgdGhlIG90aGVyIGFwb3N0cm9waGVz IHJlYWxseSBhcmUgZWxpc2lvbiBhcG9zdHJvcGhlcyB0b28uDQoNCm91biAgICAgICAgICAgICAg ICAgICAgICAgIEkgICAgICAgIEwgICAgICAgICFPIXVuZw0Kbm1uICAgICAgICAgICAgICAgICAg ICAgICAgSSAgICAgICAgTCAgICAgICAgIVjDs8O1DQpobmggICAgICAgICAgICAgICAgICAgICAg ICBJICAgICAgICBMICAgICAgICAvL0FuaQ0KZ25rICAgICAgICAgICAgICAgICAgICAgICAgSSAg ICAgICAgTCAgICAgICAgLy9HYW5hDQp4ZWcgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAg ICBFICAgICAgICAvL1hlZ3dpDQpnd2ogICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBM ICAgICAgICAvR3dpDQp4YW0gICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBFICAgICAg ICAvWGFtDQpodWMgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICA9L0h1 YQ0KYXVlICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgPS9LeCdhdS8v J2Vpbg0KaGdtICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgSGFpLy9v bQ0Ka3R6ICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgSnUvJ2hvYW4N Cm5naCAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIE4vdQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KYWNxICAgICAgICAgICAgICAgICAg ICAgICAgSSAgICAgICAgTCAgICAgICAgQXJhYmljLCBUYSdpenppLUFkZW5pIFNwb2tlbg0KYWx1 ICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgJ0FyZSdhcmUNCm10diAg ICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIEFzYXJvJ28NCmFvdCAgICAg ICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIEEndG9uZw0Ka3VkICAgICAgICAg ICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgJ0F1aGVsYXdhDQpiZWkgICAgICAgICAg ICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBCZWthdGknDQpieWQgICAgICAgICAgICAg ICAgICAgICAgICBJICAgICAgICBMICAgICAgICBCZW55YWR1Jw0KY3J0ICAgICAgICAgICAgICAg ICAgICAgICAgSSAgICAgICAgTCAgICAgICAgQ2hvcm90ZSwgSXlvandhJ2phDQpjcnEgICAgICAg ICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBDaG9yb3RlLCBJeW8nd3Vqd2ENCmRy aSAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIEMnbGVsYQ0KaW5nICAg ICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgRGVnZXhpdCdhbg0KZG9yICAg ICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgRG9yaSdvDQpkdXAgICAgICAg ICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBEdWFubycNCmZhYiAgICAgICAgICAg ICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIEZhIEQnYW1idQ0KZm1wICAgICAgICAgICAg ICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgRmUnZmUnDQpncWEgICAgICAgICAgICAgICAg ICAgICAgICBJICAgICAgICBMICAgICAgICBHYSdhbmRhDQpnZGcgICAgICAgICAgICAgICAgICAg ICAgICBJICAgICAgICBMICAgICAgICBHYSdkYW5nDQpnYXEgICAgICAgICAgICAgICAgICAgICAg ICBJICAgICAgICBMICAgICAgICBHYXRhJw0KYmJqICAgICAgICAgICAgICAgICAgICAgICAgSSAg ICAgICAgTCAgICAgICAgR2hvbcOhbMOhJw0KZ21iICAgICAgICAgICAgICAgICAgICAgICAgSSAg ICAgICAgTCAgICAgICAgR3VsYSdhbGFhDQpod2MgICAgICAgICAgICAgICAgICAgICAgICBJICAg ICAgICBMICAgICAgICBIYXdhaSdpIENyZW9sZSBFbmdsaXNoDQpocHMgICAgICAgICAgICAgICAg ICAgICAgICBJICAgICAgICBMICAgICAgICBIYXdhaSdpIFBpZGdpbiBTaWduIExhbmd1YWdlDQpo YXcgICAgICAgIGhhdyAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBIYXdhaWlhbiAg ICAgICAgICAgICBbc2hvdWxkIHRoaXMgbm90IHVzZSBhIGxldHRlciBhcG9zdHJvcGhlP10NCmRi aiAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIElkYSdhbg0KaWx1ICAg ICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgSWxpJ3V1bg0KeGtrICAgICAg ICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgS2FjbycNCmt6ZiAgICAgICAgICAg ICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIEthaWxpLCBEYSdhDQpibGsgICAgICAgICAg ICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBLYXJlbiwgUGEnbw0Ka3N3ICAgICAgICAg ICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgS2FyZW4sIFMnZ2F3DQp4eGsgICAgICAg ICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBLZSdvDQprdWsgICAgICAgICAgICAg ICAgICAgICAgICBJICAgICAgICBMICAgICAgICBLZXBvJw0KeGtjICAgICAgICAgICAgICAgICAg ICAgICAgSSAgICAgICAgTCAgICAgICAgS2hvJ2luaQ0Ka3JyICAgICAgICAgICAgICAgICAgICAg ICAgSSAgICAgICAgTCAgICAgICAgS3J1J25nIDIgICAgICAgIFt3aGF0IGlzIHRoZSAyIGhlcmU/ IDI/IExBVElOIENBUElUQUwvU01BTEwgVE9ORSBUV08/IExBVElOIExFVFRFUiBUV08gV0lUSCBT VFJPS0U/IC4uLl0NCnhtcCAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAg IEt1a3UtTXUnaW5oDQprdXkgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAg ICBLdXVrdS1ZYSd1DQpia28gICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAg ICBLd2EnDQp3a2EgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBFICAgICAgICBLdydh ZHphDQprd2YgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBLd2FyYSdh ZQ0KbGJpICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgTGEnYmkNCmxu cyAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIExhbW5zbycNCmxyYSAg ICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIExhcmEnDQpsamwgICAgICAg ICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBMaSdvDQpwcmIgICAgICAgICAgICAg ICAgICAgICAgICBJICAgICAgICBMICAgICAgICBMdWEnDQptaHkgICAgICAgICAgICAgICAgICAg ICAgICBJICAgICAgICBMICAgICAgICBNYSdhbnlhbg0KbWhpICAgICAgICAgICAgICAgICAgICAg ICAgSSAgICAgICAgTCAgICAgICAgTWEnZGkNCnNubSAgICAgICAgICAgICAgICAgICAgICAgIEkg ICAgICAgIEwgICAgICAgIE1hJ2RpLCBTb3V0aGVybg0KbHZhICAgICAgICAgICAgICAgICAgICAg ICAgSSAgICAgICAgTCAgICAgICAgTWFrdSdhDQpzbHogICAgICAgICAgICAgICAgICAgICAgICBJ ICAgICAgICBMICAgICAgICBNYSd5YQ0KeXVzICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAg ICAgTCAgICAgICAgTWF5YSwgQ2hhbiBTYW50YSBDcnV6ICAgICAgICAgICBbc2hvdWxkIHRoaXMg bm90IHVzZSBhIGxldHRlciBhcG9zdHJvcGhlP10NCnl1YSAgICAgICAgICAgICAgICAgICAgICAg IEkgICAgICAgIEwgICAgICAgIE1heWEsIFl1Y2F0w6FuICAgICAgICAgICBbc2hvdWxkIHRoaXMg bm90IHVzZSBhIGxldHRlciBhcG9zdHJvcGhlP10NCnhteSAgICAgICAgICAgICAgICAgICAgICAg IEkgICAgICAgIEwgICAgICAgIE1heWFndWR1bmENCmVteSAgICAgICAgICAgICAgICAgICAgICAg IEkgICAgICAgIEUgICAgICAgIE1heWFuLCBFcGlncmFwaGljICAgICAgICAgICBbc2hvdWxkIHRo aXMgbm90IHVzZSBhIGxldHRlciBhcG9zdHJvcGhlP10NCm10ayAgICAgICAgICAgICAgICAgICAg ICAgIEkgICAgICAgIEwgICAgICAgIE1iZScNCm11YyAgICAgICAgICAgICAgICAgICAgICAgIEkg ICAgICAgIEwgICAgICAgIE1idScNCm15bSAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAg IEwgICAgICAgIE1lJ2VuDQptZ28gICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAg ICAgICBNZXRhJw0KZ2JuICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAg TW8nZGENCm5hZSAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIE5ha2En ZWxhDQpubnogICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBOZGEnbmRh Jw0KbnhnICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgTmdhZCdhDQpu ZWEgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBOZ2FkJ2EsIEVhc3Rl cm4NCm5ibSAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIE5nYmFrYSBN YSdibw0KbmNnICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgTmlzZ2En YQ0KbnVtICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgTml1YWZvJ291 DQpueXAgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBFICAgICAgICBOeWFuZydpDQp0 eWggICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBPJ2R1DQpsdWwgICAg ICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBPbHUnYm8NCm95eSAgICAgICAg ICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIE95YSdveWENCnBxYSAgICAgICAgICAg ICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFBhJ2ENCnBsZSAgICAgICAgICAgICAgICAg ICAgICAgIEkgICAgICAgIEwgICAgICAgIFBhbHUnZQ0KcGhxICAgICAgICAgICAgICAgICAgICAg ICAgSSAgICAgICAgTCAgICAgICAgUGhhbmEnDQpxeHEgICAgICAgICAgICAgICAgICAgICAgICBJ ICAgICAgICBMICAgICAgICBRYXNocWEnaQ0KYXBiICAgICAgICAgICAgICAgICAgICAgICAgSSAg ICAgICAgTCAgICAgICAgU2EnYQ0Kc252ICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAg TCAgICAgICAgU2EnYmFuDQpzY3EgICAgICAgICAgICAgICAgICAgICAgICBJICAgICAgICBMICAg ICAgICBTYSdvY2gNCnhzdCAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAg IFNpbHQnZQ0Kc3NxICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgU28n YQ0Kcm9iICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgVGFlJw0KdGxu ICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgVGFsb25kbycNCnR0byAg ICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFRhJ29paCwgTG93ZXINCnR0 aCAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFRhJ29paCwgVXBwZXIN CnRjdCAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFQnZW4NCnR2ZSAg ICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFRlJ3VuDQptbHUgICAgICAg ICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBUbydhYmFpdGENCnRseiAgICAgICAg ICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFRvYWxhJw0Kb29kICAgICAgICAgICAg ICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgVG9ob25vIE8nb2RoYW0NCnNkYSAgICAgICAg ICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFRvcmFqYS1TYSdkYW4NCnRzbCAgICAg ICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFRzJ8O8bi1MYW8NCnVsbSAgICAg ICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFVsdW1hbmRhJw0KdXJrICAgICAg ICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgVXJhayBMYXdvaScNCndhZyAgICAg ICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFdhJ2VtYQ0Kd21oICAgICAgICAg ICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgV2FpbWEnYQ0Kd2loICAgICAgICAgICAg ICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgV2lrLU1lJ2FuaGENCmFtZSAgICAgICAgICAg ICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAgIFlhbmVzaGEnDQpwdG8gICAgICAgICAgICAg ICAgICAgICAgICBJICAgICAgICBMICAgICAgICBabyfDqQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KZW90ICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAg TCAgICAgICAgQmV0aSAoQ8O0dGUgZCdJdm9pcmUpICAgICBbZWxpc2lvbiBhcG9zdHJvcGhlXQ0K Y3JkICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgQ29ldXIgZCdBbGVu ZSAgICAgW2VsaXNpb24gYXBvc3Ryb3BoZV0NCmZsYSAgICAgICAgICAgICAgICAgICAgICAgIEkg ICAgICAgIEwgICAgICAgIEthbGlzcGVsLVBlbmQgZCdPcmVpbGxlICAgICBbZWxpc2lvbiBhcG9z dHJvcGhlXQ0Ka2ZvICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgS29y byAoQ8O0dGUgZCdJdm9pcmUpICAgICBbZWxpc2lvbiBhcG9zdHJvcGhlXQ0KbG9pICAgICAgICAg ICAgICAgICAgICAgICAgSSAgICAgICAgTCAgICAgICAgTG9tYSAoQ8O0dGUgZCdJdm9pcmUpICAg ICBbZWxpc2lvbiBhcG9zdHJvcGhlXQ0KbXJlICAgICAgICAgICAgICAgICAgICAgICAgSSAgICAg ICAgRSAgICAgICAgTWFydGhhJ3MgVmluZXlhcmQgU2lnbiBMYW5ndWFnZSAgICAgW2VsaXNpb24g YXBvc3Ryb3BoZV0NCm5nbSAgICAgICAgICAgICAgICAgICAgICAgIEkgICAgICAgIEwgICAgICAg IE5nYXRpayBNZW4ncyBDcmVvbGUgICAgIFtlbGlzaW9uIGFwb3N0cm9waGVdDQpwbHcgICAgICAg ICAgICAgICAgICAgICAgICBJICAgICAgICBMICAgICAgICBQYWxhd2FubywgQnJvb2tlJ3MgUG9p bnQgICAgIFtlbGlzaW9uIGFwb3N0cm9waGVdDQpuZWIgICAgICAgICAgICAgICAgICAgICAgICBJ ICAgICAgICBMICAgICAgICBUb3VyYSAoQ8O0dGUgZCdJdm9pcmUpICAgICBbZWxpc2lvbiBhcG9z dHJvcGhlXQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KTHRydSBtYWlsaW5nIGxpc3QNCkx0cnVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============1350464279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1350464279==-- From ltru-bounces@ietf.org Wed Oct 11 17:35:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXljR-0005PG-G9; Wed, 11 Oct 2006 17:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXljQ-0005P8-Cz for ltru@lists.ietf.org; Wed, 11 Oct 2006 17:35:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXljO-0003Ta-TH for ltru@lists.ietf.org; Wed, 11 Oct 2006 17:35:16 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXlgE-0004Tr-DJ for ltru@lists.ietf.org; Wed, 11 Oct 2006 23:31:59 +0200 Received: from du-001-044.access.de.clara.net ([212.82.227.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 23:31:58 +0200 Received: from nobody by du-001-044.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 23:31:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 11 Oct 2006 23:25:24 +0200 Organization: Lines: 100 Message-ID: <452D6144.72F@xyzzy.claranet.de> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-044.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > There is a demonstrated need to tag things like Middle English and > Ancient Egyptian, not to mention Esperanto (which would cause another > problem, as existing constructed languages would be grandfathered in, > but new ones in 639-3 would be excluded). Esperanto and Orcish don't play in the same league, that's a good "C", it couldn't cause a problem _because_ it already made it into 639-2. Other good "C" not in 639-2 would be a problem, as far as registering them individually as needed is a problem (in theory it should be easy). The attempted "grabar" registration was a model, somebody (IIRC Peter) said it should get its own code, and later sommebody else (IIRC John) found that it already has a code "axm". So far the plan was that this and all other new A, C, E, and H are automatically included in the bulk 4645bis update. This registration business (like RFC publication) boils down to "filter nonsense and try to reflect some useful reality". Some humans do this, and if it's an open process with experts and appeals etc. we hope that the outcome is good enough. If it's a rather cryptic process with very few experts who simply can't know each and every "orq"-case this outcome might be not good enough, and adding a second filter with an open process behind it could help. Increased bureaucracy is often not helpful, but we have already a way to register languages in addition to 639-3 with tons of SHOULD NOT to discourage it. We could as well add a way to register a proper subset of 639-3 (A, C, E, H) only on demand. Maybe it's a bad idea, but it's not completely impossible. > At least one Description needs to match the source standard, no matter > how bad we think the spellings might be. Yes, you can't simply "fix" the clicks, let 639-3 do it when they feel like it. It's rare that I say "please use Unicode", it was addressed to Peter, not to you... :-) > Excluding about 500 to 600 non-"L" languages would reduce the size of > the Registry by less than 8 percent Yes, it's no size issue. Using all available alpha3 is also okay, the complete registry would be still below 2 MB. It's a question of the vetting, and whether users would need to know the source of an alpha3 in the registry, or only "interesting" types, or if that's irrelevant. Apparently some including John, Peter, and me feel that it's relevant, but we still have to figure out how to do it. > The Language Subtag Reviewer and ietf-languages list can decide that > a language requested for independent registration isn't "good enough," > but if it's in an ISO standard, who are they (or we) to say? ISO standard, IANA registry, CLDR, ICU, tz database, or RFC, there are some folks empowered to decide what's in and what's out, and depending on how good that's organized the results can be good, bad, or ugly. There always will be errors, and _we_ invented the rules not allowing to fix errors in the registry. As soon as "orq" is in it stays in. And if 639-3 isn't designed for this radical approach it's our job to get it right. We did that already for the 3166 country codes. For all other 4646 sources we trust that it's unnecessary. ISO 639-3 will be a new player, and Peter always convinced me that it will be as good as the other sources. But we have to verify this, and doing it with the April draft is a good test. Peter said that they might remove "orq", and that's the purpose of this test, find nits and issues before they are "stable forever". >> If later one of the Ms gets type E adding (M,E) to a description (or >> saying Macrolanguage, Extinct in a comment) is no problem. > If a currently non-extinct language that is widespread enough to serve > as a macrolanguage goes extinct during our lifetime, it would amaze me. Me too, it was an explanation why mixing the "scope" and "type" info is possible even under unlikely conditions. >> Changing the 4646 syntax adding a completely new field however is >> IMNSHO a very bad idea. We more or less promised that that won't >> happen. > Where did we promise that no new fields would ever be added? By proposing with detailed rules before it existed, the 4646 syntax is supposed to work also for 4646bis registries. > This would also affect Addison's proposal to replace Suppress-Script > with something new. Yes, that's why I don't like the zero-one-more-script proposal. And why I don't like an additional Langtype field. And why I don't like to use UTF-8, or to replace record-jar by XML. Always the same reason, stick to the 4646 registry format, it's okay. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 17:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXm1Z-00012P-Rc; Wed, 11 Oct 2006 17:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXm0P-0000JL-6j for ltru@lists.ietf.org; Wed, 11 Oct 2006 17:52:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXltD-00040s-95 for ltru@lists.ietf.org; Wed, 11 Oct 2006 17:45:25 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXlrV-0007ei-EJ for ltru@lists.ietf.org; Wed, 11 Oct 2006 23:43:37 +0200 Received: from du-001-044.access.de.clara.net ([212.82.227.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 23:43:37 +0200 Received: from nobody by du-001-044.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 23:43:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 11 Oct 2006 23:40:29 +0200 Organization: Lines: 18 Message-ID: <452D64CD.5B9@xyzzy.claranet.de> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> <20061011143145.GH23580@ccil.org> <20061011143304.GI23580@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-044.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> I think we can expect them to go away. > Go away, I hasten to add, *before* the publication of IS 639-3, > and therefore before 4645bis. Thanks, I appreciate it. Frank [[ The last time I had anything to do with DIN was in the early 80's about obscure German sort order rules, and it wasn't me who paid for their paper. "Ask your national standards body" is no procedure I'm used to, it sounds like a recipe by you- know-who. If it's about contry codes I'd ask Debbie, not DIN. ]] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 21:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXp9S-0000kE-8T; Wed, 11 Oct 2006 21:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXp9O-0000ie-6f for ltru@ietf.org; Wed, 11 Oct 2006 21:14:18 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXp9L-0001u6-Cf for ltru@ietf.org; Wed, 11 Oct 2006 21:14:18 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9C1EDH3010236 for ; Thu, 12 Oct 2006 10:14:13 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2752_f9087f14_598e_11db_8ae8_0014221fa3c9; Thu, 12 Oct 2006 10:14:13 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:43863) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 12 Oct 2006 10:14:01 +0900 Message-Id: <6.0.0.20.2.20061012095527.075c42b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 12 Oct 2006 09:56:29 +0900 To: Peter Constable , LTRU Working Group From: Martin Duerst Subject: RE: [Ltru] Click letters In-Reply-To: References: <20061011133504.GG23580@ccil.org> <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 04:18 06/10/12, Peter Constable wrote: >Note that a prior issue for the RA and the JAC to consider is what >character set should be allowed in language names used in the 639 >standards. If you would like to submit feedback in that regard, it should >probably go to the JAC via Michael Everson -- IIRC he is IETF liaison to the JAC. There is no such record on the relevant page (http://www.ietf.org/liaisonActivities.html). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 22:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXq1v-0008CQ-3Z; Wed, 11 Oct 2006 22:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXq1t-0008CF-Rp for ltru@ietf.org; Wed, 11 Oct 2006 22:10:37 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXq1p-0002Df-JN for ltru@ietf.org; Wed, 11 Oct 2006 22:10:37 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXq1m-0003Uy-Qn; Wed, 11 Oct 2006 22:10:30 -0400 Date: Wed, 11 Oct 2006 22:10:30 -0400 To: Martin Duerst Subject: Re: [Ltru] Click letters Message-ID: <20061012021030.GB15317@ccil.org> References: <20061011133504.GG23580@ccil.org> <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> <6.0.0.20.2.20061012095527.075c42b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20061012095527.075c42b0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > >Note that a prior issue for the RA and the JAC to consider is what > >character set should be allowed in language names used in the 639 > >standards. If you would like to submit feedback in that regard, it > >should probably go to the JAC via Michael Everson -- IIRC he is IETF > >liaison to the JAC. > > There is no such record on the relevant page > (http://www.ietf.org/liaisonActivities.html). That is to say, he is the person who represents IETF concerns on the JAC, not vice versa. By the same token, I am the person who represents IETF concerns to the Lojban community. No one has to make these roles official. -- John Cowan http://www.ccil.org/~cowan .e'osai ko sarji la lojban. Please support Lojban! http://www.lojban.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 22:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXqaF-0004AW-73; Wed, 11 Oct 2006 22:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXqaD-0004AE-Od for ltru@ietf.org; Wed, 11 Oct 2006 22:46:05 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXqaC-0006QF-DL for ltru@ietf.org; Wed, 11 Oct 2006 22:46:05 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9C2jpTI012882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2006 19:45:52 -0700 Received: from [10.0.1.4] (vpn-10-50-0-114.qualcomm.com [10.50.0.114]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9C2jmVW006092; Wed, 11 Oct 2006 19:45:49 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20061012021030.GB15317@ccil.org> References: <20061011133504.GG23580@ccil.org> <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> <6.0.0.20.2.20061012095527.075c42b0@localhost> <20061012021030.GB15317@ccil.org> Date: Wed, 11 Oct 2006 19:45:47 -0700 To: John Cowan , Martin Duerst From: Ted Hardie Subject: Re: [Ltru] Click letters Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:10 PM -0400 10/11/06, John Cowan wrote: >Martin Duerst scripsit: > >> >Note that a prior issue for the RA and the JAC to consider is what >> >character set should be allowed in language names used in the 639 >> >standards. If you would like to submit feedback in that regard, it >> >should probably go to the JAC via Michael Everson -- IIRC he is IETF >> >liaison to the JAC. >> >> There is no such record on the relevant page >> (http://www.ietf.org/liaisonActivities.html). > >That is to say, he is the person who represents IETF concerns on the JAC, >not vice versa. By the same token, I am the person who represents IETF >concerns to the Lojban community. No one has to make these roles >official. > They do need to be made official if you represent the IETF; you may represent your experience (including your experience of the IETF) in any way you like. It sounds like you meant the second. "Liaison", though, has a fairly specific meaning in our discussions of relationships to other bodies, and it does tend to imply "represent the IETF" and that implies "appointed by the IAB". regards, Ted Hardie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 22:49:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXqdt-0005ue-9V; Wed, 11 Oct 2006 22:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXqds-0005uZ-KY for ltru@ietf.org; Wed, 11 Oct 2006 22:49:52 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXqdq-0007lq-V4 for ltru@ietf.org; Wed, 11 Oct 2006 22:49:52 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXqdn-0006Zn-VM; Wed, 11 Oct 2006 22:49:47 -0400 Date: Wed, 11 Oct 2006 22:49:47 -0400 To: Ted Hardie Subject: Re: [Ltru] Click letters Message-ID: <20061012024947.GA25171@ccil.org> References: <20061011133504.GG23580@ccil.org> <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> <6.0.0.20.2.20061012095527.075c42b0@localhost> <20061012021030.GB15317@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ted Hardie scripsit: > They do need to be made official if you represent the IETF; you > may represent your experience (including your experience of the > IETF) in any way you like. It sounds like you meant the second. > "Liaison", though, has a fairly specific meaning in our discussions > of relationships to other bodies, and it does tend to imply "represent > the IETF" and that implies "appointed by the IAB". Fair enough. -- Not to perambulate John Cowan the corridors http://www.ccil.org/~cowan during the hours of repose in the boots of ascension. --Sign in Austrian ski-resort hotel _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 23:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXqy2-0000xq-9G; Wed, 11 Oct 2006 23:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXqy1-0000wm-0b for ltru@lists.ietf.org; Wed, 11 Oct 2006 23:10:41 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXqmn-00011p-24 for ltru@lists.ietf.org; Wed, 11 Oct 2006 22:59:08 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXqml-0006p8-TW; Wed, 11 Oct 2006 22:59:03 -0400 Date: Wed, 11 Oct 2006 22:59:03 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Is 639-3 bogus ? Message-ID: <20061012025903.GA25648@ccil.org> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> <452D6144.72F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452D6144.72F@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > If it's a rather cryptic process with very few experts who simply can't > know each and every "orq"-case this outcome might be not good enough, > and adding a second filter with an open process behind it could help. The whole point of publishing a draft list was for expert correction, which it got. Both Anthony Aristar and I independently determined that the conlangs I mentioned did not belong in the standard, and Anthony said their presence in the draft was an oversight. > Apparently some including John, Peter, and me feel that it's relevant, > but we still have to figure out how to do it. I'm not sure what this means. We do know how to do scopes and types; the issue is whether we want to. > There always will be errors, and _we_ invented the rules not allowing > to fix errors in the registry. As soon as "orq" is in it stays in. It's not in yet and it won't be. > By proposing with detailed rules before it existed, the 4646 > syntax is supposed to work also for 4646bis registries. We stabilized the syntax of language tags. We stabilized the record-jar syntax. We stabilized certain fields (and not others). We did not stabilize the set of fields as a whole. -- John Cowan http://www.ccil.org/~cowan Raffiniert ist der Herrgott, aber boshaft ist er nicht. --Albert Einstein _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 11 23:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXrHl-0004sP-WB; Wed, 11 Oct 2006 23:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXrHk-0004sK-I7 for ltru@lists.ietf.org; Wed, 11 Oct 2006 23:31:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXrHj-0007Fv-79 for ltru@lists.ietf.org; Wed, 11 Oct 2006 23:31:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXrHa-0007tV-AF for ltru@lists.ietf.org; Thu, 12 Oct 2006 05:30:54 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 05:30:54 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 05:30:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 12 Oct 2006 05:29:37 +0200 Organization: Lines: 24 Message-ID: <452DB6A1.5FC4@xyzzy.claranet.de> References: <20061011133504.GG23580@ccil.org> <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> <6.0.0.20.2.20061012095527.075c42b0@localhost> <20061012021030.GB15317@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: Click letters X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > By the same token, I am the person who represents IETF concerns to > the Lojban community. No one has to make these roles official. If you _would_ claim to speak on behalf of the IETF there are two relevant RFCs: 4052 and 4053. From an IETF POV it is an official role (at least the incoming liaison statements like Mark's letter on hehalf of Unicode), there's a tracker, and you can get an account to manage your liaison statements, etc. The most important point is apparently that incoming statements are answered or forwarded to an appropriate WG (Chair) / area (AD) / IESG / IAB. http://tools.ietf.org/html/draft-iab-liaison-guidelines is about the opposite direction (IETF to xyz). Martin or Randy could appoint you as "official" IETF LTRU liaison to the Lojban community (if the AD tolerates it), in theory. An "official" LTRU liaison to the 639 RA or JAC (replace proper title) could be an idea: That liaison (e.g. Peter) could request an extended guarantee covering 639-3 on behalf of LTRU, and the liaison from 639 (e.g. you) would answer it, and then Addison could copy an updated stability guarantee into 4646bis. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 00:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXroU-0007SL-8y; Thu, 12 Oct 2006 00:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXroT-0007SG-DB for ltru@lists.ietf.org; Thu, 12 Oct 2006 00:04:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXroS-0005IC-3Z for ltru@lists.ietf.org; Thu, 12 Oct 2006 00:04:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXroJ-0000fS-UY for ltru@lists.ietf.org; Thu, 12 Oct 2006 06:04:43 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 06:04:43 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 06:04:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 12 Oct 2006 06:02:27 +0200 Organization: Lines: 43 Message-ID: <452DBE53.3175@xyzzy.claranet.de> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> <452D6144.72F@xyzzy.claranet.de> <20061012025903.GA25648@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Scopes and types (was: Is 639-3 bogus ?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> Apparently some including John, Peter, and me feel that it's relevant, >> but we still have to figure out how to do it. > I'm not sure what this means. We do know how to do scopes and types; > the issue is whether we want to. It means that this could be noted in a new field, or as " (M)" or " (H)" etc. at the end of the description, or verbose as " (historic)", or even in a comment - but normally we reserve comments for any info that's not a part of the source. > We stabilized the syntax of language tags. Yes. > We stabilized the record-jar syntax. One hopes. > We stabilized certain fields (and not others). Yes. > We did not stabilize the set of fields as a whole. We also didn't mention that new fields might be introduced later. For the purpose mentioned by Peter - determine if "foo" is the subtag for language "bar", where "ancient" helps to decide that it's not - the "ancient" info is relevant, not how it appears in a "bar" record. For the purpose mentioned by Addison - determine if subtag "foo" is a macrolanguage - it's the info "macrolanguage", not how it appears. Checking if subtag "foo" is the target of an extlang-prefix is not exactly straight forward (but an algorithmic solution). And for the purpose mentioned by me - check if "foo" is a pure 639-3 subtag - we have no proposal based alone on the LSR. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 00:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXs8V-0002Xa-8G; Thu, 12 Oct 2006 00:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXs8U-0002XS-Jr for ltru@ietf.org; Thu, 12 Oct 2006 00:25:34 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXs8S-00009b-D2 for ltru@ietf.org; Thu, 12 Oct 2006 00:25:34 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GXs8S-0005uK-1b; Thu, 12 Oct 2006 00:25:32 -0400 Date: Thu, 12 Oct 2006 00:25:32 -0400 To: Frank Ellermann Subject: Re: [Ltru] Scopes and types (was: Is 639-3 bogus ?) Message-ID: <20061012042531.GA22548@ccil.org> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> <452D6144.72F@xyzzy.claranet.de> <20061012025903.GA25648@ccil.org> <452DBE53.3175@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452DBE53.3175@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > We also didn't mention that new fields might be introduced later. It's not reasonable to assume that things are immutable if not mentioned otherwise -- or nothing could ever be changed unless it was decided back in 1969 that it would be mutable later. IOW, stability policies have to be explicit. > And for the purpose mentioned by me - check if "foo" is a pure 639-3 > subtag - we have no proposal based alone on the LSR. What is a pure subtag? -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.ccil.org/~cowan pleasures in life.... --Jeni Tennison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 00:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXsPs-0004Bb-MY; Thu, 12 Oct 2006 00:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXsPr-0004BD-8Q for ltru@lists.ietf.org; Thu, 12 Oct 2006 00:43:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXsPp-0003GP-Vd for ltru@lists.ietf.org; Thu, 12 Oct 2006 00:43:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXsPe-0007ra-L1 for ltru@lists.ietf.org; Thu, 12 Oct 2006 06:43:18 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 06:43:18 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 06:43:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 12 Oct 2006 06:40:56 +0200 Organization: Lines: 20 Message-ID: <452DC758.6B4A@xyzzy.claranet.de> References: <006101c6ed3d$137795b0$6501a8c0@DGBP7M81> <452D6144.72F@xyzzy.claranet.de> <20061012025903.GA25648@ccil.org> <452DBE53.3175@xyzzy.claranet.de> <20061012042531.GA22548@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: Scopes and types X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > It's not reasonable to assume that things are immutable if not mentioned > otherwise The extlangs are mentioned in RFC 4646 but not used, that indicates that the record types were meant to cover 4646bis later, and from there it's no unreasonable jump to think that the complete structure was meant to cover 4646bis. >> check if "foo" is a pure 639-3 subtag [...] > What is a pure subtag? A pure 639-3 subtag is something where the columns "Part1" and "Part2" in iso-dis-639-3_20060421.tab are empty (or should be empty after the next synchronization). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 02:16:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXtrj-0006n0-64; Thu, 12 Oct 2006 02:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXtrg-0006fj-Rx for ltru@ietf.org; Thu, 12 Oct 2006 02:16:20 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXtrc-0004yX-Hr for ltru@ietf.org; Thu, 12 Oct 2006 02:16:20 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061012061615.GTLN10025.mta10.adelphia.net@DGBP7M81>; Thu, 12 Oct 2006 02:16:15 -0400 Message-ID: <009601c6edc5$ed04e8e0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Is 639-3 bogus ? Date: Wed, 11 Oct 2006 23:16:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: >>> May I suggest that if one is willing to read the FDIS text, it would >>> be reasonably clear that it doesn't aim to list "anything". >> >> Please provide a link to the FDIS text. I can't find it. > > People can contact their national standards body to request the FDIS > text. You can find the DIS here: > > http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=PCUnicodeDocs&highlight=639#367db883-a50e5f80 I know that the national body is the normal place for individuals to go for Final Draft standards. In our particular, unique case, we are: 1) trying to update an Internet standard (lowercase "s"), almost entirely for the purpose of adding support for ISO 639-3, which will certainly be the first, and probably the highest-profile, application to use ISO 639-3; 2) joined in this effort by the Project Editor for ISO 639-3; and 3) being reminded (or cajoled) multiple times by the Project Editor to check a copy of the FDIS for updated information. Given all this, instead of each of us trying to figure out whom specifically at ANSI (or wherever) we need to contact for a personal copy, it seems more logical to me that the Project Editor might offer this group a direct link to the FDIS text. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 02:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuEZ-0003mr-4Y; Thu, 12 Oct 2006 02:39:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuEX-0003mf-V9 for ltru@ietf.org; Thu, 12 Oct 2006 02:39:57 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXuEW-0008SO-L2 for ltru@ietf.org; Thu, 12 Oct 2006 02:39:57 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061012063955.HPLE18643.mta9.adelphia.net@DGBP7M81>; Thu, 12 Oct 2006 02:39:55 -0400 Message-ID: <009c01c6edc9$3b4d7820$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <004801c6ed66$52923b00$6500a8c0@chalmers95a69n> Subject: Re: [Ltru] Click letters Date: Wed, 11 Oct 2006 23:39:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > The spelling should of course be fixed in the source standard, in this > case preferably before 639-3 is published so that we don't get these > ASCII fallbacks in the language subtag registry (not even initially). If you can get the JAC to do this before release, then of course the "fixed" spellings will appear in the Registry. This is really the only way the "use the right characters" crowd and the "follow the standard exactly" crowd are going to see eye to eye -- by getting the standard to use the "right" characters. > No, they do not look like the ASCII fallbacks used at all, except for > EXCLAMATION MARK vs. LATIN LETTER RETROFLEX CLICK. That's true for the click letters. When we fought the Apostrophe Wars, the ironic part was that that the "correct" characters looked essentially the same as the ASCII fallbacks, but *only if* they were available in the font. This was generally true for U+2019, but not at all true for U+02BB; many fonts show a box there. > Another comment I have is that country names should not be used for > disambiguation of same-named but different languages. Country names > are not quite as stable as one would want for the langauge names. > Rather one should use language group names (at a suitable level). Nor > is it always clear from the country names if one refers to closely > related languages, or to languages that are not at all related (though > one can sometimes guess). I'll let Peter address the questions of whether this would even be feasible, and whether it would improve anything. > The following language code descriptions (language names) should be > spelled with the proper letters, not using ASCII fallbacks. The > fallback to proper letter mapping appears to be as follows: > > / -> Ç€ 01C0;LATIN LETTER DENTAL CLICK;Lo;0;L;;;;;N;LATIN > LETTER PIPE;;;; > // -> Ç 01C1;LATIN LETTER LATERAL CLICK;Lo;0;L;;;;;N;LATIN > LETTER DOUBLE PIPE;;;; > =/ -> Ç‚ 01C2;LATIN LETTER ALVEOLAR CLICK;Lo;0;L;;;;;N;LATIN > LETTER PIPE DOUBLE BAR;;;; > ! -> ǃ 01C3;LATIN LETTER RETROFLEX > CLICK;Lo;0;L;;;;;N;LATIN LETTER EXCLAMATION MARK;;;; > ' -> ʼ 02BC;MODIFIER LETTER APOSTROPHE;Lm;0;L;;;;;N;;;;; My guess is that you are going to have a tough time getting the JAC to adopt characters in language names that (a) are in few to no 8-bit legacy character sets and (b) have experienced such poor uptake in modern fonts. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 10:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1li-0000v2-8n; Thu, 12 Oct 2006 10:42:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1le-0000hJ-6d for ltru@ietf.org; Thu, 12 Oct 2006 10:42:38 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1Xu-0006SO-N0 for ltru@ietf.org; Thu, 12 Oct 2006 10:28:29 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061012142823.GYLI18643.mta9.adelphia.net@DGBP7M81> for ; Thu, 12 Oct 2006 10:28:23 -0400 Message-ID: <00dd01c6ee0a$ad1d9ac0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Oct 2006 07:28:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Where to put language-type info (was: Re: Is 639-3 bogus ?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I think adding only the 'interesting' information, in the Description > or Comment field, would be a much more unobtrusive change to which I > could agree (although still not thrilled). Please, not in the Description. We'd be back to our "must match the source standard exactly" argument. I'm sure nobody want to see this: Subtag: xzh Description: Zhang-Zhung Description: Zhang-Zhung (A) etc. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 10:44:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1nF-0003g3-Oh; Thu, 12 Oct 2006 10:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1nF-0003f5-D7 for ltru@ietf.org; Thu, 12 Oct 2006 10:44:17 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1nE-0001Ys-4I for ltru@ietf.org; Thu, 12 Oct 2006 10:44:17 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061012144415.GDFN10025.mta10.adelphia.net@DGBP7M81> for ; Thu, 12 Oct 2006 10:44:15 -0400 Message-ID: <00e301c6ee0c$e4540e50$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Oct 2006 07:44:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Yinglish (was: Re: Is 639-3 bogus ?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Mnyeh. Believe me, boychik, sentences like *this* you do not find in > plain (i.e. goyish) English! I contend that this is an English dialect with Yiddish-based and -inspired words. I understood that passage perfectly well, though I would never say it that way myself. I don't want to pursue this, though, because my point was that if ISO 639-3 says it is a language, I don't feel I'm in a position to dispute that. (The reverse is not necessarily true; if they haven't listed something, I may still try to register it with ietf-languages.) -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 10:49:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1s9-0005ph-IG; Thu, 12 Oct 2006 10:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1s8-0005os-HD for ltru@ietf.org; Thu, 12 Oct 2006 10:49:20 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1s7-0002MY-61 for ltru@ietf.org; Thu, 12 Oct 2006 10:49:20 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 69DBA1E133D; Thu, 12 Oct 2006 07:49:14 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <4XHNBCXW>; Thu, 12 Oct 2006 07:49:14 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF35@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Doug Ewell' , LTRU Working Group Subject: RE: [Ltru] Where to put language-type info (was: Re: Is 639-3 bog us ?) Date: Thu, 12 Oct 2006 07:49:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 If we need a new field or fields in the Language Subtag Registry to record fields from ISO 639-3, we should add it/them. We should stop the 'match exactly' Description field nonsense. While RFC 4646 attempted (in prose and ABNF) to guess the shape of the future, it was inherently limited - topics we haven't addressed are likely to take different shapes when we DO address them. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Thursday, October 12, 2006 10:28 AM > To: LTRU Working Group > Subject: [Ltru] Where to put language-type info (was: Re: Is > 639-3 bogus > ?) > > > Martin Duerst wrote: > > > I think adding only the 'interesting' information, in the > Description > > or Comment field, would be a much more unobtrusive change > to which I > > could agree (although still not thrilled). > > Please, not in the Description. We'd be back to our "must match the > source standard exactly" argument. I'm sure nobody want to see this: > > Subtag: xzh > Description: Zhang-Zhung > Description: Zhang-Zhung (A) > etc. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.2/472 - Release Date: 10/11/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 11:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY29t-0007KZ-V1; Thu, 12 Oct 2006 11:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY29t-0007KU-56 for ltru@ietf.org; Thu, 12 Oct 2006 11:07:41 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY29q-0007vH-Tn for ltru@ietf.org; Thu, 12 Oct 2006 11:07:41 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GY29q-0000UM-Cd; Thu, 12 Oct 2006 11:07:38 -0400 Date: Thu, 12 Oct 2006 11:07:38 -0400 To: Doug Ewell Subject: Re: [Ltru] Yinglish (was: Re: Is 639-3 bogus ?) Message-ID: <20061012150738.GC22548@ccil.org> References: <00e301c6ee0c$e4540e50$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e301c6ee0c$e4540e50$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I don't want to pursue this, though, because my point was that if ISO > 639-3 says it is a language, I don't feel I'm in a position to dispute > that. Whyever not? (or "farvos nit?") The ISO 639-3 list did not, you should excuse the expression, descend from Mount Sinai, even if we have to treat it that way in a purely IETF context. This is our window to get code elements that we think are treyf removed from 639-3 before they are enshrined forever. So get off your tochus and write a letter to Joan Spanne kvetching about it. (I'm going to; your argument has convinced *me*.) -- John Cowan http://www.ccil.org/~cowan Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 12 23:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYE88-0004wI-LI; Thu, 12 Oct 2006 23:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYE86-0004vs-TF for ltru@ietf.org; Thu, 12 Oct 2006 23:54:38 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYE84-0008US-KM for ltru@ietf.org; Thu, 12 Oct 2006 23:54:38 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061013035431.KIJC10025.mta10.adelphia.net@DGBP7M81> for ; Thu, 12 Oct 2006 23:54:31 -0400 Message-ID: <007d01c6ee7b$4aa73ce0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Oct 2006 20:54:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Serbo-Croatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Desperately trying to change these Subject lines... Addison Phillips wrote: >> I'm not sure what you are calling for here: should Serbo-Croatian be >> marked as a macrolanguage in the LSR or not? > > - Serbo-Croatian marked as a macrolanguage. > - Its constituent languages maintained as type 'language' and not > converted to type 'extlang'. Wait a minute. I thought the purpose of identifying macrolanguages in the Registry was to tell tag creators which primary language subtags have extlangs under them. If we do this for Serbo-Croatian, which won't have any extlangs, then all we are doing is duplicating information from ISO 639-3, which Mark and others broadly rejected in John's Language-Type proposal. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 01:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFke-0007dU-Jb; Fri, 13 Oct 2006 01:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFkd-0007cB-Cv for ltru@ietf.org; Fri, 13 Oct 2006 01:38:31 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYFkb-0007hN-W9 for ltru@ietf.org; Fri, 13 Oct 2006 01:38:31 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061013053824.QQJA18643.mta9.adelphia.net@DGBP7M81> for ; Fri, 13 Oct 2006 01:38:24 -0400 Message-ID: <009501c6ee89$cd670990$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Oct 2006 22:38:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Re: Is 639-3 bogus ? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Esperanto and Orcish don't play in the same league, that's a good "C", > it couldn't cause a problem _because_ it already made it into 639-2. > > Other good "C" not in 639-2 would be a problem, as far as registering > them individually as needed is a problem (in theory it should be > easy). How do you determine which are "good C" and which are "bad C"? By that I don't mean that Esperanto is "good" because it has 2 million speakers (Ethnologue) or Orcish is "bad" because it has only 30 words. I want to know what general criteria you would use for the cases that are not nearly this obvious. > This registration business (like RFC publication) boils down to > "filter nonsense and try to reflect some useful reality". Some humans > do this, and if it's an open process with experts and appeals etc. we > hope that the outcome is good enough. I for one am not going to claim to be the arbiter of what is "nonsense" in ISO 639-3. You may do so if you wish. To clarify: I have no problem with the idea of going to the ISO such-and-so MA and asking that a code element be added or deleted, or that a spelling be changed or something. I have a big problem with setting up a protocol that claims to use ISO such-and-so, but then excludes some of its code elements, NOT because they cause a conflict or don't make sense with the protocol, but because somebody doesn't like them or finds them "ugly." That is pure cherry-picking, of the type described by Bruce Lilly in December 2004, and it WILL get this draft rejected by IESG. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 02:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYG5X-0001Sb-Ms; Fri, 13 Oct 2006 02:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYG5W-0001RW-3C for ltru@ietf.org; Fri, 13 Oct 2006 02:00:06 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYG5T-00056f-DL for ltru@ietf.org; Fri, 13 Oct 2006 02:00:06 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061013060002.BHYJ3369.mta13.adelphia.net@DGBP7M81> for ; Fri, 13 Oct 2006 02:00:02 -0400 Message-ID: <009d01c6ee8c$d3288cc0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 12 Oct 2006 23:00:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Re: Scopes and types X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >>> check if "foo" is a pure 639-3 subtag > [...] >> What is a pure subtag? > > A pure 639-3 subtag is something where the columns "Part1" and "Part2" > in iso-dis-639-3_20060421.tab are empty (or should be empty after the > next synchronization). In other words, a subtag derived from one of the 7,000 code elements in ISO/FDIS 639-3 that is not present in ISO 639-2. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 02:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGaI-00030J-84; Fri, 13 Oct 2006 02:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGaH-00030E-EY for ltru@ietf.org; Fri, 13 Oct 2006 02:31:53 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYGaG-0006M3-3H for ltru@ietf.org; Fri, 13 Oct 2006 02:31:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061013063151.BUWK3369.mta13.adelphia.net@DGBP7M81>; Fri, 13 Oct 2006 02:31:51 -0400 Message-ID: <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000c01c6ee77$e2dea9c0$6501a8c0@DGBP7M81> Date: Thu, 12 Oct 2006 23:31:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Sue Ellen Wright Subject: [Ltru] Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've obtained a copy of the FDIS text for ISO 639-3 from Sue Ellen Wright, Chair of the US ANSI Technical Advisory Group (TAG). I suspect other list memebers will want their very own copy as well, and so I'm wondering if the group thinks it would be beneficial for either the LTRU WG or the ietf-languages list to create an IETF liaison with ISO TC37/SC2, the subcommittee that is developing ISO 639-3. This might give us a quicker response on things like updated documentation and information about 639-3. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 03:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHcH-0005EB-1B; Fri, 13 Oct 2006 03:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHcF-0005E5-RO for ltru@ietf.org; Fri, 13 Oct 2006 03:37:59 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYHcA-0003YJ-GP for ltru@ietf.org; Fri, 13 Oct 2006 03:37:59 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004955012.msg for ; Fri, 13 Oct 2006 08:40:02 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Fri, 13 Oct 2006 08:38:01 +0100 From: "Debbie Garside" To: "'LTRU Working Group'" , "'Doug Ewell'" Subject: RE: [Ltru] Liaison with TC37/SC2 Date: Fri, 13 Oct 2006 08:37:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbukZVZnTWC7ebPStW1FMB+nvyLDAACFdwQ In-Reply-To: <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Fri, 13 Oct 2006 08:40:02 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Fri, 13 Oct 2006 08:40:02 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > I'm wondering if the group thinks it would be > beneficial for either the LTRU WG or the ietf-languages list > to create an IETF liaison with ISO TC37/SC2, the subcommittee > that is developing ISO 639-3. I think that is an excellent idea... Now where have I heard it before? ;-) One slight correction it is TC37/SC2/WG1 and this WG deals with the ISO 639 family as a whole not just 639-3. I propose Doug Ewell as Liaison. Best regards Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 13 October 2006 07:32 > To: LTRU Working Group > Cc: Sue Ellen Wright > Subject: [Ltru] Liaison with TC37/SC2 > > I've obtained a copy of the FDIS text for ISO 639-3 from Sue > Ellen Wright, Chair of the US ANSI Technical Advisory Group (TAG). > > I suspect other list memebers will want their very own copy > as well, and so I'm wondering if the group thinks it would be > beneficial for either the LTRU WG or the ietf-languages list > to create an IETF liaison with ISO TC37/SC2, the subcommittee > that is developing ISO 639-3. This might give us a quicker > response on things like updated documentation and information > about 639-3. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 03:57:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHvJ-0000Kv-Mk; Fri, 13 Oct 2006 03:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHvI-0000EJ-5g for ltru@lists.ietf.org; Fri, 13 Oct 2006 03:57:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYHvD-0006Ln-NT for ltru@lists.ietf.org; Fri, 13 Oct 2006 03:57:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYHv0-0004ur-Gd for ltru@lists.ietf.org; Fri, 13 Oct 2006 09:57:22 +0200 Received: from pd9fba926.dip0.t-ipconnect.de ([217.251.169.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 09:57:22 +0200 Received: from nobody by pd9fba926.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 09:57:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Oct 2006 09:53:38 +0200 Organization: Lines: 42 Message-ID: <452F4602.7327@xyzzy.claranet.de> References: <009501c6ee89$cd670990$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba926.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Ltru] Yinglish (was: Is 639-3 bogus ?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I don't mean that Esperanto is "good" because it has 2 million speakers > (Ethnologue) or Orcish is "bad" because it has only 30 words. Actually I didn't look for "orq", I was curious if that... http://en.wikipedia.org/wiki/Talossan_language ...somehow made it into the "C" category. I've no recipe how to identify nonsense, it's one of those "I know it when I see it" things. Of course it could be wrong, it's difficult to draw the line somewhere. For your example Yinglish I couldn't decode John's examples: | Before I knew that he had said it in shiur, I was mechaven to the Rosh | Yeshiva's pshat in the Gemara. | So get off your tochus and write a letter to Joan Spanne [...] | kvetching about it. But that's an "L", no "C" and no "vanispamcruft" (en-x-wikipedi term defined in http://en.wikipedia.org/wiki/WP:VSCA) > That is pure cherry-picking You could say the same about variant or alpha 5..8 language registrations, somebody has to do the vetting. Otherwise all in could get subtags. > it WILL get this draft rejected by IESG. They didn't approve an unrestricted location registry. With less than 26*26*26 the registry is still in reasonable size limits. With 26*26*26*26 for alpha5..8 (variant or language) it's not, 50 MB would be IMO unacceptable. I've no idea where the IESG would draw the line, but at some point Michelle could offer an opinion on behalf of IANA. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 04:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYIAl-0001Nb-KL; Fri, 13 Oct 2006 04:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYIAj-0001Jq-CG for ltru@lists.ietf.org; Fri, 13 Oct 2006 04:13:37 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYI56-0007qm-Qi for ltru@lists.ietf.org; Fri, 13 Oct 2006 04:07:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYI4t-0007Bm-Nc for ltru@lists.ietf.org; Fri, 13 Oct 2006 10:07:35 +0200 Received: from pd9fba926.dip0.t-ipconnect.de ([217.251.169.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 10:07:35 +0200 Received: from nobody by pd9fba926.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 10:07:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 13 Oct 2006 10:06:36 +0200 Organization: Lines: 6 Message-ID: <452F490C.7F20@xyzzy.claranet.de> References: <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba926.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > I propose Doug Ewell as Liaison. +1 in Or John or Peter (sparing one of them for the opposite direction) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 09:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMq8-0001b7-Db; Fri, 13 Oct 2006 09:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMq6-0001W1-Ll for ltru@ietf.org; Fri, 13 Oct 2006 09:12:38 -0400 Received: from mail05.svc.cra.dublin.eircom.net ([159.134.118.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYMq2-0007OI-CJ for ltru@ietf.org; Fri, 13 Oct 2006 09:12:38 -0400 Received: (qmail 44021 messnum 3317250 invoked from network[194.125.174.44/ts09-044.dublin.indigo.ie]); 13 Oct 2006 13:12:32 -0000 Received: from ts09-044.dublin.indigo.ie (HELO ?194.125.174.44?) (194.125.174.44) by mail05.svc.cra.dublin.eircom.net (qp 44021) with SMTP; 13 Oct 2006 13:12:32 -0000 In-Reply-To: <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> References: <000c01c6ee77$e2dea9c0$6501a8c0@DGBP7M81> <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5B8D276E-2612-4A0B-81A4-04BD82407DC2@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Liaison with TC37/SC2 Date: Fri, 13 Oct 2006 14:10:08 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Sue Ellen Wright X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 13 Oct 2006, at 06:31, scr=EDobh Doug Ewell: > I suspect other list memebers will want their very own copy as =20 > well, and so I'm wondering if the group thinks it would be =20 > beneficial for either the LTRU WG or the ietf-languages list to =20 > create an IETF liaison with ISO TC37/SC2, the subcommittee that is =20 > developing ISO 639-3. it would. > This might give us a quicker response on things like updated =20 > documentation and information about 639-3. > It might. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 09:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYN3Q-0000Dc-Bk; Fri, 13 Oct 2006 09:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYN3P-0000A7-Bi for ltru@ietf.org; Fri, 13 Oct 2006 09:26:23 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYN3I-00010w-Uc for ltru@ietf.org; Fri, 13 Oct 2006 09:26:23 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Fri, 13 Oct 2006 06:26:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 06:26:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Liaison with TC37/SC2 Date: Fri, 13 Oct 2006 06:17:37 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Liaison with TC37/SC2 thread-index: AcbukZVZnTWC7ebPStW1FMB+nvyLDAACFdwQAAvYR6A= From: Peter Constable To: , LTRU Working Group , Doug Ewell X-OriginalArrivalTime: 13 Oct 2006 13:26:15.0795 (UTC) FILETIME=[28DC8430:01C6EECB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org In ISO, liaisons to other bodies are created at the TC or SC level, never at the WG level. Also, it is really the SC that owns the 639 projects. So, it probably makes sense that a liaison would be to SC2. But since it would be coming from the IETF side, I guess it's up to people on this side to decide what group they want to relate to. Peter -----Original Message----- From: Debbie Garside [mailto:debbie@ictmarketing.co.uk]=20 Sent: Friday, October 13, 2006 12:38 AM To: 'LTRU Working Group'; 'Doug Ewell' Subject: RE: [Ltru] Liaison with TC37/SC2 Doug wrote: > I'm wondering if the group thinks it would be=20 > beneficial for either the LTRU WG or the ietf-languages list=20 > to create an IETF liaison with ISO TC37/SC2, the subcommittee=20 > that is developing ISO 639-3.=20 I think that is an excellent idea... Now where have I heard it before? ;-) One slight correction it is TC37/SC2/WG1 and this WG deals with the ISO 639 family as a whole not just 639-3. I propose Doug Ewell as Liaison. Best regards Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net]=20 > Sent: 13 October 2006 07:32 > To: LTRU Working Group > Cc: Sue Ellen Wright > Subject: [Ltru] Liaison with TC37/SC2 >=20 > I've obtained a copy of the FDIS text for ISO 639-3 from Sue=20 > Ellen Wright, Chair of the US ANSI Technical Advisory Group (TAG). >=20 > I suspect other list memebers will want their very own copy=20 > as well, and so I'm wondering if the group thinks it would be=20 > beneficial for either the LTRU WG or the ietf-languages list=20 > to create an IETF liaison with ISO TC37/SC2, the subcommittee=20 > that is developing ISO 639-3. This might give us a quicker=20 > response on things like updated documentation and information=20 > about 639-3. >=20 > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * =20 > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 09:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYN6I-0003tI-4p; Fri, 13 Oct 2006 09:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYN6H-0003sc-EA for ltru@lists.ietf.org; Fri, 13 Oct 2006 09:29:21 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYN6E-0001oi-4P for ltru@lists.ietf.org; Fri, 13 Oct 2006 09:29:21 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Fri, 13 Oct 2006 06:29:17 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Fri, 13 Oct 2006 06:29:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Yinglish (was: Is 639-3 bogus ?) Date: Fri, 13 Oct 2006 06:28:56 -0700 Message-ID: In-Reply-To: <452F4602.7327@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Yinglish (was: Is 639-3 bogus ?) thread-index: AcbunUYTmZtqF9lbTyKstMRhEirgrwALUWsA From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 13 Oct 2006 13:29:17.0597 (UTC) FILETIME=[95394CD0:01C6EECB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank, if you feel that vetting of entities coded in ISO standards is so essential, why don't you start with 639-1 and 639-2 since those are far more tractable sets and would be part of vetting 639-3 anyway. (My point isn't to actually get you to do that but rather to point out you're being somewhat arbitrary here.) Personally, I agree with Doug: the job of LTRU is to work on 4646bis, not to sift through 639-3 and cherry pick. It is *NOT* the role of LTRU to vet registration requests for variant or 5..8 language subtags; that the job of ietf-languages. Peter -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 > That is pure cherry-picking You could say the same about variant or alpha 5..8 language registrations, somebody has to do the vetting. Otherwise all in could get subtags. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 09:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNWD-0004Cq-VC; Fri, 13 Oct 2006 09:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNWC-0004Cl-J4 for ltru@lists.ietf.org; Fri, 13 Oct 2006 09:56:08 -0400 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYNWA-00065O-8t for ltru@lists.ietf.org; Fri, 13 Oct 2006 09:56:08 -0400 Received: (qmail 58828 messnum 11077731 invoked from network[194.125.174.44/ts09-044.dublin.indigo.ie]); 13 Oct 2006 13:56:04 -0000 Received: from ts09-044.dublin.indigo.ie (HELO ?194.125.174.44?) (194.125.174.44) by mail11.svc.cra.dublin.eircom.net (qp 58828) with SMTP; 13 Oct 2006 13:56:04 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <452F490C.7F20@xyzzy.claranet.de> References: <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> <452F490C.7F20@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <18824246-DC0C-4D47-B5E5-E98104344337@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Date: Fri, 13 Oct 2006 14:53:40 +0000 To: ltru@lists.ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Might I suggest that, as Sue-Ellen (of ANSI, who used to be an ISO =20 colleague of mine) is an American and SIL (RA for 639-3) also =20 American and ISO/TC 37/SC 2 already has an American Chair, we propose =20= some person(s) born in some other country less under the influence of =20= current US foreign policy in re territorial/linguistic designations =20 and more eager to respect more diverse opinions (excluding Austria, =20 because either 639-1 or 639-2 - whichever! - already has an Austrian =20 RA, which only supports the other to be under LOC_US control)? I =20 propose this as someone with an ever-growing number of US-born =20 friends who feel embarrassed by this irrational and totally =20 unnecessary push towards monopoly and who would rather much rather =20 operate professionally in a freer, less unequal atmosphere (where =20 nobody can blame any one country, especially _their_ native country, =20 for errors - and who could blame anyone for desiring that?). mg On 13 Oct 2006, at 08:06, scr=EDobh Frank Ellermann: > Debbie Garside wrote: > > >> I propose Doug Ewell as Liaison. >> > +1 in > Or John or Peter (sparing one of them for the opposite direction) - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 10:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYO05-000757-IO; Fri, 13 Oct 2006 10:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNya-0006Iu-Ba for ltru@ietf.org; Fri, 13 Oct 2006 10:25:28 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYNk5-00088u-Qv for ltru@ietf.org; Fri, 13 Oct 2006 10:10:33 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061013141029.WWAK2152.mta11.adelphia.net@DGBP7M81>; Fri, 13 Oct 2006 10:10:29 -0400 Message-ID: <004f01c6eed1$570a34a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 13 Oct 2006 07:10:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Frank Ellermann Subject: [Ltru] Re: Yinglish (was: Is 639-3 bogus ?) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> That is pure cherry-picking > > You could say the same about variant or alpha 5..8 language > registrations, somebody has to do the vetting. Otherwise all in > could get > subtags. No, "cherry-picking" has to do with selecting pieces from an external standard, usually while claiming to support the whole standard. Setting the rules for our own registrations, and accepting some and rejecting others, is not the same thing. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 11:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYOqa-0002I6-8j; Fri, 13 Oct 2006 11:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYOqY-0002I1-Ca for ltru@lists.ietf.org; Fri, 13 Oct 2006 11:21:14 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYOqW-0001lE-5T for ltru@lists.ietf.org; Fri, 13 Oct 2006 11:21:14 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYOqS-0004oC-Rt; Fri, 13 Oct 2006 11:21:08 -0400 Date: Fri, 13 Oct 2006 11:21:08 -0400 To: Frank Ellermann Subject: Re: [Ltru] Yinglish (was: Is 639-3 bogus ?) Message-ID: <20061013152108.GC22507@ccil.org> References: <009501c6ee89$cd670990$6501a8c0@DGBP7M81> <452F4602.7327@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452F4602.7327@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > For your example Yinglish I couldn't decode John's examples: > > | Before I knew that he had said it in shiur, I was mechaven to the Rosh > | Yeshiva's pshat in the Gemara. Before I knew that he had said it in class, I was in agreement with the head of the (religious) school's interpretation in the Gemara (part of the Talmud, the Jewish legal code). > | So get off your tochus and write a letter to Joan Spanne [...] > | kvetching about it. So get off your buttocks (same implication as in "Sitzfleisch") and write a letter to J.S. complaining about it. The point is that these examples are plain English with unusual vocabulary, not really different from dense slang or the technical talk of pilots, doctors, or computer programmers. -- When I'm stuck in something boring John Cowan where reading would be impossible or (who loves Asimov too) rude, I often set up math problems for cowan@ccil.org myself and solve them as a way to pass http://www.ccil.org/~cowan the time. --John Jenkins _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 13:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQze-0002rk-CC; Fri, 13 Oct 2006 13:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQzd-0002qH-4u for ltru@lists.ietf.org; Fri, 13 Oct 2006 13:38:45 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYQzY-0003ib-RV for ltru@lists.ietf.org; Fri, 13 Oct 2006 13:38:45 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Fri, 13 Oct 2006 10:38:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Fri, 13 Oct 2006 10:38:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [OT] RE: [Ltru] Yinglish (was: Is 639-3 bogus ?) Date: Fri, 13 Oct 2006 10:38:26 -0700 Message-ID: In-Reply-To: <20061013152108.GC22507@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OT] RE: [Ltru] Yinglish (was: Is 639-3 bogus ?) thread-index: Acbu340NJLl8aQmxR8WqY0EGYTlR1AADW+jQ References: <009501c6ee89$cd670990$6501a8c0@DGBP7M81><452F4602.7327@xyzzy.claranet.de> <20061013152108.GC22507@ccil.org> From: Peter Constable To: John Cowan , Frank Ellermann X-OriginalArrivalTime: 13 Oct 2006 17:38:40.0280 (UTC) FILETIME=[6BAD8980:01C6EEEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 > The point is that these examples are plain English with unusual > vocabulary, not really different from dense slang or the technical > talk of pilots, doctors, or computer programmers. Well, that's debatable. When English-speaking doctor uses a term like "hematoma" they would probably agree that these are English words albeit part of a specialized domain of vocabulary. (It's common for a language to have specialized domains of vocabulary that only certain members of the community learn.) But when a "Yinglish" speaker uses a word like "pshat", nobody would suggest that that's an English term -- I reject your suggestion that this is just plain English with specialized English vocabulary as these are clearly not English and not even borrowings into English (they are not spoken with English phonology). At that point, I believe your options (in terms of the categories that sociolinguists use) are limited to: - you deem this to be an instance of code switching: moving back and forth between two languages (I often hear devs that are mother-tongue speakers of some other language do this, switch to English for certain technical terms). - ye deem this to be a distinct language Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 14:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRvT-0006PK-IQ; Fri, 13 Oct 2006 14:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRvR-0006Op-TF for ltru@lists.ietf.org; Fri, 13 Oct 2006 14:38:29 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRvN-00049l-IT for ltru@lists.ietf.org; Fri, 13 Oct 2006 14:38:29 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYRvN-0004Ac-0u; Fri, 13 Oct 2006 14:38:25 -0400 Date: Fri, 13 Oct 2006 14:38:24 -0400 To: Peter Constable Subject: Re: [OT] RE: [Ltru] Yinglish (was: Is 639-3 bogus ?) Message-ID: <20061013183824.GA9507@ccil.org> References: <20061013152108.GC22507@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: (Taking ltru off the cc list) > But when a "Yinglish" speaker uses a word like > "pshat", nobody would suggest that that's an English term -- I reject > your suggestion that this is just plain English with specialized English > vocabulary as these are clearly not English and not even borrowings into > English (they are not spoken with English phonology). Don't be deceived by the conventional spelling: the usual pronunciation is [p@'SAt], and googling shows "peshat" as slightly more common than "pshat". Indeed, most of the Slavic and Hebrew Yiddish words with really un-English phonology have *not* been borrowed into English. The exception, of course, is the sh+consonant words that are now part, if a marginal part, of English phonology. And if I myself say "challah" (the bread) as ['XAl@], there are plenty of Jews who make it ['hAli], homonymous with "holly"; similarly ['sUrIs] for "tsuris". > At that point, I believe your options (in terms of the categories that > sociolinguists use) are limited to: > > - you deem this to be an instance of code switching: moving back and > forth between two languages (I often hear devs that are mother-tongue > speakers of some other language do this, switch to English for certain > technical terms). I think this is an excessively broad definition of code-switching. See http://recycledknowledge.blogspot.com/2005/06/french-in-all-its-purity.html for how pervasive borrowing (of English into French) can get without in any way being confused with code-switching. > - ye deem this to be a distinct language If so, it's one that smoothly integrates into the English dialect continuum, and exists in isolated clumps in the U.S., Australia, the U.K., etc., sharing most of the phonological features of the non-Jewish dialects surrounding each clump. >From the Wikipedia article on Spanglish: More importantly, the many varieties of "Spanglish" developed largely independently. In the case of a language like Spanish or English, there was a time and place where it originated, spread out to many countries and regions, and then diverged from the original form. In the case of "Spanglish," there isn't any such "original" version of it, from which its "dialects" sprang; each form represents a unique instance of English influencing the speech of Spanish speakers. -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 16:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTgH-0004o1-GX; Fri, 13 Oct 2006 16:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTgG-0004nw-RF for ltru@ietf.org; Fri, 13 Oct 2006 16:30:56 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYTgF-0004bf-G0 for ltru@ietf.org; Fri, 13 Oct 2006 16:30:56 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UM7wjwKWxxmucJYBPmVK5qhHsSqNeNQiNdtHTCk03kAXbLDRXt7DXBm7TuDaKRdH; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.2.188] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GYTgE-0001Jm-UN; Fri, 13 Oct 2006 16:30:55 -0400 Message-ID: <009801c6ef07$1fd1f1e0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000c01c6ee77$e2dea9c0$6501a8c0@DGBP7M81> <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> Subject: Re: [Ltru] Liaison with TC37/SC2 Date: Fri, 13 Oct 2006 13:35:29 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee67db63be1ffaece89c8e42cf2a907ab59350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.2.188 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Sue Ellen Wright X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Cc: "Sue Ellen Wright" > Sent: Thursday, October 12, 2006 11:31 PM > Subject: [Ltru] Liaison with TC37/SC2 > > I've obtained a copy of the FDIS text for ISO 639-3 from Sue Ellen > Wright, Chair of the US ANSI Technical Advisory Group (TAG). > > I suspect other list memebers will want their very own copy as well, and > so I'm wondering if the group thinks it would be beneficial for either > the LTRU WG or the ietf-languages list to create an IETF liaison with > ISO TC37/SC2, the subcommittee that is developing ISO 639-3. This might > give us a quicker response on things like updated documentation and > information about 639-3. ... Writing as a technical contributor... The information flow is most welcome, but... Just why would an official liaison relationship be necessary? As long as there is some overlap in the participants, and the necessary information travels where it needs to go, I think we're ok. Making it an official liaison relationship brings things under BCP 103 (RFC 4053) which might be a bit heavier-weight than we really need or want. My experience in other WGs both in ISO land as well as here in the IETF is that chairs on both ends are quite reasonable about permitting preliminary document access to outside experts, especially when there is closely related work or inter-dependencies. There are times when formal channels become necessary, but my strong personal preference is to set up formal liaison relationships only when absolutely necessary. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 18:56:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYVwq-0000vd-FQ; Fri, 13 Oct 2006 18:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYVwo-0000o6-R0 for ltru@lists.ietf.org; Fri, 13 Oct 2006 18:56:10 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYVot-0004va-Gg for ltru@lists.ietf.org; Fri, 13 Oct 2006 18:48:00 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYVos-0002Xh-5W; Fri, 13 Oct 2006 18:47:58 -0400 Date: Fri, 13 Oct 2006 18:47:58 -0400 To: Peter Constable Subject: Re: [OT] RE: [Ltru] Yinglish (was: Is 639-3 bogus ?) Message-ID: <20061013224758.GB9507@ccil.org> References: <20061013152108.GC22507@ccil.org> <20061013183824.GA9507@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061013183824.GA9507@ccil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Scripsi: > (Taking ltru off the cc list) Except I forgot to. Arrgh. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 21:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYXuD-0005Qy-Jd; Fri, 13 Oct 2006 21:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYXuC-0005Qt-Br for ltru@lists.ietf.org; Fri, 13 Oct 2006 21:01:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYXu8-0002vr-Rm for ltru@lists.ietf.org; Fri, 13 Oct 2006 21:01:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYXu7-0007wi-9o for ltru@lists.ietf.org; Sat, 14 Oct 2006 03:01:31 +0200 Received: from pd9fbadc0.dip0.t-ipconnect.de ([217.251.173.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 03:01:31 +0200 Received: from nobody by pd9fbadc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 03:01:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 03:00:48 +0200 Organization: Lines: 20 Message-ID: <453036BF.B2@xyzzy.claranet.de> References: <009501c6ee89$cd670990$6501a8c0@DGBP7M81> <452F4602.7327@xyzzy.claranet.de> <20061013152108.GC22507@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: Yinglish X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >>| So get off your tochus and write a letter to Joan Spanne [...] >>| kvetching about it. > So get off your buttocks (same implication as in "Sitzfleisch") > and write a letter to J.S. complaining about it. Thanks, for that part I could guess it (de quetschen to en press). > The point is that these examples are plain English with unusual > vocabulary, not really different from dense slang or the technical > talk of pilots, doctors, or computer programmers. Assuming that it does not yet qualify for a 639-9 code element it could still qualify for a 4646 variant. With a variant it's easy to find it as "some variant of English". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 21:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYna-0008Rb-8I; Fri, 13 Oct 2006 21:58:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYnZ-0008RS-M0 for ltru@lists.ietf.org; Fri, 13 Oct 2006 21:58:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYYnY-0003hd-86 for ltru@lists.ietf.org; Fri, 13 Oct 2006 21:58:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYYkg-0001RW-S2 for ltru@lists.ietf.org; Sat, 14 Oct 2006 03:55:51 +0200 Received: from pd9fbadc0.dip0.t-ipconnect.de ([217.251.173.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 03:55:50 +0200 Received: from nobody by pd9fbadc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 03:55:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 03:45:08 +0200 Organization: Lines: 44 Message-ID: <45304124.4824@xyzzy.claranet.de> References: <452F4602.7327@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ltru] Re: Yinglish X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > why don't you start with 639-1 and 639-2 since those are far more > tractable sets and would be part of vetting 639-3 anyway. (My point > isn't to actually get you to do that but rather to point out you're > being somewhat arbitrary here.) Yes, and "tlh" is IMO a border case, I've some doubts about it as a "language subtag". But otherwise it's something real, not only the movies and the books, folks take it as some kind of ethics or religion. For slightly different reasons "sjn" is also okay from my POV. About 25 years ago I collected a word list - the German translation didn't offer this. For "jbo" I trust that John knows why it's okay, I had no reason to check it. But that "orq" case triggered all my "Wikipedia list of micronations" alarm bells at once. There are folks out there who try to smuggle in nonsense, and some not for fun but for dubious purposes, also known as "search engine optimization" or "spam". Some "micronations" are obscure pyramid schemes or worse. And I trust that "Sea Island" in "gul" is unrelated to "Sealand". As micronation Sealand is mostly harmless, but there's a lot of fine print, "mostly" does not mean "completely", gullible folks lost some real money. > the job of LTRU is to work on 4646bis, not to sift through 639-3 and > cherry pick. It is *NOT* the role of LTRU > to vet registration requests for variant or 5..8 language subtags; > that the job of ietf-languages. Sure, but LTRU could decree that 639-3 type "C" is only registered on demand after approval by the subtag list. Probably that's pointless if there's no way to get rid of it in 639-3 later, the alpha3 code is then "lost" (occupied forever) anyway, not copying it to the registry doesn't help. A more effective procedure could be that the subtag review list gets a copy of all proposals for new code elements - maybe that boils down to "subscribe some newsletter to the subtag review list". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 22:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYzG-0007IS-6j; Fri, 13 Oct 2006 22:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYzE-0007IN-FW for ltru@lists.ietf.org; Fri, 13 Oct 2006 22:10:52 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYYzA-0006gz-8e for ltru@lists.ietf.org; Fri, 13 Oct 2006 22:10:52 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYYz9-0002oM-RS; Fri, 13 Oct 2006 22:10:47 -0400 Date: Fri, 13 Oct 2006 22:10:47 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Yinglish Message-ID: <20061014021047.GF22507@ccil.org> References: <452F4602.7327@xyzzy.claranet.de> <45304124.4824@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45304124.4824@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > For slightly different reasons "sjn" is also okay from my POV. About > 25 years ago I collected a word list - the German translation didn't > offer this. A detailed grammar has been published, as well as vocabulary lists of various sizes. > And I trust > that "Sea Island" in "gul" is unrelated to "Sealand". It is. The Sea Islands in question are off the eastern coast of South Carolina, U.S. > Sure, but LTRU could decree that 639-3 type "C" is only registered on > demand after approval by the subtag list. Probably that's pointless > if there's no way to get rid of it in 639-3 later, the alpha3 code is > then "lost" (occupied forever) anyway, not copying it to the registry > doesn't help. Just so. -- It was impossible to inveigle John Cowan Georg Wilhelm Friedrich Hegel http://www.ccil.org/~cowan Into offering the slightest apology For his Phenomenology. --W. H. Auden, from "People" (1953) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 13 22:27:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYZFI-0002al-Oy; Fri, 13 Oct 2006 22:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYZFH-0002ac-TW for ltru@lists.ietf.org; Fri, 13 Oct 2006 22:27:27 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYZFD-0002WX-8e for ltru@lists.ietf.org; Fri, 13 Oct 2006 22:27:27 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYZF8-0005yj-4i for ltru@lists.ietf.org; Sat, 14 Oct 2006 04:27:18 +0200 Received: from pd9fbadc0.dip0.t-ipconnect.de ([217.251.173.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 04:27:18 +0200 Received: from nobody by pd9fbadc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 04:27:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 04:24:33 +0200 Organization: Lines: 26 Message-ID: <45304A61.51A3@xyzzy.claranet.de> References: <000c01c6ee77$e2dea9c0$6501a8c0@DGBP7M81> <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> <009801c6ef07$1fd1f1e0$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > my strong personal preference is to set up formal liaison > relationships only when absolutely necessary. Somehow Harald (?) managed to get an official letter from the entity "ISO 639 RA JAC" and copied it into RFC 3066. Years later we copied that statement from 3066 to 4646. That could need an update confirming that there won't be conflicts between 639-1/2 and 639-3, and that withdrawn codes are never reassigned. Is that possible without a formal exchange ? If not this shouldn't be too bureaucratic: 1 - WG sends request to "RA JAC" (i.e. somebody does this on behalf of the WG, and for that part this person has to be authorized to speak for the WG). 2 - "RA JAC" sends a reply to the WG (or not), posted here. 3 - WG is happy with the reply (or not), liaison sends a "thanks" (and that terminates this liaison activity). 4 - Updated official statement integrated into 4646bis. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 02:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdI8-0001sK-81; Sat, 14 Oct 2006 02:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdI7-0001sF-Su for ltru@ietf.org; Sat, 14 Oct 2006 02:46:39 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYdI6-0000qx-GU for ltru@ietf.org; Sat, 14 Oct 2006 02:46:39 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061014064635.HUIB18643.mta9.adelphia.net@DGBP7M81> for ; Sat, 14 Oct 2006 02:46:35 -0400 Message-ID: <007601c6ef5c$7e4bbbc0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 13 Oct 2006 23:46:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Marion Gunn wrote: > Might I suggest that, as Sue-Ellen (of ANSI, who used to be an ISO > colleague of mine) is an American and SIL (RA for 639-3) also American > and ISO/TC 37/SC 2 already has an American Chair, we propose some > person(s) born in some other country less under the influence of > current US foreign policy in re territorial/linguistic designations > and more eager to respect more diverse opinions (excluding Austria, > because either 639-1 or 639-2 - whichever! - already has an Austrian > RA, which only supports the other to be under LOC_US control)? I > propose this as someone with an ever-growing number of US-born friends > who feel embarrassed by this irrational and totally unnecessary push > towards monopoly and who would rather much rather operate > professionally in a freer, less unequal atmosphere (where nobody can > blame any one country, especially _their_ native country, for errors - > and who could blame anyone for desiring that?). Well, now. First of all, I am flattered and honored by Debbie's nomination, but I am probably going to have to decline it for two main reasons: 1. I have no experience as a liaison, and no prior formal working relationship with, or membership in, an ISO SC or WG. While everyone has to start somewhere, I think this particular project should benefit from a liaison with some experience, not a trainee. 2. I have no travel budget, and no realistic hope of getting one. I'm willing to be convinced that each of these is negotiable, and not a show-stopper. I'm guessing that item 1 is going to turn out to be negotiable, and item 2 isn't. Now about this American thing. Completely disregarding the issue of me personally, I'm deeply disappointed that national origin is being considered a criterion for choosing a liaison. I would have thought it was about as important as eye color, or left-handedness versus right-handedness. I was not aware that being American-born prevented one, a priori, from being "eager to respect more diverse opinions." Perhaps there are some who do see it that way. I certainly wouldn't consider myself a slave to U.S. foreign policy. People who know me well know my objections to the current administration's foreign policy and the aggressive, bullying way it enforces it. I suppose it is that aggressive stance, combined with misplaced stereotypes, that makes some non-Americans think we all support our administration. As for "US foreign policy in re territorial/linguistic designations," it hadn't occurred to me at the time that there was such a thing. I guess the State Department's preference for "Burma" and "Burmese" over "Myanmar" is a statement of sorts about their opposition to that country's current leadership. I don't know what that has to do with the liaison position. I've never advocated changing an internationally recognized, ISO-approved language, script, or country name in the Registry to better suit U.S. policy. I tend to think of the Internet and WGs like this as true melting pots, where I can work with someone for months or years without regard for their race, age, national origin, blood type, shoe size, etc. I thought we had gotten past the days on this list of questioning someone's motives or abilities on the basis of what country they were born in or live in. I do not think I would automatically consider an Irish person unqualified or inappropriate to be a liaison simply because they were Irish. I note in passing that I was nominated by a European. I don't care to pursue this distasteful topic further. Let's find a liaison everyone in the WG can support, so we can have ready access to the documents we need to get our work done. Or, if Randy is correct and we can be assured of the necessary access without a formal liaison, let's do that instead. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 05:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfYe-0005Sa-N2; Sat, 14 Oct 2006 05:11:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYLiN-0005WD-B0 for ltru@ietf.org; Fri, 13 Oct 2006 08:00:35 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYLiI-0002JU-K7 for ltru@ietf.org; Fri, 13 Oct 2006 08:00:35 -0400 Received: by nf-out-0910.google.com with SMTP id l23so1595703nfc for ; Fri, 13 Oct 2006 05:00:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WqW8tjBuW4iVRxj5hItb86MHE742RU6SwfSc5oHFtueFMHyIwEeIYa3XUfuthx1MEN8P6vTvTcpbhaCHTee6K1TUynhGyf6FYnVsLDWtGQCayfdkej9XasDmlNP0Py/7Bo0jak9UqtM8VM3/z/vnRwShZDEUMPB3pd6QaHH+dYI= Received: by 10.48.162.15 with SMTP id k15mr6834865nfe; Fri, 13 Oct 2006 05:00:28 -0700 (PDT) Received: by 10.49.78.12 with HTTP; Fri, 13 Oct 2006 05:00:28 -0700 (PDT) Message-ID: Date: Fri, 13 Oct 2006 08:00:28 -0400 From: "Sue Ellen Wright" To: "Doug Ewell" , "christian.galinski@chello.at" , "=?ISO-8859-1?Q?H=E5vard_Hjulstad?=" , "Jennifer DeCamp" In-Reply-To: <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <000c01c6ee77$e2dea9c0$6501a8c0@DGBP7M81> <00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-Mailman-Approved-At: Sat, 14 Oct 2006 05:11:52 -0400 Cc: Gerhard Budin , LTRU Working Group Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0058672839==" Errors-To: ltru-bounces@ietf.org --===============0058672839== Content-Type: multipart/alternative; boundary="----=_Part_90696_14230729.1160740828704" ------=_Part_90696_14230729.1160740828704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear colleagues, I think a formal liaison between TC 37/SC 2 and the IETF/LTRU WG is essential. There have been many informal discussions over the years because many of us know each other, but it's really important that the working relationship be as close and cooperative as possible. (I've just spent a few hours in the last few days studying the new documents that have been posted for BCP 47.) I personally am not directly involved in the language code WG, although I try to track what is happening on all fronts on an ongoing basis. Not an easy task, actually! Can anyone tell me just what sort of arrangement if any exists, or do we need to initiate action to establish formal liaison? Best regards Sue Ellen On 10/13/06, Doug Ewell wrote: > > I've obtained a copy of the FDIS text for ISO 639-3 from Sue Ellen > Wright, Chair of the US ANSI Technical Advisory Group (TAG). > > I suspect other list memebers will want their very own copy as well, and > so I'm wondering if the group thinks it would be beneficial for either > the LTRU WG or the ietf-languages list to create an IETF liaison with > ISO TC37/SC2, the subcommittee that is developing ISO 639-3. This might > give us a quicker response on things like updated documentation and > information about 639-3. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > -- Sue Ellen Wright Institute for Applied Linguistics Kent State University Kent OH 44242 USA sellenwright@gmail.com swright@kent.edu sewright@neo.rr.com ------=_Part_90696_14230729.1160740828704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear colleagues,
I think a formal liaison between TC 37/SC 2 and the IETF/LTRU WG is essential. There have been many informal discussions over the years because many of us know each other, but it's really important that the working relationship be as close and cooperative as possible. (I've just spent a few hours in the last few days studying the new documents that have been posted for BCP 47.) I personally am not directly involved in the language code WG, although I try to track what is happening on all fronts on an ongoing basis. Not an easy task, actually! Can anyone tell me just what sort of arrangement if any exists, or do we need to initiate action to establish formal liaison?
Best regards
Sue Ellen

 
On 10/13/06, Doug Ewell <dewell@adelphia.net> wrote:
I've obtained a copy of the FDIS text for ISO 639-3 from Sue Ellen
Wright, Chair of the US ANSI Technical Advisory Group (TAG).

I suspect other list memebers will want their very own copy as well, and
so I'm wondering if the group thinks it would be beneficial for either
the LTRU WG or the ietf-languages list to create an IETF liaison with
ISO TC37/SC2, the subcommittee that is developing ISO 639-3.  This might
give us a quicker response on things like updated documentation and
information about 639-3.

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




--
Sue Ellen Wright
Institute for Applied Linguistics
Kent State University
Kent OH 44242 USA
sellenwright@gmail.com
swright@kent.edu
sewright@neo.rr.com ------=_Part_90696_14230729.1160740828704-- --===============0058672839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0058672839==-- From ltru-bounces@ietf.org Sat Oct 14 05:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfZC-0005cI-0t; Sat, 14 Oct 2006 05:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfZB-0005cC-3R for ltru@ietf.org; Sat, 14 Oct 2006 05:12:25 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYfZ9-00022e-GI for ltru@ietf.org; Sat, 14 Oct 2006 05:12:25 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004970283.msg for ; Sat, 14 Oct 2006 10:14:27 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sat, 14 Oct 2006 10:12:24 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Liaison with TC37/SC2 Date: Sat, 14 Oct 2006 10:11:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbvXNcDnAmDKsOJTzaQAACCXvJi1QAEygvg In-Reply-To: <007601c6ef5c$7e4bbbc0$6501a8c0@DGBP7M81> Message-ID: <099E56E902694298855BF6D06A52555F.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Sat, 14 Oct 2006 10:14:27 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sat, 14 Oct 2006 10:14:29 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I don't think Randy is correct and my nomination stands! It is useful to have someone there on the ground BEFORE decisions are made. Given that I have some experience of this particular SC and WG I can say Doug would not be out of his depth at all. It is my opinion that the knowledge Doug has of the RFC's in question wood be invaluable to this SC. As to travel, join ANSI. One would hope that, like BSI, they would support travel expenditure. Best Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 14 October 2006 07:47 > To: LTRU Working Group > Subject: [Ltru] Re: Liaison with TC37/SC2 > > Marion Gunn wrote: > > > Might I suggest that, as Sue-Ellen (of ANSI, who used to be an ISO > > colleague of mine) is an American and SIL (RA for 639-3) > also American > > and ISO/TC 37/SC 2 already has an American Chair, we propose some > > person(s) born in some other country less under the influence of > > current US foreign policy in re territorial/linguistic designations > > and more eager to respect more diverse opinions (excluding Austria, > > because either 639-1 or 639-2 - whichever! - already has an > Austrian > > RA, which only supports the other to be under LOC_US control)? I > > propose this as someone with an ever-growing number of > US-born friends > > who feel embarrassed by this irrational and totally > unnecessary push > > towards monopoly and who would rather much rather operate > > professionally in a freer, less unequal atmosphere (where > nobody can > > blame any one country, especially _their_ native country, > for errors - > > and who could blame anyone for desiring that?). > > Well, now. > > First of all, I am flattered and honored by Debbie's > nomination, but I am probably going to have to decline it for > two main reasons: > > 1. I have no experience as a liaison, and no prior formal > working relationship with, or membership in, an ISO SC or WG. > While everyone has to start somewhere, I think this > particular project should benefit from a liaison with some > experience, not a trainee. > > 2. I have no travel budget, and no realistic hope of getting one. > > I'm willing to be convinced that each of these is negotiable, > and not a show-stopper. I'm guessing that item 1 is going to > turn out to be negotiable, and item 2 isn't. > > Now about this American thing. > > Completely disregarding the issue of me personally, I'm > deeply disappointed that national origin is being considered > a criterion for choosing a liaison. I would have thought it > was about as important as eye color, or left-handedness > versus right-handedness. > > I was not aware that being American-born prevented one, a > priori, from being "eager to respect more diverse opinions." > Perhaps there are some who do see it that way. > > I certainly wouldn't consider myself a slave to U.S. foreign policy. > People who know me well know my objections to the current > administration's foreign policy and the aggressive, bullying > way it enforces it. I suppose it is that aggressive stance, > combined with misplaced stereotypes, that makes some > non-Americans think we all support our administration. > > As for "US foreign policy in re territorial/linguistic > designations," it hadn't occurred to me at the time that > there was such a thing. I guess the State Department's > preference for "Burma" and "Burmese" over "Myanmar" is a > statement of sorts about their opposition to that country's > current leadership. I don't know what that has to do with > the liaison position. I've never advocated changing an > internationally recognized, ISO-approved language, script, or > country name in the Registry to better suit U.S. policy. > > I tend to think of the Internet and WGs like this as true > melting pots, where I can work with someone for months or > years without regard for their race, age, national origin, > blood type, shoe size, etc. I thought we had gotten past the > days on this list of questioning someone's motives or > abilities on the basis of what country they were born in or > live in. I do not think I would automatically consider an > Irish person unqualified or inappropriate to be a liaison > simply because they were Irish. > > I note in passing that I was nominated by a European. > > I don't care to pursue this distasteful topic further. Let's > find a liaison everyone in the WG can support, so we can have > ready access to the documents we need to get our work done. > Or, if Randy is correct and we can be assured of the > necessary access without a formal liaison, let's do that instead. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 05:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfuO-0001mR-8i; Sat, 14 Oct 2006 05:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfuN-0001mM-6V for ltru@lists.ietf.org; Sat, 14 Oct 2006 05:34:19 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYfuK-00074F-S6 for ltru@lists.ietf.org; Sat, 14 Oct 2006 05:34:19 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004970442.msg for ; Sat, 14 Oct 2006 10:36:34 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sat, 14 Oct 2006 10:34:34 +0100 From: "Debbie Garside" To: , "'Frank Ellermann'" Subject: RE: [Ltru] Re: Liaison with TC37/SC2 Date: Sat, 14 Oct 2006 10:34:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbvOKtuGkPeWCU8Q7GVmLRqYlpU7QAOitjg In-Reply-To: <45304A61.51A3@xyzzy.claranet.de> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Sat, 14 Oct 2006 10:36:34 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sat, 14 Oct 2006 10:36:34 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank wrote: > 1 - WG sends request to "RA JAC" (i.e. somebody does this > on behalf of the WG, and for that part this person has > to be authorized to speak for the WG). > 2 - "RA JAC" sends a reply to the WG (or not), posted here. > 3 - WG is happy with the reply (or not), liaison sends a > "thanks" (and that terminates this liaison activity). > 4 - Updated official statement integrated into 4646bis. If only it were that simple. I think IETF-languages and LTRU would benefit greatly from a liaison with TC37/SC2 (WG1). Liaison would be tasked to work in the interests of the IETF at ISO level, in particular with regard to the updating of standards and designing of new standards. ISO 639-1 and -2 are scheduled for update next year. ISO 639-6 is scheduled for publication in January 2008 with ISO 639-4 and -5 slightly sooner. There is lots going on at WG level that IETF should have knowledge of. Liaison to JAC is not helpful at all in this case as the JAC purely make decisions on new registration requests and are not involved in the standard writing process; which is at WG level. Best regards Debbie > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 05:46:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYg6A-0000zo-TE; Sat, 14 Oct 2006 05:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYg69-0000zi-GJ for ltru@lists.ietf.org; Sat, 14 Oct 2006 05:46:29 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYg62-0001HW-SR for ltru@lists.ietf.org; Sat, 14 Oct 2006 05:46:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYg5t-0004tG-Sk for ltru@lists.ietf.org; Sat, 14 Oct 2006 11:46:13 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 11:46:13 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 11:46:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 11:38:55 +0200 Organization: Lines: 85 Message-ID: <4530B02F.1687@xyzzy.claranet.de> References: <007601c6ef5c$7e4bbbc0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Ltru] OT: regional affairs (was: Liaison with TC37/SC2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > no travel budget, and no realistic hope of getting one. Apparently you've something much more formally in mind than what I found in RFCs 4052/4053. I don't see why a liaison of this WG should ever be forced to _travel_ somewhere. I thought that LTRU will be disbanded in about six months after 4646bis and 4645bis are published. > I'm deeply disappointed that national origin is being > considered a criterion for choosing a liaison. That's a net-culture thing. A decade ago I was a member of FidoNet, and whatever that might be, it was organized in "zones" roughly mirroring continents, and "regions" roughly mirroring countries, and the outside world (non- Fido) was identified as "rfc822" (among others). Within that organization it was natural that "national origin" was to some degree important, some "zone 2" (EU) folks didn't like the policies from "zone 1" (US/CA), just an example. The US legal system and its traditions can be completely *_alien_* for outsiders (unless they're coming from England). With its ccTLDs ICANN has a similar issue, they've organized some of their support organizations into "regional" groups. I hate this. But I'd also hate it if somebody takes the US legal system with its software patents (example) for granted, a "patented algorithm" is plain nonsense from my POV. And I guess we've all read this (example): ISO also has the same issue, some regional standard bodies, and it's normal that folks with this net-cultural background consider "national origin" as important. That's how their power structure is organized. Same issue for the UN (most obviously), as soon as "regional organization" creeps in it inherits tons of bullshit. But we're used to it, and many alternatives are worse. > I suppose it is that aggressive stance, combined with > misplaced stereotypes, that makes some non-Americans think > we all support our administration. Maybe, but I'd guess it only surprised more folks that all cold war patterns with its fiction of a common transatlantic culture were just that, fictitious. And Europe has its own internal problems to solve - depending on how you count it the last seriously barbarian state of affairs is just over 60 years in the past. Or only 16 years. > I guess the State Department's preference for "Burma" and > "Burmese" over "Myanmar" is a statement of sorts about their > opposition to that country's current leadership. I don't > know what that has to do with the liaison position. Nothing. When I wanted to get rid of such old codes it didn't mean that I'm a fan of the MY-leadership. I only tried to get rid of cruft, as in Harald's big RFC decruft "experiment", and what we have now (with BU registered) was more convincing than the "date of 1766 publication" proposal. For purely technical reasons, BU was in theory valid under 1766 rules. > I tend to think of the Internet and WGs like this as true > melting pots, where I can work with someone for months or > years without regard for their race, age, national origin, > blood type, shoe size, etc. Yes. I needed some months to figure out that [I refuse to say who because it's too embarassing] is a male name. > I do not think I would automatically consider an Irish person > unqualified or inappropriate to be a liaison simply because > they were Irish. Of course not, but it's less than three days ago that I found to my great relieve that Afilias is an Irish company far away from Illinois, see above for a link with some backgrounds. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 07:56:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYi7u-0003ex-6i; Sat, 14 Oct 2006 07:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYi7t-0003em-1G for ltru@lists.ietf.org; Sat, 14 Oct 2006 07:56:25 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYi7p-0006lI-HQ for ltru@lists.ietf.org; Sat, 14 Oct 2006 07:56:25 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYi7e-0000ev-Lk for ltru@lists.ietf.org; Sat, 14 Oct 2006 13:56:10 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 13:56:10 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 13:56:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 13:47:47 +0200 Organization: Lines: 84 Message-ID: <4530CE63.48AE@xyzzy.claranet.de> References: <45304A61.51A3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > If only it were that simple. Okay, apparently I'm alone with the idea that this is only about LTRU, which will be history soon if all goes well. Above the WG level it's either the applications area, or the complete IETF. We've already discussed this on the language subtag review list (but that was about ISO 3166): Country codes normally aren't IETF territory - somebody from ICANN is apparently trying to represent the Internet at large in the 3166-MA. Where that page says "BSI" they might talk about you, and where it says DIN I'd refuse to acknowldege that this person represents my interests just because of a "D". For scripts I found the pages hosted by Unicode, and for obvious reasons that needs no formal relationship (Doug, did you see that there are two new scripts, announced on the Unicode list?) That leaves 639-x as far as the language subtag registry is concerned. And LTRU can't be the counterpart you're looking for. What do you think a liaison with the applications area or with the complete IETF could do ? RFC 4052/4053 are apparently limiting that to "forward document", "receive document", and "say 'thanks'". And then the person on the IETF side of things needs to know which WGs might be affected / interested, and post the received info on their list. For that part it helps to know which WGs exist and what the *meep* they're trying to do. Some former or active ADs and WG Chairs probably know this (e.g. Harald or Scott). > Liaison would be tasked to work in the interests of the > IETF at ISO level, in particular with regard to the > updating of standards and designing of new standards. I guess we can strike "area", what you have in mind is at the IAB level, and that's far away from LTRU (ignoring all minor obstacles like a consensus recognized by Martin or Randy). And what's "the interests of the IETF" wrt 639-x, and why should the IAB dare claim to represent these interests ? Some "candidates" for that task are busy with IDN and EAI [and the IETF desperately needs them there, not elsewhere] > There is lots going on at WG level that IETF should have > knowledge of. I'm lost what that might be, but I'd know where to find it if it's from the W3C: The IETF announce list is too busy to read it completely: In the weeks before an IETF meeting there can be 20 I-Ds announced per day. You could filter it, skip all I-Ds, read only IESG and RFC-editor announcements, with that you get still all RFCs, IETF last calls, new WG charters, etc. You could also read the IETF journal published by ISOC, but that's about the past, the last issue some weeks ago is state of the art IETF 66 (= four months ago): If some part of ISO responsible for 639-x (or more) has something similar please post an URL (text or HTML if possible, no PDF or DOC horror shows... ;-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 08:54:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYj1l-0004pF-I2; Sat, 14 Oct 2006 08:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYj1k-0004m0-8G for ltru@lists.ietf.org; Sat, 14 Oct 2006 08:54:08 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYj1h-0002OS-SB for ltru@lists.ietf.org; Sat, 14 Oct 2006 08:54:08 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004971778.msg for ; Sat, 14 Oct 2006 13:56:25 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sat, 14 Oct 2006 13:54:20 +0100 From: "Debbie Garside" To: "'Marion Gunn'" , Subject: OT RE: [Ltru] Re: Liaison with TC37/SC2 Date: Sat, 14 Oct 2006 13:53:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: Acbuz4+CDVrtIPF+R9+o8kos6q1PfwAvjAuA In-Reply-To: <18824246-DC0C-4D47-B5E5-E98104344337@egt.ie> Message-ID: X-Spam-Processed: mx1.nexbyte.net, Sat, 14 Oct 2006 13:56:25 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sat, 14 Oct 2006 13:56:26 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Marion There are moves afoot within ISO to try to encourage participation from = as many nationalities as possible so I think I know what you are getting at here; it is never a bad thing. However, for me, in this instance, it is about who is the best person for the job and that person IMHO is Doug = Ewell. I am more than a little fed up with all this political correctness we = have in society today. I really do not care whether or not Doug is an = African, one legged lesbian who fits the criteria of today's politically correct madness of inclusion of the minorities at the expense of society in = general just so we can say "aren't we so good". The IETF is an open forum; = anyone can join. If Doug was an African, one legged lesbian I would still = nominate him (or her as he would be) :-) because he is the best man for the job. Best regards Debbie =20 > -----Original Message----- > From: Marion Gunn [mailto:mgunn@egt.ie]=20 > Sent: 13 October 2006 15:54 > To: ltru@lists.ietf.org > Subject: Re: [Ltru] Re: Liaison with TC37/SC2 >=20 > Might I suggest that, as Sue-Ellen (of ANSI, who used to be=20 > an ISO colleague of mine) is an American and SIL (RA for=20 > 639-3) also American and ISO/TC 37/SC 2 already has an=20 > American Chair, we propose some person(s) born in some other=20 > country less under the influence of current US foreign policy=20 > in re territorial/linguistic designations and more eager to=20 > respect more diverse opinions (excluding Austria, because=20 > either 639-1 or 639-2 - whichever! - already has an Austrian=20 > RA, which only supports the other to be under LOC_US=20 > control)? I propose this as someone with an ever-growing=20 > number of US-born friends who feel embarrassed by this=20 > irrational and totally unnecessary push towards monopoly and=20 > who would rather much rather operate professionally in a=20 > freer, less unequal atmosphere (where nobody can blame any=20 > one country, especially _their_ native country, for errors -=20 > and who could blame anyone for desiring that?). > mg >=20 > On 13 Oct 2006, at 08:06, scr=EDobh Frank Ellermann: >=20 > > Debbie Garside wrote: > > > > > >> I propose Doug Ewell as Liaison. > >> > > +1 in > > Or John or Peter (sparing one of them for the opposite direction) >=20 > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 10:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYkPd-0007ht-63; Sat, 14 Oct 2006 10:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYkPc-0007ez-L6 for ltru@lists.ietf.org; Sat, 14 Oct 2006 10:22:52 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYkPa-0004Q3-Cp for ltru@lists.ietf.org; Sat, 14 Oct 2006 10:22:52 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYkPZ-0005VO-SR; Sat, 14 Oct 2006 10:22:49 -0400 Date: Sat, 14 Oct 2006 10:22:49 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Message-ID: <20061014142249.GB2033@ccil.org> References: <45304A61.51A3@xyzzy.claranet.de> <4530CE63.48AE@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4530CE63.48AE@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Debbie Garside wrote: > > > If only it were that simple. > > Okay, apparently I'm alone with the idea that this is only > about LTRU, which will be history soon if all goes well. > > Above the WG level it's either the applications area, or > the complete IETF. What we have here is a failure to communicate. Debbie is speaking of ISO WGs, not IETF WGs. ISO WGs are fairly permanent (they don't expire unless reaped by the parent SubCommittee), and do most of their business in FTF meetings a few times a year (hence the relevance of travel). (The fact that liaisons are accredited to the parent SC is a technicality.) The reason for this is that ISO standards are reviewed every five years to see whether they should be approved as-is, replaced, declared stable, or made obsolete. RFCs on the other hand are always stable by default and are replaced only by explicit action; consequently, IETF WGs are rather transient. So on the level of standardization work, it's hard for the IETF and ISO to liaise, because there is no permanent entity on the IETF side concerned with language tags. On the level of adding code elements to existing standards, the problem is even worse, because the group of people on ietf-languages isn't even part of the IETF as such, so there is nothing for the 639/RA-JAC to liaise with. To make things worse, IETF WGs operate openly and by individuals, ISO WGs confidentially and by countries. It doesn't do Doug that much good to know what's coming down in the ISO WG if he can't talk about it here. "I fear our intellectual differences are an insuperable barrier!" --Tom Stoppard parodying Oscar Wilde -- John Cowan http://ccil.org/~cowan cowan@ccil.org The Penguin shall hunt and devour all that is crufty, gnarly and bogacious; all code which wriggles like spaghetti, or is infested with blighting creatures, or is bound by grave and perilous Licences shall it capture. And in capturing shall it replicate, and in replicating shall it document, and in documentation shall it bring freedom, serenity and most cool froodiness to the earth and all who code therein. --Gospel of Tux _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 13:49:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYndF-0001N9-Ty; Sat, 14 Oct 2006 13:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYndF-0001N4-69 for ltru@ietf.org; Sat, 14 Oct 2006 13:49:09 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYndD-0000GY-VR for ltru@ietf.org; Sat, 14 Oct 2006 13:49:09 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYndC-0003Oe-Kr; Sat, 14 Oct 2006 13:49:06 -0400 Date: Sat, 14 Oct 2006 13:49:06 -0400 To: Addison Phillips Subject: Re: [Ltru] Great Script Debate "the Next Generation"... Message-ID: <20061014174906.GG2033@ccil.org> References: <452555BA.2040601@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <452555BA.2040601@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Reactions? It's jist awfu complicated. On reflection I think we should remove all traces of Suppress-Script from 4646bis and 4645bis as well, and go with text in 2.2.3 like this: 5. There MUST be at most one script subtag in a language tag. 6. A script subtag SHOULD be used if the document is written in a script other than that normally used for the language (i.e. zh-Latn, en-Brai). 7. A script subtag SHOULD be used if the language of the document is customarily written in more than one script (e.g. sr-Cyrl, sr-Latn). 8. A script subtag SHOULD NOT be used if the document being tagged is written in the script normally used for the language (e.g. en-Latn SHOULD NOT be used). And leave it at that. After all, script is one of the most observable properties of a document (people may debate which language a document is written in, but scarcely which script it is written in, and even computers can tell which if the document is Unicoded), so we don't really have to worry about bad script tags, and this advice will warn people off using them unnecessarily. -- One Word to write them all, John Cowan One Access to find them, http://www.ccil.org/~cowan One Excel to count them all, And thus to Windows bind them. --Mike Champion _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 14:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnrn-0003ZW-SX; Sat, 14 Oct 2006 14:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnrl-0003XR-W1 for ltru@ietf.org; Sat, 14 Oct 2006 14:04:10 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYnrj-0002SU-KP for ltru@ietf.org; Sat, 14 Oct 2006 14:04:09 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FJsRp+PQLBkxkBvhN9AGXhTmohdG5UUgeYJWeg2wfNY5KMelVdupj9TN3v2wfXto; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.45] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GYnrg-0000my-MT; Sat, 14 Oct 2006 14:04:04 -0400 Message-ID: <005201c6efbb$c84f4980$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "Sue Ellen Wright" , "christian.galinski@chello.at" , =?iso-8859-1?Q?H=E5vard_Hjulstad?= , "Jennifer DeCamp" References: <000c01c6ee77$e2dea9c0$6501a8c0@DGBP7M81><00aa01c6ee91$44d97b50$6501a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Date: Sat, 14 Oct 2006 11:08:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6655d895f303d948f97dfbf488befd44a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Gerhard Budin , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Sue Ellen Wright" > To: "Doug Ewell" ; "christian.galinski@chello.at" ; "Håvard Hjulstad" ; "Jennifer DeCamp" > Cc: "Gerhard Budin" ; "LTRU Working Group" > Sent: Friday, October 13, 2006 5:00 AM > Subject: [Ltru] Re: Liaison with TC37/SC2 > > Dear colleagues, > I think a formal liaison between TC 37/SC 2 and the IETF/LTRU WG is > essential. There have been many informal discussions over the years because > many of us know each other, but it's really important that the working > relationship be as close and cooperative as possible. (I've just spent a few > hours in the last few days studying the new documents that have been posted > for BCP 47.) I personally am not directly involved in the language code WG, > although I try to track what is happening on all fronts on an ongoing basis. > Not an easy task, actually! Can anyone tell me just what sort of arrangement > if any exists, or do we need to initiate action to establish formal liaison? ... Keep in mind that the IETF ltru WG should cease to exist sometime in early 2007. Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 14:04:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnsU-00048Q-0D; Sat, 14 Oct 2006 14:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnsT-00046o-50 for ltru@ietf.org; Sat, 14 Oct 2006 14:04:53 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYnsR-0002Xe-Nw for ltru@ietf.org; Sat, 14 Oct 2006 14:04:53 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1247762wxc for ; Sat, 14 Oct 2006 11:04:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=r2Z/ZkdG6Za5tNZfJMJbYsjtroavwAfULHerZzOsDOh2RmdkXN4n13KSFGMlWA0oTwOozagZQegRkD9ifq7viLndONRH/rc0vpS4h4MLvFfy4cWwYwQ8djcl9Pj1vh6kKfxGywG6S3Yv4rDogD1AY9I5+OIG6La5H+OwpwdvILU= Received: by 10.90.105.20 with SMTP id d20mr3022069agc; Sat, 14 Oct 2006 11:04:51 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sat, 14 Oct 2006 11:04:51 -0700 (PDT) Message-ID: <30b660a20610141104p5ea6e30cye725c4dd26ebc5bd@mail.gmail.com> Date: Sat, 14 Oct 2006 11:04:51 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Great Script Debate "the Next Generation"... In-Reply-To: <20061014174906.GG2033@ccil.org> MIME-Version: 1.0 References: <452555BA.2040601@yahoo-inc.com> <20061014174906.GG2033@ccil.org> X-Google-Sender-Auth: 0d161c7ff578788b X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0501937285==" Errors-To: ltru-bounces@ietf.org --===============0501937285== Content-Type: multipart/alternative; boundary="----=_Part_32770_15470452.1160849091455" ------=_Part_32770_15470452.1160849091455 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm very much in agreement with this approach. The text needs a few fixes. A language tag can be used to tag content (and not just documents as you have below), or can be used to query content (in which case slightly different conditions apply). And the content may not be written -- and some script tags distinguish unwritten content. And "normally used" is too weak -- someone might interpret that as >= 50% of the time, which would mean not using "Hans", for example, since Hans occurs more frequently than Hant. And using sometimes "customarily" and sometimes "normally" might lead a reader to think that some distinction is meant between them. So here is a suggested rewrite: 5. There MUST be at most one script subtag in a language tag. 6. A script subtag SHOULD be used when tagging content if the content is in a script other than that customarily used for the language (i.e. zh-Latn, en-Brai). 7. A script subtag SHOULD be used when tagging content if the language of the content is customarily written in more than one script (e.g. sr-Cyrl, sr-Latn). 8. A script subtag SHOULD NOT be used if the content being tagged is written in the script customarily used for the vast majority of content in that language (e.g. en-Latn SHOULD NOT be used). Mark On 10/14/06, John Cowan wrote: > > Addison Phillips scripsit: > > > Reactions? > > It's jist awfu complicated. > > On reflection I think we should remove all traces of Suppress-Script > from 4646bis and 4645bis as well, and go with text in 2.2.3 like this: > > 5. There MUST be at most one script subtag in a language tag. > > 6. A script subtag SHOULD be used if the document is written > in a script other than that normally used for the language > (i.e. zh-Latn, en-Brai). > > 7. A script subtag SHOULD be used if the language of the document > is customarily written in more than one script (e.g. sr-Cyrl, > sr-Latn). > > 8. A script subtag SHOULD NOT be used if the document being tagged is > written in the script normally used for the language (e.g. en-Latn > SHOULD NOT be used). > > And leave it at that. > > After all, script is one of the most observable properties of a document > (people may debate which language a document is written in, but scarcely > which script it is written in, and even computers can tell which if the > document is Unicoded), so we don't really have to worry about bad > script tags, and this advice will warn people off using them > unnecessarily. > > -- > One Word to write them all, John Cowan > One Access to find them, http://www.ccil.org/~cowan > One Excel to count them all, > And thus to Windows bind them. --Mike Champion > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_32770_15470452.1160849091455 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm very much in agreement with this approach.

The text needs a few fixes. A language tag can be used to tag content (and not just documents as you have below), or can be used to query content (in which case slightly different conditions apply). And the content may not be written -- and some script tags distinguish unwritten content. And "normally used" is too weak -- someone might interpret that as >= 50% of the time, which would mean not using "Hans", for example, since Hans occurs more frequently than Hant. And using sometimes "customarily" and sometimes "normally" might lead a reader to think that some distinction is meant between them.

So here is a suggested rewrite:

5.  There MUST be at most one script subtag in a language tag.

6.  A script subtag SHOULD be used when tagging content if the content is
   in a script other than that customarily used for the language
   (i.e. zh-Latn, en-Brai).

7.  A script subtag SHOULD be used when tagging content if the language of the content
   is customarily written in more than one script (e.g. sr-Cyrl,
   sr-Latn).

8.  A script subtag SHOULD NOT be used if the content being tagged is written
   in the script customarily used for the vast majority of content in that language
(e.g. en-Latn SHOULD NOT be used).

Mark

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

> Reactions?

<span lang="sco">It's jist awfu complicated.</span>

On reflection I think we should remove all traces of Suppress-Script
from 4646bis and 4645bis as well, and go with text in 2.2.3 like this:

5.  There MUST be at most one script subtag in a language tag.

6.  A script subtag SHOULD be used if the document is written
    in a script other than that normally used for the language
    (i.e. zh-Latn, en-Brai).

7.  A script subtag SHOULD be used if the language of the document
    is customarily written in more than one script (e.g. sr-Cyrl,
    sr-Latn).

8.  A script subtag SHOULD NOT be used if the document being tagged is
    written in the script normally used for the language (e.g. en-Latn
    SHOULD NOT be used).

And leave it at that.

After all, script is one of the most observable properties of a document
(people may debate which language a document is written in, but scarcely
which script it is written in, and even computers can tell which if the
document is Unicoded), so we don't really have to worry about bad
script tags, and this advice will warn people off using them unnecessarily.

--
One Word to write them all,             John Cowan <cowan@ccil.org>
  One Access to find them,              http://www.ccil.org/~cowan
One Excel to count them all,
  And thus to Windows bind them.                --Mike Champion

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

------=_Part_32770_15470452.1160849091455-- --===============0501937285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0501937285==-- From ltru-bounces@ietf.org Sat Oct 14 14:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnse-0004Gk-UP; Sat, 14 Oct 2006 14:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnsd-0004Ge-JP for ltru@lists.ietf.org; Sat, 14 Oct 2006 14:05:03 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYnsZ-0002YL-98 for ltru@lists.ietf.org; Sat, 14 Oct 2006 14:05:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYnsP-0006fm-N7 for ltru@lists.ietf.org; Sat, 14 Oct 2006 20:04:49 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 20:04:49 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 20:04:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 19:39:35 +0200 Organization: Lines: 23 Message-ID: <453120D7.3CB8@xyzzy.claranet.de> References: <45304A61.51A3@xyzzy.claranet.de> <4530CE63.48AE@xyzzy.claranet.de> <20061014142249.GB2033@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Debbie is speaking of ISO WGs, not IETF WGs. ACK, that was clear, I got that from the context. > "I fear our intellectual differences are an insuperable barrier!" It's interesting to dig through historical pages, the JTC1/SC2 liaison was apparently arranged by Brian as IAB Chair in 1996 to get online access on ISO 10646: http://www3.ietf.org/proceedings/96dec/gen/iab96/sld002.htm What's a "convener", something like a Chair or an AD ? I've found the TC37/SC2 page: http://www.iso.org/iso/en/CatalogueListPage.CatalogueList?COMMID=3D1469&scopelist=3DALL 64 CHF for a look into 21 pages of an ISO 639-5 draft, I can see a minor problem here, along the line of "It's dead, Jim". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 15:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYojh-0003Va-O7; Sat, 14 Oct 2006 14:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYojg-0003VV-Q9 for ltru@ietf.org; Sat, 14 Oct 2006 14:59:52 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYoje-0005dR-Ip for ltru@ietf.org; Sat, 14 Oct 2006 14:59:52 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYojd-0005L0-VV; Sat, 14 Oct 2006 14:59:49 -0400 Date: Sat, 14 Oct 2006 14:59:49 -0400 To: Mark Davis Subject: Re: [Ltru] Great Script Debate "the Next Generation"... Message-ID: <20061014185949.GH2033@ccil.org> References: <452555BA.2040601@yahoo-inc.com> <20061014174906.GG2033@ccil.org> <30b660a20610141104p5ea6e30cye725c4dd26ebc5bd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <30b660a20610141104p5ea6e30cye725c4dd26ebc5bd@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > 5. There MUST be at most one script subtag in a language tag. > > 6. A script subtag SHOULD be used when tagging content if the content is > in a script other than that customarily used for the language > (i.e. zh-Latn, en-Brai). > > 7. A script subtag SHOULD be used when tagging content if the language > of > the content > is customarily written in more than one script (e.g. sr-Cyrl, > sr-Latn). > > 8. A script subtag SHOULD NOT be used if the content being tagged is > written > in the script customarily used for the vast majority of content in that > language > (e.g. en-Latn SHOULD NOT be used). -- Híggledy-pìggledy / XML programmers John Cowan Try to escape those / I-eighteen-N woes; http://www.ccil.org/~cowan Incontrovertibly / What we need more of is cowan@ccil.org Unicode weenies and / François Yergeaus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 15:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYokH-00043T-Tm; Sat, 14 Oct 2006 15:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYokG-000404-PE for ltru@ietf.org; Sat, 14 Oct 2006 15:00:28 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYokF-0005g8-If for ltru@ietf.org; Sat, 14 Oct 2006 15:00:28 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYokE-0005MV-Br; Sat, 14 Oct 2006 15:00:26 -0400 Date: Sat, 14 Oct 2006 15:00:26 -0400 To: Randy Presuhn Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Message-ID: <20061014190026.GI2033@ccil.org> References: <005201c6efbb$c84f4980$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005201c6efbb$c84f4980$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Keep in mind that the IETF ltru WG should > cease to exist sometime in early 2007. It may need to be revived in order to handle 639-6, however, when that appears. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 17:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqky-0007aL-5r; Sat, 14 Oct 2006 17:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqkx-0007Zz-AT for ltru@ietf.org; Sat, 14 Oct 2006 17:09:19 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYqkw-00063c-1z for ltru@ietf.org; Sat, 14 Oct 2006 17:09:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061014210913.KVKC18643.mta9.adelphia.net@DGBP7M81> for ; Sat, 14 Oct 2006 17:09:13 -0400 Message-ID: <00ba01c6efd5$00fd4a70$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 14 Oct 2006 14:09:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: Liaison with TC37/SC2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > The information flow is most welcome, but... > Just why would an official liaison relationship be necessary? > > As long as there is some overlap in the participants, and the > necessary information travels where it needs to go, I think we're ok. > Making it an official liaison relationship brings things under BCP 103 > (RFC 4053) which might be a bit heavier-weight than we really need or > want. Sue Ellen and Peter both recommended it. Apparently it is a significant departure from normal procedure to procure these documents other than through a formal liaison. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 17:22:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqxk-0005f0-HF; Sat, 14 Oct 2006 17:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqxj-0005ev-WE for ltru@ietf.org; Sat, 14 Oct 2006 17:22:32 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYqxi-0000Ij-LV for ltru@ietf.org; Sat, 14 Oct 2006 17:22:31 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061014212229.BIRW3369.mta13.adelphia.net@DGBP7M81> for ; Sat, 14 Oct 2006 17:22:29 -0400 Message-ID: <00c601c6efd6$dbd7ca70$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 14 Oct 2006 14:22:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ltru] New scripts (was: Re: Liaison with TC37/SC2) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > (Doug, did you see that there are two new scripts, announced on the > Unicode list?) Yes, I did. I'll be sending Michael a couple of registration forms shortly. I wonder why the forms for CS and ME and RS haven't resulted in a new Registry yet. They were sent to IANA 9 days ago. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 14 20:03:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYtTJ-0002Cg-5J; Sat, 14 Oct 2006 20:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYtTH-0002Cb-Hy for ltru@lists.ietf.org; Sat, 14 Oct 2006 20:03:15 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYtTG-0004Im-BX for ltru@lists.ietf.org; Sat, 14 Oct 2006 20:03:15 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GYtTB-0007aK-5O; Sat, 14 Oct 2006 20:03:09 -0400 Date: Sat, 14 Oct 2006 20:03:09 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Message-ID: <20061015000309.GK2033@ccil.org> References: <45304A61.51A3@xyzzy.claranet.de> <4530CE63.48AE@xyzzy.claranet.de> <20061014142249.GB2033@ccil.org> <453120D7.3CB8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453120D7.3CB8@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > What's a "convener", something like a Chair or an AD ? Could be either: there are conveners at all three levels (Technical Committee or Joint Technical Committee, SubCommittee, and Working Group). > 64 CHF for a look into 21 pages of an ISO 639-5 draft, I can > see a minor problem here, along the line of "It's dead, Jim". That's how ISO stays afloat. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 02:30:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYzVy-0003wy-SQ; Sun, 15 Oct 2006 02:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYzVx-0003ws-Fs for ltru@ietf.org; Sun, 15 Oct 2006 02:30:25 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYzVw-0000WG-5D for ltru@ietf.org; Sun, 15 Oct 2006 02:30:25 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015063023.ROHT3369.mta13.adelphia.net@DGBP7M81> for ; Sun, 15 Oct 2006 02:30:23 -0400 Message-ID: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 14 Oct 2006 23:30:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Disambiguating specific and generic names X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've just learned, from reading the ISO 639-3 FDIS text (Section 4.3), that when a macrolanguage and an individual encompassed language have the same name -- for example, Konkani "kok" and Konkani ""knn" -- they will be suffixed with the strings "(macrolanguage)" and "(individual language)" respectively, not "(macrolanguage)" and BLANK as previously reported. I'll correct the proposed RFC 4646bis Registry to reflect this, and will submit draft-4645bis-01 to internet-drafts shortly. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 03:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ0hO-0004gy-2L; Sun, 15 Oct 2006 03:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ0hM-0004gp-QK for ltru@ietf.org; Sun, 15 Oct 2006 03:46:16 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ0hL-0001nT-HI for ltru@ietf.org; Sun, 15 Oct 2006 03:46:16 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015074614.NKDG2152.mta11.adelphia.net@DGBP7M81> for ; Sun, 15 Oct 2006 03:46:14 -0400 Message-ID: <000901c6f02d$fe9a08a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 15 Oct 2006 00:46:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ltru] Re: Great Script Debate "the Next Generation"... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Warning: micro-editing suggestions follow. Mark Davis wrote: > 5. There MUST be at most one script subtag in a language tag. I think this could be too easily read as "There MUST be one script subtag..." and would prefer turning the sentence around to something like "There MUST NOT be more than one script subtag..." > 6. A script subtag SHOULD be used when tagging content if the content > is in a script other than that customarily used for the language (i.e. > zh-Latn, en-Brai). Would this sentence mean the same, but be more concise, if the words "if the content is" were replaced by "written"? Also, the examples should be marked "e.g." instead of "i.e." > 7. A script subtag SHOULD be used when tagging content if the > language of the content is customarily written in more than one script > (e.g. sr-Cyrl, sr-Latn). Again for conciseness, if we don't need "of the content" in the previous item, we may not need it here. > 8. A script subtag SHOULD NOT be used if the content being tagged is > written in the script customarily used for the vast majority of > content in that language (e.g. en-Latn SHOULD NOT be used). How about "... if the content being tagged is not written (e.g. spoken or sung) or if it is written in the script customarily used..." -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 08:26:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ54I-0002C7-Ag; Sun, 15 Oct 2006 08:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ54H-00029W-7V for ltru@ietf.org; Sun, 15 Oct 2006 08:26:13 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ54E-0006q2-Kx for ltru@ietf.org; Sun, 15 Oct 2006 08:26:13 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50004980305.msg for ; Sun, 15 Oct 2006 13:28:15 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Sun, 15 Oct 2006 13:26:09 +0100 From: "Debbie Garside" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 15 Oct 2006 13:25:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbwLl3UyRn9hSsQSWyJM1rXP62o+wAI/82w In-Reply-To: <000901c6f02d$fe9a08a0$6501a8c0@DGBP7M81> Message-ID: <646FE1F1F4CE49C19438B8212F30CF43.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Sun, 15 Oct 2006 13:28:15 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Sun, 15 Oct 2006 13:28:17 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug wrote: > Mark Davis wrote: > > > 5. There MUST be at most one script subtag in a language tag. > > I think this could be too easily read as "There MUST be one > script subtag..." and would prefer turning the sentence > around to something like "There MUST NOT be more than one > script subtag..." I agree with Doug re Mark's wording but would suggest the following: ---- 6. No more than one script subtag may be used in a language tag. ---- Or ---- 6. Script sub tags are limited to one per language tag. ---- > > 8. A script subtag SHOULD NOT be used if the content being > tagged is > > written in the script customarily used for the vast majority of > > content in that language (e.g. en-Latn SHOULD NOT be used). > > How about "... if the content being tagged is not written > (e.g. spoken or sung) or if it is written in the script > customarily used..." Suggestion: ---- 8. A script subtag SHOULD NOT be used where the majority of content is customarily written in one script (e.g. en-Latn SHOULD NOT be used) or where the item being tagged is not written (e.g. spoken content). ---- Debbie > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 15 October 2006 08:46 > To: LTRU Working Group > Subject: [Ltru] Re: Great Script Debate "the Next Generation"... > > Warning: micro-editing suggestions follow. > > Mark Davis wrote: > > > 5. There MUST be at most one script subtag in a language tag. > > I think this could be too easily read as "There MUST be one > script subtag..." and would prefer turning the sentence > around to something like "There MUST NOT be more than one > script subtag..." > > > 6. A script subtag SHOULD be used when tagging content if > the content > > is in a script other than that customarily used for the > language (i.e. > > zh-Latn, en-Brai). > > Would this sentence mean the same, but be more concise, if > the words "if the content is" were replaced by "written"? > > Also, the examples should be marked "e.g." instead of "i.e." > > > 7. A script subtag SHOULD be used when tagging content if the > > language of the content is customarily written in more than > one script > > (e.g. sr-Cyrl, sr-Latn). > > Again for conciseness, if we don't need "of the content" in > the previous item, we may not need it here. > > > 8. A script subtag SHOULD NOT be used if the content being > tagged is > > written in the script customarily used for the vast majority of > > content in that language (e.g. en-Latn SHOULD NOT be used). > > How about "... if the content being tagged is not written > (e.g. spoken or sung) or if it is written in the script > customarily used..." > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * > UTN #14 http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 13:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZA5u-0006bi-LB; Sun, 15 Oct 2006 13:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZA5t-0006Zs-Ku for ltru@ietf.org; Sun, 15 Oct 2006 13:48:13 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZA5s-0008Di-6n for ltru@ietf.org; Sun, 15 Oct 2006 13:48:13 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1421436wxc for ; Sun, 15 Oct 2006 10:48:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=g1G+UIucM257r/7Dij3W3C2yJELPSy8GYsP0FQOr8bf+QuhGtLyRiqJZi7MK9LiA8sI2tpKN0xeYXjEapbF4JNwRDvwQ8u9l8udMnhGtNGWBPLCFPT8C2savUzCUchBAUmTSfzss9UxnmvTq+mLE0tURmlb8or8553Q2OaMWRBI= Received: by 10.90.94.2 with SMTP id r2mr3099458agb; Sun, 15 Oct 2006 10:48:09 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 15 Oct 2006 10:48:09 -0700 (PDT) Message-ID: <30b660a20610151048l2ebdf58dxaac4d0eb3b71f93a@mail.gmail.com> Date: Sun, 15 Oct 2006 10:48:09 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <000901c6f02d$fe9a08a0$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <000901c6f02d$fe9a08a0$6501a8c0@DGBP7M81> X-Google-Sender-Auth: 1aef42cc3372756c X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1382477792==" Errors-To: ltru-bounces@ietf.org --===============1382477792== Content-Type: multipart/alternative; boundary="----=_Part_41434_2840832.1160934489004" ------=_Part_41434_2840832.1160934489004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/15/06, Doug Ewell wrote: > > Warning: micro-editing suggestions follow. > > Mark Davis wrote: > > > 5. There MUST be at most one script subtag in a language tag. > > I think this could be too easily read as "There MUST be one script > subtag..." and would prefer turning the sentence around to something > like "There MUST NOT be more than one script subtag..." agreed > 6. A script subtag SHOULD be used when tagging content if the content > > is in a script other than that customarily used for the language (i.e. > > zh-Latn, en-Brai). > > Would this sentence mean the same, but be more concise, if the words "if > the content is" were replaced by "written"? I was trying to avoid the use of written -- since the script Zxxx could be being used for unwritten material (see below). Also, the examples should be marked "e.g." instead of "i.e." agreed > 7. A script subtag SHOULD be used when tagging content if the > > language of the content is customarily written in more than one script > > (e.g. sr-Cyrl, sr-Latn). > > Again for conciseness, if we don't need "of the content" in the previous > item, we may not need it here. Actually, for precision, I think we should put it in both places. > 8. A script subtag SHOULD NOT be used if the content being tagged is > > written in the script customarily used for the vast majority of > > content in that language (e.g. en-Latn SHOULD NOT be used). > > How about "... if the content being tagged is not written (e.g. spoken > or sung) or if it is written in the script customarily used..." Because of edge cases, I think we need to settle on the usage first. Let's suppose I have the following cases of content, where we follow SHOULDs, and show what it could be tagged with (with varying degrees of specificity): 1. American English, written in Latin. en en-US 2. American English, written in Cyrillic (don't laugh; a collegue of mine has a printed ad in this.) en en-US en-Cyrl en-Cyrl-US 3. American English, only spoken -- no written content en en-US en-Zxxx en-Zxxx-US 4. American English in a video, some parts spoken, and with Cyrllic subtitles. In protocols limited to a single language, this is now limited to: en en-US If a protocol allows tagging with multiple languages, then it could have any of the combinations of #2 & #3. -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_41434_2840832.1160934489004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/15/06, Doug Ewell <dewell@adelphia.net> wrote:
Warning: micro-editing suggestions follow.

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> 5.  There MUST be at most one script subtag in a language tag.

I think this could be too easily read as "There MUST be one script
subtag..." and would prefer turning the sentence around to something
like "There MUST NOT be more than one script subtag..."

agreed

> 6.  A script subtag SHOULD be used when tagging content if the content
> is in a script other than that customarily used for the language (i.e.
> zh-Latn, en-Brai).

Would this sentence mean the same, but be more concise, if the words "if
the content is" were replaced by "written"?

I was trying to avoid the use of written -- since the script Zxxx could be being used for unwritten material (see below).

Also, the examples should be marked "e.g." instead of "i.e."

agreed

> 7.  A script subtag SHOULD be used when tagging content if the
> language of the content is customarily written in more than one script
> (e.g. sr-Cyrl, sr-Latn).

Again for conciseness, if we don't need "of the content" in the previous
item, we may not need it here.

Actually, for precision, I think we should put it in both places.

> 8.  A script subtag SHOULD NOT be used if the content being tagged is
> written in the script customarily used for the vast majority of
> content in that language (e.g. en-Latn SHOULD NOT be used).

How about "... if the content being tagged is not written (e.g. spoken
or sung) or if it is written in the script customarily used..."

Because of edge cases, I think we need to settle on the usage first. Let's suppose I have the following cases of content, where we follow SHOULDs, and show what it could be tagged with (with varying degrees of specificity):

1. American English, written in Latin.
en
en-US

2. American English, written in Cyrillic (don't laugh; a collegue of mine has a printed ad in this.)
en
en-US
en-Cyrl
en-Cyrl-US

3. American English, only spoken -- no written content
en
en-US
en-Zxxx
en-Zxxx-US

4. American English in a video, some parts spoken, and with Cyrllic subtitles. In protocols limited to a single language, this is now limited to:

en
en-US

If a protocol allows tagging with multiple languages, then it could have any of the combinations of #2 & #3.

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


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

------=_Part_41434_2840832.1160934489004-- --===============1382477792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1382477792==-- From ltru-bounces@ietf.org Sun Oct 15 14:07:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAOf-00087w-9k; Sun, 15 Oct 2006 14:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAOe-00087g-1G for ltru@ietf.org; Sun, 15 Oct 2006 14:07:36 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAOc-0002LV-Lz for ltru@ietf.org; Sun, 15 Oct 2006 14:07:36 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1424226wxc for ; Sun, 15 Oct 2006 11:07:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RFx1o8kQNH/BRlz03vNokei/FzecBkhwkmOGOjHsObN2s1wbn0+P8pF1Bi3sG/VJxLrLogWraaXs0gWTSBGZPrXOkKdL+kc2fXWqfcTONrzxkyMz+bxe7h/VzbeUn4gUz7z1q8AE60RWffQ6gRM3MNV7J3Z0SknW/nckw6d1Wok= Received: by 10.90.90.3 with SMTP id n3mr3107514agb; Sun, 15 Oct 2006 11:07:34 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 15 Oct 2006 11:07:33 -0700 (PDT) Message-ID: <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> Date: Sun, 15 Oct 2006 11:07:33 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Disambiguating specific and generic names In-Reply-To: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> X-Google-Sender-Auth: e24026f76f5a4843 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1116877187==" Errors-To: ltru-bounces@ietf.org --===============1116877187== Content-Type: multipart/alternative; boundary="----=_Part_41554_13100685.1160935653846" ------=_Part_41554_13100685.1160935653846 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't see why that is necessary. The registry has the tag extlang, which tells us that knn is Konkani as an individual language. We hardly need a paranthetical to do that, because we have extlang. %% Type: extlang Subtag: knn Description: Konkani Added: 2007-01-01 Prefix: kok Formally, also, the second description line in the following is unnecessary: %% Type: language Subtag: kok Description: Konkani Description: Konkani (macrolanguage) Added: 2005-10-16 Suppress-Script: Deva I can tell that kok is Konkani as a macrolanguage simply by the fact that it is the prefix of some extlang (such as knn) in the repository. Mark On 10/14/06, Doug Ewell wrote: > > I've just learned, from reading the ISO 639-3 FDIS text (Section 4.3), > that when a macrolanguage and an individual encompassed language have > the same name -- for example, Konkani "kok" and Konkani ""knn" -- they > will be suffixed with the strings "(macrolanguage)" and "(individual > language)" respectively, not "(macrolanguage)" and BLANK as previously > reported. > > I'll correct the proposed RFC 4646bis Registry to reflect this, and will > submit draft-4645bis-01 to internet-drafts shortly. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_41554_13100685.1160935653846 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't see why that is necessary. The registry has the tag extlang, which tells us that knn is Konkani as an individual language. We hardly need a paranthetical to do that, because we have extlang.
%%
Type: extlang

Subtag: knn
Description: Konkani
Added: 2007-01-01
Prefix: kok

Formally, also, the second description line in the following is unnecessary:
%%
Type: language
Subtag: kok
Description: Konkani

Description: Konkani (macrolanguage)
Added: 2005-10-16
Suppress-Script: Deva
I can tell that kok is Konkani as a macrolanguage simply by the fact that it is the prefix of some extlang (such as knn) in the repository.

Mark

On 10/14/06, Doug Ewell <dewell@adelphia.net> wrote:
I've just learned, from reading the ISO 639-3 FDIS text (Section 4.3),
that when a macrolanguage and an individual encompassed language have
the same name -- for example, Konkani "kok" and Konkani ""knn" -- they
will be suffixed with the strings "(macrolanguage)" and "(individual
language)" respectively, not "(macrolanguage)" and BLANK as previously
reported.

I'll correct the proposed RFC 4646bis Registry to reflect this, and will
submit draft-4645bis-01 to internet-drafts shortly.

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


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

------=_Part_41554_13100685.1160935653846-- --===============1116877187== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1116877187==-- From ltru-bounces@ietf.org Sun Oct 15 14:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAZN-0006X5-AH; Sun, 15 Oct 2006 14:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZAZL-0006X0-RT for ltru@ietf.org; Sun, 15 Oct 2006 14:18:39 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZAZJ-0003uC-Kk for ltru@ietf.org; Sun, 15 Oct 2006 14:18:39 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GZAZJ-0002sB-67; Sun, 15 Oct 2006 14:18:37 -0400 Date: Sun, 15 Oct 2006 14:18:37 -0400 To: Mark Davis Subject: Re: [Ltru] Disambiguating specific and generic names Message-ID: <20061015181837.GA14126@ccil.org> References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I don't see why that is necessary. The registry has the tag extlang, > which tells us that knn is Konkani as an individual language. We hardly > need a paranthetical to do that, because we have extlang. The point here is to track 639-3 in the Description fields. > I can tell that kok is Konkani as a macrolanguage simply by the fact > that it > is the prefix of some extlang (such as knn) in the repository. In fact, you can't reliably do so, because encompassed languages that have their own 639-2 tags (e.g. sr) are given language subtags, not extlang subtags. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Half the lies they tell about me are true. -- Tallulah Bankhead, American actress _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 14:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZBCe-0003jR-0r; Sun, 15 Oct 2006 14:59:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZBCc-0003i6-8z for ltru@ietf.org; Sun, 15 Oct 2006 14:59:14 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZBCb-0002PC-00 for ltru@ietf.org; Sun, 15 Oct 2006 14:59:14 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1432282wxc for ; Sun, 15 Oct 2006 11:59:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CVGpY7t87fWa7QqaaIqNUYtWQxHkzGkxz9CsLmDxmC73VX2343hITsb07Zyl8ce7HDvvFXrgIihpg1pHJvG4TkvdcbLsd8rLlVs9Z1PMEnzKz0Dlx3ncctGGF3RRTWiJsija2VSlLvouWkXVGl0YhNUJs/Y1l41b4b8mh8P2wzg= Received: by 10.90.71.12 with SMTP id t12mr3164299aga; Sun, 15 Oct 2006 11:59:12 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 15 Oct 2006 11:59:12 -0700 (PDT) Message-ID: <30b660a20610151159y4ca958cbq67618310604fa7c0@mail.gmail.com> Date: Sun, 15 Oct 2006 11:59:12 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Disambiguating specific and generic names In-Reply-To: <20061015181837.GA14126@ccil.org> MIME-Version: 1.0 References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <20061015181837.GA14126@ccil.org> X-Google-Sender-Auth: 25b7a615b40f3ac3 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0103617021==" Errors-To: ltru-bounces@ietf.org --===============0103617021== Content-Type: multipart/alternative; boundary="----=_Part_41694_5674050.1160938752545" ------=_Part_41694_5674050.1160938752545 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Functionally in the registry, X is a macrolanguage iff it has at least one extlang. Macrolanguages that don't have any extlangs behave precisely the same as non-macro languages, so as far as the registry is concerned there is no functional difference. So the only issue is whether there could be confusion between two language tags (not including extlangs) that would be cleared up by adding the extra paranthetical to one of them that it is a macro language. So you might look to see if there are any such cases. Mark On 10/15/06, John Cowan wrote: > > Mark Davis scripsit: > > > I don't see why that is necessary. The registry has the tag extlang, > > which tells us that knn is Konkani as an individual language. We hardly > > need a paranthetical to do that, because we have extlang. > > The point here is to track 639-3 in the Description fields. > > > I can tell that kok is Konkani as a macrolanguage simply by the fact > > that it > > is the prefix of some extlang (such as knn) in the repository. > > In fact, you can't reliably do so, because encompassed languages > that have their own 639-2 tags (e.g. sr) are given language subtags, > not extlang subtags. > > -- > John Cowan cowan@ccil.org http://ccil.org/~cowan > Half the lies they tell about me are true. > -- Tallulah Bankhead, American actress > ------=_Part_41694_5674050.1160938752545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Functionally in the registry, X is a macrolanguage iff it has at least one extlang. Macrolanguages that don't have any extlangs behave precisely the same as non-macro languages, so as far as the registry is concerned there is no functional difference.

So the only issue is whether there could be confusion between two language tags (not including extlangs) that would be cleared up by adding the extra paranthetical to one of them that it is a macro language. So you might look to see if there are any such cases.

Mark

On 10/15/06, John Cowan <cowan@ccil.org> wrote:
Mark Davis scripsit:

> I don't see why that is necessary. The registry has the tag extlang,
> which tells us that knn is Konkani as an individual language. We hardly
> need a paranthetical to do that, because we have extlang.

The point here is to track 639-3 in the Description fields.

> I can tell that kok is Konkani as a macrolanguage simply by the fact
> that it
> is the prefix of some extlang (such as knn) in the repository.

In fact, you can't reliably do so, because encompassed languages
that have their own 639-2 tags (e.g. sr) are given language subtags,
not extlang subtags.

--
John Cowan     cowan@ccil.org    http://ccil.org/~cowan
Half the lies they tell about me are true.
        -- Tallulah Bankhead, American actress

------=_Part_41694_5674050.1160938752545-- --===============0103617021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0103617021==-- From ltru-bounces@ietf.org Sun Oct 15 15:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZBfc-0005W9-AN; Sun, 15 Oct 2006 15:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZBfa-0005W4-Jr for ltru@ietf.org; Sun, 15 Oct 2006 15:29:10 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZBfZ-0006kJ-Dt for ltru@ietf.org; Sun, 15 Oct 2006 15:29:10 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GZBfX-00054h-1P; Sun, 15 Oct 2006 15:29:07 -0400 Date: Sun, 15 Oct 2006 15:29:07 -0400 To: Mark Davis Subject: Re: [Ltru] Disambiguating specific and generic names Message-ID: <20061015192906.GB14126@ccil.org> References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <20061015181837.GA14126@ccil.org> <30b660a20610151159y4ca958cbq67618310604fa7c0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610151159y4ca958cbq67618310604fa7c0@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Functionally in the registry, X is a macrolanguage iff it has at least > one extlang. Syntactically, yes. Semantically, no. -- BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 15:48:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZByC-0007Un-VP; Sun, 15 Oct 2006 15:48:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZByB-0007T1-Hb for ltru@ietf.org; Sun, 15 Oct 2006 15:48:23 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZByA-0000sc-9k for ltru@ietf.org; Sun, 15 Oct 2006 15:48:23 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1439993wxc for ; Sun, 15 Oct 2006 12:48:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ekQ1JcIxwvS7vuOYC2Tbi60nXzmgR2qTflZmMBBxbakz5pvuGWvdVxyyE1wxz1ZWrxu8y6UOB2+ahBCgGWVCcSAexfyjkQ4hB4bU5EWmfbhP/1rZz56jC34UJzY3sTYL4Xt22OkfM3GEF7vMljItBLZPWR+u3HWo9z2rpV8EQls= Received: by 10.90.49.19 with SMTP id w19mr3158882agw; Sun, 15 Oct 2006 12:48:21 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 15 Oct 2006 12:48:21 -0700 (PDT) Message-ID: <30b660a20610151248x7fcd675fiadf008d0ea4232d0@mail.gmail.com> Date: Sun, 15 Oct 2006 12:48:21 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Disambiguating specific and generic names In-Reply-To: <20061015192906.GB14126@ccil.org> MIME-Version: 1.0 References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <20061015181837.GA14126@ccil.org> <30b660a20610151159y4ca958cbq67618310604fa7c0@mail.gmail.com> <20061015192906.GB14126@ccil.org> X-Google-Sender-Auth: adae7f169eccefb2 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678147521==" Errors-To: ltru-bounces@ietf.org --===============0678147521== Content-Type: multipart/alternative; boundary="----=_Part_41830_2927356.1160941701532" ------=_Part_41830_2927356.1160941701532 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The only way the semantics play a role is, as I said, if they serve to disambiguate two entries. If you think this information is necessary, it would be useful to find a case where it does, in fact, disambiguate. Otherwise it is unnecessary in the registry. There is *lots* of information about languages out in the world -- we just need to focus on the information that is necessary for the registry itself. Mark On 10/15/06, John Cowan wrote: > > Mark Davis scripsit: > > > Functionally in the registry, X is a macrolanguage iff it has at least > > one extlang. > > Syntactically, yes. Semantically, no. > > -- > BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org > BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan > ------=_Part_41830_2927356.1160941701532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The only way the semantics play a role is, as I said, if they serve to disambiguate two entries. If you think this information is necessary, it would be useful to find a case where it does, in fact, disambiguate. Otherwise it is unnecessary in the registry. There is *lots* of information about languages out in the world -- we just need to focus on the information that is necessary for the registry itself.

Mark

On 10/15/06, John Cowan <cowan@ccil.org> wrote:
Mark Davis scripsit:

> Functionally in the registry, X is a macrolanguage iff it has at least
> one extlang.

Syntactically, yes.  Semantically, no.

--
BALIN FUNDINUL          UZBAD KHAZADDUMU         cowan@ccil.org
BALIN SON OF FUNDIN     LORD OF KHAZAD-DUM      http://www.ccil.org/~cowan

------=_Part_41830_2927356.1160941701532-- --===============0678147521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0678147521==-- From ltru-bounces@ietf.org Sun Oct 15 16:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZCTd-0001Hp-Cs; Sun, 15 Oct 2006 16:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZCTc-0001Hi-0w for ltru@ietf.org; Sun, 15 Oct 2006 16:20:52 -0400 Received: from [80.76.149.212] (helo=ch-smtp01.sth.basefarm.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZCTa-0005TY-EV for ltru@ietf.org; Sun, 15 Oct 2006 16:20:52 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:63012 helo=chalmers95a69n) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GZCTQ-0004sc-5C for ltru@ietf.org; Sun, 15 Oct 2006 22:20:43 +0200 From: "Kent Karlsson" To: Subject: RE: [Ltru] Disambiguating specific and generic names Date: Sun, 15 Oct 2006 22:15:54 +0200 Message-ID: <004701c6f096$baeca770$6500a8c0@chalmers95a69n> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <30b660a20610151248x7fcd675fiadf008d0ea4232d0@mail.gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GZCTQ-0004sc-5C. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1GZCTQ-0004sc-5C acfa9c98d587f25a43652109154cc8c0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0393557590==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0393557590== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C6F0A7.7E7884B0" This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C6F0A7.7E7884B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I still hope that 639-3 will not use "(specific)"/"(macrolanguage)" or = similar parentheticals, but rather along the line of adding "Standard" (or similar) where necessary to = bring clarity to the names. =20 B.t.w, I find it strange that zne Zande (Standard Zande?) is = regarded as a "(specific)" language, while znd Zande is regarded as a "collective" language code, = not a macrolanguage code. =20 /kent k =20 -----Original Message----- From: Mark Davis [mailto:mark.davis@icu-project.org]=20 Sent: Sunday, October 15, 2006 9:48 PM To: John Cowan Cc: ltru@ietf.org Subject: Re: [Ltru] Disambiguating specific and generic names The only way the semantics play a role is, as I said, if they serve to = disambiguate two entries. If you think this information is necessary, it = would be useful to find a case where it does, in fact, disambiguate. = Otherwise it is unnecessary in the registry. There is *lots* of = information about languages out in the world -- we just need to focus on = the information that is necessary for the registry itself.=20 Mark On 10/15/06, John Cowan wrote:=20 Mark Davis scripsit: > Functionally in the registry, X is a macrolanguage iff it has at least > one extlang. Syntactically, yes. Semantically, no. -- BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org BALIN SON OF FUNDIN LORD OF KHAZAD-DUM = http://www.ccil.org/~cowan ------=_NextPart_000_0048_01C6F0A7.7E7884B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message
I still hope that 639-3 will not use=20 "(specific)"/"(macrolanguage)" or similar parentheticals, but=20 rather
along the = line of adding=20 "Standard" (or similar) where necessary to bring clarity to the=20 names.
 
B.t.w, I = find it strange=20 that    zne Zande     (Standard = Zande?) is=20 regarded as a "(specific)" language,
while       = znd = Zande    =20  is regarded as a "collective" language code, not a macrolanguage=20 code.
 
       =20 /kent k
 
-----Original Message-----
From: Mark = Davis=20 [mailto:mark.davis@icu-project.org]
Sent: Sunday, October = 15, 2006=20 9:48 PM
To: John Cowan
Cc:=20 ltru@ietf.org
Subject: Re: [Ltru] Disambiguating specific = and=20 generic names

The only way the semantics play a = role is,=20 as I said, if they serve to disambiguate two entries. If you think = this=20 information is necessary, it would be useful to find a case where it = does, in=20 fact, disambiguate. Otherwise it is unnecessary in the registry. There = is=20 *lots* of information about languages out in the world -- we just need = to=20 focus on the information that is necessary for the registry itself.=20

Mark

On 10/15/06, John=20 Cowan <cowan@ccil.org> = wrote:
Mark=20 Davis scripsit:

> Functionally in the registry, X is a=20 macrolanguage iff it has at least
> one = extlang.

Syntactically,=20 yes.  Semantically, no.

--
BALIN=20 = FUNDINUL          UZBAD= =20 KHAZADDUMU         cowan@ccil.org
BALIN SON OF=20 FUNDIN     LORD OF=20 KHAZAD-DUM      http://www.ccil.org/~cowan

------=_NextPart_000_0048_01C6F0A7.7E7884B0-- --===============0393557590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0393557590==-- From ltru-bounces@ietf.org Sun Oct 15 18:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZEqU-00087c-JG; Sun, 15 Oct 2006 18:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZEqT-00086l-60 for ltru@ietf.org; Sun, 15 Oct 2006 18:52:37 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZEqP-0000iM-IH for ltru@ietf.org; Sun, 15 Oct 2006 18:52:37 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1468841wxc for ; Sun, 15 Oct 2006 15:52:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=OHq6Nbb3EEPRJ02kYOSI0pwgGzI/4LHTSth2Y6J75MUOCBGd0QrNEpQGi/MQvHHGVbmaKZyrWHxw2pVK5M0HMXv/7EAzHmeCtGJ8KQDTjXCreY7zVRw6pQJhRG56P8i5ux09FZP3aJXWLMHZIuBmPJyDtDRW9qP5ulM/QVam5hA= Received: by 10.90.93.6 with SMTP id q6mr3168490agb; Sun, 15 Oct 2006 15:52:32 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 15 Oct 2006 15:52:32 -0700 (PDT) Message-ID: <30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> Date: Sun, 15 Oct 2006 15:52:32 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: Registry deltas In-Reply-To: <6.0.0.20.2.20061009180149.06995380@localhost> MIME-Version: 1.0 References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> <30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com> <6.0.0.20.2.20061009180149.06995380@localhost> X-Google-Sender-Auth: 44f50cc221830e2c X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574589737==" Errors-To: ltru-bounces@ietf.org --===============1574589737== Content-Type: multipart/alternative; boundary="----=_Part_42462_20217264.1160952752319" ------=_Part_42462_20217264.1160952752319 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We need to reach consensus on this. I see two basic options. A. Allow inverted names with commas, but otherwise no commas (outside of parentheticals). For consistency, also invert all the other names that could reasonably be inverted. ALLOW: Description: Ambae, West REPLACE Description: Naga, Maring WITH Description: Naga; Maring REPLACE Description: Northern Sotho WITH Description: Sotho, Northern B. Disallow inverted names. REPLACE: Description: Ambae, West WITH: Description: West Ambae REPLACE Description: Naga, Maring WITH Description: Naga; Maring Note: I think the suggestion to uniformally use ";" as a separator between different names is a good one, so I've done that with both options above. I did a quick & dirty dump of all description names containing ",", and toke a shot at how option B would look for the 5% or so of the cases. These are just my initial take -- that's the problem with the current names, they are a hodgepodge when it comes to this issue! FIX THE INVERSION Slavic, Church => Church Slavic Greek, Modern => Modern Greek Frisian, Northern => Northern Frisian Frisian, Western => Western Frisian Ndebele, North => North Ndebele Ndebele, South => South Ndebele Sotho, Southern => Southern Sotho Arára, Pará => Pará Arára Abnaki, Eastern => Eastern Abnaki Abnaki, Western => Western Abnaki Acipa, Eastern => Eastern Acipa Pashayi, Northeast => Northeast Pashayi Arrernte, Eastern => Eastern Arrernte Achí, Cubulco => Cubulco Achí Achí, Rabinal => Rabinal Achí Agta, Isarog => Isarog Agta Agta, Central Cagayan => Central Cagayan Agta Agta, Remontado => Remontado Agta Alta, Southern => Southern Alta Agta, Mt. Iriga => Mt. Iriga Agta Aizi, Tiagbamrin => Tiagbamrin Aizi Aizi, Mobumrin => Mobumrin Aizi Aizi, Aproumu => Aproumu Aizi Altai, Southern => Southern Altai Amami-Oshima, Southern => Southern Amami-Oshima English, Old => Old English Apache, Jicarilla => Jicarilla Apache Apache, Kiowa => Kiowa Apache Apache, Lipan => Lipan Apache Apache, Mescalero-Chiricahua => Mescalero-Chiricahua Apache Apache, Western => Western Apache Alta, Northern => Northern Alta Arrarnta, Western => Western Arrarnta Atta, Pudtol => Pudtol Atta Atta, Pamplona => Pamplona Atta Altai, Northern => Northern Altai Acipa, Western => Western Acipa Awyu, South => South Awyu Awyu, Central => Central Awyu Awyu, Jair => Jair Awyu Awyu, Edera => Edera Awyu Arára, Mato Grosso => Mato Grosso Arára Armenian, Middle => Middle Armenian Ayta, Sorsogon => Sorsogon Ayta Ayta, Bataan => Bataan Ayta Ayta, Tayabas => Tayabas Ayta Amuzgo, San Pedro Amuzgos => San Pedro Amuzgos Amuzgo Amuzgo, Ipalapa => Ipalapa Amuzgo CHANGE TO SEMI-COLON Yi, Sichuan => Yi; Sichuan Ayta, Ambala => Ayta; Ambala Agta, Camarines Norte => Agta; Camarines Norte Ayta, Abenlen => Ayta; Abenlen Malay, Ambonese => Malay; Ambonese Adi, Galo => Adi; Galo Tibetan, Amdo => Tibetan; Amdo Amis, Nataoran => Amis; Nataoran Amuzgo, Guerrero => Amuzgo; Guerrero Arapesh, Bumbita => Arapesh; Bumbita Asmat, Casuarina Coast => Asmat; Casuarina Coast Asuriní, Xingú => Asuriní; Xingú Asmat, Yaosakor => Asmat; Yaosakor Manobo, Ata => Manobo; Ata One, Molmo => One; Molmo Gbe, Ayizo => Gbe; Ayizo Atta, Faire => Atta; Faire Nahuatl, Highland Puebla => Nahuatl; Highland Puebla Kayan, Busang => Kayan; Busang Birifor, Malba => Birifor; Malba Pahari, Mahasu => Pahari; Mahasu Bareli, Rathwi => Bareli; Rathwi Chin, Bawm => Chin; Bawm Béte, Guiberoua => Béte; Guiberoua Bété, Daloa => Bété; Daloa Bareli, Pauri => Bareli; Pauri Itneg, Banao => Itneg; Banao Sorsogon, Masbate => Sorsogon; Masbate Karen, Pa'o => Karen; Pa'o Ayta, Mag-Indi => Ayta; Mag-Indi Kanuri, Bilma => Kanuri; Bilma ... NOTE As I was doing this, I saw the following. It may be perfectly fine, but it looks a bit suspicious, especially since there are a bunch of "Atga" entries with different modifiers. Could this be a spelling error? Agta, Mt. Iraya Mark On 10/9/06, Martin Duerst wrote: > > [co-chair hat off] > > At 02:22 06/10/03, Mark Davis wrote: > >Overall, I think inverted names are a bad idea. They are rather > anglocentric, and we find that translators often do the wrong thing with > them. They are also hugely inconsistent in the current registry. > > > >I think they are tolerable if (a) every single instance of a comma > indicates an inverted name, and (b) all names are consistently inverted. > Because of (a) one could programmatically fix the names to the correct > value. > > I don't think creating artificial syntax rules or some > kind of restricted (English) grammar for Description fields > is appropriate. What I can immagine is that we use semicolons > rather than commas to indicate boundaries between input > from different origins. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > ------=_Part_42462_20217264.1160952752319 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We need to reach consensus on this. I see two basic options.

A. Allow inverted names with commas, but otherwise no commas (outside of parentheticals). For consistency, also invert all the other names that could reasonably be inverted. 
ALLOW: Description: Ambae, West

REPLACE Description: Naga, Maring
WITH Description: Naga; Maring

REPLACE Description: Northern Sotho
WITH Description: Sotho, Northern

B. Disallow inverted names. 
REPLACE: Description: Ambae, West
WITH: Description: West Ambae

REPLACE Description: Naga, Maring
WITH Description: Naga; Maring

Note: I think the suggestion to uniformally use ";" as a separator between different names is a good one, so I've done that with both options above.

I did a quick & dirty dump of all description names containing ",", and toke a shot at how option B would look for the 5% or so of the cases. These are just my initial take -- that's the problem with the current names, they are a hodgepodge when it comes to this issue!

FIX THE INVERSION

Slavic, Church    =>    Church Slavic
Greek, Modern    =>    Modern Greek
Frisian, Northern    =>    Northern Frisian
Frisian, Western    =>    Western Frisian
Ndebele, North    =>    North Ndebele
Ndebele, South    =>    South Ndebele
Sotho, Southern    =>    Southern Sotho
Ar&#xE1;ra, Par&#xE1;    =>    Par&#xE1; Ar&#xE1;ra
Abnaki, Eastern    =>    Eastern Abnaki
Abnaki, Western    =>    Western Abnaki
Acipa, Eastern    =>    Eastern Acipa
Pashayi, Northeast    =>    Northeast Pashayi
Arrernte, Eastern    =>    Eastern Arrernte
Ach&#xED;, Cubulco    =>    Cubulco Ach&#xED;
Ach&#xED;, Rabinal    =>    Rabinal Ach&#xED;
Agta, Isarog    =>    Isarog Agta
Agta, Central Cagayan    =>    Central Cagayan Agta
Agta, Remontado    =>    Remontado Agta
Alta, Southern    =>    Southern Alta
Agta, Mt. Iriga    =>    Mt. Iriga Agta
Aizi, Tiagbamrin    =>    Tiagbamrin Aizi
Aizi, Mobumrin    =>    Mobumrin Aizi
Aizi, Aproumu    =>    Aproumu Aizi
Altai, Southern    =>    Southern Altai
Amami-Oshima, Southern    =>    Southern Amami-Oshima
English, Old    =>    Old English
Apache, Jicarilla    =>    Jicarilla Apache
Apache, Kiowa    =>    Kiowa Apache
Apache, Lipan    =>    Lipan Apache
Apache, Mescalero-Chiricahua    =>    Mescalero-Chiricahua Apache
Apache, Western    =>    Western Apache
Alta, Northern    =>    Northern Alta
Arrarnta, Western    =>    Western Arrarnta
Atta, Pudtol    =>    Pudtol Atta
Atta, Pamplona    =>    Pamplona Atta
Altai, Northern    =>    Northern Altai
Acipa, Western    =>    Western Acipa
Awyu, South    =>    South Awyu
Awyu, Central    =>    Central Awyu
Awyu, Jair    =>    Jair Awyu
Awyu, Edera    =>    Edera Awyu
Ar&#xE1;ra, Mato Grosso    =>    Mato Grosso Ar&#xE1;ra
Armenian, Middle    =>    Middle Armenian
Ayta, Sorsogon    =>    Sorsogon Ayta
Ayta, Bataan    =>    Bataan Ayta
Ayta, Tayabas    =>    Tayabas Ayta
Amuzgo, San Pedro Amuzgos    =>    San Pedro Amuzgos Amuzgo
Amuzgo, Ipalapa    =>    Ipalapa Amuzgo

CHANGE TO SEMI-COLON

Yi, Sichuan    =>    Yi; Sichuan
Ayta, Ambala    =>    Ayta; Ambala
Agta, Camarines Norte    =>    Agta; Camarines Norte
Ayta, Abenlen    =>    Ayta; Abenlen
Malay, Ambonese    =>    Malay; Ambonese
Adi, Galo    =>    Adi; Galo
Tibetan, Amdo    =>    Tibetan; Amdo
Amis, Nataoran    =>    Amis; Nataoran
Amuzgo, Guerrero    =>    Amuzgo; Guerrero
Arapesh, Bumbita    =>    Arapesh; Bumbita
Asmat, Casuarina Coast    =>    Asmat; Casuarina Coast
Asurin&#xED;, Xing&#xFA;    =>    Asurin&#xED;; Xing&#xFA;
Asmat, Yaosakor    =>    Asmat; Yaosakor
Manobo, Ata    =>    Manobo; Ata
One, Molmo    =>    One; Molmo
Gbe, Ayizo    =>    Gbe; Ayizo
Atta, Faire    =>    Atta; Faire
Nahuatl, Highland Puebla    =>    Nahuatl; Highland Puebla
Kayan, Busang    =>    Kayan; Busang
Birifor, Malba    =>    Birifor; Malba
Pahari, Mahasu    =>    Pahari; Mahasu
Bareli, Rathwi    =>    Bareli; Rathwi
Chin, Bawm    =>    Chin; Bawm
B&#xE9;te, Guiberoua    =>    B&#xE9;te; Guiberoua
B&#xE9;t&#xE9;, Daloa    =>    B&#xE9;t&#xE9;; Daloa
Bareli, Pauri    =>    Bareli; Pauri
Itneg, Banao    =>    Itneg; Banao
Sorsogon, Masbate    =>    Sorsogon; Masbate
Karen, Pa'o    =>    Karen; Pa'o
Ayta, Mag-Indi    =>    Ayta; Mag-Indi
Kanuri, Bilma    =>    Kanuri; Bilma
...

NOTE
As I was doing this, I saw the following. It may be perfectly fine, but it looks a bit suspicious, especially since there are a bunch of "Atga" entries with different modifiers. Could this be a spelling error?

Agta, Mt. Iraya

Mark

On 10/9/06, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
[co-chair hat off]

At 02:22 06/10/03, Mark Davis wrote:
>Overall, I think inverted names are a bad idea. They are rather anglocentric, and we find that translators often do the wrong thing with them. They are also hugely inconsistent in the current registry.
>
>I think they are tolerable if (a) every single instance of a comma indicates an inverted name, and (b) all names are consistently inverted. Because of (a) one could programmatically fix the names to the correct value.

I don't think creating artificial syntax rules or some
kind of restricted (English) grammar for Description fields
is appropriate. What I can immagine is that we use semicolons
rather than commas to indicate boundaries between input
from different origins.

Regards,    Martin.



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


------=_Part_42462_20217264.1160952752319-- --===============1574589737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1574589737==-- From ltru-bounces@ietf.org Sun Oct 15 19:07:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZF4x-0007us-Hc; Sun, 15 Oct 2006 19:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZF4v-0007um-S6 for ltru@ietf.org; Sun, 15 Oct 2006 19:07:33 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZF4u-0002xR-Gn for ltru@ietf.org; Sun, 15 Oct 2006 19:07:33 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015230727.SGDA3369.mta13.adelphia.net@DGBP7M81>; Sun, 15 Oct 2006 19:07:27 -0400 Message-ID: <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> Subject: Re: [Ltru] Disambiguating specific and generic names Date: Sun, 15 Oct 2006 16:07:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I don't see why that is necessary. The registry has the tag extlang, > which tells us that knn is Konkani as an individual language. We > hardly need a paranthetical to do that, because we have extlang. > ... > I can tell that kok is Konkani as a macrolanguage simply by the fact > that it is the prefix of some extlang (such as knn) in the repository. OK, then, once and for all: Are we going to adhere to a rule that all Description fields must match the source standards exactly, or are we not? We cannot continue to claim we follow this rule, constrain ourselves by it, and then not follow it, or vice versa. We must make a decision one way or the other and stick to it. I will wait until one of the co-chairs has declared a rough consensus on this issue before releasing draft-4645bis-01. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 19:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFGw-0005yY-Au; Sun, 15 Oct 2006 19:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFGv-0005tT-At for ltru@ietf.org; Sun, 15 Oct 2006 19:19:57 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZFGu-0005B9-0L for ltru@ietf.org; Sun, 15 Oct 2006 19:19:57 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1472798wxc for ; Sun, 15 Oct 2006 16:19:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=lWTUG6BRuqDK7ijiWT4SqX2/dJ8QDZvmShC7huCk2hBfGGndnpvKNDbBKLWqC4ijX7DZpCWL4ilOOy05D3u1OM9bTLL2vxpjSpUPqK/RSpMmObPE074diXU7M1u0EpsJmfukVdtEgr+nVhKqU6n6fV1ZVjA6somW5rcEiYRMt+0= Received: by 10.90.51.17 with SMTP id y17mr3169760agy; Sun, 15 Oct 2006 16:19:55 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 15 Oct 2006 16:19:55 -0700 (PDT) Message-ID: <30b660a20610151619j475e4f75k1dd5975b888c47a2@mail.gmail.com> Date: Sun, 15 Oct 2006 16:19:55 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Disambiguating specific and generic names In-Reply-To: <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> X-Google-Sender-Auth: 507fc1f13bd6ae6e X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1463986947==" Errors-To: ltru-bounces@ietf.org --===============1463986947== Content-Type: multipart/alternative; boundary="----=_Part_42630_13591329.1160954395455" ------=_Part_42630_13591329.1160954395455 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline My vote is that we do not constrain ourselves to follow precisely what is in the source standard. Our descriptions should be clear, unambiguous, and useful. Wherever the source standard description is such, we should follow it precisely. Wherever not, we should not be bound to it. Mark On 10/15/06, Doug Ewell wrote: > > Mark Davis wrote: > > > I don't see why that is necessary. The registry has the tag extlang, > > which tells us that knn is Konkani as an individual language. We > > hardly need a paranthetical to do that, because we have extlang. > > ... > > I can tell that kok is Konkani as a macrolanguage simply by the fact > > that it is the prefix of some extlang (such as knn) in the repository. > > OK, then, once and for all: > > Are we going to adhere to a rule that all Description fields must match > the source standards exactly, or are we not? > > We cannot continue to claim we follow this rule, constrain ourselves by > it, and then not follow it, or vice versa. We must make a decision one > way or the other and stick to it. > > I will wait until one of the co-chairs has declared a rough consensus on > this issue before releasing draft-4645bis-01. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > ------=_Part_42630_13591329.1160954395455 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline My vote is that we do not constrain ourselves to follow precisely what is in the source standard. Our descriptions should be clear, unambiguous, and useful. Wherever the source standard description is such, we should follow it precisely. Wherever not, we should not be bound to it.

Mark

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

> I don't see why that is necessary. The registry has the tag extlang,
> which tells us that knn is Konkani as an individual language. We
> hardly need a paranthetical to do that, because we have extlang.
> ...
> I can tell that kok is Konkani as a macrolanguage simply by the fact
> that it is the prefix of some extlang (such as knn) in the repository.

OK, then, once and for all:

Are we going to adhere to a rule that all Description fields must match
the source standards exactly, or are we not?

We cannot continue to claim we follow this rule, constrain ourselves by
it, and then not follow it, or vice versa.  We must make a decision one
way or the other and stick to it.

I will wait until one of the co-chairs has declared a rough consensus on
this issue before releasing draft-4645bis-01.

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


------=_Part_42630_13591329.1160954395455-- --===============1463986947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1463986947==-- From ltru-bounces@ietf.org Sun Oct 15 19:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFHE-0006ep-Mw; Sun, 15 Oct 2006 19:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFHC-0006ea-W0 for ltru@ietf.org; Sun, 15 Oct 2006 19:20:14 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZFHB-0005EX-MX for ltru@ietf.org; Sun, 15 Oct 2006 19:20:14 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015232013.CXJU10025.mta10.adelphia.net@DGBP7M81>; Sun, 15 Oct 2006 19:20:13 -0400 Message-ID: <002301c6f0b0$77ed5270$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000901c6f02d$fe9a08a0$6501a8c0@DGBP7M81> <30b660a20610151048l2ebdf58dxaac4d0eb3b71f93a@mail.gmail.com> Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 15 Oct 2006 16:20:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: >>> 6. A script subtag SHOULD be used when tagging content if the >>> content is in a script other than that customarily used for the >>> language (i.e. zh-Latn, en-Brai). >> >> Would this sentence mean the same, but be more concise, if the words >> "if the content is" were replaced by "written"? > > I was trying to avoid the use of written -- since the script Zxxx > could be being used for unwritten material (see below). That assumes that your proposed interpretation of "Zxxx" to mean "non-written content" is agreed to by the list, and will be part of 4646bis. You made this argument in [1] but I don't remember any other discussion of it. As a reminder, the Description field for "Zxxx" is "Code for unwritten languages" and I claimed that this is not quite the same thing. [1] http://www1.ietf.org/mail-archive/web/ltru/current/msg05971.html >>> 7. A script subtag SHOULD be used when tagging content if the >>> language of the content is customarily written in more than one >>> script (e.g. sr-Cyrl, sr-Latn). >> >> Again for conciseness, if we don't need "of the content" in the >> previous item, we may not need it here. > > Actually, for precision, I think we should put it in both places. No objection. > 2. American English, written in Cyrillic (don't laugh; a collegue of > mine has a printed ad in this.) I've seen it too, on TV. > 3. American English, only spoken -- no written content > en > en-US > en-Zxxx > en-Zxxx-US See above; if there is agreement to do this, then 4646bis should probably include an example of this usage, and/or the entry for "Zxxx" in the Registry should have a comment added. To me this is a semantic stretch almost equivalent to "sign languages used in the U.S. = American Sign Language." -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 19:24:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFL9-0008OI-Sn; Sun, 15 Oct 2006 19:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFL9-0008OD-90 for ltru@ietf.org; Sun, 15 Oct 2006 19:24:19 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZFL8-0006BV-07 for ltru@ietf.org; Sun, 15 Oct 2006 19:24:19 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015232417.DBHJ10025.mta10.adelphia.net@DGBP7M81>; Sun, 15 Oct 2006 19:24:17 -0400 Message-ID: <002c01c6f0b1$09b03ba0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> <30b660a20610151619j475e4f75k1dd5975b888c47a2@mail.gmail.com> Subject: Re: [Ltru] Disambiguating specific and generic names Date: Sun, 15 Oct 2006 16:24:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > My vote is that we do not constrain ourselves to follow precisely what > is in the source standard. Our descriptions should be clear, > unambiguous, and useful. Wherever the source standard description is > such, we should follow it precisely. Wherever not, we should not be > bound to it. To play devil's advocate, I would argue that "Konkani (macrolanguage)" and "Konkani (individual language)" are all of those: clear, unambiguous, and useful. If you want to add "maximally concise" to the list, then there are a great many Description fields that would have to be re-examined as well. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 19:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFQD-0002fy-BE; Sun, 15 Oct 2006 19:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFQC-0002cx-3N for ltru@ietf.org; Sun, 15 Oct 2006 19:29:32 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZFQA-0007ex-Qf for ltru@ietf.org; Sun, 15 Oct 2006 19:29:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015232930.DHPK10025.mta10.adelphia.net@DGBP7M81> for ; Sun, 15 Oct 2006 19:29:30 -0400 Message-ID: <003201c6f0b1$c425ff60$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 15 Oct 2006 16:29:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: Disambiguating specific and generic names X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > I still hope that 639-3 will not use "(specific)"/"(macrolanguage)" or > similar parentheticals, but rather along the line of adding "Standard" > (or similar) where necessary to bring clarity to the names. Please propose that to the 639-3 folks, then. Here on LTRU, as I said before, we need to make a decision: follow the "official" names exactly or not. Until that is settled, we are just spinning our wheels arguing about individual cases. > B.t.w, I find it strange that zne Zande (Standard Zande?) is > regarded as a "(specific)" language, while znd Zande is > regarded as a "collective" language code, not a macrolanguage code. So do I, but that is what's in the currently available draft tables for 639-3. If and when newer tables become available before the release of 4645bis, resolving some of these "strange" situations, they will replace the ones I'm using now. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 19:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFaR-0008Qr-EI; Sun, 15 Oct 2006 19:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFaQ-0008Qm-B4 for ltru@ietf.org; Sun, 15 Oct 2006 19:40:06 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZFaO-0001E7-1T for ltru@ietf.org; Sun, 15 Oct 2006 19:40:06 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061015234003.RHMQ18643.mta9.adelphia.net@DGBP7M81>; Sun, 15 Oct 2006 19:40:03 -0400 Message-ID: <003b01c6f0b3$3d89efa0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81> <20061002153915.GD22365@ccil.org> <30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com> <6.0.0.20.2.20061009180149.06995380@localhost> <30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> Subject: Re: [Ltru] Re: Registry deltas Date: Sun, 15 Oct 2006 16:40:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > We need to reach consensus on this. I see two basic options. > > A. Allow inverted names with commas, but otherwise no commas (outside > of parentheticals). For consistency, also invert all the other names > that could reasonably be inverted. > > ALLOW: Description: Ambae, West > REPLACE Description: Naga, Maring > WITH Description: Naga; Maring > REPLACE Description: Northern Sotho > WITH Description: Sotho, Northern > > B. Disallow inverted names. > > REPLACE: Description: Ambae, West > WITH: Description: West Ambae > REPLACE Description: Naga, Maring > WITH Description: Naga; Maring There shouldn't be any Description fields with a semicolon separating two alternative names. They should be two Description fields instead: Description: Naga Description: Maring That, of course, assumes this is a valid example, and "nng" really does have the two alternative names "Naga" and "Maring." That seems unlikely considering the existence of "mbw", which is also called "Maring." > I did a quick & dirty dump of all description names containing "," I can't verify the accuracy of much of this list, but one clear error stood out: > CHANGE TO SEMI-COLON > > Yi, Sichuan => Yi; Sichuan This is currently listed in ISO 639-2 as "Sichuan Yi." Likewise: > Nahuatl, Highland Puebla => Nahuatl; Highland Puebla intuitively seems wrong. I suggest if we want to embark on this, we have to go beyond the data files and look each of these up interactively on the 639-3 Web site, which does include both the inverted and non-inverted forms. Sometimes, as in the case of Sichuan Yi, this may even require going to the linked Ethnologue page. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 20:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJV-0007nT-Ka; Sun, 15 Oct 2006 20:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJU-0007nO-KO for ltru@ietf.org; Sun, 15 Oct 2006 20:26:40 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGJT-0002cb-Dv for ltru@ietf.org; Sun, 15 Oct 2006 20:26:40 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GZGJS-0000h5-9p; Sun, 15 Oct 2006 20:26:38 -0400 Date: Sun, 15 Oct 2006 20:26:38 -0400 To: Kent Karlsson Subject: Re: [Ltru] Disambiguating specific and generic names Message-ID: <20061016002638.GD14126@ccil.org> References: <30b660a20610151248x7fcd675fiadf008d0ea4232d0@mail.gmail.com> <004701c6f096$baeca770$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004701c6f096$baeca770$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > B.t.w, I find it strange that zne Zande (Standard Zande?) is > regarded as a "(specific)" language, while znd Zande is > regarded as a "collective" language code, not a macrolanguage code. Such things are not uncommon. Consider German vs. Germanic, or Greek (the language) vs. Greek (the subfamily of Indo-European), or Turkish vs. Turkic (which are the same word in Turkish). -- John Cowan cowan@ccil.org http://ccil.org/~cowan Promises become binding when there is a meeting of the minds and consideration is exchanged. So it was at King's Bench in common law England; so it was under the common law in the American colonies; so it was through more than two centuries of jurisprudence in this country; and so it is today. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 20:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJP-0007me-Hd; Sun, 15 Oct 2006 20:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJO-0007mZ-OL for ltru@lists.ietf.org; Sun, 15 Oct 2006 20:26:34 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGJN-0002XJ-F6 for ltru@lists.ietf.org; Sun, 15 Oct 2006 20:26:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZGJC-0006me-9K for ltru@lists.ietf.org; Mon, 16 Oct 2006 02:26:22 +0200 Received: from pd9fba8fa.dip0.t-ipconnect.de ([217.251.168.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Oct 2006 02:26:22 +0200 Received: from nobody by pd9fba8fa.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Oct 2006 02:26:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 16 Oct 2006 02:25:00 +0200 Organization: Lines: 23 Message-ID: <4532D15C.3711@xyzzy.claranet.de> References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8fa.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Disambiguating specific and generic names X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I will wait until one of the co-chairs has declared a rough > consensus on this issue before releasing draft-4645bis-01. If there are any modifications in your -01pre better submit it before the IETF 67 cut-off (next Monday) and let's see it. Randy and Martin can't make up such decisions, they need to see some discussions on the list first, and ideally proposed text (or alternative proposals like Mark's A vs. B). At the moment I'm not sure what's better, I like the output of B better than A. Apparently B keeps all "xyz, adjective" together in a list sorted by descriptions, that's a feature. Apparently B tosses out any original "adjective xyz", that's bad. And apparently B requires to replace some commata by semicolons based on manual inspection, that's utter dubious: If the source is buggy it has to be fixed. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 20:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJV-0007nT-Ka; Sun, 15 Oct 2006 20:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJU-0007nO-KO for ltru@ietf.org; Sun, 15 Oct 2006 20:26:40 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGJT-0002cb-Dv for ltru@ietf.org; Sun, 15 Oct 2006 20:26:40 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GZGJS-0000h5-9p; Sun, 15 Oct 2006 20:26:38 -0400 Date: Sun, 15 Oct 2006 20:26:38 -0400 To: Kent Karlsson Subject: Re: [Ltru] Disambiguating specific and generic names Message-ID: <20061016002638.GD14126@ccil.org> References: <30b660a20610151248x7fcd675fiadf008d0ea4232d0@mail.gmail.com> <004701c6f096$baeca770$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004701c6f096$baeca770$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > B.t.w, I find it strange that zne Zande (Standard Zande?) is > regarded as a "(specific)" language, while znd Zande is > regarded as a "collective" language code, not a macrolanguage code. Such things are not uncommon. Consider German vs. Germanic, or Greek (the language) vs. Greek (the subfamily of Indo-European), or Turkish vs. Turkic (which are the same word in Turkish). -- John Cowan cowan@ccil.org http://ccil.org/~cowan Promises become binding when there is a meeting of the minds and consideration is exchanged. So it was at King's Bench in common law England; so it was under the common law in the American colonies; so it was through more than two centuries of jurisprudence in this country; and so it is today. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 15 20:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJP-0007me-Hd; Sun, 15 Oct 2006 20:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZGJO-0007mZ-OL for ltru@lists.ietf.org; Sun, 15 Oct 2006 20:26:34 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZGJN-0002XJ-F6 for ltru@lists.ietf.org; Sun, 15 Oct 2006 20:26:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZGJC-0006me-9K for ltru@lists.ietf.org; Mon, 16 Oct 2006 02:26:22 +0200 Received: from pd9fba8fa.dip0.t-ipconnect.de ([217.251.168.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Oct 2006 02:26:22 +0200 Received: from nobody by pd9fba8fa.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Oct 2006 02:26:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 16 Oct 2006 02:25:00 +0200 Organization: Lines: 23 Message-ID: <4532D15C.3711@xyzzy.claranet.de> References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8fa.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Disambiguating specific and generic names X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I will wait until one of the co-chairs has declared a rough > consensus on this issue before releasing draft-4645bis-01. If there are any modifications in your -01pre better submit it before the IETF 67 cut-off (next Monday) and let's see it. Randy and Martin can't make up such decisions, they need to see some discussions on the list first, and ideally proposed text (or alternative proposals like Mark's A vs. B). At the moment I'm not sure what's better, I like the output of B better than A. Apparently B keeps all "xyz, adjective" together in a list sorted by descriptions, that's a feature. Apparently B tosses out any original "adjective xyz", that's bad. And apparently B requires to replace some commata by semicolons based on manual inspection, that's utter dubious: If the source is buggy it has to be fixed. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 01:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZKs9-00084V-FH; Mon, 16 Oct 2006 01:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZKs8-00084Q-L2 for ltru@lists.ietf.org; Mon, 16 Oct 2006 01:18:44 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZKs5-00085z-CW for ltru@lists.ietf.org; Mon, 16 Oct 2006 01:18:44 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Sun, 15 Oct 2006 22:18:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 22:18:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Liaison with TC37/SC2 Date: Sun, 15 Oct 2006 22:18:37 -0700 Message-ID: In-Reply-To: <18824246-DC0C-4D47-B5E5-E98104344337@egt.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Liaison with TC37/SC2 thread-index: Acbuz1d1yLKKcQLiRrWdafNpx72rpACEsmoA From: Peter Constable To: X-OriginalArrivalTime: 16 Oct 2006 05:18:40.0069 (UTC) FILETIME=[8A543F50:01C6F0E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Marion Gunn [mailto:mgunn@egt.ie]=20 > ISO/TC 37/SC 2 already has an American Chair The chair of ISO/TC37/SC2, Gerhard Budin, is not from the U.S.A. but rather is Austrian. Frankly, inasmuch as the role of a liaison is to report information from one body to another and not to take independent actions impinging on either, I don't quite see why nationality is a concern in this discussion. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 01:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZL0k-00040g-C2; Mon, 16 Oct 2006 01:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZL0j-0003zo-CL for ltru@lists.ietf.org; Mon, 16 Oct 2006 01:27:37 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZL0g-0002Dc-2I for ltru@lists.ietf.org; Mon, 16 Oct 2006 01:27:37 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Sun, 15 Oct 2006 22:27:33 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 22:27:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Liaison with TC37/SC2 Date: Sun, 15 Oct 2006 22:27:30 -0700 Message-ID: In-Reply-To: <20061015000309.GK2033@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Liaison with TC37/SC2 thread-index: Acbv7VondHDzUI9uS0uXM8LxVYJQWAA9lNKQ From: Peter Constable To: John Cowan , Frank Ellermann X-OriginalArrivalTime: 16 Oct 2006 05:27:32.0965 (UTC) FILETIME=[C7F5B950:01C6F0E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org An ISO WG has a convener; a TC or SC has a chair. Peter Constable -----Original Message----- From: John Cowan [mailto:cowan@ccil.org]=20 Sent: Saturday, October 14, 2006 5:03 PM To: Frank Ellermann Cc: ltru@lists.ietf.org Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Frank Ellermann scripsit: > What's a "convener", something like a Chair or an AD ? =20 Could be either: there are conveners at all three levels (Technical Committee or Joint Technical Committee, SubCommittee, and Working Group). > 64 CHF for a look into 21 pages of an ISO 639-5 draft, I can > see a minor problem here, along the line of "It's dead, Jim". That's how ISO stays afloat. --=20 John Cowan cowan@ccil.org http://www.ccil.org/~cowan Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory that the mongoose first came to India on a raft from Polynesia. --blurb for Rikki-Kon-Tiki-Tavi _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 02:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZM8w-0006td-M9; Mon, 16 Oct 2006 02:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZM8v-0006tY-Ql for ltru@ietf.org; Mon, 16 Oct 2006 02:40:09 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZM8t-0006Cq-FF for ltru@ietf.org; Mon, 16 Oct 2006 02:40:09 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061016064006.HDGD3369.mta13.adelphia.net@DGBP7M81> for ; Mon, 16 Oct 2006 02:40:06 -0400 Message-ID: <000701c6f0ed$ec0f9f40$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 15 Oct 2006 23:40:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: Disambiguating specific and generic names X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: >> I will wait until one of the co-chairs has declared a rough consensus >> on this issue before releasing draft-4645bis-01. > > Randy and Martin can't make up such decisions, they need to see some > discussions on the list first, and ideally proposed text (or > alternative proposals like Mark's A vs. B). I didn't ask them to make anything up. They need to decide and declare what "the group" wants, the rough consensus, based on however many contributions they get. If there aren't enough contributions to make a determination, for some value of "enough," they need to decide whether to fall back to "do it," "don't do it," or "cajole more responses out of the group." It's not helping for us to take the informal approach and assume everyone knows what course of action we are following. There are obviously some very strong differences of opinion on this exact-description issue. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 04:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZO68-0004Nm-JA; Mon, 16 Oct 2006 04:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZO66-0003LA-Ob for ltru@ietf.org; Mon, 16 Oct 2006 04:45:22 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZNtz-0003F9-Vh for ltru@ietf.org; Mon, 16 Oct 2006 04:32:54 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9G8WmHD020132 for ; Mon, 16 Oct 2006 17:32:48 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7b08_e7517306_5cf0_11db_9ec7_0014221f2a2d; Mon, 16 Oct 2006 17:32:47 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53995) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 16 Oct 2006 17:32:14 +0900 Message-Id: <6.0.0.20.2.20061016155505.0683e0c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 16 Oct 2006 16:02:39 +0900 To: debbie@ictmarketing.co.uk, , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Re: Liaison with TC37/SC2 In-Reply-To: <099E56E902694298855BF6D06A52555F.MAI@home> References: <007601c6ef5c$7e4bbbc0$6501a8c0@DGBP7M81> <099E56E902694298855BF6D06A52555F.MAI@home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For what it's worth, I have been involved in various liaisons (including one to the IETF) when I was at W3C. For the liaison between IETF and W3C, there was a regular teleconference (roughly 3 times a year). For another liason, the one between W3C and ISO/IEC JTC1/SC2, I prepared and sent in some liaison reports, usually before they had a meeting, but I never managed to attend a meeting, and this was not necessary. Also, there was a mechanism that we had mutual access to otherwise confidential documents. That was easier than in the case we are looking at now, because both sides had a way to keep things confidential, which we as a WG don't. The exchange of confidential information wasn't a problem because confidentiality is explicitly designed to allow exchanges of information if this is necessary for common or related work. Regards, Martin. At 18:11 06/10/14, Debbie Garside wrote: >I don't think Randy is correct and my nomination stands! It is useful to >have someone there on the ground BEFORE decisions are made. > >Given that I have some experience of this particular SC and WG I can say >Doug would not be out of his depth at all. It is my opinion that the >knowledge Doug has of the RFC's in question wood be invaluable to this SC. > >As to travel, join ANSI. One would hope that, like BSI, they would support >travel expenditure. > >Best >Debbie > >> -----Original Message----- >> From: Doug Ewell [mailto:dewell@adelphia.net] >> Sent: 14 October 2006 07:47 >> To: LTRU Working Group >> Subject: [Ltru] Re: Liaison with TC37/SC2 >> >> Marion Gunn wrote: >> >> > Might I suggest that, as Sue-Ellen (of ANSI, who used to be an ISO >> > colleague of mine) is an American and SIL (RA for 639-3) >> also American >> > and ISO/TC 37/SC 2 already has an American Chair, we propose some >> > person(s) born in some other country less under the influence of >> > current US foreign policy in re territorial/linguistic designations >> > and more eager to respect more diverse opinions (excluding Austria, >> > because either 639-1 or 639-2 - whichever! - already has an >> Austrian >> > RA, which only supports the other to be under LOC_US control)? I >> > propose this as someone with an ever-growing number of >> US-born friends >> > who feel embarrassed by this irrational and totally >> unnecessary push >> > towards monopoly and who would rather much rather operate >> > professionally in a freer, less unequal atmosphere (where >> nobody can >> > blame any one country, especially _their_ native country, >> for errors - >> > and who could blame anyone for desiring that?). >> >> Well, now. >> >> First of all, I am flattered and honored by Debbie's >> nomination, but I am probably going to have to decline it for >> two main reasons: >> >> 1. I have no experience as a liaison, and no prior formal >> working relationship with, or membership in, an ISO SC or WG. >> While everyone has to start somewhere, I think this >> particular project should benefit from a liaison with some >> experience, not a trainee. >> >> 2. I have no travel budget, and no realistic hope of getting one. >> >> I'm willing to be convinced that each of these is negotiable, >> and not a show-stopper. I'm guessing that item 1 is going to >> turn out to be negotiable, and item 2 isn't. >> >> Now about this American thing. >> >> Completely disregarding the issue of me personally, I'm >> deeply disappointed that national origin is being considered >> a criterion for choosing a liaison. I would have thought it >> was about as important as eye color, or left-handedness >> versus right-handedness. >> >> I was not aware that being American-born prevented one, a >> priori, from being "eager to respect more diverse opinions." >> Perhaps there are some who do see it that way. >> >> I certainly wouldn't consider myself a slave to U.S. foreign policy. >> People who know me well know my objections to the current >> administration's foreign policy and the aggressive, bullying >> way it enforces it. I suppose it is that aggressive stance, >> combined with misplaced stereotypes, that makes some >> non-Americans think we all support our administration. >> >> As for "US foreign policy in re territorial/linguistic >> designations," it hadn't occurred to me at the time that >> there was such a thing. I guess the State Department's >> preference for "Burma" and "Burmese" over "Myanmar" is a >> statement of sorts about their opposition to that country's >> current leadership. I don't know what that has to do with >> the liaison position. I've never advocated changing an >> internationally recognized, ISO-approved language, script, or >> country name in the Registry to better suit U.S. policy. >> >> I tend to think of the Internet and WGs like this as true >> melting pots, where I can work with someone for months or >> years without regard for their race, age, national origin, >> blood type, shoe size, etc. I thought we had gotten past the >> days on this list of questioning someone's motives or >> abilities on the basis of what country they were born in or >> live in. I do not think I would automatically consider an >> Irish person unqualified or inappropriate to be a liaison >> simply because they were Irish. >> >> I note in passing that I was nominated by a European. >> >> I don't care to pursue this distasteful topic further. Let's >> find a liaison everyone in the WG can support, so we can have >> ready access to the documents we need to get our work done. >> Or, if Randy is correct and we can be assured of the >> necessary access without a formal liaison, let's do that instead. >> >> -- >> Doug Ewell * Fullerton, California, USA * RFC 4645 * >> UTN #14 http://users.adelphia.net/~dewell/ >> http://www1.ietf.org/html.charters/ltru-charter.html >> http://www.alvestrand.no/mailman/listinfo/ietf-languages >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> >> >> > > > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 05:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOsJ-0004gd-Gm; Mon, 16 Oct 2006 05:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOsI-0004gE-9g for ltru@ietf.org; Mon, 16 Oct 2006 05:35:10 -0400 Received: from [80.76.149.213] (helo=ch-smtp02.sth.basefarm.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZOhI-0007tw-Qh for ltru@ietf.org; Mon, 16 Oct 2006 05:23:50 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:61680 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GZOgS-0007xN-98 for ltru@ietf.org; Mon, 16 Oct 2006 11:23:47 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: Registry deltas Date: Mon, 16 Oct 2006 11:18:09 +0200 Message-ID: <001701c6f103$ff558b30$6500a8c0@chalmers95a69n> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GZOgS-0007xN-98. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GZOgS-0007xN-98 145e25c78584f531d02c3e63ffb4387f X-Spam-Score: 2.4 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2028296488==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============2028296488== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C6F114.C2DFE1D0" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C6F114.C2DFE1D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mark Davis wrote: A. Allow inverted names with commas, but otherwise no commas (outside of = parentheticals). For consistency, also invert all the other names that = could reasonably be inverted.=20 I think this is preferable for LSR (and 639), but a bad idea for actual = presentation (like via CLDR). CLDR (and others) should use non-inverted = names. Note: I think the suggestion to uniformally use ";" as a separator = between different names is a good one, so I've done that with both = options above.=20 I was under the impression that the 639-3 draft tables almost did not = include any alternative names (and in the few cases where it does, it = uses ; as separator), (almost) just single but often qualified names. = But that is just my impression. (As for "Naga", there are 39 different = entries, with different qualifications (not alternatives, obviously).) =20 /kent k =20 ------=_NextPart_000_0018_01C6F114.C2DFE1D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message
Mark Davis = wrote:
A. Allow inverted names with commas, but otherwise no commas = (outside of=20 parentheticals). For consistency, also invert all the other = names that=20 could reasonably be inverted. 
I think this is preferable for LSR (and 639), but a bad = idea for=20 actual presentation (like via CLDR). CLDR (and others) should use = non-inverted=20 names.
Note: I think the suggestion to uniformally use ";" as a = separator=20 between different names is a good one, so I've done that with both = options=20 above. 
I was under the impression that the 639-3 draft tables = almost did=20 not include any alternative names (and in the few cases where it does, = it uses ;=20 as separator), (almost) just single but often qualified names. But that = is just=20 my impression. (As for "Naga", there are 39 different entries, with = different=20 qualifications (not alternatives, obviously).)
 
       =20 /kent k
 
------=_NextPart_000_0018_01C6F114.C2DFE1D0-- --===============2028296488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2028296488==-- From ltru-bounces@ietf.org Mon Oct 16 07:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZR6q-0007CG-0N; Mon, 16 Oct 2006 07:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZR6o-0007C9-Jt for ltru@ietf.org; Mon, 16 Oct 2006 07:58:18 -0400 Received: from mail05.svc.cra.dublin.eircom.net ([159.134.118.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZR6i-0002ii-Ik for ltru@ietf.org; Mon, 16 Oct 2006 07:58:18 -0400 Received: (qmail 54847 messnum 3315735 invoked from network[194.125.174.34/ts09-034.dublin.indigo.ie]); 16 Oct 2006 11:58:10 -0000 Received: from ts09-034.dublin.indigo.ie (HELO ?194.125.174.34?) (194.125.174.34) by mail05.svc.cra.dublin.eircom.net (qp 54847) with SMTP; 16 Oct 2006 11:58:10 -0000 Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Date: Mon, 16 Oct 2006 12:55:43 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Sue Ellen Wright , TC46-L Information and Documentation Technology List Subject: [Ltru] IPA, NSAI and ANSI X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org To say Ireland (NSAI) is responsible for the refusal to register IPA =20 as an ISO 15924 script is as unfair as it is untrue. I am writing to confirm that Irish users were as put out by that =20 negative decision as users elsewhere, and that that negative decision =20= was not made by NSAI. ISO 15924 is nominally the responsibility of ISO/TC 46, although not =20 under normal TC 46 control, either, and that negative decision was =20 made by the ISO 15924 advisory committee, currently made up as follows: One representative of the Registration Authority: Michael Everson, Evertype One representative of the ISO 639-2/RA: Randall K. Barry, Library of Congress One representative of ISO TC37: H=E5vard Hjulstad, Spr=E5k- og terminologitjenester One representative of ISO TC46: Fran=E7ois Demay, Encyclopaedia Universalis Two representatives of ISO/IEC JTC1/SC2: Rick McGowan, Unicode Consortium Ken Whistler, Sybase That AC failed to offer a cogent argument against tagging IPA in ISO =20 15924 and, during a public exchange on the LTRU list, its members all =20= failed to address most of the points raised, for example, when Mark =20 Davis of International Components for Unicode pointed out that [ISO =20 15924] already "incorporates variations which are essentially =20 orthography (Hant vs Hans), and other differences that are simply =20 glyphic variation (Fraktur Latin)" their answer was silence. The grounds for registering IPA as a script have been long since =20 established: it looks like a script, behaves like a script and only =20 requires standard ISO tagging to facilitate proper electronic script =20 processing. An IPA tag is urgently needed by NSAI's Irish-speaking =20 communities, (so I must continue pressing for it), as well as being =20 needed by university researchers and practical speech therapists in =20 so many countries that a positive decision to tag it for use needs to =20= made without delay, to open the door for Net searches for texts =20 written in IPA. Because that particular ISO AC was set up with a built-in US majority =20= (4 out of 6), it is the logical responsibility of ANSI (_not_ NSAI) =20 to ensure that such overloading in a big country's favour not be any =20 excuse for refusing/delaying reasonable service requests from smaller =20= countries. No country, however big it is, has any right to have such =20 control over any international standards =97 however obtained, that =20 amount of control carries with it an equal amount of answerability =20 for concomitant results. Accordingly, I respectfully request that ANSI use its influence to to =20= good effect, to persuade such members of the ISO 15924 AC as it can =20 influence to reverse their negative decision in re registering IPA in =20= ISO 15924. FWIW, I wish to affirm that I still believe in ISO 15924's potential =20 quite as much as I did many years ago, when I was NSAI's sole =20 representative in ISO/TC 37, where I first brought its first NWI =20 draft to ISO/TC 37's attention (and after it was blocked in TC 37, =20 supported its adoption in ISO/TC 46), that I regard its inception by =20 Michael Everson as something very much to his credit, and that I =20 would also regard it as to Mr Everson's credit were he now to reverse =20= his vote (withdraw his opposition to registing IPA as a script). I hold it as a reasonable expectation that the rest would probably =20 follow. mg Convener, NSAI ISO/TC 46 IG - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 09:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSZB-00021o-HV; Mon, 16 Oct 2006 09:31:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSZA-00021f-Bu for ltru@lists.ietf.org; Mon, 16 Oct 2006 09:31:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSZ0-0004RE-U3 for ltru@lists.ietf.org; Mon, 16 Oct 2006 09:31:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZSYa-0000NK-7T for ltru@lists.ietf.org; Mon, 16 Oct 2006 15:31:04 +0200 Received: from pd9fbad1d.dip0.t-ipconnect.de ([217.251.173.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Oct 2006 15:31:04 +0200 Received: from nobody by pd9fbad1d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Oct 2006 15:31:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Mon, 16 Oct 2006 15:23:14 +0200 Organization: Lines: 5 Message-ID: <453387C2.4B87@xyzzy.claranet.de> References: <450812FA.3040906@sil.org> <20060913143839.GK10145@ccil.org> <003a01c6d75f$4142ce40$6501a8c0@oemcomputer> <30b660a20609131119q40711cb4ke211d397155068a2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad1d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Ltru] OT: Latf X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just in case if somebody doesn't know it: http://www.h-roesler.de/_html/schrift.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 11:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUNP-0004Xs-6z; Mon, 16 Oct 2006 11:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUNN-0004VS-E0 for ltru@lists.ietf.org; Mon, 16 Oct 2006 11:27:37 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUNJ-0002SP-36 for ltru@lists.ietf.org; Mon, 16 Oct 2006 11:27:37 -0400 Received: by wr-out-0506.google.com with SMTP id 57so179312wri for ; Mon, 16 Oct 2006 08:27:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=bWFMu/YFStt2ji5DdYNJJ/JFbO1Q0jzdBWqPZY8s1Hh08FSo4UfQv2/aaPPUKZFfbiEQzyt/ANBc+oAzpBYUTKtzaUFEwRsJuQEX2UV/TLTeMHTDoAWFACQ0OubqSrBG2r7G2TAze9a+cXGUF8QNaBT6k1CtH3cZeMJYEfxzeNg= Received: by 10.90.100.2 with SMTP id x2mr3634713agb; Mon, 16 Oct 2006 08:27:30 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Mon, 16 Oct 2006 08:27:30 -0700 (PDT) Message-ID: <30b660a20610160827j2161528pcb638f93236faa1d@mail.gmail.com> Date: Mon, 16 Oct 2006 08:27:30 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Disambiguating specific and generic names In-Reply-To: <4532D15C.3711@xyzzy.claranet.de> MIME-Version: 1.0 References: <000301c6f023$6584ee50$6501a8c0@DGBP7M81> <30b660a20610151107w2e39d100t67a061eea804e962@mail.gmail.com> <001601c6f0ae$afde1220$6501a8c0@DGBP7M81> <4532D15C.3711@xyzzy.claranet.de> X-Google-Sender-Auth: a2324537252cccfb X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1418985295==" Errors-To: ltru-bounces@ietf.org --===============1418985295== Content-Type: multipart/alternative; boundary="----=_Part_48320_23940175.1161012450598" ------=_Part_48320_23940175.1161012450598 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline My list of examples was a quick pass, just to see what the results would look like. I do *not* think that all the items were correct. That is actually the point -- it is impossible to mechanically distinguish between cases that are inversions and the cases that are separate items. That's why knowledgeable people need to go through the items to repair this mess. Mark On 10/15/06, Frank Ellermann < nobody@xyzzy.claranet.de> wrote: > > Doug Ewell wrote: > > > I will wait until one of the co-chairs has declared a rough > > consensus on this issue before releasing draft-4645bis-01. > > If there are any modifications in your -01pre better submit > it before the IETF 67 cut-off (next Monday) and let's see it. > > Randy and Martin can't make up such decisions, they need to > see some discussions on the list first, and ideally proposed > text (or alternative proposals like Mark's A vs. B). > > At the moment I'm not sure what's better, I like the output > of B better than A. Apparently B keeps all "xyz, adjective" > together in a list sorted by descriptions, that's a feature. > > Apparently B tosses out any original "adjective xyz", that's > bad. And apparently B requires to replace some commata by > semicolons based on manual inspection, that's utter dubious: > If the source is buggy it has to be fixed. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_48320_23940175.1161012450598 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline My list of examples was a quick pass, just to see what the results would look like. I do *not* think that all the items were correct.

That is actually the point -- it is impossible to mechanically distinguish between cases that are inversions and the cases that are separate items.

That's why knowledgeable people need to go through the items to repair this mess.

Mark

On 10/15/06, Frank Ellermann < nobody@xyzzy.claranet.de> wrote:
Doug Ewell wrote:

> I will wait until one of the co-chairs has declared a rough
> consensus on this issue before releasing draft-4645bis-01.

If there are any modifications in your -01pre better submit
it before the IETF 67 cut-off (next Monday) and let's see it.

Randy and Martin can't make up such decisions, they need to
see some discussions on the list first, and ideally proposed
text (or alternative proposals like Mark's A vs. B).

At the moment I'm not sure what's better, I like the output
of B better than A.  Apparently B keeps all "xyz, adjective"
together in a list sorted by descriptions, that's a feature.

Apparently B tosses out any original "adjective xyz", that's
bad.  And apparently B requires to replace some commata by
semicolons based on manual inspection, that's utter dubious:
If the source is buggy it has to be fixed.

Frank



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

------=_Part_48320_23940175.1161012450598-- --===============1418985295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1418985295==-- From ltru-bounces@ietf.org Mon Oct 16 13:05:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVtf-0001eA-AM; Mon, 16 Oct 2006 13:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVte-0001e2-9P for ltru@ietf.org; Mon, 16 Oct 2006 13:05:02 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVtX-0000nC-En for ltru@ietf.org; Mon, 16 Oct 2006 13:05:02 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Mon, 16 Oct 2006 10:04:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 16 Oct 2006 10:04:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry deltas Date: Mon, 16 Oct 2006 10:04:49 -0700 Message-ID: In-Reply-To: <30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Registry deltas thread-index: AcbwrKbR1Ka3HndkSLqb786PbbfsvAAls8ew References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81><20061002153915.GD22365@ccil.org><30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com><6.0.0.20.2.20061009180149.06995380@localhost> <30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 16 Oct 2006 17:04:52.0756 (UTC) FILETIME=[326B2D40:01C6F145] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0086585507==" Errors-To: ltru-bounces@ietf.org --===============0086585507== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F145.329506DD" ------_=_NextPart_001_01C6F145.329506DD Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVmaW5pdGVseSBzb21lIG9mIHRoZSBjaGFuZ2VzIGJlbG93IHdvdWxkIGJlIHdyb25nOiBlLmcu LCANCg0KIA0KDQotICAgICAgICDigJxZaSwgU2ljaHVhbuKAnSBpcyBhbiBpbnZlcnRlZCBmb3Jt IG9mIOKAnFNpY2h1YW4gWWnigJ0NCg0KLSAgICAgICAg4oCcQWd0YSwgQ2FtYXJpbmVzIE5vcnRl 4oCdIGlzIGFuIGludmVydGVkIGZvcm0gb2Yg4oCcQ2FtYXJpbmVzIE5vcnRlIEFndGHigJ0NCg0K LSAgICAgICAg4oCcTWFsYXksIEFtYm9uZXNl4oCdIGlzIGFuIGludmVydGVkIGZvcm0gb2Yg4oCc QW1ib25lc2UgTWFsYXnigJ07IOKAnEFtYm9uZXNl4oCdIGlzIGFuIGFsdGVybmF0ZSBuYW1lLCBi dXQg4oCcTWFsYXnigJ0gcHJvYmFibHkgaXNu4oCZdCBhIGdvb2QgY2hvaWNlIGZvciBhbiBhbHRl cm5hdGUgbmFtZSBzaW5jZSB0aGF0IHdvdWxkIGdlbmVyYWxseSBiZSB1bmRlcnN0b29kIGFzIEJh aGFzYSBNYWxheXNpYQ0KDQotICAgICAgICDigJxOYWh1YXRsLCBIaWdobGFuZCBQdWVibGHigJ0g aXMgYW4gaW52ZXJ0ZWQgZm9ybSBvZiDigJxIaWdobGFuZCBQdWVibGEgTmFodWF0bOKAnQ0KDQog DQoNCk1vcmUgb2YgdGhlc2UgYXJlIHNpbWlsYXI7IGEgY2xvc2VyIHJldmlldyB3b3VsZCBiZSBu ZWVkZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIG9mIHRoZXNlIGNoYW5nZXMgd291bGQgcmVhbGx5IG1h a2Ugc2Vuc2UuDQoNCiANCg0KIA0KDQpQZXRlciANCg0KIA0KDQpGcm9tOiBNYXJrIERhdmlzIFtt YWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmddIA0KDQoNCg0KQ0hBTkdFIFRPIFNFTUkt Q09MT04NCg0KWWksIFNpY2h1YW4gICAgPT4gICAgWWk7IFNpY2h1YW4NCkF5dGEsIEFtYmFsYSAg ICA9PiAgICBBeXRhOyBBbWJhbGEgDQpBZ3RhLCBDYW1hcmluZXMgTm9ydGUgICAgPT4gICAgQWd0 YTsgQ2FtYXJpbmVzIE5vcnRlDQpBeXRhLCBBYmVubGVuICAgID0+ICAgIEF5dGE7IEFiZW5sZW4N Ck1hbGF5LCBBbWJvbmVzZSAgICA9PiAgICBNYWxheTsgQW1ib25lc2UNCkFkaSwgR2FsbyAgICA9 PiAgICBBZGk7IEdhbG8NClRpYmV0YW4sIEFtZG8gICAgPT4gICAgVGliZXRhbjsgQW1kbyANCkFt aXMsIE5hdGFvcmFuICAgID0+ICAgIEFtaXM7IE5hdGFvcmFuDQpBbXV6Z28sIEd1ZXJyZXJvICAg ID0+ICAgIEFtdXpnbzsgR3VlcnJlcm8NCkFyYXBlc2gsIEJ1bWJpdGEgICAgPT4gICAgQXJhcGVz aDsgQnVtYml0YQ0KQXNtYXQsIENhc3VhcmluYSBDb2FzdCAgICA9PiAgICBBc21hdDsgQ2FzdWFy aW5hIENvYXN0DQpBc3VyaW4mI3hFRDssIFhpbmcmI3hGQTsgICAgPT4gICAgQXN1cmluJiN4RUQ7 OyBYaW5nJiN4RkE7IA0KQXNtYXQsIFlhb3Nha29yICAgID0+ICAgIEFzbWF0OyBZYW9zYWtvcg0K TWFub2JvLCBBdGEgICAgPT4gICAgTWFub2JvOyBBdGENCk9uZSwgTW9sbW8gICAgPT4gICAgT25l OyBNb2xtbw0KR2JlLCBBeWl6byAgICA9PiAgICBHYmU7IEF5aXpvDQpBdHRhLCBGYWlyZSAgICA9 PiAgICBBdHRhOyBGYWlyZQ0KTmFodWF0bCwgSGlnaGxhbmQgUHVlYmxhICAgID0+ICAgIE5haHVh dGw7IEhpZ2hsYW5kIFB1ZWJsYSANCktheWFuLCBCdXNhbmcgICAgPT4gICAgS2F5YW47IEJ1c2Fu Zw0KQmlyaWZvciwgTWFsYmEgICAgPT4gICAgQmlyaWZvcjsgTWFsYmENClBhaGFyaSwgTWFoYXN1 ICAgID0+ICAgIFBhaGFyaTsgTWFoYXN1DQpCYXJlbGksIFJhdGh3aSAgICA9PiAgICBCYXJlbGk7 IFJhdGh3aQ0KQ2hpbiwgQmF3bSAgICA9PiAgICBDaGluOyBCYXdtDQpCJiN4RTk7dGUsIEd1aWJl cm91YSAgICA9PiAgICBCJiN4RTk7dGU7IEd1aWJlcm91YSANCkImI3hFOTt0JiN4RTk7LCBEYWxv YSAgICA9PiAgICBCJiN4RTk7dCYjeEU5OzsgRGFsb2ENCkJhcmVsaSwgUGF1cmkgICAgPT4gICAg QmFyZWxpOyBQYXVyaQ0KSXRuZWcsIEJhbmFvICAgID0+ICAgIEl0bmVnOyBCYW5hbw0KU29yc29n b24sIE1hc2JhdGUgICAgPT4gICAgU29yc29nb247IE1hc2JhdGUNCkthcmVuLCBQYSdvICAgID0+ ICAgIEthcmVuOyBQYSdvIA0KQXl0YSwgTWFnLUluZGkgICAgPT4gICAgQXl0YTsgTWFnLUluZGkN CkthbnVyaSwgQmlsbWEgICAgPT4gICAgS2FudXJpOyBCaWxtYQ0KLi4uDQoNCk5PVEUNCkFzIEkg d2FzIGRvaW5nIHRoaXMsIEkgc2F3IHRoZSBmb2xsb3dpbmcuIEl0IG1heSBiZSBwZXJmZWN0bHkg ZmluZSwgYnV0IGl0IGxvb2tzIGEgYml0IHN1c3BpY2lvdXMsIGVzcGVjaWFsbHkgc2luY2UgdGhl cmUgYXJlIGEgYnVuY2ggb2YgIkF0Z2EiIGVudHJpZXMgd2l0aCBkaWZmZXJlbnQgbW9kaWZpZXJz LiBDb3VsZCB0aGlzIGJlIGEgc3BlbGxpbmcgZXJyb3I/IA0KDQpBZ3RhLCBNdC4gSXJheWEgDQoN Ck1hcmsNCg0KT24gMTAvOS8wNiwgTWFydGluIER1ZXJzdCA8ZHVlcnN0QGl0LmFveWFtYS5hYy5q cD4gd3JvdGU6DQoNCltjby1jaGFpciBoYXQgb2ZmXQ0KDQpBdCAwMjoyMiAwNi8xMC8wMywgTWFy ayBEYXZpcyB3cm90ZToNCj5PdmVyYWxsLCBJIHRoaW5rIGludmVydGVkIG5hbWVzIGFyZSBhIGJh ZCBpZGVhLiBUaGV5IGFyZSByYXRoZXIgYW5nbG9jZW50cmljLCBhbmQgd2UgZmluZCB0aGF0IHRy YW5zbGF0b3JzIG9mdGVuIGRvIHRoZSB3cm9uZyB0aGluZyB3aXRoIHRoZW0uIFRoZXkgYXJlIGFs c28gaHVnZWx5IGluY29uc2lzdGVudCBpbiB0aGUgY3VycmVudCByZWdpc3RyeS4gDQo+DQo+SSB0 aGluayB0aGV5IGFyZSB0b2xlcmFibGUgaWYgKGEpIGV2ZXJ5IHNpbmdsZSBpbnN0YW5jZSBvZiBh IGNvbW1hIGluZGljYXRlcyBhbiBpbnZlcnRlZCBuYW1lLCBhbmQgKGIpIGFsbCBuYW1lcyBhcmUg Y29uc2lzdGVudGx5IGludmVydGVkLiBCZWNhdXNlIG9mIChhKSBvbmUgY291bGQgcHJvZ3JhbW1h dGljYWxseSBmaXggdGhlIG5hbWVzIHRvIHRoZSBjb3JyZWN0IHZhbHVlLiANCg0KSSBkb24ndCB0 aGluayBjcmVhdGluZyBhcnRpZmljaWFsIHN5bnRheCBydWxlcyBvciBzb21lDQpraW5kIG9mIHJl c3RyaWN0ZWQgKEVuZ2xpc2gpIGdyYW1tYXIgZm9yIERlc2NyaXB0aW9uIGZpZWxkcw0KaXMgYXBw cm9wcmlhdGUuIFdoYXQgSSBjYW4gaW1tYWdpbmUgaXMgdGhhdCB3ZSB1c2Ugc2VtaWNvbG9ucw0K cmF0aGVyIHRoYW4gY29tbWFzIHRvIGluZGljYXRlIGJvdW5kYXJpZXMgYmV0d2VlbiBpbnB1dCAN CmZyb20gZGlmZmVyZW50IG9yaWdpbnMuDQoNClJlZ2FyZHMsICAgIE1hcnRpbi4NCg0KDQoNCiMt Iy0jICBNYXJ0aW4gSi4gRHUicnN0LCBBc3NvYy4gUHJvZmVzc29yLCBBb3lhbWEgR2FrdWluIFVu aXZlcnNpdHkNCiMtIy0jICAgaHR0cDovL3d3dy5zdy5pdC5hb3lhbWEuYWMuanAgPGh0dHA6Ly93 d3cuc3cuaXQuYW95YW1hLmFjLmpwPiAgICAgICAgbWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMu anANCg0KIA0KDQo= ------_=_NextPart_001_01C6F145.329506DD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAUE1pbmdMaVUiOw0KCXBhbm9zZS0xOjIg MiA1IDAgMCAwIDAgMCAwIDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uZ21haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbF9xdW90ZTt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0IERlZmluaXRpb25zICov DQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA3NDUzMDQwOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjkyODA0NjYwIDQxOTg0ODY5MiA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1V UyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkRlZmluaXRlbHkgc29tZSBv ZiB0aGUgY2hhbmdlcyBiZWxvdyB3b3VsZCBiZSB3cm9uZzogZS5nLiwgPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBz dHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAh c3VwcG9ydExpc3RzXT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3Bhbg0Kc3R5bGU9J21zby1s aXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+4oCcWWksIFNpY2h1YW7i gJ0gaXMgYW4gaW52ZXJ0ZWQgZm9ybSBvZiDigJxTaWNodWFuIFlp4oCdPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuDQpzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4g c3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz7igJxBZ3RhLCBDYW1hcmluZXMgTm9ydGXigJ0gaXMgYW4g aW52ZXJ0ZWQgZm9ybSBvZiDigJxDYW1hcmluZXMgTm9ydGUNCkFndGHigJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3Bh biBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPuKAnE1hbGF5LCBBbWJvbmVzZeKAnSBpcyBhbiBpbnZl cnRlZCBmb3JtIG9mIOKAnEFtYm9uZXNlIE1hbGF54oCdOyDigJxBbWJvbmVzZeKAnQ0KaXMgYW4g YWx0ZXJuYXRlIG5hbWUsIGJ1dCDigJxNYWxheeKAnSBwcm9iYWJseSBpc27igJl0IGEgZ29vZCBj aG9pY2UgZm9yIGFuIGFsdGVybmF0ZQ0KbmFtZSBzaW5jZSB0aGF0IHdvdWxkIGdlbmVyYWxseSBi ZSB1bmRlcnN0b29kIGFzIEJhaGFzYSBNYWxheXNpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bhbg0Kc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48c3Bhbg0Kc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250 OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+4oCcTmFodWF0bCwgSGlnaGxhbmQgUHVlYmxh4oCdIGlzIGFuIGludmVydGVk IGZvcm0gb2Yg4oCcSGlnaGxhbmQNClB1ZWJsYSBOYWh1YXRs4oCdPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5Nb3JlIG9mIHRoZXNlIGFyZSBzaW1pbGFyOyBhIGNsb3NlciByZXZpZXcg d291bGQgYmUgbmVlZGVkIHRvIGRldGVybWluZQ0Kd2hpY2ggb2YgdGhlc2UgY2hhbmdlcyB3b3Vs ZCByZWFsbHkgbWFrZSBzZW5zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5QZXRlciA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gTWFyayBEYXZpcw0KW21haWx0bzpt YXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10gPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+Q0hBTkdFIFRPIFNFTUktQ09MT048YnI+DQo8YnI+DQpZaSwgU2ljaHVhbiZuYnNw OyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBZaTsgU2ljaHVhbjxicj4NCkF5 dGEsIEFtYmFsYSZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBBeXRh OyBBbWJhbGEgPGJyPg0KQWd0YSwgQ2FtYXJpbmVzIE5vcnRlJm5ic3A7Jm5ic3A7Jm5ic3A7ID0m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFndGE7IENhbWFyaW5lcw0KTm9ydGU8YnI+DQpBeXRhLCBB YmVubGVuJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF5dGE7IEFi ZW5sZW48YnI+DQpNYWxheSwgQW1ib25lc2UmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsm bmJzcDsmbmJzcDsgTWFsYXk7IEFtYm9uZXNlPGJyPg0KQWRpLCBHYWxvJm5ic3A7Jm5ic3A7Jm5i c3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFkaTsgR2Fsbzxicj4NClRpYmV0YW4sIEFtZG8m bmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGliZXRhbjsgQW1kbyA8 YnI+DQpBbWlzLCBOYXRhb3JhbiZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBBbWlzOyBOYXRhb3Jhbjxicj4NCkFtdXpnbywgR3VlcnJlcm8mbmJzcDsmbmJzcDsmbmJz cDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQW11emdvOyBHdWVycmVybzxicj4NCkFyYXBlc2gs IEJ1bWJpdGEmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJhcGVz aDsgQnVtYml0YTxicj4NCkFzbWF0LCBDYXN1YXJpbmEgQ29hc3QmbmJzcDsmbmJzcDsmbmJzcDsg PSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQXNtYXQ7DQpDYXN1YXJpbmEgQ29hc3Q8YnI+DQpBc3Vy aW4mYW1wOyN4RUQ7LCBYaW5nJmFtcDsjeEZBOyZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOw0KQXN1cmluJmFtcDsjeEVEOzsgWGluZyZhbXA7I3hGQTsgPGJyPg0KQXNt YXQsIFlhb3Nha29yJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFz bWF0OyBZYW9zYWtvcjxicj4NCk1hbm9ibywgQXRhJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE1hbm9ibzsgQXRhPGJyPg0KT25lLCBNb2xtbyZuYnNwOyZuYnNwOyZu YnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBPbmU7IE1vbG1vPGJyPg0KR2JlLCBBeWl6byZu YnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBHYmU7IEF5aXpvPGJyPg0K QXR0YSwgRmFpcmUmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQXR0 YTsgRmFpcmU8YnI+DQpOYWh1YXRsLCBIaWdobGFuZCBQdWVibGEmbmJzcDsmbmJzcDsmbmJzcDsg PSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTmFodWF0bDsNCkhpZ2hsYW5kIFB1ZWJsYSA8YnI+DQpL YXlhbiwgQnVzYW5nJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEth eWFuOyBCdXNhbmc8YnI+DQpCaXJpZm9yLCBNYWxiYSZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBCaXJpZm9yOyBNYWxiYTxicj4NClBhaGFyaSwgTWFoYXN1Jm5ic3A7 Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhaGFyaTsgTWFoYXN1PGJyPg0K QmFyZWxpLCBSYXRod2kmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsg QmFyZWxpOyBSYXRod2k8YnI+DQpDaGluLCBCYXdtJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENoaW47IEJhd208YnI+DQpCJmFtcDsjeEU5O3RlLCBHdWliZXJvdWEm bmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsNCkImYW1wOyN4RTk7dGU7 IEd1aWJlcm91YSA8YnI+DQpCJmFtcDsjeEU5O3QmYW1wOyN4RTk7LCBEYWxvYSZuYnNwOyZuYnNw OyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOw0KQiZhbXA7I3hFOTt0JmFtcDsjeEU5Ozsg RGFsb2E8YnI+DQpCYXJlbGksIFBhdXJpJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEJhcmVsaTsgUGF1cmk8YnI+DQpJdG5lZywgQmFuYW8mbmJzcDsmbmJzcDsmbmJz cDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSXRuZWc7IEJhbmFvPGJyPg0KU29yc29nb24sIE1h c2JhdGUmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgU29yc29nb247 IE1hc2JhdGU8YnI+DQpLYXJlbiwgUGEnbyZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBLYXJlbjsgUGEnbyA8YnI+DQpBeXRhLCBNYWctSW5kaSZuYnNwOyZuYnNwOyZu YnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBBeXRhOyBNYWctSW5kaTxicj4NCkthbnVyaSwg QmlsbWEmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgS2FudXJpOyBC aWxtYTxicj4NCi4uLjxicj4NCjxicj4NCk5PVEU8YnI+DQpBcyBJIHdhcyBkb2luZyB0aGlzLCBJ IHNhdyB0aGUgZm9sbG93aW5nLiBJdCBtYXkgYmUgcGVyZmVjdGx5IGZpbmUsIGJ1dCBpdCBsb29r cw0KYSBiaXQgc3VzcGljaW91cywgZXNwZWNpYWxseSBzaW5jZSB0aGVyZSBhcmUgYSBidW5jaCBv ZiAmcXVvdDtBdGdhJnF1b3Q7DQplbnRyaWVzIHdpdGggZGlmZmVyZW50IG1vZGlmaWVycy4gQ291 bGQgdGhpcyBiZSBhIHNwZWxsaW5nIGVycm9yPyA8YnI+DQo8YnI+DQpBZ3RhLCBNdC4gSXJheWEg PGJyPg0KPGJyPg0KTWFyazxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gY2xhc3M9Z21haWxxdW90ZT5PbiAxMC85LzA2LCA8Yj5NYXJ0aW4gRHVlcnN0 IDwvYj4mbHQ7PGENCmhyZWY9Im1haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwIiB0YXJnZXQ9 Il9ibGFuayI+ZHVlcnN0QGl0LmFveWFtYS5hYy5qcDwvYT4mZ3Q7DQp3cm90ZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPltjby1jaGFpciBoYXQgb2ZmXTxicj4NCjxicj4NCkF0IDAyOjIyIDA2LzEwLzAzLCBN YXJrIERhdmlzIHdyb3RlOjxicj4NCiZndDtPdmVyYWxsLCBJIHRoaW5rIGludmVydGVkIG5hbWVz IGFyZSBhIGJhZCBpZGVhLiBUaGV5IGFyZSByYXRoZXINCmFuZ2xvY2VudHJpYywgYW5kIHdlIGZp bmQgdGhhdCB0cmFuc2xhdG9ycyBvZnRlbiBkbyB0aGUgd3JvbmcgdGhpbmcgd2l0aCB0aGVtLg0K VGhleSBhcmUgYWxzbyBodWdlbHkgaW5jb25zaXN0ZW50IGluIHRoZSBjdXJyZW50IHJlZ2lzdHJ5 LiA8YnI+DQomZ3Q7PGJyPg0KJmd0O0kgdGhpbmsgdGhleSBhcmUgdG9sZXJhYmxlIGlmIChhKSBl dmVyeSBzaW5nbGUgaW5zdGFuY2Ugb2YgYSBjb21tYQ0KaW5kaWNhdGVzIGFuIGludmVydGVkIG5h bWUsIGFuZCAoYikgYWxsIG5hbWVzIGFyZSBjb25zaXN0ZW50bHkgaW52ZXJ0ZWQuDQpCZWNhdXNl IG9mIChhKSBvbmUgY291bGQgcHJvZ3JhbW1hdGljYWxseSBmaXggdGhlIG5hbWVzIHRvIHRoZSBj b3JyZWN0IHZhbHVlLiA8YnI+DQo8YnI+DQpJIGRvbid0IHRoaW5rIGNyZWF0aW5nIGFydGlmaWNp YWwgc3ludGF4IHJ1bGVzIG9yIHNvbWU8YnI+DQpraW5kIG9mIHJlc3RyaWN0ZWQgKEVuZ2xpc2gp IGdyYW1tYXIgZm9yIERlc2NyaXB0aW9uIGZpZWxkczxicj4NCmlzIGFwcHJvcHJpYXRlLiBXaGF0 IEkgY2FuIGltbWFnaW5lIGlzIHRoYXQgd2UgdXNlIHNlbWljb2xvbnM8YnI+DQpyYXRoZXIgdGhh biBjb21tYXMgdG8gaW5kaWNhdGUgYm91bmRhcmllcyBiZXR3ZWVuIGlucHV0IDxicj4NCmZyb20g ZGlmZmVyZW50IG9yaWdpbnMuPGJyPg0KPGJyPg0KUmVnYXJkcywmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtNYXJ0aW4uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KIy0jLSMmbmJzcDsmbmJzcDtNYXJ0 aW4gSi4gRHUmcXVvdDtyc3QsIEFzc29jLiBQcm9mZXNzb3IsIEFveWFtYSBHYWt1aW4NClVuaXZl cnNpdHk8YnI+DQojLSMtIyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuc3cuaXQuYW95 YW1hLmFjLmpwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LnN3Lml0LmFveWFtYS5hYy5q cCA8L2E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1haWx0bzo8YQ0KaHJl Zj0ibWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMuanAiIHRhcmdldD0iX2JsYW5rIj5kdWVyc3RA aXQuYW95YW1hLmFjLmpwPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8 L2h0bWw+DQo= ------_=_NextPart_001_01C6F145.329506DD-- --===============0086585507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0086585507==-- From ltru-bounces@ietf.org Mon Oct 16 13:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZW58-0006pR-VZ; Mon, 16 Oct 2006 13:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZW57-0006oj-UR for ltru@ietf.org; Mon, 16 Oct 2006 13:16:53 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZW57-0003OJ-5T for ltru@ietf.org; Mon, 16 Oct 2006 13:16:53 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Mon, 16 Oct 2006 10:16:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 16 Oct 2006 10:16:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry deltas Date: Mon, 16 Oct 2006 10:16:48 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Registry deltas thread-index: AcbwrKbR1Ka3HndkSLqb786PbbfsvAAls8ewAAB3IhA= References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81><20061002153915.GD22365@ccil.org><30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com><6.0.0.20.2.20061009180149.06995380@localhost><30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> From: Peter Constable To: Peter Constable , LTRU Working Group X-OriginalArrivalTime: 16 Oct 2006 17:16:52.0403 (UTC) FILETIME=[DF5C9830:01C6F146] X-Spam-Score: 1.2 (+) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0771051733==" Errors-To: ltru-bounces@ietf.org --===============0771051733== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F146.DE4ED3AC" ------_=_NextPart_001_01C6F146.DE4ED3AC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QlRXLCBJIG1lYW50IHRvIGFkZCBpbiB0aGlzIGRpc2N1c3Npb24gb2YgaW52ZXJ0ZWQgbmFtZXMg YW5kIG90aGVyIGFzcGVjdHMgb2YgdGhlIGZvcm1zIG9mIGRlc2NyaXB0aW9ucyAobm90IHJlZ2lz dHJ5IGRlbHRhcyEpLCBpZiB0aGVyZSBpcyBmZWVkYmFjayB0aGF0IHRoaXMgV0cgd291bGQgd2Fu dCB0byBzZW5kIGJhY2sgdG8gdGhlIElTTyA2MzkgSkFDIGZvciB0aGVpciBjb25zaWRlcmF0aW9u IGFzIHRvIGNoYW5nZXMgdGhleSBjb3VsZCBtYWtlIGluIHRoZSBkZXNjcmlwdGlvbnMgdGhhdCB3 b3VsZCBtYWtlIHRoaW5ncyBlYXNpZXIgZm9yIHRoZSBMU1IsIHRoaXMgaXMgYSBnb29kIHRpbWUg dG8gc3VibWl0IHRoYXQgYXMgdGhlIEpBQyB3aWxsIGJlIG1lZXRpbmcgaW4gYSBjb3VwbGUgb2Yg d2Vla3MgKHRlbGVjb25mKSB0byBkaXNjdXNzIHZhcmlvdXMgaXNzdWVzIHJlbGF0ZWQgdG8gdGhl IGNvbXBsZXRpb24gb2YgcGFydCAzIGFuZCBtYWludGVuYW5jZSBvZiB0aGUgdmFyaW91cyBwYXJ0 cyBpbiByZWxhdGlvbiB0byBvbmUgYW5vdGhlci4gVGhlcmUgaGF2ZSBiZWVuIHNvbWUgcGxhbnMg dG8gd29yayBvbiBuYW1lcyAoZS5nLiB0aGUgNjM5LTMgUkEgaGFkIGEgd29yayBpdGVtIHRvIHJl dmlldyB0aGUgbmFtZXMgaW4gdGhlIDYzOS0zIGRyYWZ0IGNvZGUgdGFibGUgdG8gaW1wcm92ZSBj b25zaXN0ZW5jeSwgZXNwZWNpYWxseSB3aGVyZSB0aGUgZHJhZnQgY29kZSB0YWJsZSBmb3IgcGFy dCAzIGRvZXNu4oCZdCBoYXZlIG5hbWVzIHRoYXQgYXJlIHdpZGVseSB1c2VkLCBzdWNoIGFzIOKA nERhcmnigJ0pLg0KDQogDQoNCihBbHNvLCBidHc6IHNlZWluZyB0aGUgcHJvYmxlbXMgd2UgaGF2 ZSB3aXRoIG1hbmFnaW5nIGRlc2NyaXB0aW9uIGZpZWxkcyBoYXMgZm9yIHRoZSBmaXJzdCB0aW1l IG1hZGUgbWUgd29uZGVyIGlmIHRoZSBmb3JtYWwgb3ZlcmhlYWQgb2YgSVNPIDExMTc5IG1pZ2h0 IG5vdCBvZmZlciBzb21lIGJlbmVmaXQuIEkgZG9u4oCZdCBrbm93IGVub3VnaCBhYm91dCAxMTE3 OSB0byBiZSBhYmxlIHRvIGFuc3dlciB0aGF0OyBpdOKAmXMganVzdCBhIHF1ZXN0aW9uIHRoYXQg cG9wcGVkIGludG8gbXkgaGVhZC4pDQoNCiANCg0KIA0KDQpQZXRlcg0KDQogDQoNCkZyb206IFBl dGVyIENvbnN0YWJsZSBbbWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb21dIA0KU2VudDogTW9u ZGF5LCBPY3RvYmVyIDE2LCAyMDA2IDEwOjA1IEFNDQpUbzogTFRSVSBXb3JraW5nIEdyb3VwDQpT dWJqZWN0OiBSRTogW0x0cnVdIFJlOiBSZWdpc3RyeSBkZWx0YXMNCg0KIA0KDQpEZWZpbml0ZWx5 IHNvbWUgb2YgdGhlIGNoYW5nZXMgYmVsb3cgd291bGQgYmUgd3Jvbmc6IGUuZy4sIA0KDQogDQoN Ci0gICAgICAgIOKAnFlpLCBTaWNodWFu4oCdIGlzIGFuIGludmVydGVkIGZvcm0gb2Yg4oCcU2lj aHVhbiBZaeKAnQ0KDQotICAgICAgICDigJxBZ3RhLCBDYW1hcmluZXMgTm9ydGXigJ0gaXMgYW4g aW52ZXJ0ZWQgZm9ybSBvZiDigJxDYW1hcmluZXMgTm9ydGUgQWd0YeKAnQ0KDQotICAgICAgICDi gJxNYWxheSwgQW1ib25lc2XigJ0gaXMgYW4gaW52ZXJ0ZWQgZm9ybSBvZiDigJxBbWJvbmVzZSBN YWxheeKAnTsg4oCcQW1ib25lc2XigJ0gaXMgYW4gYWx0ZXJuYXRlIG5hbWUsIGJ1dCDigJxNYWxh eeKAnSBwcm9iYWJseSBpc27igJl0IGEgZ29vZCBjaG9pY2UgZm9yIGFuIGFsdGVybmF0ZSBuYW1l IHNpbmNlIHRoYXQgd291bGQgZ2VuZXJhbGx5IGJlIHVuZGVyc3Rvb2QgYXMgQmFoYXNhIE1hbGF5 c2lhDQoNCi0gICAgICAgIOKAnE5haHVhdGwsIEhpZ2hsYW5kIFB1ZWJsYeKAnSBpcyBhbiBpbnZl cnRlZCBmb3JtIG9mIOKAnEhpZ2hsYW5kIFB1ZWJsYSBOYWh1YXRs4oCdDQoNCiANCg0KTW9yZSBv ZiB0aGVzZSBhcmUgc2ltaWxhcjsgYSBjbG9zZXIgcmV2aWV3IHdvdWxkIGJlIG5lZWRlZCB0byBk ZXRlcm1pbmUgd2hpY2ggb2YgdGhlc2UgY2hhbmdlcyB3b3VsZCByZWFsbHkgbWFrZSBzZW5zZS4N Cg0KIA0KDQogDQoNClBldGVyIA0KDQogDQoNCkZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJr LmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10gDQoNCkNIQU5HRSBUTyBTRU1JLUNPTE9ODQoNCllpLCBT aWNodWFuICAgID0+ICAgIFlpOyBTaWNodWFuDQpBeXRhLCBBbWJhbGEgICAgPT4gICAgQXl0YTsg QW1iYWxhIA0KQWd0YSwgQ2FtYXJpbmVzIE5vcnRlICAgID0+ICAgIEFndGE7IENhbWFyaW5lcyBO b3J0ZQ0KQXl0YSwgQWJlbmxlbiAgICA9PiAgICBBeXRhOyBBYmVubGVuDQpNYWxheSwgQW1ib25l c2UgICAgPT4gICAgTWFsYXk7IEFtYm9uZXNlDQpBZGksIEdhbG8gICAgPT4gICAgQWRpOyBHYWxv DQpUaWJldGFuLCBBbWRvICAgID0+ICAgIFRpYmV0YW47IEFtZG8gDQpBbWlzLCBOYXRhb3JhbiAg ICA9PiAgICBBbWlzOyBOYXRhb3Jhbg0KQW11emdvLCBHdWVycmVybyAgICA9PiAgICBBbXV6Z287 IEd1ZXJyZXJvDQpBcmFwZXNoLCBCdW1iaXRhICAgID0+ICAgIEFyYXBlc2g7IEJ1bWJpdGENCkFz bWF0LCBDYXN1YXJpbmEgQ29hc3QgICAgPT4gICAgQXNtYXQ7IENhc3VhcmluYSBDb2FzdA0KQXN1 cmluJiN4RUQ7LCBYaW5nJiN4RkE7ICAgID0+ICAgIEFzdXJpbiYjeEVEOzsgWGluZyYjeEZBOyAN CkFzbWF0LCBZYW9zYWtvciAgICA9PiAgICBBc21hdDsgWWFvc2Frb3INCk1hbm9ibywgQXRhICAg ID0+ICAgIE1hbm9ibzsgQXRhDQpPbmUsIE1vbG1vICAgID0+ICAgIE9uZTsgTW9sbW8NCkdiZSwg QXlpem8gICAgPT4gICAgR2JlOyBBeWl6bw0KQXR0YSwgRmFpcmUgICAgPT4gICAgQXR0YTsgRmFp cmUNCk5haHVhdGwsIEhpZ2hsYW5kIFB1ZWJsYSAgICA9PiAgICBOYWh1YXRsOyBIaWdobGFuZCBQ dWVibGEgDQpLYXlhbiwgQnVzYW5nICAgID0+ICAgIEtheWFuOyBCdXNhbmcNCkJpcmlmb3IsIE1h bGJhICAgID0+ICAgIEJpcmlmb3I7IE1hbGJhDQpQYWhhcmksIE1haGFzdSAgICA9PiAgICBQYWhh cmk7IE1haGFzdQ0KQmFyZWxpLCBSYXRod2kgICAgPT4gICAgQmFyZWxpOyBSYXRod2kNCkNoaW4s IEJhd20gICAgPT4gICAgQ2hpbjsgQmF3bQ0KQiYjeEU5O3RlLCBHdWliZXJvdWEgICAgPT4gICAg QiYjeEU5O3RlOyBHdWliZXJvdWEgDQpCJiN4RTk7dCYjeEU5OywgRGFsb2EgICAgPT4gICAgQiYj eEU5O3QmI3hFOTs7IERhbG9hDQpCYXJlbGksIFBhdXJpICAgID0+ICAgIEJhcmVsaTsgUGF1cmkN Ckl0bmVnLCBCYW5hbyAgICA9PiAgICBJdG5lZzsgQmFuYW8NClNvcnNvZ29uLCBNYXNiYXRlICAg ID0+ICAgIFNvcnNvZ29uOyBNYXNiYXRlDQpLYXJlbiwgUGEnbyAgICA9PiAgICBLYXJlbjsgUGEn byANCkF5dGEsIE1hZy1JbmRpICAgID0+ICAgIEF5dGE7IE1hZy1JbmRpDQpLYW51cmksIEJpbG1h ICAgID0+ICAgIEthbnVyaTsgQmlsbWENCi4uLg0KDQpOT1RFDQpBcyBJIHdhcyBkb2luZyB0aGlz LCBJIHNhdyB0aGUgZm9sbG93aW5nLiBJdCBtYXkgYmUgcGVyZmVjdGx5IGZpbmUsIGJ1dCBpdCBs b29rcyBhIGJpdCBzdXNwaWNpb3VzLCBlc3BlY2lhbGx5IHNpbmNlIHRoZXJlIGFyZSBhIGJ1bmNo IG9mICJBdGdhIiBlbnRyaWVzIHdpdGggZGlmZmVyZW50IG1vZGlmaWVycy4gQ291bGQgdGhpcyBi ZSBhIHNwZWxsaW5nIGVycm9yPyANCg0KQWd0YSwgTXQuIElyYXlhIA0KDQpNYXJrDQoNCk9uIDEw LzkvMDYsIE1hcnRpbiBEdWVyc3QgPGR1ZXJzdEBpdC5hb3lhbWEuYWMuanA+IHdyb3RlOg0KDQpb Y28tY2hhaXIgaGF0IG9mZl0NCg0KQXQgMDI6MjIgMDYvMTAvMDMsIE1hcmsgRGF2aXMgd3JvdGU6 DQo+T3ZlcmFsbCwgSSB0aGluayBpbnZlcnRlZCBuYW1lcyBhcmUgYSBiYWQgaWRlYS4gVGhleSBh cmUgcmF0aGVyIGFuZ2xvY2VudHJpYywgYW5kIHdlIGZpbmQgdGhhdCB0cmFuc2xhdG9ycyBvZnRl biBkbyB0aGUgd3JvbmcgdGhpbmcgd2l0aCB0aGVtLiBUaGV5IGFyZSBhbHNvIGh1Z2VseSBpbmNv bnNpc3RlbnQgaW4gdGhlIGN1cnJlbnQgcmVnaXN0cnkuIA0KPg0KPkkgdGhpbmsgdGhleSBhcmUg dG9sZXJhYmxlIGlmIChhKSBldmVyeSBzaW5nbGUgaW5zdGFuY2Ugb2YgYSBjb21tYSBpbmRpY2F0 ZXMgYW4gaW52ZXJ0ZWQgbmFtZSwgYW5kIChiKSBhbGwgbmFtZXMgYXJlIGNvbnNpc3RlbnRseSBp bnZlcnRlZC4gQmVjYXVzZSBvZiAoYSkgb25lIGNvdWxkIHByb2dyYW1tYXRpY2FsbHkgZml4IHRo ZSBuYW1lcyB0byB0aGUgY29ycmVjdCB2YWx1ZS4gDQoNCkkgZG9uJ3QgdGhpbmsgY3JlYXRpbmcg YXJ0aWZpY2lhbCBzeW50YXggcnVsZXMgb3Igc29tZQ0Ka2luZCBvZiByZXN0cmljdGVkIChFbmds aXNoKSBncmFtbWFyIGZvciBEZXNjcmlwdGlvbiBmaWVsZHMNCmlzIGFwcHJvcHJpYXRlLiBXaGF0 IEkgY2FuIGltbWFnaW5lIGlzIHRoYXQgd2UgdXNlIHNlbWljb2xvbnMNCnJhdGhlciB0aGFuIGNv bW1hcyB0byBpbmRpY2F0ZSBib3VuZGFyaWVzIGJldHdlZW4gaW5wdXQgDQpmcm9tIGRpZmZlcmVu dCBvcmlnaW5zLg0KDQpSZWdhcmRzLCAgICBNYXJ0aW4uDQoNCg0KDQojLSMtIyAgTWFydGluIEou IER1InJzdCwgQXNzb2MuIFByb2Zlc3NvciwgQW95YW1hIEdha3VpbiBVbml2ZXJzaXR5DQojLSMt IyAgIGh0dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpwIDxodHRwOi8vd3d3LnN3Lml0LmFveWFt YS5hYy5qcD4gICAgICAgIG1haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwDQoNCiANCg0K ------_=_NextPart_001_01C6F146.DE4ED3AC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpEPSJE QVY6IiB4bWxuczp4Mj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvZXhjZWwv MjAwMy94bWwiIHhtbG5zOm9pcz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3No YXJlcG9pbnQvc29hcC9kaXJlY3RvcnkvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAw MC8wOS94bWxkc2lnIyIgeG1sbnM6dWRjPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2Rh dGEvdWRjIiB4bWxuczp4c2Q9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxu czpzcHM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1s bnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM6 dWRjeGY9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMveG1sZmlsZSIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczpleDEydD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9leGNoYW5nZS9zZXJ2aWNl cy8yMDA2L3R5cGVzIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoN CjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29m dCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpQTWluZ0xpVTsNCglwYW5v c2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwO30NCiAvKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4t dG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdp bi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmdtYWlscXVvdGUNCgl7bXNvLXN0 eWxlLW5hbWU6Z21haWxfcXVvdGU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIwNzQ1MzA0MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTY5MjgwNDY2MCA0MTk4NDg2OTIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpQTWluZ0xpVTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1F Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkJUVywgSSBtZWFudCB0 byBhZGQgaW4gdGhpcyBkaXNjdXNzaW9uIG9mIGludmVydGVkIG5hbWVzIGFuZA0Kb3RoZXIgYXNw ZWN0cyBvZiB0aGUgZm9ybXMgb2YgZGVzY3JpcHRpb25zIChub3QgcmVnaXN0cnkgZGVsdGFzISks IGlmIHRoZXJlIGlzDQpmZWVkYmFjayB0aGF0IHRoaXMgV0cgd291bGQgd2FudCB0byBzZW5kIGJh Y2sgdG8gdGhlIElTTyA2MzkgSkFDIGZvciB0aGVpcg0KY29uc2lkZXJhdGlvbiBhcyB0byBjaGFu Z2VzIHRoZXkgY291bGQgbWFrZSBpbiB0aGUgZGVzY3JpcHRpb25zIHRoYXQgd291bGQgbWFrZQ0K dGhpbmdzIGVhc2llciBmb3IgdGhlIExTUiwgdGhpcyBpcyBhIGdvb2QgdGltZSB0byBzdWJtaXQg dGhhdCBhcyB0aGUgSkFDIHdpbGwNCmJlIG1lZXRpbmcgaW4gYSBjb3VwbGUgb2Ygd2Vla3MgKHRl bGVjb25mKSB0byBkaXNjdXNzIHZhcmlvdXMgaXNzdWVzIHJlbGF0ZWQgdG8NCnRoZSBjb21wbGV0 aW9uIG9mIHBhcnQgMyBhbmQgbWFpbnRlbmFuY2Ugb2YgdGhlIHZhcmlvdXMgcGFydHMgaW4gcmVs YXRpb24gdG8NCm9uZSBhbm90aGVyLiBUaGVyZSBoYXZlIGJlZW4gc29tZSBwbGFucyB0byB3b3Jr IG9uIG5hbWVzIChlLmcuIHRoZSA2MzktMyBSQSBoYWQNCmEgd29yayBpdGVtIHRvIHJldmlldyB0 aGUgbmFtZXMgaW4gdGhlIDYzOS0zIGRyYWZ0IGNvZGUgdGFibGUgdG8gaW1wcm92ZQ0KY29uc2lz dGVuY3ksIGVzcGVjaWFsbHkgd2hlcmUgdGhlIGRyYWZ0IGNvZGUgdGFibGUgZm9yIHBhcnQgMyBk b2VzbuKAmXQgaGF2ZSBuYW1lcw0KdGhhdCBhcmUgd2lkZWx5IHVzZWQsIHN1Y2ggYXMg4oCcRGFy aeKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4oQWxzbywgYnR3OiBzZWVpbmcg dGhlIHByb2JsZW1zIHdlIGhhdmUgd2l0aCBtYW5hZ2luZw0KZGVzY3JpcHRpb24gZmllbGRzIGhh cyBmb3IgdGhlIGZpcnN0IHRpbWUgbWFkZSBtZSB3b25kZXIgaWYgdGhlIGZvcm1hbCBvdmVyaGVh ZA0Kb2YgSVNPIDExMTc5IG1pZ2h0IG5vdCBvZmZlciBzb21lIGJlbmVmaXQuIEkgZG9u4oCZdCBr bm93IGVub3VnaCBhYm91dCAxMTE3OSB0bw0KYmUgYWJsZSB0byBhbnN3ZXIgdGhhdDsgaXTigJlz IGp1c3QgYSBxdWVzdGlvbiB0aGF0IHBvcHBlZCBpbnRvIG15IGhlYWQuKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlBldGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IFBldGVyIENvbnN0YWJsZQ0KW21haWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29t XSA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDE2LCAyMDA2IDEwOjA1IEFNPGJy Pg0KPGI+VG86PC9iPiBMVFJVIFdvcmtpbmcgR3JvdXA8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtMdHJ1XSBSZTogUmVnaXN0cnkgZGVsdGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rp dj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5EZWZpbml0ZWx5 IHNvbWUgb2YgdGhlIGNoYW5nZXMgYmVsb3cgd291bGQgYmUgd3Jvbmc6IGUuZy4sIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPuKAnFlpLCBT aWNodWFu4oCdIGlzIGFuIGludmVydGVkIGZvcm0gb2Yg4oCcU2ljaHVhbiBZaeKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3Bhbg0Kc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+4oCcQWd0YSwgQ2FtYXJpbmVzIE5vcnRl4oCd IGlzIGFuIGludmVydGVkIGZvcm0gb2Yg4oCcQ2FtYXJpbmVzIE5vcnRlDQpBZ3Rh4oCdPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuDQpzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl Jz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz7igJxNYWxheSwgQW1ib25lc2XigJ0gaXMg YW4gaW52ZXJ0ZWQgZm9ybSBvZiDigJxBbWJvbmVzZSBNYWxheeKAnTsNCuKAnEFtYm9uZXNl4oCd IGlzIGFuIGFsdGVybmF0ZSBuYW1lLCBidXQg4oCcTWFsYXnigJ0gcHJvYmFibHkgaXNu4oCZdCBh IGdvb2QgY2hvaWNlIGZvcg0KYW4gYWx0ZXJuYXRlIG5hbWUgc2luY2UgdGhhdCB3b3VsZCBnZW5l cmFsbHkgYmUgdW5kZXJzdG9vZCBhcyBCYWhhc2EgTWFsYXlzaWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PHNwYW4NCnN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPuKAnE5haHVhdGwsIEhpZ2hsYW5kIFB1ZWJsYeKAnSBpcyBhbiBp bnZlcnRlZCBmb3JtIG9mIOKAnEhpZ2hsYW5kDQpQdWVibGEgTmFodWF0bOKAnTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+TW9yZSBvZiB0aGVzZSBhcmUgc2ltaWxhcjsgYSBjbG9zZXIg cmV2aWV3IHdvdWxkIGJlIG5lZWRlZCB0bw0KZGV0ZXJtaW5lIHdoaWNoIG9mIHRoZXNlIGNoYW5n ZXMgd291bGQgcmVhbGx5IG1ha2Ugc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+UGV0ZXIgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz4gTWFyayBEYXZpcw0KW21haWx0bzptYXJrLmRhdmlzQGljdS1wcm9q ZWN0Lm9yZ10gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Q0hBTkdFIFRPIFNFTUktQ09MT048 YnI+DQo8YnI+DQpZaSwgU2ljaHVhbiZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBZaTsgU2ljaHVhbjxicj4NCkF5dGEsIEFtYmFsYSZuYnNwOyZuYnNwOyZuYnNwOyA9 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBBeXRhOyBBbWJhbGEgPGJyPg0KQWd0YSwgQ2FtYXJpbmVz IE5vcnRlJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFndGE7IENh bWFyaW5lcw0KTm9ydGU8YnI+DQpBeXRhLCBBYmVubGVuJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF5dGE7IEFiZW5sZW48YnI+DQpNYWxheSwgQW1ib25lc2UmbmJz cDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTWFsYXk7IEFtYm9uZXNlPGJy Pg0KQWRpLCBHYWxvJm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFk aTsgR2Fsbzxicj4NClRpYmV0YW4sIEFtZG8mbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsm bmJzcDsmbmJzcDsgVGliZXRhbjsgQW1kbyA8YnI+DQpBbWlzLCBOYXRhb3JhbiZuYnNwOyZuYnNw OyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBBbWlzOyBOYXRhb3Jhbjxicj4NCkFtdXpn bywgR3VlcnJlcm8mbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQW11 emdvOyBHdWVycmVybzxicj4NCkFyYXBlc2gsIEJ1bWJpdGEmbmJzcDsmbmJzcDsmbmJzcDsgPSZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJhcGVzaDsgQnVtYml0YTxicj4NCkFzbWF0LCBDYXN1YXJp bmEgQ29hc3QmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQXNtYXQ7 DQpDYXN1YXJpbmEgQ29hc3Q8YnI+DQpBc3VyaW4mYW1wOyN4RUQ7LCBYaW5nJmFtcDsjeEZBOyZu YnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOw0KQXN1cmluJmFtcDsjeEVE OzsgWGluZyZhbXA7I3hGQTsgPGJyPg0KQXNtYXQsIFlhb3Nha29yJm5ic3A7Jm5ic3A7Jm5ic3A7 ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzbWF0OyBZYW9zYWtvcjxicj4NCk1hbm9ibywgQXRh Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1hbm9ibzsgQXRhPGJy Pg0KT25lLCBNb2xtbyZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBP bmU7IE1vbG1vPGJyPg0KR2JlLCBBeWl6byZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBHYmU7IEF5aXpvPGJyPg0KQXR0YSwgRmFpcmUmbmJzcDsmbmJzcDsmbmJzcDsg PSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQXR0YTsgRmFpcmU8YnI+DQpOYWh1YXRsLCBIaWdobGFu ZCBQdWVibGEmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTmFodWF0 bDsNCkhpZ2hsYW5kIFB1ZWJsYSA8YnI+DQpLYXlhbiwgQnVzYW5nJm5ic3A7Jm5ic3A7Jm5ic3A7 ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtheWFuOyBCdXNhbmc8YnI+DQpCaXJpZm9yLCBNYWxi YSZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBCaXJpZm9yOyBNYWxi YTxicj4NClBhaGFyaSwgTWFoYXN1Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFBhaGFyaTsgTWFoYXN1PGJyPg0KQmFyZWxpLCBSYXRod2kmbmJzcDsmbmJzcDsmbmJz cDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFyZWxpOyBSYXRod2k8YnI+DQpDaGluLCBCYXdt Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoaW47IEJhd208YnI+ DQpCJmFtcDsjeEU5O3RlLCBHdWliZXJvdWEmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsm bmJzcDsmbmJzcDsNCkImYW1wOyN4RTk7dGU7IEd1aWJlcm91YSA8YnI+DQpCJmFtcDsjeEU5O3Qm YW1wOyN4RTk7LCBEYWxvYSZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNw Ow0KQiZhbXA7I3hFOTt0JmFtcDsjeEU5OzsgRGFsb2E8YnI+DQpCYXJlbGksIFBhdXJpJm5ic3A7 Jm5ic3A7Jm5ic3A7ID0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhcmVsaTsgUGF1cmk8YnI+DQpJ dG5lZywgQmFuYW8mbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSXRu ZWc7IEJhbmFvPGJyPg0KU29yc29nb24sIE1hc2JhdGUmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsm bmJzcDsmbmJzcDsmbmJzcDsgU29yc29nb247IE1hc2JhdGU8YnI+DQpLYXJlbiwgUGEnbyZuYnNw OyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBLYXJlbjsgUGEnbyA8YnI+DQpB eXRhLCBNYWctSW5kaSZuYnNwOyZuYnNwOyZuYnNwOyA9Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBB eXRhOyBNYWctSW5kaTxicj4NCkthbnVyaSwgQmlsbWEmbmJzcDsmbmJzcDsmbmJzcDsgPSZndDsm bmJzcDsmbmJzcDsmbmJzcDsgS2FudXJpOyBCaWxtYTxicj4NCi4uLjxicj4NCjxicj4NCk5PVEU8 YnI+DQpBcyBJIHdhcyBkb2luZyB0aGlzLCBJIHNhdyB0aGUgZm9sbG93aW5nLiBJdCBtYXkgYmUg cGVyZmVjdGx5IGZpbmUsIGJ1dCBpdA0KbG9va3MgYSBiaXQgc3VzcGljaW91cywgZXNwZWNpYWxs eSBzaW5jZSB0aGVyZSBhcmUgYSBidW5jaCBvZiAmcXVvdDtBdGdhJnF1b3Q7DQplbnRyaWVzIHdp dGggZGlmZmVyZW50IG1vZGlmaWVycy4gQ291bGQgdGhpcyBiZSBhIHNwZWxsaW5nIGVycm9yPyA8 YnI+DQo8YnI+DQpBZ3RhLCBNdC4gSXJheWEgPGJyPg0KPGJyPg0KTWFyazxvOnA+PC9vOnA+PC9w Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9Z21haWxxdW90ZT5P biAxMC85LzA2LCA8Yj5NYXJ0aW4gRHVlcnN0IDwvYj4mbHQ7PGENCmhyZWY9Im1haWx0bzpkdWVy c3RAaXQuYW95YW1hLmFjLmpwIiB0YXJnZXQ9Il9ibGFuayI+ZHVlcnN0QGl0LmFveWFtYS5hYy5q cDwvYT4mZ3Q7DQp3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPltjby1jaGFpciBoYXQgb2ZmXTxicj4N Cjxicj4NCkF0IDAyOjIyIDA2LzEwLzAzLCBNYXJrIERhdmlzIHdyb3RlOjxicj4NCiZndDtPdmVy YWxsLCBJIHRoaW5rIGludmVydGVkIG5hbWVzIGFyZSBhIGJhZCBpZGVhLiBUaGV5IGFyZSByYXRo ZXINCmFuZ2xvY2VudHJpYywgYW5kIHdlIGZpbmQgdGhhdCB0cmFuc2xhdG9ycyBvZnRlbiBkbyB0 aGUgd3JvbmcgdGhpbmcgd2l0aCB0aGVtLg0KVGhleSBhcmUgYWxzbyBodWdlbHkgaW5jb25zaXN0 ZW50IGluIHRoZSBjdXJyZW50IHJlZ2lzdHJ5LiA8YnI+DQomZ3Q7PGJyPg0KJmd0O0kgdGhpbmsg dGhleSBhcmUgdG9sZXJhYmxlIGlmIChhKSBldmVyeSBzaW5nbGUgaW5zdGFuY2Ugb2YgYSBjb21t YQ0KaW5kaWNhdGVzIGFuIGludmVydGVkIG5hbWUsIGFuZCAoYikgYWxsIG5hbWVzIGFyZSBjb25z aXN0ZW50bHkgaW52ZXJ0ZWQuDQpCZWNhdXNlIG9mIChhKSBvbmUgY291bGQgcHJvZ3JhbW1hdGlj YWxseSBmaXggdGhlIG5hbWVzIHRvIHRoZSBjb3JyZWN0IHZhbHVlLiA8YnI+DQo8YnI+DQpJIGRv bid0IHRoaW5rIGNyZWF0aW5nIGFydGlmaWNpYWwgc3ludGF4IHJ1bGVzIG9yIHNvbWU8YnI+DQpr aW5kIG9mIHJlc3RyaWN0ZWQgKEVuZ2xpc2gpIGdyYW1tYXIgZm9yIERlc2NyaXB0aW9uIGZpZWxk czxicj4NCmlzIGFwcHJvcHJpYXRlLiBXaGF0IEkgY2FuIGltbWFnaW5lIGlzIHRoYXQgd2UgdXNl IHNlbWljb2xvbnM8YnI+DQpyYXRoZXIgdGhhbiBjb21tYXMgdG8gaW5kaWNhdGUgYm91bmRhcmll cyBiZXR3ZWVuIGlucHV0IDxicj4NCmZyb20gZGlmZmVyZW50IG9yaWdpbnMuPGJyPg0KPGJyPg0K UmVnYXJkcywmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtNYXJ0aW4uPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KIy0jLSMmbmJzcDsmbmJzcDtNYXJ0aW4gSi4gRHUmcXVvdDtyc3QsIEFzc29jLiBQcm9m ZXNzb3IsIEFveWFtYSBHYWt1aW4NClVuaXZlcnNpdHk8YnI+DQojLSMtIyZuYnNwOyZuYnNwOzxh IGhyZWY9Imh0dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpwIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vd3d3LnN3Lml0LmFveWFtYS5hYy5qcCA8L2E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG1haWx0bzo8YQ0KaHJlZj0ibWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMu anAiIHRhcmdldD0iX2JsYW5rIj5kdWVyc3RAaXQuYW95YW1hLmFjLmpwPC9hPjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C6F146.DE4ED3AC-- --===============0771051733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0771051733==-- From ltru-bounces@ietf.org Mon Oct 16 13:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWA1-0002dO-2s; Mon, 16 Oct 2006 13:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZW9z-0002dG-Ov for ltru@ietf.org; Mon, 16 Oct 2006 13:21:55 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZW9y-0004Xz-4G for ltru@ietf.org; Mon, 16 Oct 2006 13:21:55 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Mon, 16 Oct 2006 10:21:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 10:21:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Consensus Date: Mon, 16 Oct 2006 10:21:51 -0700 Message-ID: In-Reply-To: <002f01c6e77a$a6f68d00$6401a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Consensus thread-index: AcbnerJz0HAXRGcaSqKEZL/wsvz8NwJzLMew References: <002f01c6e77a$a6f68d00$6401a8c0@DGBP7M81> From: Peter Constable To: Doug Ewell , LTRU Working Group X-OriginalArrivalTime: 16 Oct 2006 17:21:53.0328 (UTC) FILETIME=[92BA1B00:01C6F147] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540230248==" Errors-To: ltru-bounces@ietf.org --===============0540230248== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbiBhZGQgbXkgdm9pY2UgaW4gZmF2b3VyIG9mIHRoYXQgcGFydGljdWxhciBzdWdnZXN0 aW9uICgiZ2V0IHJpZCBvZiB2YWN1b3VzLi4uIikuDQoNClBldGVyDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5l dF0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAzLCAyMDA2IDExOjAyIFBNDQpUbzogTFRSVSBX b3JraW5nIEdyb3VwDQpTdWJqZWN0OiBbTHRydV0gQ29uc2Vuc3VzDQoNClJhbmR5IGFuZCBNYXJ0 aW4sDQoNClNvIGZhciB0d28gbWVtYmVycyBoYXZlIGFncmVlZCB3aXRoIG15IHByb3Bvc2FsIHRv IGdldCByaWQgb2YgdGhlIA0KdmFjdW91cyAicmVwbGFjZWQgYnkgSVNPIGNvZGUgeHh4IiBjb21t ZW50cyBpbiB0aGUgUkZDIDQ2NDZiaXMgUmVnaXN0cnkuIA0KV2hpbGUgdHdvIGlzIGhhcmRseSBh IG1ham9yaXR5IG9mIHRoZSBXRyBtZW1iZXJzaGlwLCBpdCBtYWtlcyBtZSB3b25kZXIgDQp3aGF0 IG1lY2hhbmlzbSBpcyBnb2luZyB0byBiZSB1c2VkIHRvIGdhdWdlIGNvbnNlbnN1cy4NCg0KU28g ZmFyIEkgaGF2ZW4ndCBzZWVuIGFueSBwcm9ub3VuY2VtZW50cyBvZiByb3VnaCBjb25zZW5zdXMg ZnJvbSBlaXRoZXIgDQpjby1jaGFpciwgb24gZWl0aGVyIGRyYWZ0LCBhbmQgc2luY2Ugd2UgYXJl bid0IHVzaW5nIGFuIGlzc3VlIHRyYWNrZXIgDQp0aGlzIHRpbWUgSSByZWFsbHkgZG9uJ3Qga25v dyBpZiBpc3N1ZXMgbGlrZSB0aGlzIGFyZSBldmVuIGJlaW5nIA0KcmVjb3JkZWQuDQoNCkknbSBz dGFydGluZyB0byBwcmVwYXJlIGRyYWZ0LTQ2NDViaXMtMDEgYmFzZWQgb24gSm9obiBDb3dhbidz IHN1Z2dlc3RlZCANCmNoYW5nZXMsIGFuZCBJJ2QgbGlrZSB0byBrbm93IHdoYXQgdG8gZG8gYWJv dXQgdGhlc2UgY29tbWVudHMuDQoNCi0tDQpEb3VnIEV3ZWxsICAqICBGdWxsZXJ0b24sIENhbGlm b3JuaWEsIFVTQSAgKiAgUkZDIDQ2NDUgICogIFVUTiAjMTQNCmh0dHA6Ly91c2Vycy5hZGVscGhp YS5uZXQvfmRld2VsbC8NCmh0dHA6Ly93d3cxLmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbHRydS1j aGFydGVyLmh0bWwNCmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2ll dGYtbGFuZ3VhZ2VzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnDQpodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============0540230248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0540230248==-- From ltru-bounces@ietf.org Mon Oct 16 13:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWDD-0003Il-Af; Mon, 16 Oct 2006 13:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWDB-0003Id-LQ for ltru@ietf.org; Mon, 16 Oct 2006 13:25:13 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWD9-0004os-Af for ltru@ietf.org; Mon, 16 Oct 2006 13:25:13 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Mon, 16 Oct 2006 10:25:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 10:25:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Errors in prototype 4646bis Registry Date: Mon, 16 Oct 2006 10:25:08 -0700 Message-ID: In-Reply-To: <004d01c6dc71$67a3c8c0$6401a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Errors in prototype 4646bis Registry thread-index: AcbccW5tDt80+zzjTymTgUKKEWUagAU1ntCw References: <004d01c6dc71$67a3c8c0$6401a8c0@DGBP7M81> From: Peter Constable To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 16 Oct 2006 17:25:10.0433 (UTC) FILETIME=[0835F110:01C6F148] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0174953156==" Errors-To: ltru-bounces@ietf.org --===============0174953156== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUgdGhlIGR1cGxpY2F0ZSAiRGltbGkiLCBpdCB3b3VsZCBzZWVtIHJlYXNvbmFibGUgdG8gbWUg dG8gZW1wbG95IHRoZSBzYW1lIG1lY2hhbmlzbSB0aGF0IDYzOS0zIHVzZXM6ICJEaW1saSAobWFj cm9sYW5ndWFnZSkiLg0KDQoNClBldGVyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IERvdWcgRXdlbGwgW21haWx0bzpkZXdlbGxAYWRlbHBoaWEubmV0XSANClNlbnQ6IFR1 ZXNkYXksIFNlcHRlbWJlciAxOSwgMjAwNiA5OjU4IFBNDQpUbzogTFRSVSBXb3JraW5nIEdyb3Vw DQpTdWJqZWN0OiBbTHRydV0gRXJyb3JzIGluIHByb3RvdHlwZSA0NjQ2YmlzIFJlZ2lzdHJ5DQoN ClRoZXJlIGFyZSB0d28gcHJvYmxlbXMgaW4gdGhlIHByb3RvdHlwZSBSRkMgNDY0NmJpcyBSZWdp c3RyeSBJIHBvc3RlZCBhIA0KZmV3IGRheXMgYWdvLg0KDQpUaGUgZmlyc3QgcHJvYmxlbSBpcyBh biBleHRyYSB0cmFpbGluZyBzcGFjZS1hbmQtYXN0ZXJpc2sgaW4gMTMgDQpEZXNjcmlwdGlvbiBm aWVsZHMsIGZvciB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlY29yZHMgdGhhdCBoYXZlIGFuIGV4dGxh bmcgDQp3aXRoIHRoZSBzYW1lIG5hbWUuICBUaGUgZ3JvdXAgYWdyZWVkIChJIHRoaW5rKSBub3Qg dG8gY2hhbmdlIGFueSANCmV4aXN0aW5nIG5hbWVzLCBhbHRob3VnaCB0aGF0IG1lYW5zIHdlIHdp bGwgaGF2ZSAoZm9yIGV4YW1wbGUpIGEgDQpsYW5ndWFnZSBzdWJ0YWcgY2FsbGVkICJLb25rYW5p IiBhbmQgIktvbmthbmkgKG1hY3JvbGFuZ3VhZ2UpIiBhbmQgYW4gDQpleHRsYW5nIGFsc28gY2Fs bGVkICJLb25rYW5pIi4gIEkgbWFya2VkIHRoZXNlIDEzIGNhc2VzIHdpdGggYW4gYXN0ZXJpc2sg DQpzbyB0aGV5IGNvdWxkIGJlIGVhc2lseSByZW1vdmVkIChvciByZXRhaW5lZCkgYWZ0ZXIgdGhl IGRlY2lzaW9uIHdhcyANCm1hZGUsIGFuZCBmb3Jnb3QgdG8gcmlwIG91dCB0aGUgYXN0ZXJpc2tz IGJlZm9yZSBwb3N0aW5nLg0KDQpUaGUgc2Vjb25kIHByb2JsZW0gcnVucyBhIGJpdCBkZWVwZXIu ICBJU08gNjM5LTIganVzdCBhZGRlZCBhIG5ldyBjb2RlIA0KZWxlbWVudCAienphIiB3aXRoIHNp eCBuYW1lcywgb25lIG9mIHdoaWNoIGlzICJEaW1saSIuICBJU08gNjM5LTMgaGFzIGEgDQpjb2Rl IGVsZW1lbnQgImRpcSIgd2l0aCB0aGUgbmFtZSAiRGltbGkiLiAgSWYgYm90aCBvZiB0aGVzZSBh cmUgYWRtaXR0ZWQgDQppbnRvIHRoZSBSZWdpc3RyeSwgdGhlcmUgd2lsbCBiZSB0d28gc3VidGFn cyBvZiB0aGUgKnNhbWUgdHlwZSogd2l0aCB0aGUgDQpzYW1lIERlc2NyaXB0aW9uLiAgTm8gbWF0 dGVyIHdoYXQgYW55b25lIHNheXMgYWJvdXQgcmV0YWluaW5nIHRoZSANCiJvZmZpY2lhbCIgSVNP IG5hbWVzLCB0aGF0IGlzIG5vdCBhIHRvbGVyYWJsZSBzaXR1YXRpb24uDQoNClBldGVyIGluZGlj YXRlZCBvbiBpZXRmLWxhbmd1YWdlcyB0aGF0IHRoZSBJU08gNjM5IEpBQyB3b3VsZCBkZWNpZGUg d2hhdCANCnRvIGRvIGFib3V0IHRoaXMgaW4gZHVlIGNvdXJzZSwgYnV0IHVudGlsIHRoZXkgZG8s IEkgbmVlZCB0byBrbm93IHdoYXQgDQp0byBkbyB3aXRoIHRoZSBSZWdpc3RyeS4gIEknbGwgcG9z dCBhbiB1cGRhdGVkIHZlcnNpb24gd2hlbiBhIGRlY2lzaW9uIA0KaXMgcmVhY2hlZC4NCg0KLS0N CkRvdWcgRXdlbGwNCkZ1bGxlcnRvbiwgQ2FsaWZvcm5pYSwgVVNBDQpodHRwOi8vdXNlcnMuYWRl bHBoaWEubmV0L35kZXdlbGwvDQpSRkMgNDY0NSAgKiAgVVROICMxNA0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMdHJ1IG1haWxpbmcgbGlzdA0K THRydUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRy dQ0K --===============0174953156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0174953156==-- From ltru-bounces@ietf.org Mon Oct 16 14:15:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWza-0005yn-DO; Mon, 16 Oct 2006 14:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWzZ-0005ya-8v for ltru@ietf.org; Mon, 16 Oct 2006 14:15:13 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWzQ-00020b-TM for ltru@ietf.org; Mon, 16 Oct 2006 14:15:06 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9GIEwn7081802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Oct 2006 11:14:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=T1KRG0b2fDJeDd8OA3A5OMJ2y4gm4XlKZdU/UZE8NRDxENz/YJ2cAtBzYc8BQoG/ Message-ID: <4533CC21.1020301@yahoo-inc.com> Date: Mon, 16 Oct 2006 11:14:57 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: Registry deltas References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81><20061002153915.GD22365@ccil.org><30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com><6.0.0.20.2.20061009180149.06995380@localhost><30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id k9GIEwn7081802 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > BTW, I meant to add in this discussion of inverted names and other=20 > aspects of the forms of descriptions (not registry deltas!), if there i= s=20 > feedback that this WG would want to send back to the ISO 639 JAC for=20 > their consideration as to changes they could make in the descriptions=20 > that would make things easier for the LSR, this is a good time to submi= t=20 > that as the JAC will be meeting in a couple of weeks (teleconf) to=20 > discuss various issues related to the completion of part 3 and=20 > maintenance of the various parts in relation to one another.=20 How about: use a different separator for multiple names than for=20 reversed names and be consistent in that usage. That is, this list is=20 unambiguous: Saxon, Low; Low Saxon > There have > been some plans to work on names (e.g. the 639-3 RA had a work item to=20 > review the names in the 639-3 draft code table to improve consistency,=20 > especially where the draft code table for part 3 doesn=E2=80=99t have n= ames that=20 > are widely used, such as =E2=80=9CDari=E2=80=9D). >=20 On some level, completing the list of names in the ILSR isn't that=20 important. While it is nice to search the ILSR and find one's language,=20 at some point the user will need to resort to external references for=20 ambiguous items. Attempts to provide *every* commonplace name for a=20 language in one particular language (English??) or script (Latin) is=20 just as foolish as attempting to provide a localization in every language. >=20 > (Also, btw: seeing the problems we have with managing description field= s=20 > has for the first time made me wonder if the formal overhead of ISO=20 > 11179 might not offer some benefit. I don=E2=80=99t know enough about 1= 1179 to=20 > be able to answer that; it=E2=80=99s just a question that popped into m= y head.) >=20 You're kidding, right? *We* (LTRU) don't appear to have a problem,=20 woolly attempts at making the registry the One Shining Source for ISO=20 639 aside. If ISO 639 made the names consistent, there wouldn't be any=20 issue with description fields. I'd be happier with a rule for Doug and Michael to follow that is clear=20 and unambiguous and has the required latitude---and then letting the=20 problem take care of itself, as, so far, it has. Perhaps: -- If more than one name is provided by the underlying standard for a new=20 or updated record or the same name appears in multiple formats, the=20 Language Subtag Reviewer MAY select which name or names appear in a=20 Description field in the associated registry record (subject to=20 community consensus) and MAY edit the names to correct spelling,=20 orthographic, or formatting errors. The Reviewer MAY split a list of=20 names into separate Description fields. Note: Additional Description=20 fields MAY be added in various formats via the registration process. -- PS> I didn't have any problem finding the language record for 'cu' this=20 morning to see what we'd done previously. Addison --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 14:27:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXBJ-0002NU-I2; Mon, 16 Oct 2006 14:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXBI-0002NP-Kn for ltru@ietf.org; Mon, 16 Oct 2006 14:27:20 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXBG-0005ZL-CK for ltru@ietf.org; Mon, 16 Oct 2006 14:27:20 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Mon, 16 Oct 2006 11:27:17 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:27:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry deltas Date: Mon, 16 Oct 2006 11:27:13 -0700 Message-ID: In-Reply-To: <4533CC21.1020301@yahoo-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Registry deltas thread-index: AcbxTwN4PCfp/iC4Sx21LwzTHAWPAQAAVwDA References: <010e01c6e5e3$2f933030$6401a8c0@DGBP7M81><20061002153915.GD22365@ccil.org><30b660a20610021022t511f8ab5sbed9c5574d064b86@mail.gmail.com><6.0.0.20.2.20061009180149.06995380@localhost><30b660a20610151552h29b5a425u9869b4610f811438@mail.gmail.com> <4533CC21.1020301@yahoo-inc.com> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 16 Oct 2006 18:27:14.0190 (UTC) FILETIME=[B3BE2AE0:01C6F150] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1845212308==" Errors-To: ltru-bounces@ietf.org --===============1845212308== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQWRkaXNvbiBQaGlsbGlwcyBbbWFpbHRvOmFkZGlzb25AeWFob28taW5jLmNvbV0gDQoN Cj4gSG93IGFib3V0OiB1c2UgYSBkaWZmZXJlbnQgc2VwYXJhdG9yIGZvciBtdWx0aXBsZSBuYW1l cyB0aGFuIGZvciANCj4gcmV2ZXJzZWQgbmFtZXMgYW5kIGJlIGNvbnNpc3RlbnQgaW4gdGhhdCB1 c2FnZS4gVGhhdCBpcywgdGhpcyBsaXN0IGlzIA0KPiB1bmFtYmlndW91czoNCg0KICAgU2F4b24s IExvdzsgTG93IFNheG9uDQoNCkkganVzdCBnbGFuY2VkIHRocm91Z2ggdGhlIGNvZGUgdGFibGUg YXQgdGhlIExPQyBzaXRlIGZvciA2MzktMiBhbmQgY2Fubm90IGZpbmQgYW55IGluY29uc2lzdGVu Y2llczogIjsiIGlzIHVzZWQgdG8gc2VwYXJhdGUgYWx0ZXJuYXRlIG5hbWVzIGFuZCAiLCIgaXMg dXNlZCBmb3IgbmFtZSBpbnZlcnNpb24uIFdpdGggdGhhdCBpbiBtaW5kLCBJIGRvbid0IHNlZSBh bnkgYW1iaWd1aXR5IGluDQoNCiAgIFNheG9uLCBMb3c7IExvdyBTYXhvbg0KDQoNCg0KUGV0ZXIg Q29uc3RhYmxlDQo= --===============1845212308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1845212308==-- From ltru-bounces@ietf.org Mon Oct 16 15:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYRZ-0004ml-0m; Mon, 16 Oct 2006 15:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYQ9-0003qq-Bp for ltru@ietf.org; Mon, 16 Oct 2006 15:46:45 -0400 Received: from [80.76.149.213] (helo=ch-smtp02.sth.basefarm.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYOq-0003yQ-IG for ltru@ietf.org; Mon, 16 Oct 2006 15:45:26 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:64007 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GZYOo-0001ky-7O for ltru@ietf.org; Mon, 16 Oct 2006 21:45:23 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] Errors in prototype 4646bis Registry Date: Mon, 16 Oct 2006 21:40:33 +0200 Message-ID: <003401c6f15a$f2411520$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GZYOo-0001ky-7O. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GZYOo-0001ky-7O aea4e323df84e3e133222fceacb71c97 X-Spam-Score: 2.3 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I still very much dislike a parenthetical "(macrolanguage)" (or "(collection)" if that is the case, or "(individual)") in a name. "Dimli languages" maybe, or use an alternate name for the "macrolanguage" if one of the alternatives already refer more to the "macrolanguage" (Zaza?) than the others, or similar would be preferable. (But ok, not for LTRU to decide.) NOBODY except those familiar (to some extent) with 639-3 would even use the terms "macrolanguage", "individual language", or "language collection". That's why I dislike seeing those (or similar) terms in language "names". W.r.t. the new zza code, not only is there already a "Dimli" in the draft 639-3 list (code diq), there is also a "Kirmanjki" (code kiu), *both* of which are listed among the alternate names for the new zza code (Zaza; Dimili; Dimli; Kirdki; Kirmanjki; Zazaki). /kent k > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: Monday, October 16, 2006 7:25 PM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Errors in prototype 4646bis Registry > > > Re the duplicate "Dimli", it would seem reasonable to me to > employ the same mechanism that 639-3 uses: "Dimli (macrolanguage)". > > > Peter > > > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Tuesday, September 19, 2006 9:58 PM > To: LTRU Working Group > Subject: [Ltru] Errors in prototype 4646bis Registry > > There are two problems in the prototype RFC 4646bis Registry > I posted a > few days ago. > > The first problem is an extra trailing space-and-asterisk in 13 > Description fields, for the language subtag records that have > an extlang > with the same name. The group agreed (I think) not to change any > existing names, although that means we will have (for example) a > language subtag called "Konkani" and "Konkani (macrolanguage)" and an > extlang also called "Konkani". I marked these 13 cases with > an asterisk > so they could be easily removed (or retained) after the decision was > made, and forgot to rip out the asterisks before posting. > > The second problem runs a bit deeper. ISO 639-2 just added a > new code > element "zza" with six names, one of which is "Dimli". ISO > 639-3 has a > code element "diq" with the name "Dimli". If both of these > are admitted > into the Registry, there will be two subtags of the *same > type* with the > same Description. No matter what anyone says about retaining the > "official" ISO names, that is not a tolerable situation. > > Peter indicated on ietf-languages that the ISO 639 JAC would > decide what > to do about this in due course, but until they do, I need to > know what > to do with the Registry. I'll post an updated version when a > decision > is reached. > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > RFC 4645 * UTN #14 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 16:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZMp-0001oS-Jg; Mon, 16 Oct 2006 16:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZMo-0001oI-OE for ltru@ietf.org; Mon, 16 Oct 2006 16:47:22 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZZMa-0001Ty-6h for ltru@ietf.org; Mon, 16 Oct 2006 16:47:22 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Mon, 16 Oct 2006 13:47:07 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 16 Oct 2006 13:47:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Errors in prototype 4646bis Registry Date: Mon, 16 Oct 2006 13:46:35 -0700 Message-ID: In-Reply-To: <003401c6f15a$f2411520$6500a8c0@chalmers95a69n> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Errors in prototype 4646bis Registry thread-index: AcbxXBD6dTT8hTdHSHq0+k1E9d1VDAAB23cQ References: <003401c6f15a$f2411520$6500a8c0@chalmers95a69n> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 16 Oct 2006 20:47:07.0216 (UTC) FILETIME=[3E604D00:01C6F164] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0534993948==" Errors-To: ltru-bounces@ietf.org --===============0534993948== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IkRpbWxpIGxhbmdhdWdlcyIgY29udmV5cyB0aGF0IHRoZSBlbnRyeSBpcyBhIGNvbGxlY3Rpb24g YW5kIGhlbmNlIHdvdWxkIGJlIG1pc2xlYWRpbmcgYW5kIGluYXBwcm9wcmlhdGUuIElmIHRoZXJl IHdlcmUgYW4gYWx0ZXJuYXRlIG5hbWUgZm9yIHRoZSBtYWNyb2xhbmd1YWdlLCB0aGF0IHdvdWxk IGJlIHVzZWQsIGJ1dCB0aGF0IG1pZ2h0IG5vdCBhbHdheXMgYmUgdGhlIGNhc2UuDQoNCkkgZG9u J3QgcGFydGljdWxhcmx5IGxpa2UgdGhlc2UgbXlzZWxmLCBidXQgd2UgZmVsdCBpdCB3YXMgbmVj ZXNzYXJ5IHRvIG1ha2Ugc3VyZSB0aGUgbmFtZSB2YWx1ZXMgYXJlIHVuaXF1ZTogaWYgdGhhdCB2 YWx1ZSBpcyB0aGUgcHJpbWFyeSBpbmRpY2F0b3Igb2YgdGhlIGRpc3RpbmN0IGRlbm90YXRpb24g Zm9yIGFueSBnaXZlbiBlbnRyeSwgdGhlbiB0aGV5IG5lZWQgdG8gYmUgZGlzdGluY3QuDQoNCk5v dGUgdGhhdCB3aGF0IGlzIGluIHRoZSBkcmFmdCBjb2RlIHRhYmxlIGlzIHN0aWxsIGp1c3QgdGhh dDogZHJhZnQuIEl0IG1heSBiZSB0aGF0IHNvbWUgb2YgdGhlIHVzZXMgb2YgIihtYWNyb2xhbmd1 YWdlKSIgYW5kICIoaW5kaXZpZHVhbCBsYW5ndWFnZSkiIHdpbGwgZGlzYXBwZWFyIGJlZm9yZSBw dWJsaWNhdGlvbi4NCg0KDQpQZXRlcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEtlbnQgS2FybHNzb24gW21haWx0bzprZW50Lmthcmxzc29uMTRAY29taGVtLnNlXSAN ClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNiwgMjAwNiAxMjo0MSBQTQ0KVG86ICdMVFJVIFdvcmtp bmcgR3JvdXAnDQpTdWJqZWN0OiBSRTogW0x0cnVdIEVycm9ycyBpbiBwcm90b3R5cGUgNDY0NmJp cyBSZWdpc3RyeQ0KDQoNCkkgc3RpbGwgdmVyeSBtdWNoIGRpc2xpa2UgYSBwYXJlbnRoZXRpY2Fs ICIobWFjcm9sYW5ndWFnZSkiIChvciAiKGNvbGxlY3Rpb24pIg0KaWYgdGhhdCBpcyB0aGUgY2Fz ZSwgb3IgIihpbmRpdmlkdWFsKSIpIGluIGEgbmFtZS4gIkRpbWxpIGxhbmd1YWdlcyIgbWF5YmUs IG9yDQp1c2UgYW4gYWx0ZXJuYXRlIG5hbWUgZm9yIHRoZSAibWFjcm9sYW5ndWFnZSIgaWYgb25l IG9mIHRoZSBhbHRlcm5hdGl2ZXMNCmFscmVhZHkgcmVmZXIgbW9yZSB0byB0aGUgIm1hY3JvbGFu Z3VhZ2UiIChaYXphPykgdGhhbiB0aGUgb3RoZXJzLCBvcg0Kc2ltaWxhciB3b3VsZCBiZSBwcmVm ZXJhYmxlLiAoQnV0IG9rLCBub3QgZm9yIExUUlUgdG8gZGVjaWRlLikNCg0KTk9CT0RZIGV4Y2Vw dCB0aG9zZSBmYW1pbGlhciAodG8gc29tZSBleHRlbnQpIHdpdGggNjM5LTMgd291bGQgZXZlbiB1 c2UNCnRoZSB0ZXJtcyAibWFjcm9sYW5ndWFnZSIsICJpbmRpdmlkdWFsIGxhbmd1YWdlIiwgb3Ig Imxhbmd1YWdlIGNvbGxlY3Rpb24iLg0KVGhhdCdzIHdoeSBJIGRpc2xpa2Ugc2VlaW5nIHRob3Nl IChvciBzaW1pbGFyKSB0ZXJtcyBpbiBsYW5ndWFnZSAibmFtZXMiLg0KDQpXLnIudC4gdGhlIG5l dyB6emEgY29kZSwgbm90IG9ubHkgaXMgdGhlcmUgYWxyZWFkeSBhICJEaW1saSIgaW4gdGhlIGRy YWZ0IDYzOS0zDQpsaXN0IChjb2RlIGRpcSksIHRoZXJlIGlzIGFsc28gYSAiS2lybWFuamtpIiAo Y29kZSBraXUpLCAqYm90aCogb2Ygd2hpY2ggYXJlDQpsaXN0ZWQgYW1vbmcgdGhlIGFsdGVybmF0 ZSBuYW1lcyBmb3IgdGhlIG5ldyB6emEgY29kZSAoWmF6YTsgRGltaWxpOyBEaW1saTsNCktpcmRr aTsgS2lybWFuamtpOyBaYXpha2kpLg0KDQoJL2tlbnQgaw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFBldGVyIENvbnN0YWJsZSBbbWFpbHRvOnBldGVyY29uQG1pY3Jv c29mdC5jb21dIA0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTYsIDIwMDYgNzoyNSBQTQ0KPiBU bzogRG91ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJFOiBbTHRydV0g RXJyb3JzIGluIHByb3RvdHlwZSA0NjQ2YmlzIFJlZ2lzdHJ5DQo+IA0KPiANCj4gUmUgdGhlIGR1 cGxpY2F0ZSAiRGltbGkiLCBpdCB3b3VsZCBzZWVtIHJlYXNvbmFibGUgdG8gbWUgdG8gDQo+IGVt cGxveSB0aGUgc2FtZSBtZWNoYW5pc20gdGhhdCA2MzktMyB1c2VzOiAiRGltbGkgKG1hY3JvbGFu Z3VhZ2UpIi4NCj4gDQo+IA0KPiBQZXRlcg0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IERvdWcgRXdlbGwgW21haWx0bzpkZXdlbGxAYWRlbHBoaWEubmV0XSAN Cj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDE5LCAyMDA2IDk6NTggUE0NCj4gVG86IExUUlUg V29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gRXJyb3JzIGluIHByb3RvdHlwZSA0NjQ2 YmlzIFJlZ2lzdHJ5DQo+IA0KPiBUaGVyZSBhcmUgdHdvIHByb2JsZW1zIGluIHRoZSBwcm90b3R5 cGUgUkZDIDQ2NDZiaXMgUmVnaXN0cnkgDQo+IEkgcG9zdGVkIGEgDQo+IGZldyBkYXlzIGFnby4N Cj4gDQo+IFRoZSBmaXJzdCBwcm9ibGVtIGlzIGFuIGV4dHJhIHRyYWlsaW5nIHNwYWNlLWFuZC1h c3RlcmlzayBpbiAxMyANCj4gRGVzY3JpcHRpb24gZmllbGRzLCBmb3IgdGhlIGxhbmd1YWdlIHN1 YnRhZyByZWNvcmRzIHRoYXQgaGF2ZSANCj4gYW4gZXh0bGFuZyANCj4gd2l0aCB0aGUgc2FtZSBu YW1lLiAgVGhlIGdyb3VwIGFncmVlZCAoSSB0aGluaykgbm90IHRvIGNoYW5nZSBhbnkgDQo+IGV4 aXN0aW5nIG5hbWVzLCBhbHRob3VnaCB0aGF0IG1lYW5zIHdlIHdpbGwgaGF2ZSAoZm9yIGV4YW1w bGUpIGEgDQo+IGxhbmd1YWdlIHN1YnRhZyBjYWxsZWQgIktvbmthbmkiIGFuZCAiS29ua2FuaSAo bWFjcm9sYW5ndWFnZSkiIGFuZCBhbiANCj4gZXh0bGFuZyBhbHNvIGNhbGxlZCAiS29ua2FuaSIu ICBJIG1hcmtlZCB0aGVzZSAxMyBjYXNlcyB3aXRoIA0KPiBhbiBhc3RlcmlzayANCj4gc28gdGhl eSBjb3VsZCBiZSBlYXNpbHkgcmVtb3ZlZCAob3IgcmV0YWluZWQpIGFmdGVyIHRoZSBkZWNpc2lv biB3YXMgDQo+IG1hZGUsIGFuZCBmb3Jnb3QgdG8gcmlwIG91dCB0aGUgYXN0ZXJpc2tzIGJlZm9y ZSBwb3N0aW5nLg0KPiANCj4gVGhlIHNlY29uZCBwcm9ibGVtIHJ1bnMgYSBiaXQgZGVlcGVyLiAg SVNPIDYzOS0yIGp1c3QgYWRkZWQgYSANCj4gbmV3IGNvZGUgDQo+IGVsZW1lbnQgInp6YSIgd2l0 aCBzaXggbmFtZXMsIG9uZSBvZiB3aGljaCBpcyAiRGltbGkiLiAgSVNPIA0KPiA2MzktMyBoYXMg YSANCj4gY29kZSBlbGVtZW50ICJkaXEiIHdpdGggdGhlIG5hbWUgIkRpbWxpIi4gIElmIGJvdGgg b2YgdGhlc2UgDQo+IGFyZSBhZG1pdHRlZCANCj4gaW50byB0aGUgUmVnaXN0cnksIHRoZXJlIHdp bGwgYmUgdHdvIHN1YnRhZ3Mgb2YgdGhlICpzYW1lIA0KPiB0eXBlKiB3aXRoIHRoZSANCj4gc2Ft ZSBEZXNjcmlwdGlvbi4gIE5vIG1hdHRlciB3aGF0IGFueW9uZSBzYXlzIGFib3V0IHJldGFpbmlu ZyB0aGUgDQo+ICJvZmZpY2lhbCIgSVNPIG5hbWVzLCB0aGF0IGlzIG5vdCBhIHRvbGVyYWJsZSBz aXR1YXRpb24uDQo+IA0KPiBQZXRlciBpbmRpY2F0ZWQgb24gaWV0Zi1sYW5ndWFnZXMgdGhhdCB0 aGUgSVNPIDYzOSBKQUMgd291bGQgDQo+IGRlY2lkZSB3aGF0IA0KPiB0byBkbyBhYm91dCB0aGlz IGluIGR1ZSBjb3Vyc2UsIGJ1dCB1bnRpbCB0aGV5IGRvLCBJIG5lZWQgdG8gDQo+IGtub3cgd2hh dCANCj4gdG8gZG8gd2l0aCB0aGUgUmVnaXN0cnkuICBJJ2xsIHBvc3QgYW4gdXBkYXRlZCB2ZXJz aW9uIHdoZW4gYSANCj4gZGVjaXNpb24gDQo+IGlzIHJlYWNoZWQuDQo+IA0KPiAtLQ0KPiBEb3Vn IEV3ZWxsDQo+IEZ1bGxlcnRvbiwgQ2FsaWZvcm5pYSwgVVNBDQo+IGh0dHA6Ly91c2Vycy5hZGVs cGhpYS5uZXQvfmRld2VsbC8NCj4gUkZDIDQ2NDUgICogIFVUTiAjMTQNCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxp bmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCj4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============0534993948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0534993948==-- From ltru-bounces@ietf.org Mon Oct 16 17:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZlS-0004yR-FF; Mon, 16 Oct 2006 17:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZGc-0007J2-Qz for ltru@ietf.org; Mon, 16 Oct 2006 16:40:58 -0400 Received: from [80.76.149.213] (helo=ch-smtp02.sth.basefarm.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYZ3-0006B6-Lb for ltru@ietf.org; Mon, 16 Oct 2006 15:56:25 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:60032 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GZYZ2-0000zu-8p for ltru@ietf.org; Mon, 16 Oct 2006 21:55:57 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: Registry deltas Date: Mon, 16 Oct 2006 21:51:08 +0200 Message-ID: <003601c6f15c$6c50d5c0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4533CC21.1020301@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GZYZ2-0000zu-8p. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GZYZ2-0000zu-8p 36711ef37adcd617426f6edc33cb8a2b X-Spam-Score: 2.3 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 as modified below (but needs wordsmithing). > From: Addison Phillips [mailto:addison@yahoo-inc.com] > I'd be happier with a rule for Doug and Michael to follow that is clear > and unambiguous and has the required latitude---and then letting the > problem take care of itself, as, so far, it has. Perhaps: > > -- > If more than one name is provided by the underlying standard > for a new > or updated record or the same name appears in multiple formats, the > Language Subtag Reviewer MAY select which name or names appear in a > Description field in the associated registry record (subject to > community consensus) and MAY edit the names to correct spelling, > orthographic, or formatting errors. even if there is just one name given in the source registry > The Reviewer MAY split a list of in this case: "MAY" -> "SHOULD", or (preferably) even "SHALL" > names into separate Description fields. Note: Additional Description > fields MAY be added in various formats via the registration process. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 16 21:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdpx-0004oU-OE; Mon, 16 Oct 2006 21:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdpw-0004nM-OB for ltru@ietf.org; Mon, 16 Oct 2006 21:33:44 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZdpt-0004td-8u for ltru@ietf.org; Mon, 16 Oct 2006 21:33:44 -0400 Received: by wx-out-0506.google.com with SMTP id h30so1729021wxd for ; Mon, 16 Oct 2006 18:33:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=cTrUOH0Sh+/ai3qFCRqY13azJs23D9GMDCV87xagqVFHulJYDIlfGWsQsUhW+/6UfcRuyvnthgiR/C0TB/Qv2ay/IBwD3TNEEcIgM2oudsAeP8BTnkyDgtU5PVwV0mBLwk1tl2nJYHPyGJErZXhpcto1cxWCpU0uEKAzjc6Z5ZU= Received: by 10.90.65.11 with SMTP id n11mr4202959aga; Mon, 16 Oct 2006 18:33:40 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Mon, 16 Oct 2006 18:33:40 -0700 (PDT) Message-ID: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> Date: Mon, 16 Oct 2006 18:33:40 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: aa2af1d4ab3bb1ec X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Ltru] Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1745864629==" Errors-To: ltru-bounces@ietf.org --===============1745864629== Content-Type: multipart/alternative; boundary="----=_Part_54548_5020618.1161048820466" ------=_Part_54548_5020618.1161048820466 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I processed through the 01 file and generated the following data, listing every case where a Tag or Subtag contains a Description with a comma or "(". It is comma-delimited, so a useful way to view it is in Excel or OpenOffice, where you can filter and sort. http://macchiato.com/ltru/ltru-commas.txt (excel version http://macchiato.com/ltru/ltru-commas.xls) My conclusions are that it would be possible to support option A (allow inverted names), but it would definitely require some considerable cleanup. The key is that the inversion has to be predictable, otherwise people can get garbage when they try to reconstruct the "real" name. The algorithm to "de-invert" used the following. It assumes the Description is of the form: precomma ("," postComma) ("(" parenComment ")")? When there is a comma outside of the parenComment, the inversion is formed as: postComma " " preComma // plus "(" parenComment ")" if found The deinversion is listed after "=>" in the file. It doesn't work in many cases. I marked certain cases with "@" in column E that could be mechanically distinguished. 1. There are examples containing a double comma; those don't invert properly Resian, Resianic, Rezijan 2. There is one case where a description contains nothing but comment. This should just be deparened, IMO. (alias for Hiragana + Katakana) 3. There are multiple duplicates. "Ainu (Japan)" and "Ainu" [The vast majority of the items with comments don't duplicate, so it is clearly more consistent not to.] 4. Sometimes the inverted form is *also* listed as a name; much more often it is not. This is also an inconsistency that should be fixed. Altai, Southern 5. There are multiple other failures of inversion, like the following. These cannot be detected automatically; they must be reviewed by knowledgeable people (column F) Natisone dialect, Nadiza dialect => Nadiza dialect Natisone dialect 6. There are missing inversions, which for consistency should be present. *Bulgarian, Old (These were done with a simple check, looking for Northern, North, ....) I'm sure that there are many more, but those would require experts to review. Now, my preference is still to do option B -- I think A is inherently troublesome for translation -- but I wanted to give people the data I found. What I think would also be useful, as a by-product of this, would be to move all of the parenComments into real Comment fields. Mark On 10/16/06, Kent Karlsson wrote: > > > +1 as modified below (but needs wordsmithing). > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > I'd be happier with a rule for Doug and Michael to follow that is clear > > and unambiguous and has the required latitude---and then letting the > > problem take care of itself, as, so far, it has. Perhaps: > > > > -- > > If more than one name is provided by the underlying standard > > for a new > > or updated record or the same name appears in multiple formats, the > > Language Subtag Reviewer MAY select which name or names appear in a > > Description field in the associated registry record (subject to > > community consensus) and MAY edit the names to correct spelling, > > orthographic, or formatting errors. > > even if there is just one name given in the source registry > > > The Reviewer MAY split a list of > > in this case: "MAY" -> "SHOULD", or (preferably) even "SHALL" > > > names into separate Description fields. Note: Additional Description > > fields MAY be added in various formats via the registration process. > > /kent k > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_54548_5020618.1161048820466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I processed through the 01 file and generated the following data, listing every case where a Tag or Subtag contains a Description with a comma or "(". It is comma-delimited, so a useful way to view it is in Excel or OpenOffice, where you can filter and sort.

http://macchiato.com/ltru/ltru-commas.txt
(excel version http://macchiato.com/ltru/ltru-commas.xls )

My conclusions are that it would be possible to support option A (allow inverted names), but it would definitely require some considerable cleanup. The key is that the inversion has to be predictable, otherwise people can get garbage when they try to reconstruct the "real" name.

The algorithm to "de-invert" used the following. It assumes the Description is of the form:

precomma ("," postComma) ("(" parenComment ")")?

When there is a comma outside of the parenComment, the inversion is formed as:

postComma " " preComma                 // plus "(" parenComment ")" if found

The deinversion is listed after "=>" in the file. It doesn't work in many cases. I marked certain cases with "@" in column E that could be mechanically distinguished.

1. There are examples containing a double comma; those don't invert properly
Resian, Resianic, Rezijan

2. There is one case where a description contains nothing but comment. This should just be deparened, IMO.
(alias for Hiragana + Katakana)

3. There are multiple duplicates.
"Ainu (Japan)" and "Ainu"

[The vast majority of the items with comments don't duplicate, so it is clearly more consistent not to.]

4. Sometimes the inverted form is *also* listed as a name; much more often it is not. This is also an inconsistency that should be fixed.
Altai, Southern

5. There are multiple other failures of inversion, like the following. These cannot be detected automatically; they must be reviewed by knowledgeable people (column F)

Natisone dialect, Nadiza dialect => Nadiza dialect Natisone dialect

6. There are missing inversions, which for consistency should be present.
*Bulgarian, Old

(These were done with a simple check, looking for Northern, North, ....) I'm sure that there are many more, but those would require experts to review.

Now, my preference is still to do option B -- I think A is inherently troublesome for translation -- but I wanted to give people the data I found.

What I think would also be useful, as a by-product of this, would be to move all of the parenComments into real Comment fields.

Mark

On 10/16/06, Kent Karlsson <kent.karlsson14@comhem.se> wrote:

+1 as modified below (but needs wordsmithing).

> From: Addison Phillips [mailto:addison@yahoo-inc.com]

> I'd be happier with a rule for Doug and Michael to follow that is clear
> and unambiguous and has the required latitude---and then letting the
> problem take care of itself, as, so far, it has. Perhaps:
>
> --
> If more than one name is provided by the underlying standard
> for a new
> or updated record or the same name appears in multiple formats, the
> Language Subtag Reviewer MAY select which name or names appear in a
> Description field in the associated registry record (subject to
> community consensus) and MAY edit the names to correct spelling,
> orthographic, or formatting errors.

even if there is just one name given in the source registry

> The Reviewer MAY split a list of

in this case: "MAY" -> "SHOULD", or (preferably) even "SHALL"

> names into separate Description fields. Note: Additional Description
> fields MAY be added in various formats via the registration process.

                /kent k


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

 ------=_Part_54548_5020618.1161048820466-- --===============1745864629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1745864629==-- From ltru-bounces@ietf.org Mon Oct 16 23:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfnk-0004A5-MZ; Mon, 16 Oct 2006 23:39:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfnj-00049z-5Q for ltru@ietf.org; Mon, 16 Oct 2006 23:39:35 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZfng-0005VY-Kl for ltru@ietf.org; Mon, 16 Oct 2006 23:39:35 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9H3dMnD008030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Oct 2006 20:39:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=CPUDPxcAyyNzwmIAiUrVdW0tG1VEYur+IQIO3BKBhx5IBe8fEkYTwSig9tHN8zst Message-ID: <4534506B.9000902@yahoo-inc.com> Date: Mon, 16 Oct 2006 20:39:23 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Inversions and other problems References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> In-Reply-To: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark, I think my solution would be the most elegant way of dealing with this. Doug Ewell is a better approximation of a Turing machine than any inversion algorithm. Perhaps the only addition to my message below would be to permit the same form of editing of the description fields in 4645bis. IOW, the rules would be: 1. Follow the source standard. 2. Split multiple names into multiple description fields. 3. Omit or edit problematic items, subject to consensus. Addison Mark Davis wrote: > I processed through the 01 file and generated the following data, > listing every case where a Tag or Subtag contains a Description with a > comma or "(". It is comma-delimited, so a useful way to view it is in > Excel or OpenOffice, where you can filter and sort. > > http://macchiato.com/ltru/ltru-commas.txt > (excel version http://macchiato.com/ltru/ltru-commas.xls ) > > My conclusions are that it would be possible to support option A (allow > inverted names), but it would definitely require some considerable > cleanup. The key is that the inversion has to be predictable, otherwise > people can get garbage when they try to reconstruct the "real" name. > > The algorithm to "de-invert" used the following. It assumes the > Description is of the form: > > precomma ("," postComma) ("(" parenComment ")")? > > When there is a comma outside of the parenComment, the inversion is > formed as: > > postComma " " preComma // plus "(" parenComment ")" if found > > The deinversion is listed after "=>" in the file. It doesn't work in > many cases. I marked certain cases with "@" in column E that could be > mechanically distinguished. > > 1. There are examples containing a double comma; those don't invert > properly > Resian, Resianic, Rezijan > > 2. There is one case where a description contains nothing but comment. > This should just be deparened, IMO. > (alias for Hiragana + Katakana) > > 3. There are multiple duplicates. > "Ainu (Japan)" and "Ainu" > > [The vast majority of the items with comments don't duplicate, so it is > clearly more consistent not to.] > > 4. Sometimes the inverted form is *also* listed as a name; much more > often it is not. This is also an inconsistency that should be fixed. > Altai, Southern > > 5. There are multiple other failures of inversion, like the following. > These cannot be detected automatically; they must be reviewed by > knowledgeable people (column F) > > Natisone dialect, Nadiza dialect => Nadiza dialect Natisone dialect > > 6. There are missing inversions, which for consistency should be present. > *Bulgarian, Old > > (These were done with a simple check, looking for Northern, North, ....) > I'm sure that there are many more, but those would require experts to > review. > > Now, my preference is still to do option B -- I think A is inherently > troublesome for translation -- but I wanted to give people the data I found. > > What I think would also be useful, as a by-product of this, would be to > move all of the parenComments into real Comment fields. > > Mark > > On 10/16/06, *Kent Karlsson * > wrote: > > > +1 as modified below (but needs wordsmithing). > > > From: Addison Phillips [mailto:addison@yahoo-inc.com > ] > > > I'd be happier with a rule for Doug and Michael to follow that is > clear > > and unambiguous and has the required latitude---and then letting the > > problem take care of itself, as, so far, it has. Perhaps: > > > > -- > > If more than one name is provided by the underlying standard > > for a new > > or updated record or the same name appears in multiple formats, the > > Language Subtag Reviewer MAY select which name or names appear in a > > Description field in the associated registry record (subject to > > community consensus) and MAY edit the names to correct spelling, > > orthographic, or formatting errors. > > even if there is just one name given in the source registry > > > The Reviewer MAY split a list of > > in this case: "MAY" -> "SHOULD", or (preferably) even "SHALL" > > > names into separate Description fields. Note: Additional Description > > fields MAY be added in various formats via the registration process. > > /kent k > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 00:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgYF-0002sW-6i; Tue, 17 Oct 2006 00:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgYD-0002qH-5s for ltru@ietf.org; Tue, 17 Oct 2006 00:27:37 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZgNT-0007EH-4r for ltru@ietf.org; Tue, 17 Oct 2006 00:16:35 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lSohBnaaS4cRIkdv8l0tCEjrG+e6woBFvc+9PYGghKc5es7yTC1gkBZihlgftPUJ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.71] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GZgNJ-0001T5-0I for ltru@ietf.org; Tue, 17 Oct 2006 00:16:21 -0400 Message-ID: <066001c6f1a3$8a160520$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <099E56E902694298855BF6D06A52555F.MAI@home> Subject: Re: [Ltru] Re: Liaison with TC37/SC2 Date: Mon, 16 Oct 2006 21:19:32 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6f3deef8927d630b46119aa91651e5804350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.71 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Debbie Garside" > To: ; "'LTRU Working Group'" > Sent: Saturday, October 14, 2006 2:11 AM > Subject: RE: [Ltru] Re: Liaison with TC37/SC2 ... > As to travel, join ANSI. One would hope that, like BSI, they would support > travel expenditure. ... The structure and organization of standardization activities in the US is quite different from how things work in the UK. Skimming http://publicaa.ansi.org/sites/apdl/Documents/News%20and%20Publications/Other%20Documents/US-Stdzn-System-FINAL.pdf might give you an idea just *how* different things are. Basic individual membership in ANSI is $495 per year, but that really doesn't provide the access one would like to participate in most interesting activities. For that, one (or more typically, one's company) joins an ANSI-accredited technical committee that serves as the TAG for the area of interest, rather than actually joining ANSI. Unless something has changed radically since my days in INCITS (formerly X3) T3 and T5, the individual (or his/her employer) is responsible for all expenses in either case. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 00:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgfb-0000hr-Ov; Tue, 17 Oct 2006 00:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgfZ-0000hA-TF for ltru@lists.ietf.org; Tue, 17 Oct 2006 00:35:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZgfY-0004V2-JR for ltru@lists.ietf.org; Tue, 17 Oct 2006 00:35:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZgfT-00011P-3d for ltru@lists.ietf.org; Tue, 17 Oct 2006 06:35:07 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 06:35:07 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 06:35:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 06:34:10 +0200 Organization: Lines: 40 Message-ID: <45345D42.342B@xyzzy.claranet.de> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > IOW, the rules would be: > 1. Follow the source standard. > 2. Split multiple names into multiple description fields. > 3. Omit or edit problematic items, subject to consensus. Where (2) is "normally indicated by a semicolon" (?) I like the "inverted form", it allows to spot all related subtags in a list sorted by descriptions, e.g. all subtags with one or more descriptions starting with "Arabic". Or very visible in Mark's list, find out if "Quechua" is the same as "Quichua" - but I didn't try that ;-) Creating a derived list without inversions is apparently simple, but the opposite direction isn't necessarily. The @DOUBLE_COMMA stuff is apparently limited to a few enumerations, for "redundant" subtags we could improve it: Instead of (example, one of six): - German, Swiss variant, traditional orthography + German traditional orthography, Swiss variant The nedis / rozaj cases could get a semicolon... - Natisone dialect, Nadiza dialect - Resian, Resianic, Rezija + Natisone dialect; Nadiza dialect + Resian; Resianic; Rezija ...resulting in multiple descriptions. But IMO that's unnecessary, also unnecessary for zh-min and zh-min-nan, where the @DOUBLE_COMMA is an ordinary enumeration in grandfathered tags. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 00:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgtV-0001ke-BL; Tue, 17 Oct 2006 00:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgtS-0001jp-Pi for ltru@ietf.org; Tue, 17 Oct 2006 00:49:34 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZgtR-0007DS-DJ for ltru@ietf.org; Tue, 17 Oct 2006 00:49:34 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=k88gT0pAps/vhohwFGY9YH8589UiJsVLUjiWCRnpqk5HMo6HDiE0jWIj5sJETzLZ; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.71] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GZgsv-0006UM-Un; Tue, 17 Oct 2006 00:49:02 -0400 Message-ID: <06cf01c6f1a8$25929140$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "Marion Gunn" , "LTRU Working Group" References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie> Subject: Re: [Ltru] IPA, NSAI and ANSI Date: Mon, 16 Oct 2006 21:52:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee63e7e86199e1cdfc53f835b134b3fe38b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.71 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Sue Ellen Wright , TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As co-chair: It's odd that Marion's message was addressed to the ltru working group, and not to whatever the relevant ANSI-accredited committee would be, since the message appears to be a request for action to be taken by ANSI. As a technical contributor: The fact that someone happens to come from the US does not imply that ANSI has any influence whatsoever over their actions. ANSI is a private organization, not a government body, and it is just one of many standards-generating orgnizations in the US. It is an especially significant one, but by no means the only one. Randy ----- Original Message ----- From: "Marion Gunn" To: "LTRU Working Group" Cc: "Sue Ellen Wright" ; "TC46-L Information and Documentation Technology List" Sent: Monday, October 16, 2006 5:55 AM Subject: [Ltru] IPA, NSAI and ANSI To say Ireland (NSAI) is responsible for the refusal to register IPA as an ISO 15924 script is as unfair as it is untrue. I am writing to confirm that Irish users were as put out by that negative decision as users elsewhere, and that that negative decision was not made by NSAI. ISO 15924 is nominally the responsibility of ISO/TC 46, although not under normal TC 46 control, either, and that negative decision was made by the ISO 15924 advisory committee, currently made up as follows: One representative of the Registration Authority: Michael Everson, Evertype One representative of the ISO 639-2/RA: Randall K. Barry, Library of Congress One representative of ISO TC37: Håvard Hjulstad, Språk- og terminologitjenester One representative of ISO TC46: François Demay, Encyclopaedia Universalis Two representatives of ISO/IEC JTC1/SC2: Rick McGowan, Unicode Consortium Ken Whistler, Sybase That AC failed to offer a cogent argument against tagging IPA in ISO 15924 and, during a public exchange on the LTRU list, its members all failed to address most of the points raised, for example, when Mark Davis of International Components for Unicode pointed out that [ISO 15924] already "incorporates variations which are essentially orthography (Hant vs Hans), and other differences that are simply glyphic variation (Fraktur Latin)" their answer was silence. The grounds for registering IPA as a script have been long since established: it looks like a script, behaves like a script and only requires standard ISO tagging to facilitate proper electronic script processing. An IPA tag is urgently needed by NSAI's Irish-speaking communities, (so I must continue pressing for it), as well as being needed by university researchers and practical speech therapists in so many countries that a positive decision to tag it for use needs to made without delay, to open the door for Net searches for texts written in IPA. Because that particular ISO AC was set up with a built-in US majority (4 out of 6), it is the logical responsibility of ANSI (_not_ NSAI) to ensure that such overloading in a big country's favour not be any excuse for refusing/delaying reasonable service requests from smaller countries. No country, however big it is, has any right to have such control over any international standards — however obtained, that amount of control carries with it an equal amount of answerability for concomitant results. Accordingly, I respectfully request that ANSI use its influence to to good effect, to persuade such members of the ISO 15924 AC as it can influence to reverse their negative decision in re registering IPA in ISO 15924. FWIW, I wish to affirm that I still believe in ISO 15924's potential quite as much as I did many years ago, when I was NSAI's sole representative in ISO/TC 37, where I first brought its first NWI draft to ISO/TC 37's attention (and after it was blocked in TC 37, supported its adoption in ISO/TC 46), that I regard its inception by Michael Everson as something very much to his credit, and that I would also regard it as to Mr Everson's credit were he now to reverse his vote (withdraw his opposition to registing IPA as a script). I hold it as a reasonable expectation that the rest would probably follow. mg Convener, NSAI ISO/TC 46 IG - - Marion Gunn * EGTeo (Estab.1991) 27 Páirc an Fhéithlinn, Baile an Bhóthair, Co. Átha Cliath, Éire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 10:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqGC-0001Qc-91; Tue, 17 Oct 2006 10:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqGA-0001QL-UN for ltru@lists.ietf.org; Tue, 17 Oct 2006 10:49:38 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqG6-0000ZG-EM for ltru@lists.ietf.org; Tue, 17 Oct 2006 10:49:38 -0400 Received: by wr-out-0506.google.com with SMTP id 71so261776wra for ; Tue, 17 Oct 2006 07:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=eohIzA/SGI3UCtsWKBrjj450HfPn2plDC+Ah8dYMDCXgE6I1JhGpXzo30kUq3w9B3MhS035PsFu6HMGlBJ2Md2d2mYhV+dmcJBULHqqq1Riff9hPSWvMrLbtjr+C3B1le3SWBVVGEqxsa/9Q0u537N47geKVVQmDw9ocx1l7cOI= Received: by 10.90.105.19 with SMTP id d19mr4880342agc; Tue, 17 Oct 2006 07:49:33 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 07:49:33 -0700 (PDT) Message-ID: <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> Date: Tue, 17 Oct 2006 07:49:33 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <45345D42.342B@xyzzy.claranet.de> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> X-Google-Sender-Auth: f8f89581749a5b5d X-Spam-Score: 0.5 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507839349==" Errors-To: ltru-bounces@ietf.org --===============1507839349== Content-Type: multipart/alternative; boundary="----=_Part_60151_32756477.1161096573799" ------=_Part_60151_32756477.1161096573799 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline As I said before, I can live with inversion IF it is fixed. That means an extension of Addison's proposed rules. 1. Follow the source standard. 2. Split multiple names into multiple description fields. I believe Addison meant: X, Y, Y => Description: X Description: Y Description: Z 3. Omit or edit problematic items, subject to consensus. plus 4. Ensure that there are no duplicates (where inversion and/or removal of parenComments results in a duplicate within the same subtag, or where names are the same across different subtags of the same type) Eg no cases like Subtag: ain Description: Ainu Description: Ainu (Japan) or Description: Northern Sotho Description: Sotho, Northern or (there are currently none of these) Subtag: x Description: y Subtag: z Description: y 5. The only information in parentheses is a comment, eg a clarification of the description. 6. The final result being that there are NO description items with commas outside of parenComments, except for the case that there is a single comma indicating inversion. If these are the rules, then I'm satisfied. == Ideally, we'd have two additional rules: 7. The most commonly known name is in the first Description. (This may already be the case -- I don't know.) 8. A description is unique even if the parenComment is removed. As it stands, there are 138 cases where a description is only distinguished by a parenComment. Ideally, those would be fixed so that the rest of the description was unique. These are in that same directory: http://macchiato.com/ltru/, in the file ltru-duplicates.txt Example: 126 Aja (Benin) language ajg 127 Aja (Sudan) language aja For example, if these were the following, then the comments would not be necessary. ajg: Aja, Benin aja: Aja, Sudan That would also be more consistent with other uses like Sotho, Northern vs Sotho, Southern -- the adjective is not just in a parenComment. For those interested, - ltru-reverse.txt is a "reverse" list, ordered by description. - ltru-reverse-no-comments.txt is the same, but with the parenComments removed. Mark On 10/16/06, Frank Ellermann wrote: > > Addison Phillips wrote: > > > IOW, the rules would be: > > 1. Follow the source standard. > > 2. Split multiple names into multiple description fields. > > 3. Omit or edit problematic items, subject to consensus. > > Where (2) is "normally indicated by a semicolon" (?) > > I like the "inverted form", it allows to spot all related > subtags in a list sorted by descriptions, e.g. all subtags > with one or more descriptions starting with "Arabic". > > Or very visible in Mark's list, find out if "Quechua" is > the same as "Quichua" - but I didn't try that ;-) > > Creating a derived list without inversions is apparently > simple, but the opposite direction isn't necessarily. > > The @DOUBLE_COMMA stuff is apparently limited to a few > enumerations, for "redundant" subtags we could improve it: > > Instead of (example, one of six): > - German, Swiss variant, traditional orthography > + German traditional orthography, Swiss variant > > The nedis / rozaj cases could get a semicolon... > > - Natisone dialect, Nadiza dialect > - Resian, Resianic, Rezija > + Natisone dialect; Nadiza dialect > + Resian; Resianic; Rezija > > ...resulting in multiple descriptions. But IMO that's > unnecessary, also unnecessary for zh-min and zh-min-nan, > where the @DOUBLE_COMMA is an ordinary enumeration in > grandfathered tags. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_60151_32756477.1161096573799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline As I said before, I can live with inversion IF it is fixed. That means an extension of Addison's proposed rules.

1. Follow the source standard.

2. Split multiple names into multiple description fields.
I believe Addison meant: X, Y, Y =>
Description: X
Description: Y
Description: Z

3. Omit or edit problematic items, subject to consensus.

plus

4. Ensure that there are no duplicates (where inversion and/or removal of parenComments results in a duplicate within the same subtag, or where names are the same across different subtags of the same type)
Eg no cases like
Subtag: ain
Description: Ainu
Description: Ainu (Japan)
or
Description: Northern Sotho
Description: Sotho, Northern
or (there are currently none of these)
Subtag: x
Description: y
Subtag: z
Description: y

5. The only information in parentheses is a comment, eg a clarification of the description.

6. The final result being that there are NO description items with commas outside of parenComments, except for the case that there is a single comma indicating inversion.

If these are the rules, then I'm satisfied.

==

Ideally, we'd have two additional rules:

7. The most commonly known name is in the first Description.
(This may already be the case -- I don't know.)

8. A description is unique even if the parenComment is removed.

As it stands, there are 138 cases where a description is only distinguished by a parenComment. Ideally, those would be fixed so that the rest of the description was unique. These are in that same directory: http://macchiato.com/ltru/, in the file ltru-duplicates.txt

Example:

126    Aja (Benin)    language    ajg
127    Aja (Sudan)    language    aja

For example, if these were the following, then the comments would not be necessary.
ajg: Aja, Benin
aja: Aja, Sudan
That would also be more consistent with other uses like Sotho, Northern vs Sotho, Southern -- the adjective is not just in a parenComment.

For those interested,
  • ltru-reverse.txt is a "reverse" list, ordered by description.
  • ltru-reverse-no-comments.txt is the same, but with the parenComments removed.
Mark

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

> IOW, the rules would be:
> 1. Follow the source standard.
> 2. Split multiple names into multiple description fields.
> 3. Omit or edit problematic items, subject to consensus.

Where (2) is "normally indicated by a semicolon" (?)

I like the "inverted form", it allows to spot all related
subtags in a list sorted by descriptions, e.g. all subtags
with one or more descriptions starting with "Arabic".

Or very visible in Mark's list, find out if "Quechua" is
the same as "Quichua" - but I didn't try that ;-)

Creating a derived list without inversions is apparently
simple, but the opposite direction isn't necessarily.

The @DOUBLE_COMMA stuff is apparently limited to a few
enumerations, for "redundant" subtags we could improve it:

Instead of (example, one of six):
- German, Swiss variant, traditional orthography
+ German traditional orthography, Swiss variant

The nedis / rozaj cases could get a semicolon...

- Natisone dialect, Nadiza dialect
- Resian, Resianic, Rezija
+ Natisone dialect; Nadiza dialect
+ Resian; Resianic; Rezija

...resulting in multiple descriptions.  But IMO that's
unnecessary, also unnecessary for zh-min and zh-min-nan,
where the @DOUBLE_COMMA is an ordinary enumeration in
grandfathered tags.

Frank



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

------=_Part_60151_32756477.1161096573799-- --===============1507839349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1507839349==-- From ltru-bounces@ietf.org Tue Oct 17 11:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqvV-0008SW-V0; Tue, 17 Oct 2006 11:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqvU-0008SR-KV for ltru@lists.ietf.org; Tue, 17 Oct 2006 11:32:20 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqvO-0004nr-TC for ltru@lists.ietf.org; Tue, 17 Oct 2006 11:32:20 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9HFW8dD033549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 08:32:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=rtIHFruFrJox3qa+CXDHCK+UFoXS/mstAKvXVwqN8BZap8tv3MJN5D6b+eeAIIZW Message-ID: <4534F776.8090306@yahoo-inc.com> Date: Tue, 17 Oct 2006 08:32:06 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> In-Reply-To: <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > As I said before, I can live with inversion IF it is fixed. That means > an extension of Addison's proposed rules. > > 1. Follow the source standard. > > 2. Split multiple names into multiple description fields. > I believe Addison meant: X, Y, Y => > Description: X > Description: Y > Description: Z Yes, exactly so. > > 3. Omit or edit problematic items, subject to consensus. > > plus Well... my goal was to avoid having to spell all of this out. We've got enough rules, so I think some hand-waving is in order. While I note the problem projects like CLDR might have producing localizations, the use of an actual Turing machine (aka Doug Ewell) to create the entries should eliminate a lot of woes. Furthermore, I tend to think that the *detailed* rules you propose should go into 4645bis (i.e. "how did the entries get this way"), while the simpler version I proposed can go into 4646bis (perhaps with a pointer to "pre-existing customary practice" in 4645bis). > > 4. Ensure that there are no duplicates (where inversion and/or removal > of parenComments results in a duplicate within the same subtag, or where > names are the same across different subtags of the same type) I wasn't specific enough in my little bit of text above. "Duplicates" (including inverted duplicates) are members of the class "problematic". > > 5. The only information in parentheses is a comment, eg a clarification > of the description. This could be guidance added to rule 3. > > 6. The final result being that there are NO description items with > commas outside of parenComments, except for the case that there is a > single comma indicating inversion. > Except that you go on to demonstrate below that sometimes inversion is illusory. > If these are the rules, then I'm satisfied. > > == > > Ideally, we'd have two additional rules: > > 7. The most commonly known name is in the first Description. > (This may already be the case -- I don't know.) I don't think this is appropriate. The level of judgment required is too great for the ietf-languages list to manage. > > 8. A description is unique even if the parenComment is removed. > We need a "MUST" here. I'd propose: -- For a given record type, each Description field MUST be unique. -- Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 11:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrJN-0000Ua-E1; Tue, 17 Oct 2006 11:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrJM-0000UQ-RK for ltru@lists.ietf.org; Tue, 17 Oct 2006 11:57:00 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrJL-0007tJ-EY for ltru@lists.ietf.org; Tue, 17 Oct 2006 11:57:00 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9HFuncx034627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 08:56:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=YDd+3Yc8D6oLWZMl1wW0Uz06UFHJsZSY60Q0IOIqNQ/jSrps1ZYXWELWF9SVmCHo Message-ID: <4534FD40.1030704@yahoo-inc.com> Date: Tue, 17 Oct 2006 08:56:48 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: Inversions and other problems References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> In-Reply-To: <4534F776.8090306@yahoo-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Maybe more to the point, I propose we insert this text into the 'Description' section of the document (the current Section 3.1.3.2): For a records of a given 'Type', the value of the 'Description' field MUST be unique. For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the source standard. Multiple descriptions in the source standard MUST be split into separate 'Description' fields. The source standard's descriptions MAY also be edited prior to insertion. Duplicate, redundant, conflicting, or otherwise problematic descriptions SHOULD be omitted. Parenthetical comments, inverted names, and other formatting quirks SHOULD be regularized according to the guidelines used to update the registry in . Addison Addison Phillips wrote: > Mark Davis wrote: >> As I said before, I can live with inversion IF it is fixed. That means >> an extension of Addison's proposed rules. >> >> 1. Follow the source standard. >> >> 2. Split multiple names into multiple description fields. >> I believe Addison meant: X, Y, Y => >> Description: X >> Description: Y >> Description: Z > > Yes, exactly so. > >> >> 3. Omit or edit problematic items, subject to consensus. >> >> plus > > Well... my goal was to avoid having to spell all of this out. We've got > enough rules, so I think some hand-waving is in order. While I note the > problem projects like CLDR might have producing localizations, the use > of an actual Turing machine (aka Doug Ewell) to create the entries > should eliminate a lot of woes. Furthermore, I tend to think that the > *detailed* rules you propose should go into 4645bis (i.e. "how did the > entries get this way"), while the simpler version I proposed can go into > 4646bis (perhaps with a pointer to "pre-existing customary practice" in > 4645bis). > >> >> 4. Ensure that there are no duplicates (where inversion and/or removal >> of parenComments results in a duplicate within the same subtag, or >> where names are the same across different subtags of the same type) > > I wasn't specific enough in my little bit of text above. "Duplicates" > (including inverted duplicates) are members of the class "problematic". > > >> >> 5. The only information in parentheses is a comment, eg a >> clarification of the description. > > This could be guidance added to rule 3. > >> >> 6. The final result being that there are NO description items with >> commas outside of parenComments, except for the case that there is a >> single comma indicating inversion. >> > > Except that you go on to demonstrate below that sometimes inversion is > illusory. > >> If these are the rules, then I'm satisfied. >> >> == >> >> Ideally, we'd have two additional rules: >> >> 7. The most commonly known name is in the first Description. >> (This may already be the case -- I don't know.) > > I don't think this is appropriate. The level of judgment required is too > great for the ietf-languages list to manage. > >> >> 8. A description is unique even if the parenComment is removed. >> > > We need a "MUST" here. I'd propose: > > -- > For a given record type, each Description field MUST be unique. > -- > > Addison > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 14:30:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZths-0005nP-1S; Tue, 17 Oct 2006 14:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZthq-0005lq-L8 for ltru@lists.ietf.org; Tue, 17 Oct 2006 14:30:26 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZthm-0002Xu-5U for ltru@lists.ietf.org; Tue, 17 Oct 2006 14:30:26 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 227AF1E15BA; Tue, 17 Oct 2006 11:06:25 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Oct 2006 11:06:24 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF3F@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Addison Phillips' Subject: RE: [Ltru] Re: Inversions and other problems Date: Tue, 17 Oct 2006 11:06:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Addison Phillips [mailto:addison@yahoo-inc.com] Sent: Tuesday, October 17, 2006 11:57 AM To: Addison Phillips Cc: Frank Ellermann; ltru@lists.ietf.org Subject: Re: [Ltru] Re: Inversions and other problems Maybe more to the point, I propose we insert this text into the 'Description' section of the document (the current Section 3.1.3.2): For a records of a given 'Type', the value of the 'Description' field MUST be unique. For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the source standard. Multiple descriptions in the source standard MUST be split into separate 'Description' fields. The source standard's descriptions MAY also be edited prior to insertion. Duplicate, redundant, conflicting, or otherwise problematic descriptions SHOULD be omitted. Parenthetical comments, inverted names, and other formatting quirks SHOULD be regularized according to the guidelines used to update the registry in . Addison Addison Phillips wrote: > Mark Davis wrote: >> As I said before, I can live with inversion IF it is fixed. That means >> an extension of Addison's proposed rules. >> >> 1. Follow the source standard. >> >> 2. Split multiple names into multiple description fields. >> I believe Addison meant: X, Y, Y => >> Description: X >> Description: Y >> Description: Z > > Yes, exactly so. > >> >> 3. Omit or edit problematic items, subject to consensus. >> >> plus > > Well... my goal was to avoid having to spell all of this out. We've got > enough rules, so I think some hand-waving is in order. While I note the > problem projects like CLDR might have producing localizations, the use > of an actual Turing machine (aka Doug Ewell) to create the entries > should eliminate a lot of woes. Furthermore, I tend to think that the > *detailed* rules you propose should go into 4645bis (i.e. "how did the > entries get this way"), while the simpler version I proposed can go into > 4646bis (perhaps with a pointer to "pre-existing customary practice" in > 4645bis). > >> >> 4. Ensure that there are no duplicates (where inversion and/or removal >> of parenComments results in a duplicate within the same subtag, or >> where names are the same across different subtags of the same type) > > I wasn't specific enough in my little bit of text above. "Duplicates" > (including inverted duplicates) are members of the class "problematic". > > >> >> 5. The only information in parentheses is a comment, eg a >> clarification of the description. > > This could be guidance added to rule 3. > >> >> 6. The final result being that there are NO description items with >> commas outside of parenComments, except for the case that there is a >> single comma indicating inversion. >> > > Except that you go on to demonstrate below that sometimes inversion is > illusory. > >> If these are the rules, then I'm satisfied. >> >> == >> >> Ideally, we'd have two additional rules: >> >> 7. The most commonly known name is in the first Description. >> (This may already be the case -- I don't know.) > > I don't think this is appropriate. The level of judgment required is too > great for the ietf-languages list to manage. > >> >> 8. A description is unique even if the parenComment is removed. >> > > We need a "MUST" here. I'd propose: > > -- > For a given record type, each Description field MUST be unique. > -- > > Addison > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.4/480 - Release Date: 10/17/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 15:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZukX-0008Rp-UQ; Tue, 17 Oct 2006 15:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZukW-0008Rg-Hh for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:37:16 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZukW-0002AJ-43 for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:37:16 -0400 Received: by wx-out-0506.google.com with SMTP id h28so22429wxd for ; Tue, 17 Oct 2006 12:37:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=qJ3YJ/Zb5ptrXE2Kh5RERaPMC9ukJKjfoDI5RrAZx+BOBp+Pvcl17anen3PmHoJxUzpjegPtRdDrCrP0oRiuloLYJGRvU1A/TvtHFDQ8ztSqfiRQBmioo0aUViXqRfgk1hQIr4AQW4m7l1ZyCBKkur/+G4vxO2GZKfH74HWl8dc= Received: by 10.90.113.18 with SMTP id l18mr5405313agc; Tue, 17 Oct 2006 12:37:13 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 12:37:13 -0700 (PDT) Message-ID: <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> Date: Tue, 17 Oct 2006 12:37:13 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <4534F776.8090306@yahoo-inc.com> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> X-Google-Sender-Auth: 8d17883b00e16c50 X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0160582438==" Errors-To: ltru-bounces@ietf.org --===============0160582438== Content-Type: multipart/alternative; boundary="----=_Part_63068_4225460.1161113833707" ------=_Part_63068_4225460.1161113833707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/17/06, Addison Phillips wrote: > > Mark Davis wrote: > > As I said before, I can live with inversion IF it is fixed. That means > > an extension of Addison's proposed rules. > > > > 1. Follow the source standard. > > > > 2. Split multiple names into multiple description fields. > > I believe Addison meant: X, Y, Y => > > Description: X > > Description: Y > > Description: Z > > Yes, exactly so. > > > > > 3. Omit or edit problematic items, subject to consensus. > > > > plus > > Well... my goal was to avoid having to spell all of this out. We've got > enough rules, so I think some hand-waving is in order. While I note the > problem projects like CLDR might have producing localizations, the use > of an actual Turing machine (aka Doug Ewell) to create the entries > should eliminate a lot of woes. Furthermore, I tend to think that the > *detailed* rules you propose should go into 4645bis (i.e. "how did the > entries get this way"), while the simpler version I proposed can go into > 4646bis (perhaps with a pointer to "pre-existing customary practice" in > 4645bis). That's ok, as long as they are sufficiently spelled out such that they prevent mistakes. > > > 4. Ensure that there are no duplicates (where inversion and/or removal > > of parenComments results in a duplicate within the same subtag, or where > > names are the same across different subtags of the same type) > > I wasn't specific enough in my little bit of text above. "Duplicates" > (including inverted duplicates) are members of the class "problematic". ok > > > 5. The only information in parentheses is a comment, eg a clarification > > of the description. > > This could be guidance added to rule 3. ok > > > 6. The final result being that there are NO description items with > > commas outside of parenComments, except for the case that there is a > > single comma indicating inversion. > > > > Except that you go on to demonstrate below that sometimes inversion is > illusory. No. What I mean is that any cases of false inversion need to be fixed. There are not that many of them. > If these are the rules, then I'm satisfied. > > > > == > > > > Ideally, we'd have two additional rules: > > > > 7. The most commonly known name is in the first Description. > > (This may already be the case -- I don't know.) > > I don't think this is appropriate. The level of judgment required is too > great for the ietf-languages list to manage. I'm not thinking of a requirement, more of a weak should. > > > 8. A description is unique even if the parenComment is removed. > > > > We need a "MUST" here. I'd propose: > > -- > For a given record type, each Description field MUST be unique. I'd like slightly string. For a given record type, each Description field (after removing any parantheticals and inverting any comma-separated strings) MUST be unique. -- > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > ------=_Part_63068_4225460.1161113833707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/17/06, Addison Phillips <addison@yahoo-inc.com> wrote:
Mark Davis wrote:
> As I said before, I can live with inversion IF it is fixed. That means
> an extension of Addison's proposed rules.
>
> 1. Follow the source standard.
>
> 2. Split multiple names into multiple description fields.
> I believe Addison meant: X, Y, Y =>
> Description: X
> Description: Y
> Description: Z

Yes, exactly so.

>
> 3. Omit or edit problematic items, subject to consensus.
>
> plus

Well... my goal was to avoid having to spell all of this out. We've got
enough rules, so I think some hand-waving is in order. While I note the
problem projects like CLDR might have producing localizations, the use
of an actual Turing machine (aka Doug Ewell) to create the entries
should eliminate a lot of woes. Furthermore, I tend to think that the
*detailed* rules you propose should go into 4645bis (i.e. "how did the
entries get this way"), while the simpler version I proposed can go into
4646bis (perhaps with a pointer to "pre-existing customary practice" in
4645bis).

That's ok, as long as they are sufficiently spelled out such that they prevent mistakes.

>
> 4. Ensure that there are no duplicates (where inversion and/or removal
> of parenComments results in a duplicate within the same subtag, or where
> names are the same across different subtags of the same type)

I wasn't specific enough in my little bit of text above. "Duplicates"
(including inverted duplicates) are members of the class "problematic".

ok

>
> 5. The only information in parentheses is a comment, eg a clarification
> of the description.

This could be guidance added to rule 3.

ok

>
> 6. The final result being that there are NO description items with
> commas outside of parenComments, except for the case that there is a
> single comma indicating inversion.
>

Except that you go on to demonstrate below that sometimes inversion is
illusory.

No. What I mean is that any cases of false inversion need to be fixed. There are not that many of them.

> If these are the rules, then I'm satisfied.
>
> ==
>
> Ideally, we'd have two additional rules:
>
> 7. The most commonly known name is in the first Description.
> (This may already be the case -- I don't know.)

I don't think this is appropriate. The level of judgment required is too
great for the ietf-languages list to manage.

I'm not thinking of a requirement, more of a weak should.

>
> 8. A description is unique even if the parenComment is removed.
>

We need a "MUST" here. I'd propose:

--
For a given record type, each Description field MUST be unique.

I'd like slightly string.

For a given record type, each Description field (after removing any parantheticals and inverting any comma-separated strings) MUST be unique.

--

Addison

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

Internationalization is an architecture.
It is not a feature.

------=_Part_63068_4225460.1161113833707-- --===============0160582438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0160582438==-- From ltru-bounces@ietf.org Tue Oct 17 15:43:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZuqk-0005Iw-0L; Tue, 17 Oct 2006 15:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZuqi-0005If-GM for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:43:40 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuqf-0003Ii-HH for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:43:40 -0400 Received: by wx-out-0506.google.com with SMTP id h28so24225wxd for ; Tue, 17 Oct 2006 12:43:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jNUST4+bmenEzAXZvcdxUNdUUJaNrzRwrGGAHrEFpj0XoJAdNjNCVIkhyVc7xxlq2GdpW0Utm73r0yZuhRZQ+fqmXW8SSGV8CYMZOm6KUIbys0Ui0gXrlDn0WTLPBv+Z4H2WeVqPgfS0f9SQLgJusUT1MkaByWiXZ7wPvPvOCQk= Received: by 10.90.81.14 with SMTP id e14mr5399366agb; Tue, 17 Oct 2006 12:43:37 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 12:43:37 -0700 (PDT) Message-ID: <30b660a20610171243i49caaa5cs3ac3ade758e1c997@mail.gmail.com> Date: Tue, 17 Oct 2006 12:43:37 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <4534FD40.1030704@yahoo-inc.com> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> X-Google-Sender-Auth: 36f702c3333af00f X-Spam-Score: 0.6 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0282034297==" Errors-To: ltru-bounces@ietf.org --===============0282034297== Content-Type: multipart/alternative; boundary="----=_Part_63136_15918429.1161114217265" ------=_Part_63136_15918429.1161114217265 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm ok with the direction. I think it needs a bit more qualification, so I suggest the text below. For a records of a given 'Type', the value of the 'Description' field MUST be unique, after removing parentheticals and inverting any string containing commas. For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the source standard. Multiple descriptions in the source standard MUST be split into separate 'Description' fields. Outside of parentheticals, commas MUST only be used for inverted strings. The source standard's descriptions MAY also be edited prior to insertion. Duplicate, redundant, conflicting, or otherwise problematic descriptions MUST be corrected or omitted. Parenthetical comments, inverted names, and other formatting variants SHOULD be regularized according to the guidelines used to update the registry in . Mark On 10/17/06, Addison Phillips wrote: > > Maybe more to the point, I propose we insert this text into the > 'Description' section of the document (the current Section 3.1.3.2): > > For a records of a given 'Type', the value of the 'Description' field > MUST be unique. For records taken from a source standard (such as ISO > 639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the > source standard. Multiple descriptions in the source standard MUST be > split into separate 'Description' fields. The source standard's > descriptions MAY also be edited prior to insertion. Duplicate, > redundant, conflicting, or otherwise problematic descriptions SHOULD be > omitted. Parenthetical comments, inverted names, and other formatting > quirks SHOULD be regularized according to the guidelines used to update > the registry in . > > Addison > > Addison Phillips wrote: > > Mark Davis wrote: > >> As I said before, I can live with inversion IF it is fixed. That means > >> an extension of Addison's proposed rules. > >> > >> 1. Follow the source standard. > >> > >> 2. Split multiple names into multiple description fields. > >> I believe Addison meant: X, Y, Y => > >> Description: X > >> Description: Y > >> Description: Z > > > > Yes, exactly so. > > > >> > >> 3. Omit or edit problematic items, subject to consensus. > >> > >> plus > > > > Well... my goal was to avoid having to spell all of this out. We've got > > enough rules, so I think some hand-waving is in order. While I note the > > problem projects like CLDR might have producing localizations, the use > > of an actual Turing machine (aka Doug Ewell) to create the entries > > should eliminate a lot of woes. Furthermore, I tend to think that the > > *detailed* rules you propose should go into 4645bis (i.e. "how did the > > entries get this way"), while the simpler version I proposed can go into > > 4646bis (perhaps with a pointer to "pre-existing customary practice" in > > 4645bis). > > > >> > >> 4. Ensure that there are no duplicates (where inversion and/or removal > >> of parenComments results in a duplicate within the same subtag, or > >> where names are the same across different subtags of the same type) > > > > I wasn't specific enough in my little bit of text above. "Duplicates" > > (including inverted duplicates) are members of the class "problematic". > > > > > >> > >> 5. The only information in parentheses is a comment, eg a > >> clarification of the description. > > > > This could be guidance added to rule 3. > > > >> > >> 6. The final result being that there are NO description items with > >> commas outside of parenComments, except for the case that there is a > >> single comma indicating inversion. > >> > > > > Except that you go on to demonstrate below that sometimes inversion is > > illusory. > > > >> If these are the rules, then I'm satisfied. > >> > >> == > >> > >> Ideally, we'd have two additional rules: > >> > >> 7. The most commonly known name is in the first Description. > >> (This may already be the case -- I don't know.) > > > > I don't think this is appropriate. The level of judgment required is too > > great for the ietf-languages list to manage. > > > >> > >> 8. A description is unique even if the parenComment is removed. > >> > > > > We need a "MUST" here. I'd propose: > > > > -- > > For a given record type, each Description field MUST be unique. > > -- > > > > Addison > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > ------=_Part_63136_15918429.1161114217265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm ok with the direction. I think it needs a bit more qualification, so I suggest the text below.

<t>For a records of a given 'Type', the value of the 'Description' field
MUST be unique, after removing parentheticals and inverting any string
containing commas. For records taken from a source standard (such as ISO
639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the
source standard. Multiple descriptions in the source standard MUST be
split into separate 'Description' fields. Outside of parentheticals, commas
MUST only be used for inverted strings. The source standard's
descriptions MAY also be edited prior to insertion. Duplicate,
redundant, conflicting, or otherwise problematic descriptions MUST be
corrected or omitted. Parenthetical comments, inverted names, and other
formatting variants SHOULD be regularized according to the guidelines used
to update the registry in <xref target="registry-update"><
/xref>.</t>

Mark

On 10/17/06, Addison Phillips <addison@yahoo-inc.com > wrote:
Maybe more to the point, I propose we insert this text into the
'Description' section of the document (the current Section 3.1.3.2):

<t>For a records of a given 'Type', the value of the 'Description' field
MUST be unique. For records taken from a source standard (such as ISO
639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the
source standard. Multiple descriptions in the source standard MUST be
split into separate 'Description' fields. The source standard's
descriptions MAY also be edited prior to insertion. Duplicate,
redundant, conflicting, or otherwise problematic descriptions SHOULD be
omitted. Parenthetical comments, inverted names, and other formatting
quirks SHOULD be regularized according to the guidelines used to update
the registry in <xref target="registry-update"></xref>.</t>

Addison

Addison Phillips wrote:
> Mark Davis wrote:
>> As I said before, I can live with inversion IF it is fixed. That means
>> an extension of Addison's proposed rules.
>>
>> 1. Follow the source standard.
>>
>> 2. Split multiple names into multiple description fields.
>> I believe Addison meant: X, Y, Y =>
>> Description: X
>> Description: Y
>> Description: Z
>
> Yes, exactly so.
>
>>
>> 3. Omit or edit problematic items, subject to consensus.
>>
>> plus
>
> Well... my goal was to avoid having to spell all of this out. We've got
> enough rules, so I think some hand-waving is in order. While I note the
> problem projects like CLDR might have producing localizations, the use
> of an actual Turing machine (aka Doug Ewell) to create the entries
> should eliminate a lot of woes. Furthermore, I tend to think that the
> *detailed* rules you propose should go into 4645bis (i.e. "how did the
> entries get this way"), while the simpler version I proposed can go into
> 4646bis (perhaps with a pointer to "pre-existing customary practice" in
> 4645bis).
>
>>
>> 4. Ensure that there are no duplicates (where inversion and/or removal
>> of parenComments results in a duplicate within the same subtag, or
>> where names are the same across different subtags of the same type)
>
> I wasn't specific enough in my little bit of text above. "Duplicates"
> (including inverted duplicates) are members of the class "problematic".
>
>
>>
>> 5. The only information in parentheses is a comment, eg a
>> clarification of the description.
>
> This could be guidance added to rule 3.
>
>>
>> 6. The final result being that there are NO description items with
>> commas outside of parenComments, except for the case that there is a
>> single comma indicating inversion.
>>
>
> Except that you go on to demonstrate below that sometimes inversion is
> illusory.
>
>> If these are the rules, then I'm satisfied.
>>
>> ==
>>
>> Ideally, we'd have two additional rules:
>>
>> 7. The most commonly known name is in the first Description.
>> (This may already be the case -- I don't know.)
>
> I don't think this is appropriate. The level of judgment required is too
> great for the ietf-languages list to manage.
>
>>
>> 8. A description is unique even if the parenComment is removed.
>>
>
> We need a "MUST" here. I'd propose:
>
> --
> For a given record type, each Description field MUST be unique.
> --
>
> Addison
>

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

Internationalization is an architecture.
It is not a feature.

------=_Part_63136_15918429.1161114217265-- --===============0282034297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0282034297==-- From ltru-bounces@ietf.org Tue Oct 17 15:46:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZutG-0008V7-EM; Tue, 17 Oct 2006 15:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZutF-0008UW-QI for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:46:17 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZutE-0003nF-FH for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:46:17 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9HJk68G046578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 12:46:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=k/Z+o183csi7GhIJQKM2Pe++afmsrj+ilgyUiQBDd0v5IHkZqvrVXXsn1Ka/oPQf Message-ID: <453532FD.2050202@yahoo-inc.com> Date: Tue, 17 Oct 2006 12:46:05 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> In-Reply-To: <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > For a given record type, each Description field MUST be unique. > > > I'd like slightly string. Mnrgle? > > For a given record type, each Description field (after removing any > parantheticals and inverting any comma-separated strings) MUST be unique. > No, actually, if two of the same description field appear anywhere in the file, something is wrong. We wouldn't want: Subtag: xx Description: Western Xish %% Subtag: xy Description: Western Xish If what you're say is that the following should also be prohibited, I agree: Subtag: xx Description: Western Xish %% Subtag: xy Description: Xish, Western Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 16:05:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvBY-0001ZM-62; Tue, 17 Oct 2006 16:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvBW-0001Yg-QJ for ltru@lists.ietf.org; Tue, 17 Oct 2006 16:05:10 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZv9j-00067x-Uf for ltru@lists.ietf.org; Tue, 17 Oct 2006 16:03:21 -0400 Received: by wx-out-0506.google.com with SMTP id h28so29862wxd for ; Tue, 17 Oct 2006 13:03:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=qSMoPRDl5cpAWeCbEAJDIEUvDZn7ZubbM3PFPQQbblrebduNZ/HFmQPMLTl268sXvkU2fslSHurQUfc37wvp+77otrJvHeROX45bedxtv0OBfW5q8ADjAaEmbqM2TJSgF/kKho5ZFxY8FRVsXwLG1ZUEaEJcp4nijjBzWlE8U+M= Received: by 10.90.55.19 with SMTP id d19mr5432617aga; Tue, 17 Oct 2006 13:03:19 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 13:03:19 -0700 (PDT) Message-ID: <30b660a20610171303h2010c44cq5ccf50c2f9fb83e0@mail.gmail.com> Date: Tue, 17 Oct 2006 13:03:19 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <30b660a20610171243i49caaa5cs3ac3ade758e1c997@mail.gmail.com> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <30b660a20610171243i49caaa5cs3ac3ade758e1c997@mail.gmail.com> X-Google-Sender-Auth: 491ae8f09636a62e X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809727609==" Errors-To: ltru-bounces@ietf.org --===============1809727609== Content-Type: multipart/alternative; boundary="----=_Part_63400_6908345.1161115399142" ------=_Part_63400_6908345.1161115399142 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I generated a file at http://macchiato.com/ltru/ltru-inversions.txt. It contains a mapping from all of the descriptions (sans parentheticals) to their uninverted forms. It also *adds* cases that are "possibly missing", marked with @MISSING. The file, as usuall, is tab delimited, so best pulled into a program that lines them up into columns, like Excel or equivalent. The "possibly missing" inversions are produced by collecting all of the prefixes and suffixes of existing inversions, and seeing if any of the uninverted string matches such an existing prefix or suffix. For example, if there is some preexisting inversion such as "Armenian, X" in the 01 data file, and the program sees "Y Armenian", then it includes "Armenian, Y @MISSING" for review in this file. There are 251 of these items. So that we have consistent inversion, these should be reviewed before we finalize the descriptions. For example, in the list we see: 103 Armenian, Classical Classical Armenian 104 Armenian, Eastern Eastern Armenian @MISSING 105 Armenian, Middle Middle Armenian 106 Armenian, Western Western Armenian @MISSING #104 and #106 are missing, meaning that we don't invert those (although, IMO, clearly we should if we are doing inversion). The whole list could probably stand review -- it exposes some clear spurious differences, eg "Alaska" vs "Alaskan" in the following: 31 Alaska Inupiatun, Northwest Northwest Alaska Inupiatun @MISSING 32 Alaskan Inupiatun, North North Alaskan Inupiatun @MISSING Mark ------=_Part_63400_6908345.1161115399142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I generated a file at http://macchiato.com/ltru/ltru-inversions.txt. It contains a mapping from all of the descriptions (sans parentheticals) to their uninverted forms. It also *adds* cases that are "possibly missing", marked with @MISSING. The file, as usuall, is tab delimited, so best pulled into a program that lines them up into columns, like Excel or equivalent.

The "possibly missing" inversions are produced by collecting all of the prefixes and suffixes of existing inversions, and seeing if any of the uninverted string matches such an existing prefix or suffix. For example, if there is some preexisting inversion such as "Armenian, X" in the 01 data file, and the program sees "Y Armenian", then it includes "Armenian, Y @MISSING" for review in this file.

There are 251 of these items. So that we have consistent inversion, these should be reviewed before we finalize the descriptions. For example, in the list we see:
103	Armenian, Classical	Classical Armenian

104	Armenian, Eastern	Eastern Armenian	@MISSING
105	Armenian, Middle	Middle Armenian
106	Armenian, Western	Western Armenian	@MISSING
#104 and #106 are missing, meaning that we don't invert those (although, IMO, clearly we should if we are doing inversion).

The whole list could probably stand review -- it exposes some clear spurious differences, eg "Alaska" vs "Alaskan" in the following:
31	Alaska Inupiatun, Northwest	Northwest Alaska Inupiatun	@MISSING

32	Alaskan Inupiatun, North	North Alaskan Inupiatun	@MISSING
Mark
------=_Part_63400_6908345.1161115399142-- --===============1809727609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1809727609==-- From ltru-bounces@ietf.org Tue Oct 17 16:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZviK-0001NN-I3; Tue, 17 Oct 2006 16:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvC6-0001kF-O3 for ltru@lists.ietf.org; Tue, 17 Oct 2006 16:05:46 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZv1Q-0005Dm-1a for ltru@lists.ietf.org; Tue, 17 Oct 2006 15:54:45 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9HJsXaD046978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 12:54:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=U4QgjrcfwFApO/lyYq6ezZN0ch96PAnTYww29Q2/uy28C31vfbiSWkpm3eTjP2A1 Message-ID: <453534F9.80805@yahoo-inc.com> Date: Tue, 17 Oct 2006 12:54:33 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <30b660a20610171243i49caaa5cs3ac3ade758e1c997@mail.gmail.com> In-Reply-To: <30b660a20610171243i49caaa5cs3ac3ade758e1c997@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I'm ok with the direction. I think it needs a bit more qualification, so > I suggest the text below. > Additional edits were needed, notably for the "For a records" typo. I ended up with: -- For each collection of records of a particular 'Type', each of the values that appears in a 'Description' field MUST be unique. For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the source standard. Multiple descriptions in the source standard MUST be split into separate 'Description' fields. The source standard's descriptions MAY also be edited prior to insertion. Duplicate, redundant, conflicting, or otherwise problematic descriptions MUST either be corrected or omitted. Parenthetical comments, inverted names, and other formatting quirks SHOULD be regularized according to the guidelines used to update the registry in . -- Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 20:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz26-00037Q-ES; Tue, 17 Oct 2006 20:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz25-00037L-Vf for ltru@lists.ietf.org; Tue, 17 Oct 2006 20:11:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZz20-0003pg-MC for ltru@lists.ietf.org; Tue, 17 Oct 2006 20:11:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZz1t-0002bt-7d for ltru@lists.ietf.org; Wed, 18 Oct 2006 02:11:29 +0200 Received: from pd9fbadb9.dip0.t-ipconnect.de ([217.251.173.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 02:11:29 +0200 Received: from nobody by pd9fbadb9.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 02:11:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 18 Oct 2006 02:09:18 +0200 Organization: Lines: 32 Message-ID: <453570AE.6A4A@xyzzy.claranet.de> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadb9.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: >> I'd like slightly string. > Mnrgle? "slightly more stringent MUSTard" ;-) >> For a given record type, each Description field (after removing any >> parantheticals and inverting any comma-separated strings) MUST be unique. > No, actually, if two of the same description field appear anywhere in > the file, something is wrong. That could happen with deprecated tags or subtags. We have three records with description "Hebrew" in 4645bis-00, and one of those is the script. > If what you're say is that the following should also be prohibited, I > agree: > Subtag: xx > Description: Western Xish > %% > Subtag: xy > Description: Xish, Western That's apparently what it says for readers of this thread. Is "inverting any comma-separated string" also obvious for readers of 4646bis, or does it need an example ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 20:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzAX-00011q-BX; Tue, 17 Oct 2006 20:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzAW-00011i-0y for ltru@lists.ietf.org; Tue, 17 Oct 2006 20:20:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzAT-0004IM-NV for ltru@lists.ietf.org; Tue, 17 Oct 2006 20:20:24 -0400 Received: by wx-out-0506.google.com with SMTP id h28so94095wxd for ; Tue, 17 Oct 2006 17:20:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KNcA3xvNxaNlmei5q04W+DRJ0p6GZEox88332k71vGnaVQ30xch8qIbhRkQ9IuagcXnqFanBMJtDEhBsV6gzZlI0GjzNL/c+pwKF2n4OIMZmmSZ9fgA2i/1ndD8NAjiavu4FF7VvLr870iO/RTPDHm3WQ6XfOfNnxB791Sfxbt8= Received: by 10.90.118.10 with SMTP id q10mr5659682agc; Tue, 17 Oct 2006 17:20:21 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 17:20:21 -0700 (PDT) Message-ID: <30b660a20610171720h7d7ce6c2lee32ce179bac30c1@mail.gmail.com> Date: Tue, 17 Oct 2006 17:20:21 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <453570AE.6A4A@xyzzy.claranet.de> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> <453570AE.6A4A@xyzzy.claranet.de> X-Google-Sender-Auth: 5e0b8ee943d20ffb X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1295641695==" Errors-To: ltru-bounces@ietf.org --===============1295641695== Content-Type: multipart/alternative; boundary="----=_Part_64832_6371999.1161130821046" ------=_Part_64832_6371999.1161130821046 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Good point: we need to exclude the deprecated cases (I did that in my program, but neglected to note it). Mark On 10/17/06, Frank Ellermann wrote: > > Addison Phillips wrote: > > >> I'd like slightly string. > > > Mnrgle? > > "slightly more stringent MUSTard" ;-) > > >> For a given record type, each Description field (after removing any > >> parantheticals and inverting any comma-separated strings) MUST be > unique. > > > No, actually, if two of the same description field appear anywhere in > > the file, something is wrong. > > That could happen with deprecated tags or subtags. We have three records > with description "Hebrew" in 4645bis-00, and one of those is the script. > > > If what you're say is that the following should also be prohibited, I > > agree: > > > Subtag: xx > > Description: Western Xish > > %% > > Subtag: xy > > Description: Xish, Western > > That's apparently what it says for readers of this thread. Is "inverting > any comma-separated string" also obvious for readers of 4646bis, or does > it need an example ? I always think examples are worthwhile: we could include Xish cases for clarity. Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_64832_6371999.1161130821046 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Good point: we need to exclude the deprecated cases (I did that in my program, but neglected to note it).

Mark

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

>> I'd like slightly string.

> Mnrgle?

"slightly more stringent MUSTard" ;-)

>> For a given record type, each Description field (after removing any
>> parantheticals and inverting any comma-separated strings) MUST be unique.

> No, actually, if two of the same description field appear anywhere in
> the file, something is wrong.

That could happen with deprecated tags or subtags.  We have three records
with description "Hebrew" in 4645bis-00, and one of those is the script.

> If what you're say is that the following should also be prohibited, I
> agree:

> Subtag: xx
> Description: Western Xish
> %%
> Subtag: xy
> Description: Xish, Western

That's apparently what it says for readers of this thread.  Is "inverting
any comma-separated string" also obvious for readers of 4646bis, or does
it need an example ?

I always think examples are worthwhile: we could include Xish cases for clarity.

Frank



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

------=_Part_64832_6371999.1161130821046-- --===============1295641695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1295641695==-- From ltru-bounces@ietf.org Tue Oct 17 22:16:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0yP-0006Bz-7s; Tue, 17 Oct 2006 22:16:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0yL-00066A-Ux for ltru@ietf.org; Tue, 17 Oct 2006 22:15:57 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga0qq-0004nS-0S for ltru@ietf.org; Tue, 17 Oct 2006 22:08:13 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Ga0qp-0003od-Iq; Tue, 17 Oct 2006 22:08:11 -0400 Date: Tue, 17 Oct 2006 22:08:11 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems Message-ID: <20061018020811.GA20645@ccil.org> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> <453570AE.6A4A@xyzzy.claranet.de> <30b660a20610171720h7d7ce6c2lee32ce179bac30c1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610171720h7d7ce6c2lee32ce179bac30c1@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Good point: we need to exclude the deprecated cases (I did that in my > program, but neglected to note it). It's not uncommon for a script and a language to have the same name, and I don't think we should insist on an artificial distinction here. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master. --Kehlog Albran Besides, the Temple of Toplat is across the street." The Profit _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 22:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1Sd-0003uq-Bt; Tue, 17 Oct 2006 22:47:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1Sb-0003qJ-GY for ltru@lists.ietf.org; Tue, 17 Oct 2006 22:47:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZvTR-0002oL-Me for ltru@lists.ietf.org; Tue, 17 Oct 2006 16:23:41 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZvHn-0002eS-7C for ltru@lists.ietf.org; Tue, 17 Oct 2006 16:11:42 -0400 Received: by wx-out-0506.google.com with SMTP id h28so32124wxd for ; Tue, 17 Oct 2006 13:11:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iwjiLxWz1c8ZSih6k6nlLAyyv/VNnPNMdpRTsAzCgooak6SLsW20NDAZ8ZXQtfjv4GwaVvLE8VGWH6SgUrRUkGHRFLzLfGG/O19xBiKL+bsBqre+ckOaTap7mq8zSQQT3L01S6GaivfGxgDPE9bo2TE6zr1Bl1aa2YMF8SkLt7I= Received: by 10.90.103.2 with SMTP id a2mr5462567agc; Tue, 17 Oct 2006 13:11:38 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 13:11:38 -0700 (PDT) Message-ID: <30b660a20610171311v7381b71dme7546600beeeebdd@mail.gmail.com> Date: Tue, 17 Oct 2006 13:11:38 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <453532FD.2050202@yahoo-inc.com> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> X-Google-Sender-Auth: 97b3b1667ca4b1b7 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0202284496==" Errors-To: ltru-bounces@ietf.org --===============0202284496== Content-Type: multipart/alternative; boundary="----=_Part_63500_33333022.1161115898736" ------=_Part_63500_33333022.1161115898736 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/17/06, Addison Phillips wrote: > > Mark Davis wrote: > > For a given record type, each Description field MUST be unique. > > > > > > I'd like slightly string. > > Mnrgle? ypu, srory! > > > For a given record type, each Description field (after removing any > > parantheticals and inverting any comma-separated strings) MUST be > unique. > > > > No, actually, if two of the same description field appear anywhere in > the file, something is wrong. We wouldn't want: > > > Subtag: xx > Description: Western Xish > %% > Subtag: xy > Description: Western Xish > > If what you're say is that the following should also be prohibited, I > agree: Yes, that's what it means. "For a given record type, each Description field (after removing any parantheticals and inverting any comma-separated strings) MUST be unique." means that if we have Description: Western Xish then each of the following is disallowed, anywhere else (under the same type, of course!): Description: Western Xish Description: Western Xish (Amusing) Description: Xish, Western (Amusing) Description: Xish, Western Subtag: xx > Description: Western Xish > %% > Subtag: xy > Description: Xish, Western > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > ------=_Part_63500_33333022.1161115898736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/17/06, Addison Phillips <addison@yahoo-inc.com> wrote:
Mark Davis wrote:
>     For a given record type, each Description field MUST be unique.
>
>
> I'd like slightly string.

Mnrgle?

ypu, srory!

>
> For a given record type, each Description field (after removing any
> parantheticals and inverting any comma-separated strings) MUST be unique.
>

No, actually, if two of the same description field appear anywhere in
the file, something is wrong. We wouldn't want:


Subtag: xx
Description: Western Xish
%%
Subtag: xy
Description: Western Xish

If what you're say is that the following should also be prohibited, I agree:

Yes, that's what it means. "For a given record type, each Description field (after removing any parantheticals and inverting any comma-separated strings) MUST be unique." means that if we have

Description: Western Xish

then each of the following is disallowed, anywhere else (under the same type, of course!):

Description: Western Xish
Description: Western Xish (Amusing)
Description: Xish, Western (Amusing)
Description: Xish, Western

Subtag: xx
Description: Western Xish
%%
Subtag: xy
Description: Xish, Western

Addison

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

Internationalization is an architecture.
It is not a feature.

------=_Part_63500_33333022.1161115898736-- --===============0202284496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0202284496==-- From ltru-bounces@ietf.org Tue Oct 17 22:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1ZN-0007pb-TD; Tue, 17 Oct 2006 22:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1ZM-0007pW-OY for ltru@ietf.org; Tue, 17 Oct 2006 22:54:12 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga1ZL-0002VL-EZ for ltru@ietf.org; Tue, 17 Oct 2006 22:54:12 -0400 Received: by wx-out-0506.google.com with SMTP id h30so144707wxd for ; Tue, 17 Oct 2006 19:54:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kKHXVj9PN30k3CyRF3qB3UsIgIMc2lfwCwi1ZqOekEocEnuFBPemrfMUJiZ+Eir0gjalSEtq5j6mRk0qWveGaBz7nCZ3Fzrmm/6sjOK6sBejkX6JIsTHc0fgcFbn1YWuB0QIh2qsoy7yhB//SgcWW34D9Sc7ChooWMV9J3ouOjk= Received: by 10.90.25.3 with SMTP id 3mr5719709agy; Tue, 17 Oct 2006 19:54:10 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 17 Oct 2006 19:54:10 -0700 (PDT) Message-ID: <30b660a20610171954m4a6f5e42xda6571650d7c3a4b@mail.gmail.com> Date: Tue, 17 Oct 2006 19:54:10 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <20061018020811.GA20645@ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> <453570AE.6A4A@xyzzy.claranet.de> <30b660a20610171720h7d7ce6c2lee32ce179bac30c1@mail.gmail.com> <20061018020811.GA20645@ccil.org> X-Google-Sender-Auth: 77aabc9c4ac77671 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You misunderstand. There are 3 items called "Hebrew" The script is distinct from the others, and is not at issue. Everything we have been saying is that the items must be distinct *within a type*. See the line: >For a records of a given 'Type', the value of the 'Description' The problem is that there are two cases with type=language & description=Hebrew: he and iw. For that reasons, we need to restrict the clause to only worry about non-deprecated languages. Fleshing it out with examples, reordering slightly, and adding the qualification, here is my suggested language: For each collection of records of a particular 'Type' (excluding records with a Deprecated field), each of the values that appears in a 'Description' field MUST be unique. The description values MUST also be unique even after removing parentheticals and inverting any string containing commas. Outside of parentheticals, commas MUST only be used for inverted strings. An inverted name such as "Xishu, Gibrus" is used to facilitate sorting in English according to most salient feature (in this case, "Xishu"). Such inversions would not necessarily be reflected in translations to other languages. Commas (outside of parentheticals) always indicates inversion, not multiple names or other constructs. Thus "Xishu, Gibrus" is always equivalent to "Gibrus Xishu", just differing in presentation. For example, suppose that the following description is in a language subtag record: 
Description: Gibrus Xishu
Then that line cannot occur again in that record, nor in any other language subtag record. Moreover, none of the following can occur in any language subtag record: 
Description: Gibrus Xishu (any comment)
Description: Xishu, Gibrus 
Description: Xishu, Gibrus (any comment)
For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD be based on the source standard. The source standard's descriptions MAY also be edited prior to insertion. Multiple descriptions in the source standard MUST be split into separate 'Description' fields. Duplicate, redundant, conflicting, or otherwise problematic descriptions MUST either be corrected or omitted. Parenthetical comments, inverted names, and other formatting variants SHOULD be regularized according to the guidelines used to update the registry in . Mark On 10/17/06, John Cowan wrote: > Mark Davis scripsit: > > > Good point: we need to exclude the deprecated cases (I did that in my > > program, but neglected to note it). > > It's not uncommon for a script and a language to have the same name, > and I don't think we should insist on an artificial distinction here. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > "After all, would you consider a man without honor wealthy, even if his > Dinar laid end to end would reach from here to the Temple of Toplat?" > "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. > "A Dinar doesn't go very far these days, Master. --Kehlog Albran > Besides, the Temple of Toplat is across the street." The Profit > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 17 23:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2Fm-0004CY-DD; Tue, 17 Oct 2006 23:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2Fk-0004CQ-He for ltru@lists.ietf.org; Tue, 17 Oct 2006 23:38:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2Fi-000830-4A for ltru@lists.ietf.org; Tue, 17 Oct 2006 23:38:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ga2FN-00075N-JU for ltru@lists.ietf.org; Wed, 18 Oct 2006 05:37:37 +0200 Received: from pd9fbadb9.dip0.t-ipconnect.de ([217.251.173.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 05:37:37 +0200 Received: from nobody by pd9fbadb9.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 05:37:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 18 Oct 2006 05:36:24 +0200 Organization: Lines: 41 Message-ID: <4535A138.1A26@xyzzy.claranet.de> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> <453570AE.6A4A@xyzzy.claranet.de> <30b660a20610171720h7d7ce6c2lee32ce179bac30c1@mail.gmail.com> <20061018020811.GA20645@ccil.org> <30b660a20610171954m4a6f5e42xda6571650d7c3a4b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadb9.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > here is my suggested language: >| For each collection of records of a particular 'Type' (excluding >| records with a Deprecated field), each of the values that appears >| in a 'Description' field MUST be unique. ACK so far, that just makes sense. It doesn't catch the fine print of a shared namespace for language and extlang (JFTR, I'm not saying that it should) >| The description values MUST also be unique even after removing >| parentheticals [...] I'm not sure about this parenthical bit, see below, [...] >| and inverting any string containing commas. [...] That's again clear, and I like it. [...] >| Outside of parentheticals, commas MUST only be used for inverted >| strings. If you insist on this new comma-rule we're forced to patch several redundant and grandfathered descriptions, as noted before in another article - for the six 1901/1996 cases it would be simple. >| For example, suppose that the following description is in a >| language subtag record: > 
Description: Gibrus Xishu
My preferred style would be what we get from the "inverted name" column in the table derived from the 639-3 draft: Xishu, Gibrus How does your parenthical rule handle Ainu (China) vs. Ainu (Japan), or similar Aja (Sudan) vs. Aja (Benin) ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 00:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2i1-00078p-FM; Wed, 18 Oct 2006 00:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2i0-00078W-5z for ltru@ietf.org; Wed, 18 Oct 2006 00:07:12 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2hy-0004DC-T5 for ltru@ietf.org; Wed, 18 Oct 2006 00:07:12 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018040710.COXF9984.mta9.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 00:07:10 -0400 Message-ID: <00b701c6f26a$e3338f20$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 17 Oct 2006 21:07:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: IPA, NSAI and ANSI X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Considering that RFC 4646 is a relatively high-profile application of code elements from ISO 639, 3166, and 15924, it was probably inevitable that some would expect this WG to exert authority over these standards and their RAs and MAs, but the simple truth is that we do not control them, and they do not control us. We do control our own rules for how we choose to use these standards, and we have chosen -- wisely IMHO -- not to extend them unilaterally, by registering subtags that conflict with potentially assignable code elements. This means if someone wants code element ABC added to ISO standard XYZ, the place to make that argument is the ISO XYZ/MA, or national bodies, and not the LTRU WG -- unless the person wants to propose instead that we change our rules and extend the standard. I'll leave it to others to speak to the issue of characterizing the workings of the ISO 15924 AC as a battle between big countries and small countries. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 00:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2zk-0002jn-07; Wed, 18 Oct 2006 00:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2zj-0002ih-6Y for ltru@ietf.org; Wed, 18 Oct 2006 00:25:31 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2qV-00064e-JZ for ltru@ietf.org; Wed, 18 Oct 2006 00:16:00 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018041558.DCBE9984.mta9.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 00:15:58 -0400 Message-ID: <00ca01c6f26c$1e20e5a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 17 Oct 2006 21:15:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ltru] Sorry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I apologize for re-sending an entire digest back to the list. When you click "Reply" in Outlook Express, then stutter on the mouse and click again in the same spot, you've just hit the "Send" button. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 00:25:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga301-0002pg-6C; Wed, 18 Oct 2006 00:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga300-0002kp-7S for ltru@ietf.org; Wed, 18 Oct 2006 00:25:48 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2mB-0004yz-Gc for ltru@ietf.org; Wed, 18 Oct 2006 00:11:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018041129.CVOK9984.mta9.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 00:11:29 -0400 Message-ID: <00bd01c6f26b$7dd6a800$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 17 Oct 2006 21:11:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Errors in prototype 4646bis Registry X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Re the duplicate "Dimli", it would seem reasonable to me to employ the > same mechanism that 639-3 uses: "Dimli (macrolanguage)". Kent Karlsson replied: > I still very much dislike a parenthetical "(macrolanguage)" (or > "(collection)" if that is the case, or "(individual)") in a name. > "Dimli languages" maybe, or use an alternate name for the > "macrolanguage" if one of the alternatives already refer more to the > "macrolanguage" (Zaza?) than the others, or similar would be > preferable. (But ok, not for LTRU to decide.) Before we address this or any other specific case, we must agree on whether the Registry can deviate from names in the ISO standards. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 00:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga30o-0003FD-BG; Wed, 18 Oct 2006 00:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2zt-0002kq-HN for ltru@ietf.org; Wed, 18 Oct 2006 00:25:41 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2nQ-0005TT-Qg for ltru@ietf.org; Wed, 18 Oct 2006 00:12:51 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018041247.DTWD5383.mta13.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 00:12:47 -0400 Message-ID: <00c301c6f26b$ac297b60$6501a8c0@DGBP7M81> From: "Doug Ewell" To: References: Date: Tue, 17 Oct 2006 21:12:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Subject: [Ltru] Re: Ltru Digest, Vol 20, Issue 35 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ----- Original Message ----- From: To: Sent: Monday, October 16, 2006 10:16 Subject: Ltru Digest, Vol 20, Issue 35 > Send Ltru mailing list submissions to > ltru@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/ltru > or, via email, send a message with subject or body 'help' to > ltru-request@ietf.org > > You can reach the person managing the list at > ltru-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ltru digest..." > > > Today's Topics: > > 1. RE: Re: Registry deltas (Peter Constable) > 2. RE: Re: Registry deltas (Peter Constable) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Oct 2006 10:04:49 -0700 > From: Peter Constable > Subject: RE: [Ltru] Re: Registry deltas > To: LTRU Working Group > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Definitely some of the changes below would be wrong: e.g., > > > > - “Yi, Sichuan†is an inverted form of “Sichuan Yi†> > - “Agta, Camarines Norte†is an inverted form of “Camarines > Norte Agta†> > - “Malay, Ambonese†is an inverted form of “Ambonese Malayâ€; > “Ambonese†is an alternate name, but “Malay†probably isn’t a good > choice for an alternate name since that would generally be understood > as Bahasa Malaysia > > - “Nahuatl, Highland Puebla†is an inverted form of “Highland > Puebla Nahuatl†> > > > More of these are similar; a closer review would be needed to > determine which of these changes would really make sense. > > > > > > Peter > > > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > > > CHANGE TO SEMI-COLON > > Yi, Sichuan => Yi; Sichuan > Ayta, Ambala => Ayta; Ambala > Agta, Camarines Norte => Agta; Camarines Norte > Ayta, Abenlen => Ayta; Abenlen > Malay, Ambonese => Malay; Ambonese > Adi, Galo => Adi; Galo > Tibetan, Amdo => Tibetan; Amdo > Amis, Nataoran => Amis; Nataoran > Amuzgo, Guerrero => Amuzgo; Guerrero > Arapesh, Bumbita => Arapesh; Bumbita > Asmat, Casuarina Coast => Asmat; Casuarina Coast > Asuriní, Xingú => Asuriní; Xingú > Asmat, Yaosakor => Asmat; Yaosakor > Manobo, Ata => Manobo; Ata > One, Molmo => One; Molmo > Gbe, Ayizo => Gbe; Ayizo > Atta, Faire => Atta; Faire > Nahuatl, Highland Puebla => Nahuatl; Highland Puebla > Kayan, Busang => Kayan; Busang > Birifor, Malba => Birifor; Malba > Pahari, Mahasu => Pahari; Mahasu > Bareli, Rathwi => Bareli; Rathwi > Chin, Bawm => Chin; Bawm > Béte, Guiberoua => Béte; Guiberoua > Bété, Daloa => Bété; Daloa > Bareli, Pauri => Bareli; Pauri > Itneg, Banao => Itneg; Banao > Sorsogon, Masbate => Sorsogon; Masbate > Karen, Pa'o => Karen; Pa'o > Ayta, Mag-Indi => Ayta; Mag-Indi > Kanuri, Bilma => Kanuri; Bilma > ... > > NOTE > As I was doing this, I saw the following. It may be perfectly fine, > but it looks a bit suspicious, especially since there are a bunch of > "Atga" entries with different modifiers. Could this be a spelling > error? > > Agta, Mt. Iraya > > Mark > > On 10/9/06, Martin Duerst wrote: > > [co-chair hat off] > > At 02:22 06/10/03, Mark Davis wrote: >>Overall, I think inverted names are a bad idea. They are rather >>anglocentric, and we find that translators often do the wrong thing >>with them. They are also hugely inconsistent in the current registry. >> >>I think they are tolerable if (a) every single instance of a comma >>indicates an inverted name, and (b) all names are consistently >>inverted. Because of (a) one could programmatically fix the names to >>the correct value. > > I don't think creating artificial syntax rules or some > kind of restricted (English) grammar for Description fields > is appropriate. What I can immagine is that we use semicolons > rather than commas to indicate boundaries between input > from different origins. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/ltru/attachments/20061016/21078be7/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Mon, 16 Oct 2006 10:16:48 -0700 > From: Peter Constable > Subject: RE: [Ltru] Re: Registry deltas > To: Peter Constable , LTRU Working Group > > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > BTW, I meant to add in this discussion of inverted names and other > aspects of the forms of descriptions (not registry deltas!), if there > is feedback that this WG would want to send back to the ISO 639 JAC > for their consideration as to changes they could make in the > descriptions that would make things easier for the LSR, this is a good > time to submit that as the JAC will be meeting in a couple of weeks > (teleconf) to discuss various issues related to the completion of part > 3 and maintenance of the various parts in relation to one another. > There have been some plans to work on names (e.g. the 639-3 RA had a > work item to review the names in the 639-3 draft code table to improve > consistency, especially where the draft code table for part 3 doesn’t > have names that are widely used, such as “Dariâ€). > > > > (Also, btw: seeing the problems we have with managing description > fields has for the first time made me wonder if the formal overhead of > ISO 11179 might not offer some benefit. I don’t know enough about > 11179 to be able to answer that; it’s just a question that popped into > my head.) > > > > > > Peter > > > > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: Monday, October 16, 2006 10:05 AM > To: LTRU Working Group > Subject: RE: [Ltru] Re: Registry deltas > > > > Definitely some of the changes below would be wrong: e.g., > > > > - “Yi, Sichuan†is an inverted form of “Sichuan Yi†> > - “Agta, Camarines Norte†is an inverted form of “Camarines > Norte Agta†> > - “Malay, Ambonese†is an inverted form of “Ambonese Malayâ€; > “Ambonese†is an alternate name, but “Malay†probably isn’t a good > choice for an alternate name since that would generally be understood > as Bahasa Malaysia > > - “Nahuatl, Highland Puebla†is an inverted form of “Highland > Puebla Nahuatl†> > > > More of these are similar; a closer review would be needed to > determine which of these changes would really make sense. > > > > > > Peter > > > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > CHANGE TO SEMI-COLON > > Yi, Sichuan => Yi; Sichuan > Ayta, Ambala => Ayta; Ambala > Agta, Camarines Norte => Agta; Camarines Norte > Ayta, Abenlen => Ayta; Abenlen > Malay, Ambonese => Malay; Ambonese > Adi, Galo => Adi; Galo > Tibetan, Amdo => Tibetan; Amdo > Amis, Nataoran => Amis; Nataoran > Amuzgo, Guerrero => Amuzgo; Guerrero > Arapesh, Bumbita => Arapesh; Bumbita > Asmat, Casuarina Coast => Asmat; Casuarina Coast > Asuriní, Xingú => Asuriní; Xingú > Asmat, Yaosakor => Asmat; Yaosakor > Manobo, Ata => Manobo; Ata > One, Molmo => One; Molmo > Gbe, Ayizo => Gbe; Ayizo > Atta, Faire => Atta; Faire > Nahuatl, Highland Puebla => Nahuatl; Highland Puebla > Kayan, Busang => Kayan; Busang > Birifor, Malba => Birifor; Malba > Pahari, Mahasu => Pahari; Mahasu > Bareli, Rathwi => Bareli; Rathwi > Chin, Bawm => Chin; Bawm > Béte, Guiberoua => Béte; Guiberoua > Bété, Daloa => Bété; Daloa > Bareli, Pauri => Bareli; Pauri > Itneg, Banao => Itneg; Banao > Sorsogon, Masbate => Sorsogon; Masbate > Karen, Pa'o => Karen; Pa'o > Ayta, Mag-Indi => Ayta; Mag-Indi > Kanuri, Bilma => Kanuri; Bilma > ... > > NOTE > As I was doing this, I saw the following. It may be perfectly fine, > but it looks a bit suspicious, especially since there are a bunch of > "Atga" entries with different modifiers. Could this be a spelling > error? > > Agta, Mt. Iraya > > Mark > > On 10/9/06, Martin Duerst wrote: > > [co-chair hat off] > > At 02:22 06/10/03, Mark Davis wrote: >>Overall, I think inverted names are a bad idea. They are rather >>anglocentric, and we find that translators often do the wrong thing >>with them. They are also hugely inconsistent in the current registry. >> >>I think they are tolerable if (a) every single instance of a comma >>indicates an inverted name, and (b) all names are consistently >>inverted. Because of (a) one could programmatically fix the names to >>the correct value. > > I don't think creating artificial syntax rules or some > kind of restricted (English) grammar for Description fields > is appropriate. What I can immagine is that we use semicolons > rather than commas to indicate boundaries between input > from different origins. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/ltru/attachments/20061016/bac99ead/attachment.html > > ------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > End of Ltru Digest, Vol 20, Issue 35 > ************************************ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 01:03:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3aZ-00039O-4n; Wed, 18 Oct 2006 01:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3aX-00039G-Om for ltru@ietf.org; Wed, 18 Oct 2006 01:03:33 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga3aV-0006A7-TF for ltru@ietf.org; Wed, 18 Oct 2006 01:03:33 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018050331.ESBX9984.mta9.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 01:03:31 -0400 Message-ID: <00e801c6f272$c27d8f80$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 17 Oct 2006 22:03:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org First, I was not aware there were any comma-separated compound names at all in the ISO 639-3 data file. I thought all of the compound names were separated by semicolons. I'd like to ask Peter to confirm this. Second, *IF* the above is true, then any inverted name can be un-inverted mechanically by converting "B, A" to "A B". No intelligence is needed here. (Note that the reverse is not true if either A or B consists of more than one word.) Third, we have apparently started to plan exact wording for 4646bis on how to modify names from the ISO standards WITHOUT having settled the underlying question of whether this should even happen. Debbie and at least one other person (I think Peter) had wanted at least one Description to match the name in the standard exactly, so the entries can be correlated in case the subtag doesn't match the code element (they might have to differ for stability reasons). "Exactly" does not mean un-inverting names, removing parenthetical qualifications, changing the type of apostrophe, or even correcting typographical errors. (I have written privately to request some minor capitalization and spacing changes in 639-3.) There are valid arguments for both courses of action IMHO, and I do not argue here that we must follow one course or the other. I am arguing that we should settle the basic question first -- to follow the standards exactly or not -- BEFORE we start writing text that implements one of the possible outcomes. I ask the co-chairs again to declare consensus one way or the other on this basic question. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 01:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3cb-0004KR-QL; Wed, 18 Oct 2006 01:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3ca-0004JI-Rn for ltru@ietf.org; Wed, 18 Oct 2006 01:05:40 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga3cZ-0006R1-8o for ltru@ietf.org; Wed, 18 Oct 2006 01:05:40 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018050538.EUFV9984.mta9.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 01:05:38 -0400 Message-ID: <00ec01c6f273$0e51a3b0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 17 Oct 2006 22:05:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Doug Ewell is a better approximation of a Turing machine than any > inversion algorithm. Now I know what I'm going to have carved on my headstone. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 01:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3iA-0007LW-6s; Wed, 18 Oct 2006 01:11:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga3i8-0007LL-Hq for ltru@ietf.org; Wed, 18 Oct 2006 01:11:24 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga3i7-0007d5-9d for ltru@ietf.org; Wed, 18 Oct 2006 01:11:24 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061018051122.FANN9984.mta9.adelphia.net@DGBP7M81> for ; Wed, 18 Oct 2006 01:11:22 -0400 Message-ID: <00f001c6f273$db713c70$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 17 Oct 2006 22:11:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > 1. There are examples containing a double comma; those don't invert > properly > Resian, Resianic, Rezijan IMHO we should specifically not attempt to transform the names of any grandfathered or redundant tags. Those exist as historical artifacts from RFC 1766 and 3066 and should not be tampered with. If we are going to alter redundant tags, we may as well get rid of them. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 01:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga4Jo-00011A-9I; Wed, 18 Oct 2006 01:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga4Jm-0000xs-Fy for ltru@ietf.org; Wed, 18 Oct 2006 01:50:18 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga4Jg-0006q4-2p for ltru@ietf.org; Wed, 18 Oct 2006 01:50:18 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Tue, 17 Oct 2006 22:50:11 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 17 Oct 2006 22:50:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Inversions and other problems Date: Tue, 17 Oct 2006 22:49:03 -0700 Message-ID: In-Reply-To: <00e801c6f272$c27d8f80$6501a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Inversions and other problems thread-index: AcbycsjpfhCUHa3hTFqLwp8V5imfNQABe9rw From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 18 Oct 2006 05:50:10.0501 (UTC) FILETIME=[45F0C750:01C6F279] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re use of commas, I believe there is no case in the 639-3 draft code table data file where alternate names are separated by commas, but I'd have to investigate to determine for sure. Re mapping "B, A" to "A B", it might not always be that simple if A contains a parenthetical -- i.e. we're talking about "B, C (D)", which should map to "C B (D)". Peter -----Original Message----- From: Doug Ewell [mailto:dewell@adelphia.net]=20 Sent: Tuesday, October 17, 2006 10:04 PM To: LTRU Working Group Subject: [Ltru] Re: Inversions and other problems First, I was not aware there were any comma-separated compound names at=20 all in the ISO 639-3 data file. I thought all of the compound names=20 were separated by semicolons. I'd like to ask Peter to confirm this. Second, *IF* the above is true, then any inverted name can be=20 un-inverted mechanically by converting "B, A" to "A B". No intelligence is needed here. (Note that the reverse is not true if either A or B=20 consists of more than one word.) Third, we have apparently started to plan exact wording for 4646bis on=20 how to modify names from the ISO standards WITHOUT having settled the=20 underlying question of whether this should even happen. Debbie and at=20 least one other person (I think Peter) had wanted at least one=20 Description to match the name in the standard exactly, so the entries=20 can be correlated in case the subtag doesn't match the code element=20 (they might have to differ for stability reasons). "Exactly" does not=20 mean un-inverting names, removing parenthetical qualifications, changing the type of apostrophe, or even correcting typographical errors. (I=20 have written privately to request some minor capitalization and spacing=20 changes in 639-3.) There are valid arguments for both courses of action IMHO, and I do not=20 argue here that we must follow one course or the other. I am arguing=20 that we should settle the basic question first -- to follow the=20 standards exactly or not -- BEFORE we start writing text that implements one of the possible outcomes. I ask the co-chairs again to declare=20 consensus one way or the other on this basic question. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 10:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBzs-0003g0-Gx; Wed, 18 Oct 2006 10:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBzr-0003dj-5a for ltru@ietf.org; Wed, 18 Oct 2006 10:02:15 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBzn-0004M5-RM for ltru@ietf.org; Wed, 18 Oct 2006 10:02:15 -0400 Received: by wx-out-0506.google.com with SMTP id h30so309352wxd for ; Wed, 18 Oct 2006 07:02:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=AGZJ7gocUB3+hKHsre2PPb7YxAjOvkwf4Oz+3uoS6j3q0oSpwniCfnyENyA7WhrcW/PSrFWh8EYxbaWhxJpXvKTFKLmvy8qSkfbJDjZTNZZdE6zmkI2AaCNjjPrDzbex4CKqce8r+y4zmUrvrUG1tyi/PtOTqfObO0BR0z4NWC8= Received: by 10.90.54.4 with SMTP id c4mr6224724aga; Wed, 18 Oct 2006 07:02:11 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Wed, 18 Oct 2006 07:02:11 -0700 (PDT) Message-ID: <30b660a20610180702hac7bbdkfac07841f1d3ec39@mail.gmail.com> Date: Wed, 18 Oct 2006 07:02:11 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <00ec01c6f273$0e51a3b0$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <00ec01c6f273$0e51a3b0$6501a8c0@DGBP7M81> X-Google-Sender-Auth: d7563b933b230404 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282857317==" Errors-To: ltru-bounces@ietf.org --===============1282857317== Content-Type: multipart/alternative; boundary="----=_Part_69814_25738781.1161180131406" ------=_Part_69814_25738781.1161180131406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I liked that one too! Mark On 10/17/06, Doug Ewell wrote: > > Addison Phillips wrote: > > > Doug Ewell is a better approximation of a Turing machine than any > > inversion algorithm. > > Now I know what I'm going to have carved on my headstone. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_69814_25738781.1161180131406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I liked that one too!

Mark

On 10/17/06, Doug Ewell <dewell@adelphia.net> wrote:
Addison Phillips <addison at yahoo dash inc dot com> wrote:

> Doug Ewell is a better approximation of a Turing machine than any
> inversion algorithm.

Now I know what I'm going to have carved on my headstone.

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


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

------=_Part_69814_25738781.1161180131406-- --===============1282857317== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1282857317==-- From ltru-bounces@ietf.org Wed Oct 18 10:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC3H-0007vF-Og; Wed, 18 Oct 2006 10:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC3F-0007s4-UH for ltru@ietf.org; Wed, 18 Oct 2006 10:05:45 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaC3B-0004oQ-Ey for ltru@ietf.org; Wed, 18 Oct 2006 10:05:45 -0400 Received: by wr-out-0506.google.com with SMTP id i5so37211wra for ; Wed, 18 Oct 2006 07:05:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oRxjCCkjVRdBKprGKEsYXWjzGF7Sysqn4zYfA1Rlf9Yorc/vQhFvyKGUru4ppAq4dp8HWryKEQ6M9vHy+JI6PHHY74QZ1w3Ftk1l/Md90Q5GONnKr2DIkUb1Pr74uwGPCQgynV022MSwIkf7fQZRpIBHr6AIMO+Zok2ynWg1G8k= Received: by 10.90.118.12 with SMTP id q12mr6245227agc; Wed, 18 Oct 2006 07:05:40 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Wed, 18 Oct 2006 07:05:40 -0700 (PDT) Message-ID: <30b660a20610180705j7e01262cg8cc09a39ee9ce1fe@mail.gmail.com> Date: Wed, 18 Oct 2006 07:05:40 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: MIME-Version: 1.0 References: <00e801c6f272$c27d8f80$6501a8c0@DGBP7M81> X-Google-Sender-Auth: e1b855df425ad9b1 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1703486715==" Errors-To: ltru-bounces@ietf.org --===============1703486715== Content-Type: multipart/alternative; boundary="----=_Part_69882_23783214.1161180340823" ------=_Part_69882_23783214.1161180340823 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The algorithm I used was (logically): If there is a parenthetical If it isn't at the end it's an error Otherwise remove it. In the remainder If there are two commas it's an error If there is one comma, invert the string Append the parenthetical if there was one. Mark On 10/17/06, Peter Constable wrote: > > Re use of commas, I believe there is no case in the 639-3 draft code > table data file where alternate names are separated by commas, but I'd > have to investigate to determine for sure. > > Re mapping "B, A" to "A B", it might not always be that simple if A > contains a parenthetical -- i.e. we're talking about "B, C (D)", which > should map to "C B (D)". > > > Peter > > > > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Tuesday, October 17, 2006 10:04 PM > To: LTRU Working Group > Subject: [Ltru] Re: Inversions and other problems > > First, I was not aware there were any comma-separated compound names at > all in the ISO 639-3 data file. I thought all of the compound names > were separated by semicolons. I'd like to ask Peter to confirm this. > > Second, *IF* the above is true, then any inverted name can be > un-inverted mechanically by converting "B, A" to "A B". No intelligence > > is needed here. (Note that the reverse is not true if either A or B > consists of more than one word.) > > Third, we have apparently started to plan exact wording for 4646bis on > how to modify names from the ISO standards WITHOUT having settled the > underlying question of whether this should even happen. Debbie and at > least one other person (I think Peter) had wanted at least one > Description to match the name in the standard exactly, so the entries > can be correlated in case the subtag doesn't match the code element > (they might have to differ for stability reasons). "Exactly" does not > mean un-inverting names, removing parenthetical qualifications, changing > > the type of apostrophe, or even correcting typographical errors. (I > have written privately to request some minor capitalization and spacing > changes in 639-3.) > > There are valid arguments for both courses of action IMHO, and I do not > argue here that we must follow one course or the other. I am arguing > that we should settle the basic question first -- to follow the > standards exactly or not -- BEFORE we start writing text that implements > > one of the possible outcomes. I ask the co-chairs again to declare > consensus one way or the other on this basic question. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_69882_23783214.1161180340823 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The algorithm I used was (logically):

If there is a parenthetical
  If it isn't at the end it's an error
  Otherwise remove it.
In the remainder
  If there are two commas it's an error
  If there is one comma, invert the string
Append the parenthetical if there was one.

Mark

On 10/17/06, Peter Constable <petercon@microsoft.com > wrote:
Re use of commas, I believe there is no case in the 639-3 draft code
table data file where alternate names are separated by commas, but I'd
have to investigate to determine for sure.

Re mapping "B, A" to "A B", it might not always be that simple if A
contains a parenthetical -- i.e. we're talking about "B, C (D)", which
should map to "C B (D)".


Peter



-----Original Message-----
From: Doug Ewell [mailto:dewell@adelphia.net ]
Sent: Tuesday, October 17, 2006 10:04 PM
To: LTRU Working Group
Subject: [Ltru] Re: Inversions and other problems

First, I was not aware there were any comma-separated compound names at
all in the ISO 639-3 data file.  I thought all of the compound names
were separated by semicolons.  I'd like to ask Peter to confirm this.

Second, *IF* the above is true, then any inverted name can be
un-inverted mechanically by converting "B, A" to "A B".  No intelligence

is needed here.  (Note that the reverse is not true if either A or B
consists of more than one word.)

Third, we have apparently started to plan exact wording for 4646bis on
how to modify names from the ISO standards WITHOUT having settled the
underlying question of whether this should even happen.  Debbie and at
least one other person (I think Peter) had wanted at least one
Description to match the name in the standard exactly, so the entries
can be correlated in case the subtag doesn't match the code element
(they might have to differ for stability reasons).  "Exactly" does not
mean un-inverting names, removing parenthetical qualifications, changing

the type of apostrophe, or even correcting typographical errors.  (I
have written privately to request some minor capitalization and spacing
changes in 639-3.)

There are valid arguments for both courses of action IMHO, and I do not
argue here that we must follow one course or the other.  I am arguing
that we should settle the basic question first -- to follow the
standards exactly or not -- BEFORE we start writing text that implements

one of the possible outcomes.  I ask the co-chairs again to declare
consensus one way or the other on this basic question.

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


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

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

------=_Part_69882_23783214.1161180340823-- --===============1703486715== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1703486715==-- From ltru-bounces@ietf.org Wed Oct 18 10:29:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCPg-00082V-AW; Wed, 18 Oct 2006 10:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCPf-00081z-9B for ltru@lists.ietf.org; Wed, 18 Oct 2006 10:28:55 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCPb-0000Zc-Pc for ltru@lists.ietf.org; Wed, 18 Oct 2006 10:28:55 -0400 Received: by wx-out-0506.google.com with SMTP id h28so279135wxd for ; Wed, 18 Oct 2006 07:28:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Ib7rguVY0hCSNHXJwN+LsI7wXPD50iEk0JMjqzcICDlvCND8l/HNbdcn11npwooJSNljxvRteDh3D+q47S0JlU6wfhKI1acQCSu4KtiHgxwqLZqx2/XuxWwehqR7xIGDY+EeNItDBOZ/n855U8N9DVJMHf3PChBjGvfCWYjSOg8= Received: by 10.90.105.20 with SMTP id d20mr6261332agc; Wed, 18 Oct 2006 07:28:51 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Wed, 18 Oct 2006 07:28:51 -0700 (PDT) Message-ID: <30b660a20610180728k14c621e5vf186f316bbeeb64f@mail.gmail.com> Date: Wed, 18 Oct 2006 07:28:51 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <4535A138.1A26@xyzzy.claranet.de> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <30b660a20610171237l57ea4699m3c2669c587cc7f56@mail.gmail.com> <453532FD.2050202@yahoo-inc.com> <453570AE.6A4A@xyzzy.claranet.de> <30b660a20610171720h7d7ce6c2lee32ce179bac30c1@mail.gmail.com> <20061018020811.GA20645@ccil.org> <30b660a20610171954m4a6f5e42xda6571650d7c3a4b@mail.gmail.com> <4535A138.1A26@xyzzy.claranet.de> X-Google-Sender-Auth: 664cc0e999a623f0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0789372118==" Errors-To: ltru-bounces@ietf.org --===============0789372118== Content-Type: multipart/alternative; boundary="----=_Part_70094_16342015.1161181731206" ------=_Part_70094_16342015.1161181731206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/17/06, Frank Ellermann wrote: > > Mark Davis wrote: > > > here is my suggested language: > > >| For each collection of records of a particular 'Type' (excluding > >| records with a Deprecated field), each of the values that appears > >| in a 'Description' field MUST be unique. > > ACK so far, that just makes sense. It doesn't catch the fine print > of a shared namespace for language and extlang (JFTR, I'm not saying > that it should) We could handle that by adding: "For the purposes of determining uniqueness, extlang records are treated as if they were language tags." >| The description values MUST also be unique even after removing > >| parentheticals > [...] > I'm not sure about this parenthical bit, see below, > [...] > >| and inverting any string containing commas. > [...] > That's again clear, and I like it. > [...] > >| Outside of parentheticals, commas MUST only be used for inverted > >| strings. > > If you insist on this new comma-rule we're forced to patch several > redundant and grandfathered descriptions, as noted before in another > article - for the six 1901/1996 cases it would be simple. Yes, we would have to fix a few items. But there are few, and the result would then be consistent. Better to do that than to have some descriptions be inverted and some not, with no way to tell which is which. (And adding additional structure or description to allow people to determine which are inverted and which not is *much* more painful than just fixing the instances that are not). As I've said, my preference would be not to have inverted names, but since the majority seem to want them, we have to make their usage completely predictable. >| For example, suppose that the following description is in a > >| language subtag record: > > > 
Description: Gibrus Xishu
> > My preferred style would be what we get from the "inverted name" > column in the table derived from the 639-3 draft: Xishu, Gibrus The example was not mean to prefer one form other another, just to say that if any form exists, the others can't. Maybe that is better captured by changing: OLD: For example, suppose that the following description is in a language subtag record: 
Description: Gibrus Xishu
Then that line cannot occur again in that record, nor in any other language subtag record. Moreover, none of the following can occur in any language subtag record: 
Description: Gibrus Xishu (any comment)
Description: Xishu, Gibrus 
Description: Xishu, Gibrus (any comment)
NEW: For example, if any one of the following occurs in a language subtag record, then none of the others can occur in any language subtag record. 
Description: Gibrus Xishu
Description: Gibrus Xishu (any comment)
Description: Xishu, Gibrus 
Description: Xishu, Gibrus (any comment)
END How does your parenthical rule handle Ainu (China) vs. Ainu (Japan), > or similar Aja (Sudan) vs. Aja (Benin) ? Those would need to be fixed. There are 138 such cases, as I indicated in previous messages, so that would involve changing 69..138 values, depending on the resolution. For example, since "Ainu" alone is already a description on 'ain', I think the correct change there would be to drop the description "Ainu (Japan)" on 'ain' and change the "Ainu (China)" to "Ainu, China" on 'aib'. Now, I want to make clear, I distinguished this as a "nice to have" in my original list (#8); it makes it easier for translation, and better we fix 1% or so of the cases than to leave them in. But it would also be possible to adjust the text to allow descriptions only differing by parentheticals. Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_70094_16342015.1161181731206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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

> here is my suggested language:

>| For each collection of records of a particular 'Type' (excluding
>| records with a Deprecated field), each of the values that appears
>| in a 'Description' field MUST be unique.

ACK so far, that just makes sense.  It doesn't catch the fine print
of a shared namespace for language and extlang (JFTR, I'm not saying
that it should)

We could handle that by adding: "For the purposes of determining uniqueness, extlang records are treated as if they were language tags."

>| The description values MUST also be unique even after removing
>| parentheticals
[...]
I'm not sure about this parenthical bit, see below,
[...]
>| and inverting any string containing commas.
[...]
That's again clear, and I like it.
[...]
>| Outside of parentheticals, commas MUST only be used for inverted
>| strings.

If you insist on this new comma-rule we're forced to patch several
redundant and grandfathered descriptions, as noted before in another
article - for the six 1901/1996 cases it would be simple.

Yes, we would have to fix a few items. But there are few, and the result would then be consistent. Better to do that than to have some descriptions be inverted and some not, with no way to tell which is which. (And adding additional structure or description to allow people to determine which are inverted and which not is *much* more painful than just fixing the instances that are not). As I've said, my preference would be not to have inverted names, but since the majority seem to want them, we have to make their usage completely predictable.

>| For example, suppose that the following description is in a
>| language subtag record:

> <pre>Description: Gibrus Xishu</pre>

My preferred style would be what we get from the "inverted name"
column in the table derived from the 639-3 draft:  Xishu, Gibrus

The example was not mean to prefer one form other another, just to say that if any form exists, the others can't. Maybe that is better captured by changing:

OLD:
<t>For example, suppose that the following description is in a
language subtag record:</t>

<pre>Description: Gibrus Xishu</pre>

<t>Then that line cannot occur again in that record, nor in any other
language subtag record. Moreover, none of the following can occur in
any language subtag record:</t>

<pre>Description: Gibrus Xishu (any comment)</pre>
<pre>Description: Xishu, Gibrus </pre>
<pre>Description: Xishu, Gibrus (any comment)</pre>

NEW:

<t>For example, if any one of the following occurs in a language subtag record, then none of the others can occur in any language subtag record.</t>

<pre>Description: Gibrus Xishu</pre>
<pre>Description: Gibrus Xishu (any comment)</pre>
<pre>Description: Xishu, Gibrus </pre>
<pre>Description: Xishu, Gibrus (any comment)</pre>

END

How does your parenthical rule handle Ainu (China) vs. Ainu (Japan),
or similar Aja (Sudan) vs. Aja (Benin) ?

Those would need to be fixed. There are 138 such cases, as I indicated in previous messages, so that would involve changing 69..138 values, depending on the resolution. For example, since "Ainu" alone is already a description on 'ain', I think the correct change there would be to drop the description "Ainu (Japan)" on 'ain' and change the "Ainu (China)" to "Ainu, China" on 'aib'. Now, I want to make clear, I distinguished this as a "nice to have" in my original list (#8); it makes it easier for translation, and better we fix 1% or so of the cases than to leave them in. But it would also be possible to adjust the text to allow descriptions only differing by parentheticals.

Frank



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

------=_Part_70094_16342015.1161181731206-- --===============0789372118== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0789372118==-- From ltru-bounces@ietf.org Wed Oct 18 19:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKYt-0008FI-Sg; Wed, 18 Oct 2006 19:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ3m-00015N-DB for ltru@lists.ietf.org; Wed, 18 Oct 2006 17:34:46 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJ00-0006Zy-UM for ltru@lists.ietf.org; Wed, 18 Oct 2006 17:30:54 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 30C171E1649; Wed, 18 Oct 2006 14:30:50 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Oct 2006 14:30:50 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: ltru@lists.ietf.org Date: Wed, 18 Oct 2006 14:30:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Ltru] FW: I think IE7 is going to break language negotiation on many se rvers X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, Richard Ishida just sent this note to W3C I18N list. The complaint it makes is just shifting from 'fr' to 'fr-FR' (language/region) and doesn't even include a script subtag. Peter Constable - is this a real or imaginary problem? [copied Richard, because I'm not sure he's subscribed to LTRU] Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: www-international-request@w3.org [mailto:www-international-request@w3.org]On Behalf Of Richard Ishida Sent: Wednesday, October 18, 2006 11:25 AM To: www-international@w3.org Subject: I think IE7 is going to break language negotiation on many servers FYI http://people.w3.org/rishida/blog/?p=3D68 "The IE7 blog just announced Microsoft's intention to change the way = browser preferences for Accept-language are set up by default. Basically your preferences will no longer, by default, be set to fr if you=E2=80=99re = French, but to fr-FR instead, ie. your locale as determined by Windows settings. I think this is going to cause major problems with content negotiation = on the Web. To give a practical example: ..." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.5/483 - Release Date: = 10/18/2006 =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 20:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLqu-00060K-1Y; Wed, 18 Oct 2006 20:33:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLqs-0005zw-8Z for ltru@lists.ietf.org; Wed, 18 Oct 2006 20:33:38 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLqq-00063d-R9 for ltru@lists.ietf.org; Wed, 18 Oct 2006 20:33:38 -0400 Received: from [10.72.72.88] (snvvpn1-10-72-72-c88.corp.yahoo.com [10.72.72.88]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9J0XWNu018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 17:33:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=k+RDzNU7K6YjsyQG0Vje6MpE5E/mPn5ILYdNxd7c1PwFYVHwbv14OPXz79j1IOhw Message-ID: <4536C7DB.30103@yahoo-inc.com> Date: Wed, 18 Oct 2006 17:33:31 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "McDonald, Ira" Subject: Re: [Ltru] FW: I think IE7 is going to break language negotiation on many se rvers References: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id k9J0XWNu018983 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Yes, he's right, systems based on Basic Filtering, such as Apache, will=20 not find the same content they used to find. This is why many of us who=20 have implemented language negotiation schemes have based ours on the=20 Lookup scheme. The Apache approach is difficult to manage for a large=20 web property (it relies on file suffixes) and produces problematic=20 behavior (such as not finding French when I ask for 'fr-FR', eh?) The former practice also means that less specific information was=20 available from the browser than is actually available. It is good to=20 know if your user prefers French or Canadian usage! I should note: I have long complained about how the W3C server's=20 language negotiation is set up. It never seems to "language negotiate"=20 with me unless I specifically set the right (really short) tag is at the=20 top of my list. If that's the behavior we're breaking, I'm all for it. Addison --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. McDonald, Ira wrote: > Hi, >=20 > Richard Ishida just sent this note to W3C I18N list. >=20 > The complaint it makes is just shifting from 'fr' to > 'fr-FR' (language/region) and doesn't even include a > script subtag. >=20 > Peter Constable - is this a real or imaginary problem? >=20 > [copied Richard, because I'm not sure he's subscribed > to LTRU] >=20 > Cheers, > - Ira >=20 > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com >=20 > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org]On Behalf Of Richard Ishida > Sent: Wednesday, October 18, 2006 11:25 AM > To: www-international@w3.org > Subject: I think IE7 is going to break language negotiation on many > servers >=20 >=20 >=20 > FYI >=20 > http://people.w3.org/rishida/blog/?p=3D68 >=20 > "The IE7 blog just announced Microsoft's intention to change the way br= owser > preferences for Accept-language are set up by default. Basically your > preferences will no longer, by default, be set to fr if you=E2=80=99re = French, but > to fr-FR instead, ie. your locale as determined by Windows settings. >=20 > I think this is going to cause major problems with content negotiation = on > the Web. >=20 > To give a practical example: ..." >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) >=20 > http://www.w3.org/People/Ishida/ > http://www.w3.org/International/ > http://people.w3.org/rishida/blog/ > http://www.flickr.com/photos/ishida/ >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 21:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaMu3-0003Og-3v; Wed, 18 Oct 2006 21:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaMty-0003JX-31 for ltru@lists.ietf.org; Wed, 18 Oct 2006 21:40:54 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaMor-0000o8-Fl for ltru@lists.ietf.org; Wed, 18 Oct 2006 21:35:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9J1ZX9k027984 for ; Thu, 19 Oct 2006 10:35:33 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 5e46_1cc4c4ac_5f12_11db_9445_0014221fa3c9; Thu, 19 Oct 2006 10:35:32 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60502) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 19 Oct 2006 10:35:15 +0900 Message-Id: <6.0.0.20.2.20061018170124.0adf76d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 18 Oct 2006 17:10:57 +0900 To: Addison Phillips , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <4534FD40.1030704@yahoo-inc.com> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:56 06/10/18, Addison Phillips wrote: >Maybe more to the point, I propose we insert this text into the 'Description' section of the document (the current Section 3.1.3.2): > >For a records of a given 'Type', the value of the 'Description' field MUST be unique. This doesn't fly, as there are multiple 'Description' fields. Is it "The 'Description' fields of a record each have to be unique among themselves." or "All the 'Description' fields across a given 'Type' have to be unique." or "Each record of a given type has to contain at least a 'Description' that is unique among all the 'Description' fields of a type." or something else? (MUSTardization at your disgression) Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 18 21:49:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaN1p-0007Gh-UU; Wed, 18 Oct 2006 21:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaN1n-00076n-Sr for ltru@lists.ietf.org; Wed, 18 Oct 2006 21:48:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaN1m-0003jN-HH for ltru@lists.ietf.org; Wed, 18 Oct 2006 21:48:59 -0400 Received: by wx-out-0506.google.com with SMTP id h28so461704wxd for ; Wed, 18 Oct 2006 18:48:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=inKTfD6ANUdIqzwMuL/zK5QujWYseWSlWRAcams83MqGPEiNjX8kbA+acFOYiPU33znlKtkCH+vK/wiP0WP5mi0G2mrlhn7tRazwKnAjYHxxmVRabIvdeS8qObeIMQVKLatOROZrZEco2UozoPRoI8ujSZRN8tdZXLZzyWI6xsE= Received: by 10.90.34.9 with SMTP id h9mr6987600agh; Wed, 18 Oct 2006 18:48:58 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Wed, 18 Oct 2006 18:48:58 -0700 (PDT) Message-ID: <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> Date: Wed, 18 Oct 2006 18:48:58 -0700 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <6.0.0.20.2.20061018170124.0adf76d0@localhost> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> X-Google-Sender-Auth: db1ec7333f7b00d0 X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766238793==" Errors-To: ltru-bounces@ietf.org --===============0766238793== Content-Type: multipart/alternative; boundary="----=_Part_74885_24889006.1161222538257" ------=_Part_74885_24889006.1161222538257 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Is this any clearer? (would need some reworking, but I want to get the concept across.) Given a description, a variant description is any that could be created by adding or removing a parenthetical, or inverting or uninverting the string, or both. Within a given type, a given description MUST be unique. That is, it MUST NOT occur more than once in that record, and MUST NOT occur at all in any other record of that type. Moreover, no variant description MAY occur in that record or any other record of that type. On 10/18/06, Martin Duerst wrote: > > At 00:56 06/10/18, Addison Phillips wrote: > >Maybe more to the point, I propose we insert this text into the > 'Description' section of the document (the current Section 3.1.3.2): > > > >For a records of a given 'Type', the value of the 'Description' field > MUST be unique. > > This doesn't fly, as there are multiple 'Description' fields. > > Is it "The 'Description' fields of a record each have to be unique among > themselves." > or "All the 'Description' fields across a given 'Type' have to be unique." > or "Each record of a given type has to contain at least a 'Description' > that is unique > among all the 'Description' fields of a type." or something else? > > (MUSTardization at your disgression) > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_74885_24889006.1161222538257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is this any clearer? (would need some reworking, but I want to get the concept across.)

Given a description, a variant description is any that could be created by adding or removing a parenthetical, or inverting or uninverting the string, or both.

Within a given type, a given description MUST be unique. That is, it MUST NOT occur more than once in that record, and MUST NOT occur at all in any other record of that type. Moreover, no variant description MAY occur in that record or any other record of that type.


On 10/18/06, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
At 00:56 06/10/18, Addison Phillips wrote:
>Maybe more to the point, I propose we insert this text into the 'Description' section of the document (the current Section 3.1.3.2):
>
><t>For a records of a given 'Type', the value of the 'Description' field MUST be unique.

This doesn't fly, as there are multiple 'Description' fields.

Is it "The 'Description' fields of a record each have to be unique among themselves."
or "All the 'Description' fields across a given 'Type' have to be unique."
or "Each record of a given type has to contain at least a 'Description' that is unique
among all the 'Description' fields of a type." or something else?

(MUSTardization at your disgression)

Regards,     Martin.



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


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

------=_Part_74885_24889006.1161222538257-- --===============0766238793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0766238793==-- From ltru-bounces@ietf.org Thu Oct 19 00:36:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaPdb-0005Z4-H2; Thu, 19 Oct 2006 00:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaPdb-0005Yz-0W for ltru@lists.ietf.org; Thu, 19 Oct 2006 00:36:11 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaPdX-0008KZ-Lh for ltru@lists.ietf.org; Thu, 19 Oct 2006 00:36:10 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Wed, 18 Oct 2006 21:36:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.148]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Wed, 18 Oct 2006 21:36:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 21:36:02 -0700 Message-ID: In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I think IE7 is going to break language negotiation on many servers thread-index: Acby/LCX+COJ0u66S5SBn1lRFTEqVgAOz3PA References: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> From: Peter Constable To: "McDonald, Ira" , X-OriginalArrivalTime: 19 Oct 2006 04:36:06.0595 (UTC) FILETIME=[17944930:01C6F338] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ltru] RE: I think IE7 is going to break language negotiation on many servers X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855609769==" Errors-To: ltru-bounces@ietf.org --===============0855609769== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb24ndCBrbm93IGFueXRoaW5nIGFib3V0IHdoYXQgSUU3IGlzIGRvaW5nLCBidXQgSSd2ZSBw YXNzZWQgdGhpcyBvbiB0byBzb21lb25lIGRlYWxpbmcgd2l0aCBnbG9iYWxpemF0aW9uIGlzc3Vl cyBpbiBJRSBhbmQgaGUncyBsb29raW5nIGludG8gaXQuDQoNCg0KUGV0ZXINCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1jRG9uYWxkLCBJcmEgW21haWx0bzppbWNkb25hbGRA c2hhcnBsYWJzLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTgsIDIwMDYgMjozMSBQ TQ0KVG86IGx0cnVAbGlzdHMuaWV0Zi5vcmcNCkNjOiBQZXRlciBDb25zdGFibGU7ICdSaWNoYXJk IElzaGlkYScNClN1YmplY3Q6IEZXOiBJIHRoaW5rIElFNyBpcyBnb2luZyB0byBicmVhayBsYW5n dWFnZSBuZWdvdGlhdGlvbiBvbiBtYW55IHNlcnZlcnMNCg0KSGksDQoNClJpY2hhcmQgSXNoaWRh IGp1c3Qgc2VudCB0aGlzIG5vdGUgdG8gVzNDIEkxOE4gbGlzdC4NCg0KVGhlIGNvbXBsYWludCBp dCBtYWtlcyBpcyBqdXN0IHNoaWZ0aW5nIGZyb20gJ2ZyJyB0bw0KJ2ZyLUZSJyAobGFuZ3VhZ2Uv cmVnaW9uKSBhbmQgZG9lc24ndCBldmVuIGluY2x1ZGUgYQ0Kc2NyaXB0IHN1YnRhZy4NCg0KUGV0 ZXIgQ29uc3RhYmxlIC0gaXMgdGhpcyBhIHJlYWwgb3IgaW1hZ2luYXJ5IHByb2JsZW0/DQoNCltj b3BpZWQgUmljaGFyZCwgYmVjYXVzZSBJJ20gbm90IHN1cmUgaGUncyBzdWJzY3JpYmVkDQp0byBM VFJVXQ0KDQpDaGVlcnMsDQotIElyYQ0KDQpJcmEgTWNEb25hbGQgKE11c2ljaWFuIC8gU29mdHdh cmUgQXJjaGl0ZWN0KQ0KQmx1ZSBSb29mIE11c2ljIC8gSGlnaCBOb3J0aCBJbmMNClBPIEJveCAy MjEgIEdyYW5kIE1hcmFpcywgTUkgIDQ5ODM5DQpwaG9uZTogKzEtOTA2LTQ5NC0yNDM0DQplbWFp bDogaW1jZG9uYWxkQHNoYXJwbGFicy5jb20NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHd3dy1pbnRlcm5hdGlvbmFsLXJlcXVlc3RAdzMub3JnDQpbbWFpbHRvOnd3dy1pbnRl cm5hdGlvbmFsLXJlcXVlc3RAdzMub3JnXU9uIEJlaGFsZiBPZiBSaWNoYXJkIElzaGlkYQ0KU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDE4LCAyMDA2IDExOjI1IEFNDQpUbzogd3d3LWludGVybmF0 aW9uYWxAdzMub3JnDQpTdWJqZWN0OiBJIHRoaW5rIElFNyBpcyBnb2luZyB0byBicmVhayBsYW5n dWFnZSBuZWdvdGlhdGlvbiBvbiBtYW55DQpzZXJ2ZXJzDQoNCg0KDQpGWUkNCg0KaHR0cDovL3Bl b3BsZS53My5vcmcvcmlzaGlkYS9ibG9nLz9wPTY4DQoNCiJUaGUgSUU3IGJsb2cganVzdCBhbm5v dW5jZWQgTWljcm9zb2Z0J3MgaW50ZW50aW9uIHRvIGNoYW5nZSB0aGUgd2F5IGJyb3dzZXINCnBy ZWZlcmVuY2VzIGZvciBBY2NlcHQtbGFuZ3VhZ2UgYXJlIHNldCB1cCBieSBkZWZhdWx0LiBCYXNp Y2FsbHkgeW91cg0KcHJlZmVyZW5jZXMgd2lsbCBubyBsb25nZXIsIGJ5IGRlZmF1bHQsIGJlIHNl dCB0byBmciBpZiB5b3XigJlyZSBGcmVuY2gsIGJ1dA0KdG8gZnItRlIgaW5zdGVhZCwgaWUuIHlv dXIgbG9jYWxlIGFzIGRldGVybWluZWQgYnkgV2luZG93cyBzZXR0aW5ncy4NCg0KSSB0aGluayB0 aGlzIGlzIGdvaW5nIHRvIGNhdXNlIG1ham9yIHByb2JsZW1zIHdpdGggY29udGVudCBuZWdvdGlh dGlvbiBvbg0KdGhlIFdlYi4NCg0KVG8gZ2l2ZSBhIHByYWN0aWNhbCBleGFtcGxlOiAuLi4iDQoN Cg0KDQo9PT09PT09PT09PT0NClJpY2hhcmQgSXNoaWRhDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBM ZWFkDQpXM0MgKFdvcmxkIFdpZGUgV2ViIENvbnNvcnRpdW0pDQoNCmh0dHA6Ly93d3cudzMub3Jn L1Blb3BsZS9Jc2hpZGEvDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsLw0KaHR0cDov L3Blb3BsZS53My5vcmcvcmlzaGlkYS9ibG9nLw0KaHR0cDovL3d3dy5mbGlja3IuY29tL3Bob3Rv cy9pc2hpZGEvDQoNCg0KLS0gDQpObyB2aXJ1cyBmb3VuZCBpbiB0aGlzIG91dGdvaW5nIG1lc3Nh Z2UuDQpDaGVja2VkIGJ5IEFWRyBGcmVlIEVkaXRpb24uDQpWZXJzaW9uOiA3LjEuNDA4IC8gVmly dXMgRGF0YWJhc2U6IDI2OC4xMy41LzQ4MyAtIFJlbGVhc2UgRGF0ZTogMTAvMTgvMjAwNg0KIA0K --===============0855609769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0855609769==-- From ltru-bounces@ietf.org Thu Oct 19 03:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaRz0-0001xo-RF; Thu, 19 Oct 2006 03:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaRyz-0001wz-FX for ltru@lists.ietf.org; Thu, 19 Oct 2006 03:06:25 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaRm7-0004qu-BB for ltru@lists.ietf.org; Thu, 19 Oct 2006 02:53:08 -0400 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id 7890BD97 for ; Thu, 19 Oct 2006 09:53:04 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 22360-11-3 for ; Thu, 19 Oct 2006 09:53:04 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 37D4D56AE for ; Thu, 19 Oct 2006 09:53:04 +0300 (EEST) Date: Thu, 19 Oct 2006 09:53:03 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@lists.ietf.org Subject: Re: [Ltru] FW: I think IE7 is going to break language negotiation on many se rvers In-Reply-To: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> Message-ID: References: <789E617C880666438EDEE30C2A3E8D10EF44@mailsrvnt05.enet.sharplabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, 18 Oct 2006, McDonald, Ira wrote: > Richard Ishida just sent this note to W3C I18N list. > > The complaint it makes is just shifting from 'fr' to > 'fr-FR' (language/region) and doesn't even include a > script subtag. That's not such a big change, given the fact that web browsers already so often send _only_ a language variant (such as 'en-US') in the Accept-Language header. So this is something that authors (who are willing to language-negotiate) have had to face for a long time. Quoting "Language Negotiation Notes" by Alan J. Flavell: "However, the big surprise was the overwhelming proportion of requests whose language preferences contained only "en-us": the great majority of these requests were coming from MSIE versions, although some other browsers (Netscape6, even Lynx) were represented in small numbers." http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html Moreover, the following warning in the HTTP/1.1 protocol (RFC 2616) has generally been ignored: Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior. So authors who try to set up language negotiation in a way that works have had to do things like implying "en" from the presence of "en-gb", even though this violates the HTTP/1.1 protocol. The basic problem is that browsers have language preferences _at all_ as silent defaults. The preferences are typically taken from the browser's own interface language (setting them, for example, to 'en' or even 'en-US' because the user is using an English-language version - just because it's the only one available for the _newest_ version of the browser). The preferences should, of course, be based on information that the _user_ has been prompted to specify when the browser is being installed or used for the first time. Before this practical problem can be solved, language negotiation on the web is mostly just an academic exercise. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 04:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTRE-00082x-3Q; Thu, 19 Oct 2006 04:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTRC-000803-QI for ltru@lists.ietf.org; Thu, 19 Oct 2006 04:39:38 -0400 Received: from mail09.svc.cra.dublin.eircom.net ([159.134.118.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaTR8-0007yR-96 for ltru@lists.ietf.org; Thu, 19 Oct 2006 04:39:38 -0400 Received: (qmail 1024 messnum 2879982 invoked from network[194.125.174.67/ts09-067.dublin.indigo.ie]); 19 Oct 2006 08:39:31 -0000 Received: from ts09-067.dublin.indigo.ie (HELO ?194.125.174.67?) (194.125.174.67) by mail09.svc.cra.dublin.eircom.net (qp 1024) with SMTP; 19 Oct 2006 08:39:31 -0000 In-Reply-To: <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Message-Id: <61E3CA6C-3A65-4F9B-9FD7-F7BB6B296DE0@egt.ie> From: Marion Gunn Subject: Re: [Ltru] Re: Inversions and other problems Date: Thu, 19 Oct 2006 09:37:00 +0000 To: Mark Davis , ltru@lists.ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: Frank Ellermann X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0875465601==" Errors-To: ltru-bounces@ietf.org --===============0875465601== Content-Type: multipart/alternative; boundary=Apple-Mail-1-407310122 --Apple-Mail-1-407310122 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed "A given description within a given type must be unique. That means =20 it may not occur more than once in any specific record and may not =20 occur in any other record of the same type. Moreover, no variant =20 description may occur in that specific record or in any other record =20 of the same type." mg On 19 Oct 2006, at 01:48, scr=EDobh Mark Davis: > Is this any clearer? (would need some reworking, but I want to get =20 > the concept across.) > > Given a description, a variant description is any that could be =20 > created by adding or removing a parenthetical, or inverting or =20 > uninverting the string, or both. > > Within a given type, a given description MUST be unique. That is, =20 > it MUST NOT occur more than once in that record, and MUST NOT occur =20= > at all in any other record of that type. Moreover, no variant =20 > description MAY occur in that record or any other record of that type. > > > On 10/18/06, Martin Duerst wrote: > At 00:56 06/10/18, Addison Phillips wrote: > >Maybe more to the point, I propose we insert this text into the =20 > 'Description' section of the document (the current Section 3.1.3.2): > > > >For a records of a given 'Type', the value of the 'Description' =20= > field MUST be unique. > > This doesn't fly, as there are multiple 'Description' fields. > > Is it "The 'Description' fields of a record each have to be unique =20 > among themselves." > or "All the 'Description' fields across a given 'Type' have to be =20 > unique." > or "Each record of a given type has to contain at least a =20 > 'Description' that is unique > among all the 'Description' fields of a type." or something else? > > (MUSTardization at your disgression) > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp =20 > mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * --Apple-Mail-1-407310122 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 "A given description within a = given type must be unique. That means it may not occur more than once in = any specific record and may not occur in any other record of the same = type. Moreover, no variant description may occur in that specific record = or in any other record of the same = type."
mg
=A0
On 19 Oct 2006, at 01:48, = scr=EDobh Mark Davis:

Is this = any clearer? (would need some reworking, but I want to get the concept = across.)

Given a description, a variant description is any that = could be created by adding or removing a parenthetical, or inverting or = uninverting the string, or both.

Within a given type, a given = description MUST be unique. That is, it MUST NOT occur more than once in = that record, and MUST NOT occur at all in any other record of that type. = Moreover, no variant description MAY occur in that record or any other = record of that type.


On = 10/18/06, Martin Duerst <duerst@it.aoyama.ac.jp> = wrote:
At 00:56 06/10/18, Addison Phillips wrote:
>Maybe more to = the point, I propose we insert this text into the 'Description' section = of the document (the current Section 3.1.3.2):
>
><t>For a = records of a given 'Type', the value of the 'Description' field MUST be = unique.

This doesn't fly, as there are multiple 'Description' = fields.

Is it "The 'Description' fields of a record each have to = be unique among themselves."
or "All the 'Description' fields across = a given 'Type' have to be unique."
or "Each record of a given type = has to contain at least a 'Description' that is unique
among all the = 'Description' fields of a type." or something else? =

(MUSTardization at your disgression)

Regards,=A0=A0=A0=A0 = Martin.



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

<= BR>_______________________________________________
Ltru mailing = list
Ltru@ietf.org
= https://www1.ietf.org/mailman/listinfo/ltru

=
Ltru mailing list


- = -=A0
Marion Gunn * EGTeo (Estab.1991)
27 P=E1irc an = Fh=E9ithlinn, Baile an
Bh=F3thair, Co. =C1tha Cliath, = =C9ire.
=

= --Apple-Mail-1-407310122-- --===============0875465601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0875465601==-- From ltru-bounces@ietf.org Thu Oct 19 09:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY6S-0003Wb-3e; Thu, 19 Oct 2006 09:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY6R-0003So-1i for ltru@lists.ietf.org; Thu, 19 Oct 2006 09:38:31 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY6O-0006gB-ED for ltru@lists.ietf.org; Thu, 19 Oct 2006 09:38:31 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:61568 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GaY6L-0001sQ-8A for ltru@lists.ietf.org; Thu, 19 Oct 2006 15:38:26 +0200 From: "Kent Karlsson" To: Subject: RE: [Ltru] Re: Inversions and other problems Date: Thu, 19 Oct 2006 15:38:13 +0200 Message-ID: <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <30b660a20610180728k14c621e5vf186f316bbeeb64f@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GaY6L-0001sQ-8A. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GaY6L-0001sQ-8A 8337891ba49734ea2503defae2c5a56e X-Spam-Score: 0.6 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0570926008==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0570926008== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C6F394.9736D3E0" This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C6F394.9736D3E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mark Davis wrote: Those would need to be fixed. There are 138 such cases, as I indicated = in previous messages, so that would involve changing 69..138 values, = depending on the resolution. For example, since "Ainu" alone is already = a description on 'ain', I think the correct change there would be to = drop the description "Ainu (Japan)" on 'ain' and change the "Ainu = (China)" to "Ainu, China" on 'aib'.=20 I'm not fond of the idea "to drop the description "Ainu (Japan)" on = 'ain'" (leaving just "Ainu"), since that does not hint that there *may* = be more than one "Ainu". Nor do I like the idea of "change the "Ainu = (China)" to "Ainu, China" on 'aib'", since 1) that would be "equivalent" to "China Ainu" which looks strange ("Chinese Ainu" would = seem better), and 2) if the country name is replaced by a language group = name (which I would prefer, compare "Slave (Athapascan)"), both the = inverted and non-inverted name would look really strange. =20 One more reason that I don't like using country names for distinguishing = same-named but different languages is that name tags, as per 1766 and successors, already allow region codes. One may well be = tempted to think that: =20 * "ain-CN" is the same as "aib", which it is not and "Ainu (China)" is = therefore misleading (and many UIs might not make a display name = distinction), and that =20 * "swa-CG" (or "swa-CD") is the same as "swa-swc", which I cannot tell = if it is or isn't (swa is a macrolanguage covering swc); I guess they = may be the "same", and if so, using the country name in the language = description would be more appropriate (but still subject to name = instability, (one of the) Congo(s) was called Za=C3=AFre not so very = long ago). There is no requirement that systems treat them the same = though, but it may warrant a comment that swa-swc is preferred (or not) = over swa-CG or swa-CD. =20 There are several instances of a) (clearly?) unrelated, and b) = (apparently?) closely related languages that have the same name but = (currently) distinguished by country name in the draft (yes, I know it = is a draft!) 639-3 registry tables. The former should certainly be = distinguished by something else than country name (in 639-3...). =20 /kent k =20 ------=_NextPart_000_0027_01C6F394.9736D3E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message
Mark Davis wrote:
Those would need to be fixed. There are 138 such cases, as I = indicated in=20 previous messages, so that would involve changing 69..138 values, = depending on=20 the resolution. For example, since "Ainu" alone is already a = description on=20 'ain', I think the correct change there would be to drop the = description "Ainu=20 (Japan)" on 'ain' and change the "Ainu (China)" to "Ainu, China" on=20 'aib'. 
I'm not fond = of the idea=20 "to drop the description "Ainu (Japan)" on = 'ain'"=20 (leaving just "Ainu"), since that does not hint that there *may* be = more=20 than one "Ainu". Nor do I like the idea of "change = the "Ainu=20 (China)" to "Ainu, China" on 'aib'", since 1) that would=20 be
"equivalent" = to "China=20 Ainu" which looks strange ("Chinese Ainu" would seem better), and 2) if = the=20 country name is replaced by a language group name (which I would = prefer,=20 compare "Slave (Athapascan)"), both the inverted and non-inverted=20 name would look really strange.
 
One more = reason that I=20 don't like using country names for distinguishing same-named but = different=20 languages is that name tags,
as per 1766 = and=20 successors, already allow region codes. One may well be tempted to think = that:
 
* "ain-CN" is the=20 same as "aib", which it is not and "Ainu (China)" is therefore = misleading (and=20 many UIs might not make a display name distinction), and=20 that
 
* "swa-CG" = (or=20 "swa-CD") is the same as "swa-swc", which I cannot tell if it is or = isn't=20 (swa is a macrolanguage covering swc); I guess they may be the "same", = and if=20 so, using the country name in the language description would be more = appropriate=20 (but still subject to name instability, (one of the) Congo(s) was called = Za=C3=AFre=20 not so very long ago). There is no requirement that systems treat them = the same=20 though, but it may warrant a comment that swa-swc is preferred (or not) = over=20 swa-CG or swa-CD.
 
There are = several=20 instances of a) (clearly?) unrelated, and b) (apparently?) closely = related=20 languages that have the same name but (currently) distinguished by = country name=20 in the draft (yes, I know it is a draft!) 639-3 registry tables. The = former=20 should certainly be distinguished by something else than country name = (in=20 639-3...).
 
         &nb= sp;     =20 /kent k
 
------=_NextPart_000_0027_01C6F394.9736D3E0-- --===============0570926008== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0570926008==-- From ltru-bounces@ietf.org Thu Oct 19 09:39:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY7S-00046s-7o; Thu, 19 Oct 2006 09:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY7Q-00046k-VA for ltru@ietf.org; Thu, 19 Oct 2006 09:39:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY7M-0006qg-Md for ltru@ietf.org; Thu, 19 Oct 2006 09:39:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GaY7M-0001X9-9o; Thu, 19 Oct 2006 09:39:28 -0400 Date: Thu, 19 Oct 2006 09:39:28 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems Message-ID: <20061019133928.GC4622@ccil.org> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Within a given type, a given description MUST be unique. That is, it MUST > NOT occur more than once in that record, and MUST NOT occur at all in any > other record of that type. Moreover, no variant description MAY occur in > that record or any other record of that type. Well, that's fine, but it completely cabbages the requirement to keep the Description fields in sync with the underlying standards. Can't have it both ways as long as 639-2 and 639-3 haven't settled their differences, and we can only hope that they *will* settle them. This is as good a place as any to report that I heard back from Joan Spanne at the 639-3/RA-to-be saying that there while my complaints about Yinglish and the bogus conlangs would be considered after 639-3 became a standard, no changes would be looked at between the FDIS (which has already happened) and the IS. Oh well. So we will probably have a bunch of deprecations later. -- He made the Legislature meet at one-horse John Cowan tank-towns out in the alfalfa belt, so that cowan@ccil.org hardly nobody could get there and most of http://www.ccil.org/~cowan the leaders would stay home and let him go --H.L. Mencken's to work and do things as he pleased. Declaration of Independence _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 09:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYBa-0006ND-Rm; Thu, 19 Oct 2006 09:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYBa-0006N7-Cl for ltru@lists.ietf.org; Thu, 19 Oct 2006 09:43:50 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYBZ-0007Sf-5F for ltru@lists.ietf.org; Thu, 19 Oct 2006 09:43:50 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GaYBY-0001f4-SJ; Thu, 19 Oct 2006 09:43:48 -0400 Date: Thu, 19 Oct 2006 09:43:48 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: Inversions and other problems Message-ID: <20061019134348.GD4622@ccil.org> References: <30b660a20610180728k14c621e5vf186f316bbeeb64f@mail.gmail.com> <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > I'm not fond of the idea "to drop the description "Ainu (Japan)" on > 'ain'" (leaving just "Ainu"), since that does not hint that there *may* > be more than one "Ainu". Nor do I like the idea of "change the "Ainu > (China)" to "Ainu, China" on 'aib'", since 1) that would be "equivalent" > to "China Ainu" which looks strange ("Chinese Ainu" would seem better), > and 2) if the country name is replaced by a language group name (which > I would prefer, compare "Slave (Athapascan)"), both the inverted and > non-inverted name would look really strange. In addition, both "China Ainu" and even more so "Chinese Ainu" would suggest some relation to the Ainu language of Japan, but there is none. > There are several instances of a) (clearly?) unrelated, and b) > (apparently?) closely related languages that have the same name but > (currently) distinguished by country name in the draft (yes, I know > it is a draft!) 639-3 registry tables. The former should certainly be > distinguished by something else than country name (in 639-3...). As a practical matter, country name is probably the most well-known attribute in these cases, and is fairly uncontroversial (though as you say subject to change). Most people know nothing about language affiliations. -- We do, doodley do, doodley do, doodley do, John Cowan What we must, muddily must, muddily must, muddily must; Muddily do, muddily do, muddily do, muddily do, http://www.ccil.org/~cowan Until we bust, bodily bust, bodily bust, bodily bust. --Bokonon _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 09:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYEd-0007g4-UW; Thu, 19 Oct 2006 09:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYEc-0007aa-9A for ltru@lists.ietf.org; Thu, 19 Oct 2006 09:46:58 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYEX-0007z1-Ry for ltru@lists.ietf.org; Thu, 19 Oct 2006 09:46:58 -0400 Received: by wr-out-0506.google.com with SMTP id 69so126202wri for ; Thu, 19 Oct 2006 06:46:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ST0D+Dyuqn1f4Hupc8/RGEAXz68O2aMBVXGQHKSxFiKcIMig1iCj4yzaTp7CxhyD+krZTK09VjkrbvAKU1RJQtLmW3eNzFhwl+eIe0jcM4HWuW7vrPrcBKIerbwNXhYZqI9+vBEuin1GD3hN0tp1X1S86mLJvrS2p5cImieSu18= Received: by 10.90.52.18 with SMTP id z18mr7242547agz; Thu, 19 Oct 2006 06:46:53 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Thu, 19 Oct 2006 06:46:53 -0700 (PDT) Message-ID: <30b660a20610190646t3d637eb0m6f5b60be96e9bd80@mail.gmail.com> Date: Thu, 19 Oct 2006 06:46:53 -0700 From: "Mark Davis" To: "Kent Karlsson" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 References: <30b660a20610180728k14c621e5vf186f316bbeeb64f@mail.gmail.com> <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: 6a71368d110daf51 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1897284091==" Errors-To: ltru-bounces@ietf.org --===============1897284091== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGNvdW50cnkgbmFtZXMgLS0gd2hldGhlciBpbiBwYXJlbnRo ZXRpY2FscyBvcgpub3QgLS0gYXJlIG5vdCBhIGdvb2QgbWV0aG9kIG9mIGRpc3Rpbmd1aXNoaW5n IGxhbmd1YWdlIHN1YnRhZ3MuIFNvIGlmCndlIGhhdmUgb3RoZXIgaW5mb3JtYXRpb24gdG8gaGVs cCB0byBuYW1lIHRoZW0sIHRoYXQgd291bGQgYmUgYmV0dGVyLgoKSSBkaWZmZXIgb24gdGhlIHNp bXVsdGFuZW91cyB1c2Ugb2YKCmRlc2NyaXB0aW9uKHh4eCkgPSBBIEIKZGVzY3JpcHRpb24oeXl5 KSA9IEIuCgpXZSBkbyB0aGF0IGEgbG90LCBhbmQgSSBkb24ndCB0aGluayBpdCBsZWFkcyB0byB0 aGF0IG11Y2ggY29uZnVzaW9uLgpJdCBpcyByZWFzb25hYmxlIHdoZW4gd2hhdCBpcyBkZW5vdGVk IGJ5IEIgKHRoYXQgaXMsIHl5eSkgaXMgdGhlCnByZWRvbWluYW50IHVzYWdlLiBXaGVuIHNvbWVv bmUgc2F5cyBBaW51LCBpdCByZWFsbHkgbWVhbnMgQWludSwgYXMgaW4KSmFwYW4sIHVubGVzcyBp dCBpcyBvdGhlcndpc2UgcXVhbGlmaWVkLiBJdCBpcyB0aGUgdW51c3VhbCBjYXNlIHRoYXQKbmVl ZHMgYSBxdWFsaWZpY2F0aW9uLgoKTWFyawoKT24gMTAvMTkvMDYsIEtlbnQgS2FybHNzb24gPGtl bnQua2FybHNzb24xNEBjb21oZW0uc2U+IHdyb3RlOgo+Cj4KPiBNYXJrIERhdmlzIHdyb3RlOgo+ Cj4KPiBUaG9zZSB3b3VsZCBuZWVkIHRvIGJlIGZpeGVkLiBUaGVyZSBhcmUgMTM4IHN1Y2ggY2Fz ZXMsIGFzIEkgaW5kaWNhdGVkIGluCj4gcHJldmlvdXMgbWVzc2FnZXMsIHNvIHRoYXQgd291bGQg aW52b2x2ZSBjaGFuZ2luZyA2OS4uMTM4IHZhbHVlcywgZGVwZW5kaW5nCj4gb24gdGhlIHJlc29s dXRpb24uIEZvciBleGFtcGxlLCBzaW5jZSAiQWludSIgYWxvbmUgaXMgYWxyZWFkeSBhIGRlc2Ny aXB0aW9uCj4gb24gJ2FpbicsIEkgdGhpbmsgdGhlIGNvcnJlY3QgY2hhbmdlIHRoZXJlIHdvdWxk IGJlIHRvIGRyb3AgdGhlIGRlc2NyaXB0aW9uCj4gIkFpbnUgKEphcGFuKSIgb24gJ2FpbicgYW5k IGNoYW5nZSB0aGUgIkFpbnUgKENoaW5hKSIgdG8gIkFpbnUsIENoaW5hIiBvbgo+ICdhaWInLgo+ IEknbSBub3QgZm9uZCBvZiB0aGUgaWRlYSAidG8gZHJvcCB0aGUgZGVzY3JpcHRpb24gIkFpbnUg KEphcGFuKSIgb24gJ2FpbiciCj4gKGxlYXZpbmcganVzdCAiQWludSIpLCBzaW5jZSB0aGF0IGRv ZXMgbm90IGhpbnQgdGhhdCB0aGVyZSAqbWF5KiBiZSBtb3JlCj4gdGhhbiBvbmUgIkFpbnUiLiBO b3IgZG8gSSBsaWtlIHRoZSBpZGVhIG9mICJjaGFuZ2UgdGhlICJBaW51IChDaGluYSkiIHRvCj4g IkFpbnUsIENoaW5hIiBvbiAnYWliJyIsIHNpbmNlIDEpIHRoYXQgd291bGQgYmUKPiAiZXF1aXZh bGVudCIgdG8gIkNoaW5hIEFpbnUiIHdoaWNoIGxvb2tzIHN0cmFuZ2UgKCJDaGluZXNlIEFpbnUi IHdvdWxkIHNlZW0KPiBiZXR0ZXIpLCBhbmQgMikgaWYgdGhlIGNvdW50cnkgbmFtZSBpcyByZXBs YWNlZCBieSBhIGxhbmd1YWdlIGdyb3VwIG5hbWUKPiAod2hpY2ggSSB3b3VsZCBwcmVmZXIsIGNv bXBhcmUgIlNsYXZlIChBdGhhcGFzY2FuKSIpLCBib3RoIHRoZSBpbnZlcnRlZCBhbmQKPiBub24t aW52ZXJ0ZWQgbmFtZSB3b3VsZCBsb29rIHJlYWxseSBzdHJhbmdlLgo+Cj4gT25lIG1vcmUgcmVh c29uIHRoYXQgSSBkb24ndCBsaWtlIHVzaW5nIGNvdW50cnkgbmFtZXMgZm9yIGRpc3Rpbmd1aXNo aW5nCj4gc2FtZS1uYW1lZCBidXQgZGlmZmVyZW50IGxhbmd1YWdlcyBpcyB0aGF0IG5hbWUgdGFn cywKPiBhcyBwZXIgMTc2NiBhbmQgc3VjY2Vzc29ycywgYWxyZWFkeSBhbGxvdyByZWdpb24gY29k ZXMuIE9uZSBtYXkgd2VsbCBiZQo+IHRlbXB0ZWQgdG8gdGhpbmsgdGhhdDoKPgo+ICogImFpbi1D TiIgaXMgdGhlIHNhbWUgYXMgImFpYiIsIHdoaWNoIGl0IGlzIG5vdCBhbmQgIkFpbnUgKENoaW5h KSIgaXMKPiB0aGVyZWZvcmUgbWlzbGVhZGluZyAoYW5kIG1hbnkgVUlzIG1pZ2h0IG5vdCBtYWtl IGEgZGlzcGxheSBuYW1lCj4gZGlzdGluY3Rpb24pLCBhbmQgdGhhdAo+Cj4gKiAic3dhLUNHIiAo b3IgInN3YS1DRCIpIGlzIHRoZSBzYW1lIGFzICJzd2Etc3djIiwgd2hpY2ggSSBjYW5ub3QgdGVs bCBpZiBpdAo+IGlzIG9yIGlzbid0IChzd2EgaXMgYSBtYWNyb2xhbmd1YWdlIGNvdmVyaW5nIHN3 Yyk7IEkgZ3Vlc3MgdGhleSBtYXkgYmUgdGhlCj4gInNhbWUiLCBhbmQgaWYgc28sIHVzaW5nIHRo ZSBjb3VudHJ5IG5hbWUgaW4gdGhlIGxhbmd1YWdlIGRlc2NyaXB0aW9uIHdvdWxkCj4gYmUgbW9y ZSBhcHByb3ByaWF0ZSAoYnV0IHN0aWxsIHN1YmplY3QgdG8gbmFtZSBpbnN0YWJpbGl0eSwgKG9u ZSBvZiB0aGUpCj4gQ29uZ28ocykgd2FzIGNhbGxlZCBaYcOvcmUgbm90IHNvIHZlcnkgbG9uZyBh Z28pLiBUaGVyZSBpcyBubyByZXF1aXJlbWVudAo+IHRoYXQgc3lzdGVtcyB0cmVhdCB0aGVtIHRo ZSBzYW1lIHRob3VnaCwgYnV0IGl0IG1heSB3YXJyYW50IGEgY29tbWVudCB0aGF0Cj4gc3dhLXN3 YyBpcyBwcmVmZXJyZWQgKG9yIG5vdCkgb3ZlciBzd2EtQ0cgb3Igc3dhLUNELgo+Cj4gVGhlcmUg YXJlIHNldmVyYWwgaW5zdGFuY2VzIG9mIGEpIChjbGVhcmx5PykgdW5yZWxhdGVkLCBhbmQgYikg KGFwcGFyZW50bHk/KQo+IGNsb3NlbHkgcmVsYXRlZCBsYW5ndWFnZXMgdGhhdCBoYXZlIHRoZSBz YW1lIG5hbWUgYnV0IChjdXJyZW50bHkpCj4gZGlzdGluZ3Vpc2hlZCBieSBjb3VudHJ5IG5hbWUg aW4gdGhlIGRyYWZ0ICh5ZXMsIEkga25vdyBpdCBpcyBhIGRyYWZ0ISkKPiA2MzktMyByZWdpc3Ry eSB0YWJsZXMuIFRoZSBmb3JtZXIgc2hvdWxkIGNlcnRhaW5seSBiZSBkaXN0aW5ndWlzaGVkIGJ5 Cj4gc29tZXRoaW5nIGVsc2UgdGhhbiBjb3VudHJ5IG5hbWUgKGluIDYzOS0zLi4uKS4KPgo+ICAg ICAgICAgICAgICAgICAva2VudCBrCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+Cj4K --===============1897284091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1897284091==-- From ltru-bounces@ietf.org Thu Oct 19 09:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYIy-0006Bp-D7; Thu, 19 Oct 2006 09:51:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYIx-0006Aj-BN for ltru@ietf.org; Thu, 19 Oct 2006 09:51:27 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYIu-0000O4-HL for ltru@ietf.org; Thu, 19 Oct 2006 09:51:27 -0400 Received: by wx-out-0506.google.com with SMTP id h30so686614wxd for ; Thu, 19 Oct 2006 06:51:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=a+sl2nxvhB85RC+oCh9bQdbmASjo5iLTkFPlZJIlFWYF3fVm0ZcAFBbMim8Wht1QO7DZeZOtaocRDQk9cXxQ+CI8u7Fy93kHJL0bGlOD8gePxg26DEiLBvN4RWaKI8NnhFM5W0oM7kCGLn3zLH+cancXzr47HnRN6jBC27sA+bA= Received: by 10.90.28.12 with SMTP id b12mr7247049agb; Thu, 19 Oct 2006 06:51:24 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Thu, 19 Oct 2006 06:51:24 -0700 (PDT) Message-ID: <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> Date: Thu, 19 Oct 2006 06:51:24 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <20061019133928.GC4622@ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> X-Google-Sender-Auth: 934c5ac095bcc328 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 10/19/06, John Cowan wrote: > Mark Davis scripsit: > > > Within a given type, a given description MUST be unique. That is, it MUST > > NOT occur more than once in that record, and MUST NOT occur at all in any > > other record of that type. Moreover, no variant description MAY occur in > > that record or any other record of that type. > > Well, that's fine, but it completely cabbages the requirement to keep the > Description fields in sync with the underlying standards. Can't have it > both ways as long as 639-2 and 639-3 haven't settled their differences, > and we can only hope that they *will* settle them. That is clear in the wording that Addison and I have been working on, and also clear as soon as we have separate names split into different description fields. I think we need to have a strong SHOULD to parallel the underlying standard as much as possible, but we owe it to our users to present unambiguous descriptions, so if the source standards do not do that, we should. After all, if someone wants to look at the original source, they can clearly do that. > > This is as good a place as any to report that I heard back from Joan > Spanne at the 639-3/RA-to-be saying that there while my complaints about > Yinglish and the bogus conlangs would be considered after 639-3 became > a standard, no changes would be looked at between the FDIS (which has > already happened) and the IS. Oh well. So we will probably have a > bunch of deprecations later. dang! > > -- > He made the Legislature meet at one-horse John Cowan > tank-towns out in the alfalfa belt, so that cowan@ccil.org > hardly nobody could get there and most of http://www.ccil.org/~cowan > the leaders would stay home and let him go --H.L. Mencken's > to work and do things as he pleased. Declaration of Independence > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 10:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYbY-0007er-Jy; Thu, 19 Oct 2006 10:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYbX-0007ei-Mk for ltru@ietf.org; Thu, 19 Oct 2006 10:10:39 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYbR-0004JJ-9g for ltru@ietf.org; Thu, 19 Oct 2006 10:10:39 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GaYbQ-0002i1-Oo; Thu, 19 Oct 2006 10:10:32 -0400 Date: Thu, 19 Oct 2006 10:10:32 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems Message-ID: <20061019141032.GF4622@ccil.org> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534506B.9000902@yahoo-inc.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > That is clear in the wording that Addison and I have been working on, > and also clear as soon as we have separate names split into different > description fields. I think we need to have a strong SHOULD to > parallel the underlying standard as much as possible, but we owe it to > our users to present unambiguous descriptions, so if the source > standards do not do that, we should. After all, if someone wants to > look at the original source, they can clearly do that. Fair enough. I am absolutely opposed, however, to creating inversions where the source has none. Mark's list shows its absurdity in its first few entries. "South Africa" is the name of a country, and inverting it to "Africa, South" makes no sense at all; it winds up mixed in with the U.N. regions "Southern Africa", "Northern Africa", etc. etc. We also wind up with "African Sign Language, South" which of course is the sign language of South Africa, but when inverted in this fashion looks like the Southern variety of a fictitious "African Sign Language". Where we have an inverted form we should use it, because it contains more information than the uninverted form. Where we have only an uninverted form, we must live with it. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Sound change operates regularly to produce irregularities; analogy operates irregularly to produce regularities. --E.H. Sturtevant, ca. 1945, probably at Yale _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 10:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYcQ-0000LE-CO; Thu, 19 Oct 2006 10:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYcO-0000Iy-FD for ltru@lists.ietf.org; Thu, 19 Oct 2006 10:11:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYcI-0004Tu-6o for ltru@lists.ietf.org; Thu, 19 Oct 2006 10:11:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GaYcH-0002kX-T1; Thu, 19 Oct 2006 10:11:25 -0400 Date: Thu, 19 Oct 2006 10:11:25 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems Message-ID: <20061019141125.GG4622@ccil.org> References: <30b660a20610180728k14c621e5vf186f316bbeeb64f@mail.gmail.com> <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> <30b660a20610190646t3d637eb0m6f5b60be96e9bd80@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610190646t3d637eb0m6f5b60be96e9bd80@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@lists.ietf.org, Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > We do that a lot, and I don't think it leads to that much confusion. > It is reasonable when what is denoted by B (that is, yyy) is the > predominant usage. When someone says Ainu, it really means Ainu, as in > Japan, unless it is otherwise qualified. It is the unusual case that > needs a qualification. Probably true for people referring to Ainu in anglophone countries -- but in China things may be otherwise. -- "The serene chaos that is Courage, and the phenomenon cowan@ccil.org of Unopened Consciousness have been known to the John Cowan Great World eons longer than Extaboulism." "Why is that?" the woman inquired. "Because I just made that word up", the Master said wisely. --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 11:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZUw-0002RN-J9; Thu, 19 Oct 2006 11:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZUv-0002MY-4E for ltru@ietf.org; Thu, 19 Oct 2006 11:07:53 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZUr-0000qN-IS for ltru@ietf.org; Thu, 19 Oct 2006 11:07:53 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:63346 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GaZUj-0007Bg-72 for ltru@ietf.org; Thu, 19 Oct 2006 17:07:42 +0200 From: "Kent Karlsson" To: "'LTRU Working Group'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Thu, 19 Oct 2006 17:07:29 +0200 Message-ID: <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <30b660a20610151048l2ebdf58dxaac4d0eb3b71f93a@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GaZUj-0007Bg-72. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GaZUj-0007Bg-72 2dc0a76949a417319b4c42de82ff5b67 X-Spam-Score: 0.5 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576959962==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1576959962== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C6F3A1.0F5A7AF0" This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C6F3A1.0F5A7AF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > 8. A script subtag SHOULD NOT be used if the content being tagged is > written in the script customarily used for the vast majority of > content in that language (e.g. en-Latn SHOULD NOT be used). There may be exceptions. While the following is about locale naming rather than language tagging (ready-made) text content, those are closely related, and a language tag can well be used to select the (almost) same-named locale. While 'th' currently has a Suppress-Script of 'Thai', and would still be covered by the above "SHOULD" if we remove "Suppress-Script", 'th' and 'th-Thai' (or as a locale name 'th_Thai'), in that generated digits (generated from some computation, or some database access, or similar) may be formatted differently for presentation: 'th' would imply the use of the digits 0-9 (which I understand is common in modern Thai), while 'th-Thai' (or rather a 'th_Thai' locale) would imply that they are presented using the Thai digits (U+0E50-U+0E59). Similarly, Arabic mixes the use of 0-9 and Arabic-Indic digits, and one may want to have separate locales for presenting computed number/date values using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). It would be possible to use variants for this, but that seems needless. Or would you consider such use as described above of script subtags as inappropriate? /kent k ------=_NextPart_000_003E_01C6F3A1.0F5A7AF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message
 
> 8.  A script subtag SHOULD NOT be used if the = content=20 being tagged is
> written in the script customarily used for = the vast=20 majority of
> content in that language (e.g. en-Latn SHOULD = NOT be=20 used). 
There may be exceptions. While the following is about = locale=20 naming rather
than = language tagging=20 (ready-made) text content, those are closely = related,
and a = language=20 tag = can well be=20 used to select the (almost) same-named locale.
 
While 'th' = currently has=20 a Suppress-Script of 'Thai', and would still be = covered
by the above = "SHOULD" if=20 we remove "Suppress-Script", 'th' and 'th-Thai'
(or as a = locale name=20 'th_Thai'), in that generated digits (generated from = some
computation, = or some=20 database access, or similar) may be formatted = differently
for = presentation: 'th' = would imply the=20 use of the digits 0-9 (which I understand
is common in = modern=20 Thai), while 'th-Thai' (or rather a 'th_Thai' locale) = would
imply that = they are=20 presented using=20 the Thai digits (U+0E50-U+0E59).
 
Similarly, = Arabic mixes=20 the use of 0-9 and Arabic-Indic digits, and one may
want to have = separate=20 locales for presenting computed number/date values
using 0-9 = (ar) or using=20 Arabic-Indic digits (ar-Arab).
 
It would be = possible to=20 use variants for this, but that seems needless. Or = would
you consider = such use as=20 described above of script subtags as inappropriate?
 
       =20 /kent k
 
------=_NextPart_000_003E_01C6F3A1.0F5A7AF0-- --===============1576959962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1576959962==-- From ltru-bounces@ietf.org Thu Oct 19 12:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaama-0004UN-Ui; Thu, 19 Oct 2006 12:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaamZ-0004Po-K6 for ltru@ietf.org; Thu, 19 Oct 2006 12:30:11 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaamV-0003HK-9M for ltru@ietf.org; Thu, 19 Oct 2006 12:30:11 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GaamP-0007rA-H6; Thu, 19 Oct 2006 12:30:01 -0400 Date: Thu, 19 Oct 2006 12:30:01 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... Message-ID: <20061019163001.GI4622@ccil.org> References: <30b660a20610151048l2ebdf58dxaac4d0eb3b71f93a@mail.gmail.com> <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > While 'th' currently has a Suppress-Script of 'Thai', and would still > be covered by the above "SHOULD" if we remove "Suppress-Script", 'th' > and 'th-Thai' (or as a locale name 'th_Thai'), in that generated digits > (generated from some computation, or some database access, or similar) > may be formatted differently for presentation: 'th' would imply the > use of the digits 0-9 (which I understand is common in modern Thai), > while 'th-Thai' (or rather a 'th_Thai' locale) would imply that they > are presented using the Thai digits (U+0E50-U+0E59). I think this is a very hacky trick, and extensions of it would be disastrous. All the Indic scripts have their own digit runs: some are used routinely, others only in historical documents. > It would be possible to use variants for this, but that seems > needless. Or would you consider such use as described above of script > subtags as inappropriate? Variants, or failing to tag at all when both styles are understood by the user community, seem ideal for this sort of very language-specific thing. -- He played King Lear as though John Cowan someone had played the ace. http://www.ccil.org/~cowan --Eugene Field _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 13:12:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabRc-0005zn-Rv; Thu, 19 Oct 2006 13:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabRc-0005zi-2s for ltru@ietf.org; Thu, 19 Oct 2006 13:12:36 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GabRa-0005bj-Pd for ltru@ietf.org; Thu, 19 Oct 2006 13:12:36 -0400 Received: by wx-out-0506.google.com with SMTP id h30so753361wxd for ; Thu, 19 Oct 2006 10:12:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=AhoaDsmNjovUgyGToYNx/G5FsrM2MVtsF0RljHvqNl89SyNtoOggzzLA+xQhhVDlIjjHWg+PXolqjkgd5I539GJhGEA4pEuFokHLQ/F6aZH6y9Nc2bXEaAEoa3HMJBooZ8lxAdzWPdJ88MpMg/7eAc+iA8N6/GpFKsefolvwXwE= Received: by 10.90.117.15 with SMTP id p15mr278279agc; Thu, 19 Oct 2006 10:12:34 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Thu, 19 Oct 2006 10:12:34 -0700 (PDT) Message-ID: <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> Date: Thu, 19 Oct 2006 10:12:34 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <20061019141032.GF4622@ccil.org> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> X-Google-Sender-Auth: 60741413b263e92c X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331177003==" Errors-To: ltru-bounces@ietf.org --===============0331177003== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTAvMTkvMDYsIEpvaG4gQ293YW4gPGNvd2FuQGNjaWwub3JnPiB3cm90ZToKPiBNYXJrIERh dmlzIHNjcmlwc2l0Ogo+Cj4gPiBUaGF0IGlzIGNsZWFyIGluIHRoZSB3b3JkaW5nIHRoYXQgQWRk aXNvbiBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiwKPiA+IGFuZCBhbHNvIGNsZWFyIGFzIHNv b24gYXMgd2UgaGF2ZSBzZXBhcmF0ZSBuYW1lcyBzcGxpdCBpbnRvIGRpZmZlcmVudAo+ID4gZGVz Y3JpcHRpb24gZmllbGRzLiBJIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBhIHN0cm9uZyBTSE9VTEQg dG8KPiA+IHBhcmFsbGVsIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkIGFzIG11Y2ggYXMgcG9zc2li bGUsIGJ1dCB3ZSBvd2UgaXQgdG8KPiA+IG91ciB1c2VycyB0byBwcmVzZW50IHVuYW1iaWd1b3Vz IGRlc2NyaXB0aW9ucywgc28gaWYgdGhlIHNvdXJjZQo+ID4gc3RhbmRhcmRzIGRvIG5vdCBkbyB0 aGF0LCB3ZSBzaG91bGQuIEFmdGVyIGFsbCwgaWYgc29tZW9uZSB3YW50cyB0bwo+ID4gbG9vayBh dCB0aGUgb3JpZ2luYWwgc291cmNlLCB0aGV5IGNhbiBjbGVhcmx5IGRvIHRoYXQuCj4KPiBGYWly IGVub3VnaC4KPgo+IEkgYW0gYWJzb2x1dGVseSBvcHBvc2VkLCBob3dldmVyLCB0byBjcmVhdGlu ZyBpbnZlcnNpb25zIHdoZXJlIHRoZSBzb3VyY2UKPiBoYXMgbm9uZS4gIE1hcmsncyBsaXN0IDxo dHRwOi8vbWFjY2hpYXRvLmNvbS9sdHJ1L2x0cnUtaW52ZXJzaW9ucy50eHQ+Cj4gc2hvd3MgaXRz IGFic3VyZGl0eSBpbiBpdHMgZmlyc3QgZmV3IGVudHJpZXMuICAiU291dGggQWZyaWNhIiBpcyB0 aGUgbmFtZQoKImFic3VyZGl0eSI/IEl0IGlzIHByZXR0eSBkYXJuZWQgYW5ub3lpbmcgd2hlbiBu byBtYXR0ZXIgaG93IEkgcXVhbGlmeQptZXNzYWdlcywgc29tZSBwZW9wbGUgY29tcGxldGVseSBz a2lwIG92ZXIgdGhhdC4gUGxlYXNlIGxvb2sgYXQgd2hhdCBJCndyb3RlLiBJIERJRCBOT1QgU0FZ IFRIQVQgQUxMIE9GIFRIRSBJVEVNUyBTSE9VTEQgQkUgRE9ORS4gSSBTQUlEIFRIQVQKVEhFWSBB UkUgIlBPU1NJQkxZIE1JU1NJTkciIEFORCBQVVQgVEhFTSBVUCBGT1IgUkVWSUVXLiBJdCBpcyBu b3QKYWJzdXJkIHRvIHB1dCB1cCBpbmZvcm1hdGlvbiBmb3IgcmV2aWV3LgoKVG8gbWFrZSBpdCBk aXJ0LXNpbXBsZSwgSSBwdXQgdXAgYSBmaWxlIGNhbGxlZApodHRwOi8vbWFjY2hpYXRvLmNvbS9s dHJ1L2x0cnUtaW52ZXJzaW9ucy1wb3NzaWJseS1taXNzaW5nLnhscwoobm90aWNlIHRoZSAicG9z c2libHkiIGluIHRoZSBuYW1lKSB0aGF0IGhhcyBhbGwgb2YgdGhlIHBvc3NpYmxlIGl0ZW1zCnNv cnRlZCBieSB0eXBlLiBJdCBpcyBhbiBFeGNlbCBmaWxlLCBidXQgaWYgeW91IGFyZSBhIHBhcmF0 aHlyb3Bob2JlCnlvdSBjYW4gdXNlIE9wZW5PZmZpY2UuCgpOb3csIEkgYW0sIGFzIEkgaGF2ZSBz YWlkIG1hbnkgdGltZXMsIG5vdCBpbiBmYXZvciBvZiBpbnZlcnNpb24uIEJ1dAppZiB3ZSBhcmUg Z29pbmcgdG8gaW52ZXJ0LCB3ZSBzaG91bGQgbWFrZSBhdCBsZWFzdCAqc29tZSogZWZmb3J0IHRv Cm1ha2UgaXQgd29yayBjb25zaXN0ZW50bHkuIEdpdmVuICphbGwqIHRoZSBvdGhlciBpbnZlcnNp b25zLCBpdCBpcwpub3QsIGF0IGxlYXN0IHByaW1hIGZhY2llLCBhYnN1cmQgdG8gaGF2ZToKCkJv bGl2aWFuIEd1YXJhbsOtLCBFYXN0ZXJuCkJvbGl2aWFuIEd1YXJhbsOtLCBXZXN0ZXJuCm9yCkNh bmFkaWFuIEludWt0aXR1dCwgRWFzdGVybgpDYW5hZGlhbiBJbnVrdGl0dXQsIFdlc3Rlcm4Kb3IK R3VpeWFuZyBIbW9uZywgTm9ydGhlcm4KR3VpeWFuZyBIbW9uZywgU291dGhlcm4KR3VpeWFuZyBI bW9uZywgU291dGh3ZXN0ZXJuCgpvciBtYW55IG90aGVycyBsaXN0ZWQgdGhlcmUuCgpPZiBjb3Vy c2UsIHNvbWUgb2YgdGhlIGludmVyc2lvbnMgc2hvdWxkbid0IGJlIGRvbmUsIHN1Y2ggYXMgdGhv c2UKc3BsaXR0aW5nIFNvdXRoIEFmcmljYSB3aGVyZSBpdCBtZWFucyB0aGUgY291bnRyeS4gVGhh dCdzIHdoeSB0aGVzZQp3aGVyZSBjaGFyYWN0ZXJpemVkIGFzICJwb3NzaWJsZSIuIFdoYXQgd291 bGQgYmUgdXNlZnVsIGlzIGlmIHlvdSB3ZXJlCnRvIGdvIHRocm91Z2ggdGhlIGRvY3VtZW50IGFu ZCBwaWNrIG91dCB0aGUgb25lcyB0aGF0IHlvdSB0aGluawpzaG91bGRuJ3QgYmUgZG9uZS4KCj4g b2YgYSBjb3VudHJ5LCBhbmQgaW52ZXJ0aW5nIGl0IHRvICJBZnJpY2EsIFNvdXRoIiBtYWtlcyBu byBzZW5zZSBhdCBhbGw7Cj4gaXQgd2luZHMgdXAgbWl4ZWQgaW4gd2l0aCB0aGUgVS5OLiByZWdp b25zICJTb3V0aGVybiBBZnJpY2EiLCAiTm9ydGhlcm4KPiBBZnJpY2EiLCBldGMuIGV0Yy4gIFdl IGFsc28gd2luZCB1cCB3aXRoICJBZnJpY2FuIFNpZ24gTGFuZ3VhZ2UsIFNvdXRoIgo+IHdoaWNo IG9mIGNvdXJzZSBpcyB0aGUgc2lnbiBsYW5ndWFnZSBvZiBTb3V0aCBBZnJpY2EsIGJ1dCB3aGVu IGludmVydGVkCj4gaW4gdGhpcyBmYXNoaW9uIGxvb2tzIGxpa2UgdGhlIFNvdXRoZXJuIHZhcmll dHkgb2YgYSBmaWN0aXRpb3VzICJBZnJpY2FuCj4gU2lnbiBMYW5ndWFnZSIuCj4KPiBXaGVyZSB3 ZSBoYXZlIGFuIGludmVydGVkIGZvcm0gd2Ugc2hvdWxkIHVzZSBpdCwgYmVjYXVzZSBpdCBjb250 YWlucwo+IG1vcmUgaW5mb3JtYXRpb24gdGhhbiB0aGUgdW5pbnZlcnRlZCBmb3JtLiAgV2hlcmUg d2UgaGF2ZSBvbmx5IGFuIHVuaW52ZXJ0ZWQKPiBmb3JtLCB3ZSBtdXN0IGxpdmUgd2l0aCBpdC4K Pgo+IC0tCj4gSm9obiBDb3dhbiAgICBjb3dhbkBjY2lsLm9yZyAgICBodHRwOi8vY2NpbC5vcmcv fmNvd2FuCj4gICAgICAgICBTb3VuZCBjaGFuZ2Ugb3BlcmF0ZXMgcmVndWxhcmx5IHRvIHByb2R1 Y2UgaXJyZWd1bGFyaXRpZXM7Cj4gICAgICAgICBhbmFsb2d5IG9wZXJhdGVzIGlycmVndWxhcmx5 IHRvIHByb2R1Y2UgcmVndWxhcml0aWVzLgo+ICAgICAgICAgICAgICAgICAtLUUuSC4gU3R1cnRl dmFudCwgY2EuIDE5NDUsIHByb2JhYmx5IGF0IFlhbGUKPgo= --===============0331177003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0331177003==-- From ltru-bounces@ietf.org Thu Oct 19 13:55:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gac6m-0007Ub-ET; Thu, 19 Oct 2006 13:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gac6l-0007UN-4l for ltru@ietf.org; Thu, 19 Oct 2006 13:55:07 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gac6i-0006O5-Vr for ltru@ietf.org; Thu, 19 Oct 2006 13:55:06 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:62349 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Gac6g-0002ce-8H; Thu, 19 Oct 2006 19:55:02 +0200 From: "Kent Karlsson" To: "'Mark Davis'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Thu, 19 Oct 2006 19:54:50 +0200 Message-ID: <004f01c6f3a7$acc92830$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <30b660a20610190906s46dee490s3494706c3cbda463@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1Gac6g-0002ce-8H. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Gac6g-0002ce-8H 18b554af32e60ace55a3c899f493af4f X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > It would be really impractical to depend on any consistent distinction > ever being drawn between th-Thai and th, either as languages or as > locales (in the CLDR sense, which is essentially the same as > language). The only difference would be that in matching, th could > match th-Latn (a romanization), for example. But that is going to be > extremely rare cases. Well, th_Latn (and I'm still considering locale names) would have all data associated with it in the Latin script. Whereas th would have all data but the LDML/ in Thai, and th_Thai would differ from th only in . And I'm looking at an actual, and rather widespread, system that already has a th_TH locale as well as a th_TH_TH locale, with just this difference, and the only difference, but (currently) with a worse naming. I'm not sure why John finds using th_Thai, and similar for some other languages, disastrous, nor why variants would be ideal. Indeed, using variants for this seems *very* unpractical, especially if one prefers a restriction to (for language tags) registered variants. I'm not going to push for registering such (a) variant(s), and I don't think one should be registered, nor that ietf-languages group would accept such a variant. An (explicit, -x-) private use variant for this would be out of the question, I'd say. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 14:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GacJT-0000LW-5V; Thu, 19 Oct 2006 14:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GacJR-0000DN-0r for ltru@ietf.org; Thu, 19 Oct 2006 14:08:13 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GacJP-0000AP-LP for ltru@ietf.org; Thu, 19 Oct 2006 14:08:12 -0400 Received: from [10.72.72.123] (snvvpn1-10-72-72-c123.corp.yahoo.com [10.72.72.123]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9JI7pjc060882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 11:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=B+mFy2yRZ2Y9+uXs6fW3HWYlvw0ZYU2Tf0TE9FcLq7+mEULkXIi+ZBPYK/q2r1/o Message-ID: <4537BEF6.9000609@yahoo-inc.com> Date: Thu, 19 Oct 2006 11:07:50 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kent Karlsson Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... References: <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> In-Reply-To: <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > > Similarly, Arabic mixes the use of 0-9 and Arabic-Indic digits, and one may > want to have separate locales for presenting computed number/date values > using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). > > It would be possible to use variants for this, but that seems needless. > Or would > you consider such use as described above of script subtags as inappropriate? > I don't understand why the "thai" script subtag would imply this at all, even in a locale identifier. Minor variations in user preference such as this really shouldn't be inferred from a script subtag. Similarly the numeric shaping in Arabic locales (or in the Indic languages, for that matter). For example, I wouldn't expect a script subtag to control whether the date format in a Chinese locale is all-numeric or presents ideographs. These are properly API options or minor variations within a locale hierarchy. I *do* agree that there are cases in which, even when normally it would be "suppressed", the script subtag should be visible and this could even apply to locale identifiers (although I can't think of a good example off the top of my head). But I don't think this is a valid example of such a case. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 15:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gad9R-0001xQ-Lq; Thu, 19 Oct 2006 15:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gad9Q-0001sp-Fo for ltru@ietf.org; Thu, 19 Oct 2006 15:01:56 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gad9N-00008B-Rs for ltru@ietf.org; Thu, 19 Oct 2006 15:01:56 -0400 Received: from [10.72.72.123] (snvvpn1-10-72-72-c123.corp.yahoo.com [10.72.72.123]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9JJ1PMD062181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 12:01:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=rMhl0G6NhulIoDHLjrDlTm5s/QnGPWgT9UVzWYcd3JgoNvBIbSRqYtpj+zZkTJeq Message-ID: <4537CB84.7060603@yahoo-inc.com> Date: Thu, 19 Oct 2006 12:01:24 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> In-Reply-To: <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id k9JJ1PMD062181 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org We've been batting this around awhile. I did a major edit on that=20 section (incorporating some of Marion's text) to produce this: --
The field 'Description' contains a description of the tag or subtag=20 in the record. The 'Description' field MAY appear more than once per=20 record, that is, there can be multiple descriptions for a given record.=20 At least one of the 'Description' fields MUST be written or transcribed=20 into the Latin script; additional 'Description' fields MAY also include=20 a description in a non-Latin script. Each 'Description' field MUST be=20 unique, both within the record in which it appears and for the=20 collection of records of the same type. Moreover, formatting variations=20 of the same description MUST NOT occur in that specific record or in any=20 other record of the same type. For example, while the ISO 639-1 code=20 'fy' contains both the descriptions "Western Frisian" and "Frisian,=20 Western", only one of these descriptions appears in the registry. The 'Description' field is used for identification purposes and=20 SHOULD NOT be taken to represent the actual native name of the language=20 or variation or to be in any particular language.For records=20 taken from a source standard (such as ISO 639 or ISO 3166), the=20 'Description' value(s) SHOULD be taken from the source standard.=20 Multiple descriptions in the source standard MUST be split into separate=20 'Description' fields. The source standard's descriptions MAY be edited,=20 either prior to insertion or via the registration process. When creating a new registry entry, duplicate, redundant,=20 conflicting, or otherwise problematic descriptions MUST either be=20 corrected or omitted. Parenthetical comments, inverted names, and other=20 irregularities SHOULD be regularized according to the guidelines used to=20 update the registry in . Note: Descriptions in registry entries that correspond to ISO 639,=20 ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate the=20 meaning of that identifier as defined in the source standard at the time=20 it was added to the registry. The description does not replace the=20 content of the source standard itself. The descriptions are not intended=20 to be the English localized names for the subtags. Localization or=20 translation of language tag and subtag descriptions is out of scope of=20 this document.
-- Mark Davis wrote: > On 10/19/06, John Cowan wrote: >> Mark Davis scripsit: >> >> > That is clear in the wording that Addison and I have been working on= , >> > and also clear as soon as we have separate names split into differen= t >> > description fields. I think we need to have a strong SHOULD to >> > parallel the underlying standard as much as possible, but we owe it = to >> > our users to present unambiguous descriptions, so if the source >> > standards do not do that, we should. After all, if someone wants to >> > look at the original source, they can clearly do that. >> >> Fair enough. >> >> I am absolutely opposed, however, to creating inversions where the sou= rce >> has none. Mark's list >> shows its absurdity in its first few entries. "South Africa" is the n= ame >=20 > "absurdity"? It is pretty darned annoying when no matter how I qualify > messages, some people completely skip over that. Please look at what I > wrote. I DID NOT SAY THAT ALL OF THE ITEMS SHOULD BE DONE. I SAID THAT > THEY ARE "POSSIBLY MISSING" AND PUT THEM UP FOR REVIEW. It is not > absurd to put up information for review. >=20 > To make it dirt-simple, I put up a file called > http://macchiato.com/ltru/ltru-inversions-possibly-missing.xls > (notice the "possibly" in the name) that has all of the possible items > sorted by type. It is an Excel file, but if you are a parathyrophobe > you can use OpenOffice. >=20 > Now, I am, as I have said many times, not in favor of inversion. But > if we are going to invert, we should make at least *some* effort to > make it work consistently. Given *all* the other inversions, it is > not, at least prima facie, absurd to have: >=20 > Bolivian Guaran=C3=AD, Eastern > Bolivian Guaran=C3=AD, Western > or > Canadian Inuktitut, Eastern > Canadian Inuktitut, Western > or > Guiyang Hmong, Northern > Guiyang Hmong, Southern > Guiyang Hmong, Southwestern >=20 > or many others listed there. >=20 > Of course, some of the inversions shouldn't be done, such as those > splitting South Africa where it means the country. That's why these > where characterized as "possible". What would be useful is if you were > to go through the document and pick out the ones that you think > shouldn't be done. >=20 >> of a country, and inverting it to "Africa, South" makes no sense at al= l; >> it winds up mixed in with the U.N. regions "Southern Africa", "Norther= n >> Africa", etc. etc. We also wind up with "African Sign Language, South= " >> which of course is the sign language of South Africa, but when inverte= d >> in this fashion looks like the Southern variety of a fictitious "Afric= an >> Sign Language". >> >> Where we have an inverted form we should use it, because it contains >> more information than the uninverted form. Where we have only an=20 >> uninverted >> form, we must live with it. >> >> --=20 >> John Cowan cowan@ccil.org http://ccil.org/~cowan >> Sound change operates regularly to produce irregularities; >> analogy operates irregularly to produce regularities. >> --E.H. Sturtevant, ca. 1945, probably at Yale >> >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 15:16:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadNN-00011t-RT; Thu, 19 Oct 2006 15:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadNM-00011h-D6 for ltru@ietf.org; Thu, 19 Oct 2006 15:16:20 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadNK-0002RJ-Rz for ltru@ietf.org; Thu, 19 Oct 2006 15:16:20 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:63791 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GadNI-00045V-8D; Thu, 19 Oct 2006 21:16:16 +0200 From: "Kent Karlsson" To: "'Addison Phillips'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Thu, 19 Oct 2006 21:16:04 +0200 Message-ID: <005001c6f3b3$05d4de50$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4537BEF6.9000609@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GadNI-00045V-8D. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GadNI-00045V-8D d9fbdb2fb5de427fb0559bc0c8024264 X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > I don't understand why the "thai" script subtag would imply this at all, > even in a locale identifier. You could see it as knd of emphasis: "really all Thai, digits too". > Minor variations in user preference such as > this really shouldn't be inferred from a script subtag. Similarly the > numeric shaping in Arabic locales (or in the Indic languages, > for that matter). > > For example, I wouldn't expect a script subtag to control whether the > date format in a Chinese locale is all-numeric or presents ideographs. > These are properly API options or minor variations within a locale > hierarchy. As for using ideographs, that use seems mostly comparable to using number spellout, like 120 -> "one-two-zero" or "one hundred and twenty". But looking at the same system as I mentioned before, there is a "ko_KR" locale and a "ko_KR_HANI" locale, which differs in just that: The number *spellout* (for datetimes, currently) in ko_KR is in Sino-Korean Hangul, whereas in ko_KR_HANI (yes, the current name has the script code after the territory code, but that is a separate issue; they were named before RFC 4646) the *spellout* is in Hanja ideographs. Both have non-spellout digits as 0-9 (both for ordinary numbers and datetimes). But ko_KR_HANI has all data in Hanja, not just for number spellout. ko_KR has, of course, all data in Hangul. That th_TH_TH is named that way instead of th_TH_THAI is more an accident than design, I think. I did not name these locales. > I *do* agree that there are cases in which, even when normally it would > be "suppressed", the script subtag should be visible and this could even > apply to locale identifiers (although I can't think of a good example > off the top of my head). But I don't think this is a valid example of > such a case. There are already such cases, see above. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 16:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeED-0001gt-Gs; Thu, 19 Oct 2006 16:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeE6-0001ZE-30 for ltru@lists.ietf.org; Thu, 19 Oct 2006 16:10:50 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaeDR-0001y8-B4 for ltru@lists.ietf.org; Thu, 19 Oct 2006 16:10:50 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005082106.msg for ; Thu, 19 Oct 2006 21:11:37 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 19 Oct 2006 21:09:30 +0100 From: "Debbie Garside" To: Subject: RE: [Ltru] Re: Inversions and other problems Date: Thu, 19 Oct 2006 21:08:56 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbzhAKC9l8esVZXRSe3tFQogLxY5QANd7Kw In-Reply-To: <002601c6f383$d3aaf6a0$6500a8c0@chalmers95a69n> Message-ID: <1C9FC9C7420A4D87BDDF6C2E166B395A.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 19 Oct 2006 21:11:37 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@lists.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 19 Oct 2006 21:11:38 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0045571287==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0045571287== Content-Type: multipart/alternative; boundary="----=_NextPart_000_12B2_01C6F3C2.CC20E270" This is a multi-part message in MIME format. ------=_NextPart_000_12B2_01C6F3C2.CC20E270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Playing catchup. Apologies if I am just reiterating my position on = this. =20 It is my humble opinion that if the ISO standard says Ainu (Japan) then = that should be copied EXACTLY within the registry. Please do not make = changes to the data from the underlying standards where this data has been added in order to differentiate between language (or other) entities. I have no objection to spelling errors etc being corrected and the JAC being = informed of such corrections.=20 =20 Best regards =20 Debbie =20 Mark Davis wrote: Those would need to be fixed. There are 138 such cases, as I indicated = in previous messages, so that would involve changing 69..138 values, = depending on the resolution. For example, since "Ainu" alone is already a = description on 'ain', I think the correct change there would be to drop the = description "Ainu (Japan)" on 'ain' and change the "Ainu (China)" to "Ainu, China" = on 'aib'.=20 I'm not fond of the idea "to drop the description "Ainu (Japan)" on = 'ain'" (leaving just "Ainu"), since that does not hint that there *may* be more than one "Ainu". Nor do I like the idea of "change the "Ainu (China)" to "Ainu, China" on 'aib'", since 1) that would be "equivalent" to "China Ainu" which looks strange ("Chinese Ainu" would = seem better), and 2) if the country name is replaced by a language group name (which I would prefer, compare "Slave (Athapascan)"), both the inverted = and non-inverted name would look really strange. =20 One more reason that I don't like using country names for distinguishing same-named but different languages is that name tags, as per 1766 and successors, already allow region codes. One may well be tempted to think that: =20 * "ain-CN" is the same as "aib", which it is not and "Ainu (China)" is therefore misleading (and many UIs might not make a display name distinction), and that =20 * "swa-CG" (or "swa-CD") is the same as "swa-swc", which I cannot tell = if it is or isn't (swa is a macrolanguage covering swc); I guess they may be = the "same", and if so, using the country name in the language description = would be more appropriate (but still subject to name instability, (one of the) Congo(s) was called Za=EFre not so very long ago). There is no = requirement that systems treat them the same though, but it may warrant a comment = that swa-swc is preferred (or not) over swa-CG or swa-CD. =20 There are several instances of a) (clearly?) unrelated, and b) = (apparently?) closely related languages that have the same name but (currently) distinguished by country name in the draft (yes, I know it is a draft!) 639-3 registry tables. The former should certainly be distinguished by something else than country name (in 639-3...). =20 /kent k =20 ------=_NextPart_000_12B2_01C6F3C2.CC20E270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Playing catchup.  Apologies if I am just = reiterating my position on this.
 
It is=20 my humble opinion that if the ISO standard says Ainu (Japan) then that = should be=20 copied EXACTLY within the registry.  Please do not make changes to = the data=20 from the underlying standards where this data has been added in order to = differentiate between language (or other) entities. I have no = objection to=20 spelling errors etc being corrected and the JAC being informed of = such=20 corrections. 
 
Best=20 regards
 
Debbie

 
Mark Davis wrote:
Those would need to be fixed. There are 138 such cases, as I = indicated=20 in previous messages, so that would involve changing 69..138 values, = depending on the resolution. For example, since "Ainu" alone is = already a=20 description on 'ain', I think the correct change there would be to = drop the=20 description "Ainu (Japan)" on 'ain' and change the "Ainu (China)" to = "Ainu,=20 China" on 'aib'. 
I'm not = fond of the=20 idea "to drop the description "Ainu (Japan)" on=20 'ain'" (leaving just "Ainu"), since that does not hint = that there=20 *may* be more than one "Ainu". Nor do I like the idea of "change the "Ainu (China)" to "Ainu, China" on = 'aib'",=20 since 1) that would be
"equivalent" to "China=20 Ainu" which looks strange ("Chinese Ainu" would seem better), and 2) = if the=20 country name is replaced by a language group name (which I would = prefer,=20 compare "Slave (Athapascan)"), both the inverted and non-inverted = name would look really strange.
 
One more = reason that I=20 don't like using country names for distinguishing same-named but = different=20 languages is that name tags,
as per = 1766 and=20 successors, already allow region codes. One may well be tempted to = think=20 that:
 
* "ain-CN" is the=20 same as "aib", which it is not and "Ainu (China)" is therefore = misleading (and=20 many UIs might not make a display name distinction), and=20 that
 
* "swa-CG" = (or=20 "swa-CD") is the same as "swa-swc", which I cannot tell if it is = or isn't=20 (swa is a macrolanguage covering swc); I guess they may be the "same", = and if=20 so, using the country name in the language description would be more=20 appropriate (but still subject to name instability, (one of the) = Congo(s) was=20 called Za=EFre not so very long ago). There is no requirement that = systems treat=20 them the same though, but it may warrant a comment that swa-swc is = preferred=20 (or not) over swa-CG or swa-CD.
 
There are = several=20 instances of a) (clearly?) unrelated, and b) (apparently?) closely = related=20 languages that have the same name but (currently) distinguished by = country=20 name in the draft (yes, I know it is a draft!) 639-3 registry tables. = The=20 former should certainly be distinguished by something else than = country name=20 (in 639-3...).
 
         &nb= sp;     =20 /kent k
 
------=_NextPart_000_12B2_01C6F3C2.CC20E270-- --===============0045571287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0045571287==-- From ltru-bounces@ietf.org Thu Oct 19 16:20:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeNq-0004hd-Np; Thu, 19 Oct 2006 16:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaeNo-0004dG-CX for ltru@ietf.org; Thu, 19 Oct 2006 16:20:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaeNo-0003QT-Am for ltru@ietf.org; Thu, 19 Oct 2006 16:20:52 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaeHx-0004IP-18 for ltru@ietf.org; Thu, 19 Oct 2006 16:14:55 -0400 Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005082200.msg for ; Thu, 19 Oct 2006 21:16:21 +0100 Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 19 Oct 2006 21:14:12 +0100 From: "Debbie Garside" To: "'LTRU Working Group'" Date: Thu, 19 Oct 2006 21:13:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcbzuxILEfrzRg81STapAttRf86n4g== Message-ID: <8962EAED2E7543EBA0D4449CD7F9623E.MAI@home> X-Spam-Processed: mx1.nexbyte.net, Thu, 19 Oct 2006 21:16:21 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.51.14 X-Return-Path: debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: ltru@ietf.org X-MDAV-Processed: mx1.nexbyte.net, Thu, 19 Oct 2006 21:16:22 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Descriptions X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi I am just wondering whether it might be an idea to be more specific with the "Description" fields. Why not have an "ISO_Description" as well as any number of other "Description" fields. Then you can do what you like with the other descriptions. Just a thought. Debbie Debbie Garside Managing Director GeoLang Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 1437 766441 Web: http://www.geolang.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 20:33:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiJf-0001gX-MO; Thu, 19 Oct 2006 20:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiJe-0001gR-B0 for ltru@lists.ietf.org; Thu, 19 Oct 2006 20:32:50 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaiJY-0002QU-VZ for ltru@lists.ietf.org; Thu, 19 Oct 2006 20:32:50 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaiIo-0001y1-0E for ltru@lists.ietf.org; Fri, 20 Oct 2006 02:32:01 +0200 Received: from pd9fba8c8.dip0.t-ipconnect.de ([217.251.168.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 02:31:57 +0200 Received: from nobody by pd9fba8c8.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 02:31:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Oct 2006 02:21:55 +0200 Organization: Lines: 22 Message-ID: <453816A3.4B11@xyzzy.claranet.de> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8c8.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > if you are a parathyrophobe you can use OpenOffice. Your TAB-separated files were perfectly readable from my POV, the XLS-file isn't. What is a "parathyrophobe" ? Am I safe from this condition without "OpenOffice" ? >> This is as good a place as any to report that I heard back >> from Joan Spanne at the 639-3/RA-to-be saying that there >> while my complaints about Yinglish and the bogus conlangs >> would be considered after 639-3 became a standard, no changes >> would be looked at between the FDIS (which has already >> happened) and the IS. Oh well. So we will probably have a >> bunch of deprecations later. > dang! An "orq" registry wouldn't pass a giggle test, we can't submit it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 20:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiQl-0002Py-Co; Thu, 19 Oct 2006 20:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiQj-0002Pa-LL for ltru@lists.ietf.org; Thu, 19 Oct 2006 20:40:09 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaiQi-0003pK-C8 for ltru@lists.ietf.org; Thu, 19 Oct 2006 20:40:09 -0400 Received: by wx-out-0506.google.com with SMTP id h28so804430wxd for ; Thu, 19 Oct 2006 17:40:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=md3035ho92Ljs7pFlpemTkKG5TKpLczO0JQzy6619MfSznvNCCCINuEERNfBUqN+DKkQZd+n3G/T1aGCcSnxN/X6NaDfNTEhR92ZJwCuoWX4ebgplAj6r0T2CGxa/pPH0UWgw2zSdtywWrjOxL+ZExLIMlseaY3WWUBjsilignM= Received: by 10.90.79.6 with SMTP id c6mr689923agb; Thu, 19 Oct 2006 17:40:07 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Thu, 19 Oct 2006 17:40:07 -0700 (PDT) Message-ID: <30b660a20610191740h5605759fud9c510d2da3825f5@mail.gmail.com> Date: Thu, 19 Oct 2006 17:40:07 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Inversions and other problems In-Reply-To: <453816A3.4B11@xyzzy.claranet.de> MIME-Version: 1.0 References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> <453816A3.4B11@xyzzy.claranet.de> X-Google-Sender-Auth: 3d855913a7982616 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1943279030==" Errors-To: ltru-bounces@ietf.org --===============1943279030== Content-Type: multipart/alternative; boundary="----=_Part_83042_17144660.1161304807936" ------=_Part_83042_17144660.1161304807936 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline parathyrophobe - someone who doesn't like Windows (my coinage) OpenOffice is an open-source office product that let's people on other platforms read Windows files, like xls files. Mark On 10/19/06, Frank Ellermann wrote: > > Mark Davis wrote: > > > if you are a parathyrophobe you can use OpenOffice. > > Your TAB-separated files were perfectly readable from my POV, > the XLS-file isn't. What is a "parathyrophobe" ? Am I safe > from this condition without "OpenOffice" ? > > >> This is as good a place as any to report that I heard back > >> from Joan Spanne at the 639-3/RA-to-be saying that there > >> while my complaints about Yinglish and the bogus conlangs > >> would be considered after 639-3 became a standard, no changes > >> would be looked at between the FDIS (which has already > >> happened) and the IS. Oh well. So we will probably have a > >> bunch of deprecations later. > > > dang! > > An "orq" registry wouldn't pass a giggle test, we can't submit it. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_83042_17144660.1161304807936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline parathyrophobe - someone who doesn't like Windows (my coinage)

OpenOffice is an open-source office product that let's people on other platforms read Windows files, like xls files.

Mark

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

> if you are a parathyrophobe you can use OpenOffice.

Your TAB-separated files were perfectly readable from my POV,
the XLS-file isn't.  What is a "parathyrophobe" ?  Am I safe
from this condition without "OpenOffice" ?

>> This is as good a place as any to report that I heard back
>> from Joan Spanne at the 639-3/RA-to-be saying that there
>> while my complaints about Yinglish and the bogus conlangs
>> would be considered after 639-3 became a standard, no changes
>> would be looked at between the FDIS (which has already
>> happened) and the IS.  Oh well.  So we will probably have a
>> bunch of deprecations later.

> dang!

An "orq" registry wouldn't pass a giggle test, we can't submit it.

Frank



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

------=_Part_83042_17144660.1161304807936-- --===============1943279030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1943279030==-- From ltru-bounces@ietf.org Thu Oct 19 22:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gak8r-0000oN-Df; Thu, 19 Oct 2006 22:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gak8p-0000o3-6b for ltru@ietf.org; Thu, 19 Oct 2006 22:29:47 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaaPJ-0006DI-Qp for ltru@ietf.org; Thu, 19 Oct 2006 12:06:13 -0400 Received: by wx-out-0506.google.com with SMTP id h30so732964wxd for ; Thu, 19 Oct 2006 09:06:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TmAcjM9+F6Xsr5IDvqspOxtrwMLmnv4UkdI/58enwH7tL7mPCmghC//lR2FJXWU7XAmahAYKNzuK26YlOkXtCWR+gZeBoJzrnr10+gSQ3vJ0nbQGaJ+nJewa23vQN97Z6ZUJ1E7Ai9AxJ6bsW/idz2nALeOVX8ibZc0aLjh5gaA= Received: by 10.90.65.11 with SMTP id n11mr130929aga; Thu, 19 Oct 2006 09:06:08 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Thu, 19 Oct 2006 09:06:08 -0700 (PDT) Message-ID: <30b660a20610190906s46dee490s3494706c3cbda463@mail.gmail.com> Date: Thu, 19 Oct 2006 09:06:08 -0700 From: "Mark Davis" To: "Kent Karlsson" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30b660a20610151048l2ebdf58dxaac4d0eb3b71f93a@mail.gmail.com> <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: 46e40e199dff2490 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It would be really impractical to depend on any consistent distinction ever being drawn between th-Thai and th, either as languages or as locales (in the CLDR sense, which is essentially the same as language). The only difference would be that in matching, th could match th-Latn (a romanization), for example. But that is going to be extremely rare cases. Mark On 10/19/06, Kent Karlsson wrote: > > > > > > > > > 8. A script subtag SHOULD NOT be used if the content being tagged is > > > written in the script customarily used for the vast majority of > > > content in that language (e.g. en-Latn SHOULD NOT be used). > > There may be exceptions. While the following is about locale naming rather > than language tagging (ready-made) text content, those are closely related, > and a language tag can well be used to select the (almost) same-named > locale. > > While 'th' currently has a Suppress-Script of 'Thai', and would still be > covered > by the above "SHOULD" if we remove "Suppress-Script", 'th' and 'th-Thai' > (or as a locale name 'th_Thai'), in that generated digits (generated from > some > computation, or some database access, or similar) may be formatted > differently > for presentation: 'th' would imply the use of the digits 0-9 (which I > understand > is common in modern Thai), while 'th-Thai' (or rather a 'th_Thai' locale) > would > imply that they are presented using the Thai digits (U+0E50-U+0E59). > > Similarly, Arabic mixes the use of 0-9 and Arabic-Indic digits, and one may > want to have separate locales for presenting computed number/date values > using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). > > It would be possible to use variants for this, but that seems needless. Or > would > you consider such use as described above of script subtags as inappropriate? > > /kent k > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 19 23:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GalXw-0008D0-4E; Thu, 19 Oct 2006 23:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GalXv-0008Co-7n for ltru@lists.ietf.org; Thu, 19 Oct 2006 23:59:47 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GalXq-0002zF-Sg for ltru@lists.ietf.org; Thu, 19 Oct 2006 23:59:47 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GalXe-00041U-VA for ltru@lists.ietf.org; Fri, 20 Oct 2006 05:59:30 +0200 Received: from pd9fbad03.dip0.t-ipconnect.de ([217.251.173.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 05:59:30 +0200 Received: from nobody by pd9fbad03.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 05:59:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 20 Oct 2006 05:57:54 +0200 Organization: Lines: 24 Message-ID: <45384942.30DB@xyzzy.claranet.de> References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> <453816A3.4B11@xyzzy.claranet.de> <30b660a20610191740h5605759fud9c510d2da3825f5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad03.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] file formats (was: Inversions and other problems) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > parathyrophobe - someone who doesn't like Windows (my coinage) "Can't read XLS" and "don't like a 'parathyro'" isn't the same, as far as I know it W2K is a nice OS, as shipped without Excel ;-) > OpenOffice is an open-source office product that let's people > on other platforms read Windows files, like xls files. On _some_ other platforms _if_ installed. I should finally delete a vintage '95 "IBM works for OS/2" directory, it's in an unusable state. MIME text/csv got its own RFC 4180 a year ago, with a link to the same TaoUP as in RFC 4646 (incl. among others "record-jar"): And RFC 4180 mentions that there's a text/tab-separated-values MIME type, nice, I didn't know that: Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 00:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GalnF-0007KQ-Kq; Fri, 20 Oct 2006 00:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GalnE-0007Hb-Hb for ltru@lists.ietf.org; Fri, 20 Oct 2006 00:15:36 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GalnD-0008JU-7M for ltru@lists.ietf.org; Fri, 20 Oct 2006 00:15:36 -0400 Received: from [10.72.76.9] (snvvpn2-10-72-76-c9.corp.yahoo.com [10.72.76.9]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9K4FOsc085768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 21:15:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=fqefvH5KGRRVU0qFu7Q0vvXuwqBpa1/ei4HlqWy29zg/a4C3UQ0bxpS3CAd+JJYB Message-ID: <45384D5C.3010902@yahoo-inc.com> Date: Thu, 19 Oct 2006 21:15:24 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] file formats References: <30b660a20610161833y1ec6d858w1a779ba486fd9f35@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> <453816A3.4B11@xyzzy.claranet.de> <30b660a20610191740h5605759fud9c510d2da3825f5@mail.gmail.com> <45384942.30DB@xyzzy.claranet.de> In-Reply-To: <45384942.30DB@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id k9K4FOsc085768 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Mark Davis wrote: > >> parathyrophobe - someone who doesn't like Windows (my coinage) (laughing) =CE=A0=CE=B1=CF=81=CE=AC=CE=B8=CF=85=CF=81=CE=B1. Ah, it took = me a couple of minutes to figure that=20 out. Knowledge of Greek roots doesn't help at all here. Addison --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 02:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gao3z-00025g-28; Fri, 20 Oct 2006 02:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gao3w-00021C-Ia for ltru@ietf.org; Fri, 20 Oct 2006 02:41:00 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gao3v-0001qN-8U for ltru@ietf.org; Fri, 20 Oct 2006 02:41:00 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061020064057.WCDI14484.mta10.adelphia.net@DGBP7M81> for ; Fri, 20 Oct 2006 02:40:57 -0400 Message-ID: <001201c6f412$b39e1bf0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 19 Oct 2006 23:40:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > I'm not fond of the idea "to drop the description "Ainu (Japan)" on > 'ain'" (leaving just "Ainu"), since that does not hint that there > *may* be more than one "Ainu". Nor do I like the idea of "change the > "Ainu (China)" to "Ainu, China" on 'aib'", since 1) that would be > "equivalent" to "China Ainu" which looks strange ("Chinese Ainu" would > seem better), and 2) if the country name is replaced by a language > group name (which I would prefer, compare "Slave (Athapascan)"), both > the inverted and non-inverted name would look really strange. I agree. I don't see anything inherently wrong with these parenthetical modifiers that would be improved by using a comma instead. We still need to be very careful not to confuse the three issues of (1) macrolanguage, (2) collective code element, and (3) different languages with the same name. I'm sure Peter would be happy to repeat this explanation again. > One more reason that I don't like using country names for > distinguishing same-named but different languages is that name tags, > as per 1766 and successors, already allow region codes. One may well > be tempted to think that: > > * "ain-CN" is the same as "aib", which it is not and "Ainu (China)" is > therefore misleading (and many UIs might not make a display name > distinction), and that > > * "swa-CG" (or "swa-CD") is the same as "swa-swc", The use of "(country)" qualifiers may cause some confusion for casual perusers of the Registry, but it's probably the best we've got for two unrelated languages that happen to have the same name. Some are very uncommon (Ethnologue cites 15 speakers of "Ainu (Japan)", and states that "Ainu (China)" is spoken only within the home) and there should be little real-world confusion. Names based on linguistic family classifications might be a lot harder for non-linguists to understand. Subtags like these are extremely unlikely to be used with region subtags anyway. Pretending for the moment that the two Ainus were in MUCH more widespread use, all of the following tags would make sense, because "Ainu of China" and ""Ainu of Japan are two different languages. aib-CN ("Ainu of China") as used in China aib-JP ("Ainu of China") as used in Japan ain-CN ("Ainu of Japan") as used in China ain-JP ("Ainu of Japan") as used in Japan Because they are both in such limited use, both by area and by number of speakers, the use of region subtags above would qualify as overkill. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 05:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaqEU-0006Kr-4R; Fri, 20 Oct 2006 05:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaqES-0006GA-57 for ltru@ietf.org; Fri, 20 Oct 2006 05:00:00 -0400 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaqEQ-0002zG-T4 for ltru@ietf.org; Fri, 20 Oct 2006 05:00:00 -0400 Received: (qmail 23586 messnum 11062883 invoked from network[194.125.174.64/ts09-064.dublin.indigo.ie]); 20 Oct 2006 08:59:57 -0000 Received: from ts09-064.dublin.indigo.ie (HELO ?194.125.174.64?) (194.125.174.64) by mail11.svc.cra.dublin.eircom.net (qp 23586) with SMTP; 20 Oct 2006 08:59:57 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <8962EAED2E7543EBA0D4449CD7F9623E.MAI@home> References: <8962EAED2E7543EBA0D4449CD7F9623E.MAI@home> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Descriptions Date: Fri, 20 Oct 2006 10:00:03 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1. mg On 19 Oct 2006, at 20:13, scr=EDobh Debbie Garside: > ...I am just wondering whether it might be an idea to be more =20 > specific with the > "Description" fields. Why not have an "ISO_Description" as well as =20= > any > number of other "Description" fields. Then you can do what you like =20= > with the > other descriptions. Let "what yoiu like" include fixing ISO errors (generally from other =20 sources "snuk" into ISO Standards). mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 05:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaqHD-0003SV-Vp; Fri, 20 Oct 2006 05:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaqHC-0003Rt-LU for ltru@ietf.org; Fri, 20 Oct 2006 05:02:50 -0400 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaqH9-00042m-9V for ltru@ietf.org; Fri, 20 Oct 2006 05:02:50 -0400 Received: (qmail 45545 messnum 2897713 invoked from network[194.125.174.64/ts09-064.dublin.indigo.ie]); 20 Oct 2006 09:02:46 -0000 Received: from ts09-064.dublin.indigo.ie (HELO ?194.125.174.64?) (194.125.174.64) by mail07.svc.cra.dublin.eircom.net (qp 45545) with SMTP; 20 Oct 2006 09:02:46 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <8962EAED2E7543EBA0D4449CD7F9623E.MAI@home> References: <8962EAED2E7543EBA0D4449CD7F9623E.MAI@home> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <707FC1BF-EA5B-48DC-BC52-5E1891707F9C@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Descriptions Date: Fri, 20 Oct 2006 10:03:52 +0000 To: LTRU Working Group X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 19 Oct 2006, at 20:13, scr=EDobh Debbie Garside: > ... I am just wondering whether it might be an idea to be more =20 > specific with the > "Description" fields. Why not have an "ISO_Description" as well as =20= > any > number of other "Description" fields. +1. > Then you can do what you like with the > other descriptions. Such as fixing errors "snuk" into ISO from other sources. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 06:19:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarTC-0004xK-24; Fri, 20 Oct 2006 06:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarTB-0004qe-8E for ltru@lists.ietf.org; Fri, 20 Oct 2006 06:19:17 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GarT9-0000ih-VC for ltru@lists.ietf.org; Fri, 20 Oct 2006 06:19:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0C02726C277 for ; Fri, 20 Oct 2006 12:18:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2D19B26C288 for ; Fri, 20 Oct 2006 12:01:12 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2069958ED0B for ; Fri, 20 Oct 2006 12:01:12 +0200 (CEST) Date: Fri, 20 Oct 2006 12:01:12 +0200 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Message-ID: <20061020100112.GA13376@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.6.17-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Cc: Subject: [Ltru] Archive no longer updated? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org http://www1.ietf.org/mail-archive/web/ltru/current/index.html stops two days ago. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 13:44:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GayPg-0007C0-6o; Fri, 20 Oct 2006 13:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GayPe-0007AR-QR; Fri, 20 Oct 2006 13:44:06 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GayPb-0003O6-Ge; Fri, 20 Oct 2006 13:44:06 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YSrimvihwaDvvxekaPz7CnjBayibftklJLIw75b/u1GSCzwjrxABMdJzqnSFETcs; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.246] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GayPb-0007BV-5m; Fri, 20 Oct 2006 13:44:03 -0400 Message-ID: <000a01c6f470$00e41560$6601a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Fri, 20 Oct 2006 10:48:50 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee65f1f628d70f22048c153404498c33999350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.246 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group Subject: [Ltru] ltru WG archive isn't getting messages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - No messages have appeared in the ltru WG archive since the 18th, despite considerable traffic on the mailing list. I've checked the list adminstrative interface, and didn't notice any obvious problems. Randy ltru co-chair & list admin _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 20 20:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb4pe-0007GP-3Z; Fri, 20 Oct 2006 20:35:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb4pd-0007GK-4X for ltru@ietf.org; Fri, 20 Oct 2006 20:35:21 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb4pb-00040P-Qa for ltru@ietf.org; Fri, 20 Oct 2006 20:35:21 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tchE4DiiFxcyhb532rFiPBlHQYtHSxBdH1XcHwUZK7FHaLzETdEY0skjVngvAH7D; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.211] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gb4pb-0002wq-6z for ltru@ietf.org; Fri, 20 Oct 2006 20:35:19 -0400 Message-ID: <000a01c6f4a9$6cf9d300$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 20 Oct 2006 17:39:46 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6786f9c9653cb54eb5a312d087a93d840350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.211 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ltru] Fw: ltru WG archive isn't getting messages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - The ltru WG archive seems to be up-to-date. Thanks to Stephane for letting us know about the problem, and to Scott for fixing it! Randy ltru co-chair & list admin > From: "Scott Blomquist via RT" > To: > Sent: Friday, October 20, 2006 2:03 PM > Subject: [Inquiry #89184] ltru WG archive isn't getting messages > > > [randy_presuhn@mindspring.com - Fri Oct 20 13:44:08 2006]: > > > > Hi - > > > > No messages have appeared in the ltru WG archive since the 18th, > > despite considerable traffic on the mailing list. I've checked > > the list adminstrative interface, and didn't notice any obvious > > problems. > > > > Randy > > ltru co-chair & list admin > > > > Hi Randy, > > Thanks for the notification the web converter got stuck. I unstuck it. > > Thanks. > > sb. Scott Blomquist _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 06:26:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbE3W-0001y7-LK; Sat, 21 Oct 2006 06:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbE3V-0001w0-Gh for ltru@ietf.org; Sat, 21 Oct 2006 06:26:17 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbE3R-0006N8-KZ for ltru@ietf.org; Sat, 21 Oct 2006 06:26:17 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9LAPxbZ015505 for ; Sat, 21 Oct 2006 19:26:00 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4997_8ba5073c_60ee_11db_97a2_0014221f2a2d; Sat, 21 Oct 2006 19:25:59 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51905) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 21 Oct 2006 19:25:28 +0900 Message-Id: <6.0.0.20.2.20061021102638.092a6a70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 21 Oct 2006 10:27:55 +0900 To: "Mark Davis" , "Kent Karlsson" From: Martin Duerst Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <30b660a20610190906s46dee490s3494706c3cbda463@mail.gmail.co m> References: <30b660a20610151048l2ebdf58dxaac4d0eb3b71f93a@mail.gmail.com> <003d01c6f390$4bd1aaf0$6500a8c0@chalmers95a69n> <30b660a20610190906s46dee490s3494706c3cbda463@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Mark and others that it's a bad idea to let the presence or absence of a script tag indicate the useage of a certain kind of digits. This is not what the script tag was/is intended for, and it's very brittle. Regards, Martin. At 01:06 06/10/20, Mark Davis wrote: >It would be really impractical to depend on any consistent distinction >ever being drawn between th-Thai and th, either as languages or as >locales (in the CLDR sense, which is essentially the same as >language). The only difference would be that in matching, th could >match th-Latn (a romanization), for example. But that is going to be >extremely rare cases. > >Mark > >On 10/19/06, Kent Karlsson wrote: >> >> >> >> >> > >> > > 8. A script subtag SHOULD NOT be used if the content being tagged is >> > > written in the script customarily used for the vast majority of >> > > content in that language (e.g. en-Latn SHOULD NOT be used). >> >> There may be exceptions. While the following is about locale naming rather >> than language tagging (ready-made) text content, those are closely related, >> and a language tag can well be used to select the (almost) same-named >> locale. >> >> While 'th' currently has a Suppress-Script of 'Thai', and would still be >> covered >> by the above "SHOULD" if we remove "Suppress-Script", 'th' and 'th-Thai' >> (or as a locale name 'th_Thai'), in that generated digits (generated from >> some >> computation, or some database access, or similar) may be formatted >> differently >> for presentation: 'th' would imply the use of the digits 0-9 (which I >> understand >> is common in modern Thai), while 'th-Thai' (or rather a 'th_Thai' locale) >> would >> imply that they are presented using the Thai digits (U+0E50-U+0E59). >> >> Similarly, Arabic mixes the use of 0-9 and Arabic-Indic digits, and one may >> want to have separate locales for presenting computed number/date values >> using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). >> >> It would be possible to use variants for this, but that seems needless. Or >> would >> you consider such use as described above of script subtags as inappropriate? >> >> /kent k >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 08:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbFw1-0006jh-1U; Sat, 21 Oct 2006 08:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbFw0-0006jb-4J for ltru@ietf.org; Sat, 21 Oct 2006 08:26:40 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbFvv-00044C-Hy for ltru@ietf.org; Sat, 21 Oct 2006 08:26:40 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:60751 helo=chalmers95a69n) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GbFvd-0003dk-4C; Sat, 21 Oct 2006 14:26:23 +0200 From: "Kent Karlsson" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sat, 21 Oct 2006 14:25:41 +0200 Message-ID: <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <6.0.0.20.2.20061021102638.092a6a70@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GbFvd-0003dk-4C. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1GbFvd-0003dk-4C 701e4bc7542483e5f3e2c3883f158115 X-Spam-Score: 2.3 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org So how would you suggest dealing with the (existing!) locale currently named th_TH_TH if one were to rename it more in the spirit of RFC4646 language tags? Granted, locale names are not necessarily bound by how IETF language tags are formed. Almost all locales in CLDR are named according to IETF language tags, with the exceptions hy_AM_REVISED, aa_ER_SAAHO, and el_POLYTONI, for which I do think variant language subtags would be warranted, en_US_POSIX, and root which are indeed special cases. th_TH_TH isn't a CLDR locale, but I don't want to make another exception for it in naming, CLDR or not. There is still a need to support th_TH_TH (*and* th_TH, but th_TH_TH will likely be more used than th_TH for the applications I have in mind, which use generated digits quite a lot), but I'd rather see its name mapped to something more up-to-date. And I would guess there is a similar need for other languages, Indic ones in particular. As I mentioned, registering a *language* variant subtag for this (digit preference for **generated** decimal digits, not (generated) spellout digits) would be inappropriate, I think (I would not support such a registration, at least). So would using a private use subtag. /kent k > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Saturday, October 21, 2006 3:28 AM > To: Mark Davis; Kent Karlsson > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... > > > I agree with Mark and others that it's a bad idea to let the presence > or absence of a script tag indicate the useage of a certain kind of > digits. This is not what the script tag was/is intended for, and it's > very brittle. > > Regards, Martin. > > At 01:06 06/10/20, Mark Davis wrote: > >It would be really impractical to depend on any consistent > distinction > >ever being drawn between th-Thai and th, either as languages or as > >locales (in the CLDR sense, which is essentially the same as > >language). The only difference would be that in matching, th could > >match th-Latn (a romanization), for example. But that is going to be > >extremely rare cases. > > > >Mark > > > >On 10/19/06, Kent Karlsson wrote: > >> > >> > >> > >> > >> > > >> > > 8. A script subtag SHOULD NOT be used if the content > being tagged is > >> > > written in the script customarily used for the vast majority of > >> > > content in that language (e.g. en-Latn SHOULD NOT be used). > >> > >> There may be exceptions. While the following is about > locale naming rather > >> than language tagging (ready-made) text content, those are > closely related, > >> and a language tag can well be used to select the (almost) > same-named > >> locale. > >> > >> While 'th' currently has a Suppress-Script of 'Thai', and > would still be > >> covered > >> by the above "SHOULD" if we remove "Suppress-Script", 'th' > and 'th-Thai' > >> (or as a locale name 'th_Thai'), in that generated digits > (generated from > >> some > >> computation, or some database access, or similar) may be formatted > >> differently > >> for presentation: 'th' would imply the use of the digits > 0-9 (which I > >> understand > >> is common in modern Thai), while 'th-Thai' (or rather a > 'th_Thai' locale) > >> would > >> imply that they are presented using the Thai digits > (U+0E50-U+0E59). > >> > >> Similarly, Arabic mixes the use of 0-9 and Arabic-Indic > digits, and one may > >> want to have separate locales for presenting computed > number/date values > >> using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). > >> > >> It would be possible to use variants for this, but that > seems needless. Or > >> would > >> you consider such use as described above of script subtags > as inappropriate? > >> > >> /kent k > >> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > >> > >> > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp > mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 11:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbIyb-0003xX-Tf; Sat, 21 Oct 2006 11:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbIya-0003xS-4u for ltru@ietf.org; Sat, 21 Oct 2006 11:41:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbIyX-0005bC-UP for ltru@ietf.org; Sat, 21 Oct 2006 11:41:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GbIyS-0004Le-GB; Sat, 21 Oct 2006 11:41:24 -0400 Date: Sat, 21 Oct 2006 11:41:24 -0400 To: Kent Karlsson Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... Message-ID: <20061021154124.GA17132@ccil.org> References: <6.0.0.20.2.20061021102638.092a6a70@localhost> <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > As I mentioned, registering a *language* variant subtag for > this (digit preference for **generated** decimal digits, not > (generated) spellout digits) would be inappropriate, I think > (I would not support such a registration, at least). I conclude, then, that preferences are not languages, and that this question is simply out of scope for RFC 4646. -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.ccil.org/~cowan but it pours? cowan@ccil.org --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 12:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbJby-0005SP-2t; Sat, 21 Oct 2006 12:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbJbw-0005Px-KD for ltru@ietf.org; Sat, 21 Oct 2006 12:22:12 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbJbv-0002tM-4F for ltru@ietf.org; Sat, 21 Oct 2006 12:22:12 -0400 Received: from [10.72.76.131] (snvvpn2-10-72-76-c131.corp.yahoo.com [10.72.76.131]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9LGLifC067653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Oct 2006 09:21:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=vkYBFo7K85aqaik41p1Pkvn+7iAs7xdTraVxC/7QcWYpaksHPyuOAMVD4VFPN+cm Message-ID: <453A4918.1080905@yahoo-inc.com> Date: Sat, 21 Oct 2006 09:21:44 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kent Karlsson Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... References: <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> In-Reply-To: <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > So how would you suggest dealing with the (existing!) locale > currently named th_TH_TH if one were to rename it more > in the spirit of RFC4646 language tags? The "obvious" first response: this is what private use is for! th-TH-x-{your subtags here} I note that no short identifier is going to be able to manage all of the variations possible *within* a locale. Locales don't provide for every permutation of a user's preferences and shouldn't try to. To indicate digit shaping choices at the locale (or language tag) level strikes me as somewhat overly specific. > > As I mentioned, registering a *language* variant subtag for > this (digit preference for **generated** decimal digits, not > (generated) spellout digits) would be inappropriate, I think > (I would not support such a registration, at least). A case could be made for a language tag "extension" specific to locale identification. This would allow whatever additional stuff necessary to our information systems to be identified without interfering with the language tag proper. Specific variations, such as collation, calendar, and, well, digit shaping, aren't really "locale differences" anyway, they are tailorings within a particular locale. These could be identified in an extension sequence quite comfortably without impinging on the language tag or what I call the "gross locale identifier" (the "th-TH" part). The use of variants in POSIX locales shows the limitations of the tri-partite locale identifier. Variants in particular have a checkered history of being annoying and accumulating junk. Using tailorings is a much more scalable, manageable approach to this problem. *And* is keeps the purity of the language tag/locale identifer! In fact, I'd go so far as to say I'm surprised CLDR hasn't produced an extension for this purpose or that one hasn't been proposed for W3C's LTLI. I think CLDR in particular has stretched about as far as it can against the boundaries of what can be done with variants. Before I pooh-pooh variant registration, I'll point out that it is, in many ways, difficult to divide a locale from a language. The computer generated part of a text is just as much a part of the text as the static strings are. We all look oddly on a sentence that mixes one with another: What's this? en-CH?: "There were 1'347 errors in the last 13,75 seconds." So it is possible that some variations of this nature might merit registration as language tag variants, although, as you say, I'm also pretty sure I can't think of a case where it would be appropriate today and I'm pretty sure I wouldn't support most proposals to try one. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 15:31:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMZO-0004TF-BK; Sat, 21 Oct 2006 15:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMZN-0004Sp-E9 for ltru@ietf.org; Sat, 21 Oct 2006 15:31:45 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbMUi-0004xF-Mt for ltru@ietf.org; Sat, 21 Oct 2006 15:26:58 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:63301 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GbMUg-0006QV-8Y; Sat, 21 Oct 2006 21:26:55 +0200 From: "Kent Karlsson" To: "'Addison Phillips'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sat, 21 Oct 2006 21:26:28 +0200 Message-ID: <002701c6f546$cee1acd0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <453A4918.1080905@yahoo-inc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GbMUg-0006QV-8Y. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GbMUg-0006QV-8Y b0fde81df5ff9dae85fc723f43bc5c0e X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > > So how would you suggest dealing with the (existing!) locale > > currently named th_TH_TH if one were to rename it more > > in the spirit of RFC4646 language tags? > > The "obvious" first response: this is what private use is for! > > th-TH-x-{your subtags here} Definitely not. The use I have in mind is as *public* a use as one can get. > I note that no short identifier is going to be able to manage all of the > variations possible *within* a locale. Locales don't provide for every > permutation of a user's preferences and shouldn't try to. To indicate > digit shaping choices at the locale (or language tag) level strikes me > as somewhat overly specific. Maybe, maybe not. But firstly, those specifying which digit rendering to use will in most cases not be programmers, so a programming API for selecting such options are out of the question. Further, selecting options for this comes very close to selecting another locale. So I'm not surprised that in this case it is currently done by locale selection. > > As I mentioned, registering a *language* variant subtag for > > this (digit preference for **generated** decimal digits, not > > (generated) spellout digits) would be inappropriate, I think > > (I would not support such a registration, at least). > > A case could be made for a language tag "extension" specific to locale > identification. This would allow whatever additional stuff necessary to > our information systems to be identified without interfering with the > language tag proper. Specific variations, such as collation, calendar, > and, well, digit shaping, aren't really "locale differences" anyway, > they are tailorings within a particular locale. These could be > identified in an extension sequence quite comfortably without impinging > on the language tag or what I call the "gross locale identifier" (the > "th-TH" part). In the case of th, the -TH part is really overspecifying. An advantange of th/th-Thai over th/th-, is that adding (the superfluous) TH in the first case makes no real difference (prefix matching), whereas in the second case it comes between the th and the interfering with prefix matching. > In fact, I'd go so far as to say I'm surprised CLDR hasn't produced an > extension for this purpose or that one hasn't been proposed for W3C's > LTLI. I think CLDR in particular has stretched about as far as it can > against the boundaries of what can be done with variants. If the CLDR project or W3C applies for an extension tag for this and similar matters, I would not oppose that. But I still don't find it to be the niftiest of solutions, since an extraneous -TH still interferes with prefix matching. Extended matching isn't necessarily available. /kent k > Before I pooh-pooh variant registration, I'll point out that it is, in > many ways, difficult to divide a locale from a language. The computer > generated part of a text is just as much a part of the text as the > static strings are. We all look oddly on a sentence that > mixes one with another: > > What's this? en-CH?: "There were 1'347 errors in the last > 13,75 seconds." > > So it is possible that some variations of this nature might merit > registration as language tag variants, although, as you say, I'm also > pretty sure I can't think of a case where it would be appropriate today > and I'm pretty sure I wouldn't support most proposals to try one. > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 16:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbNIl-0001y5-Ru; Sat, 21 Oct 2006 16:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbNIl-0001sz-3t for ltru@ietf.org; Sat, 21 Oct 2006 16:18:39 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbN6G-0003uz-Bl for ltru@ietf.org; Sat, 21 Oct 2006 16:05:45 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061021200539.NPWJ9984.mta9.adelphia.net@DGBP7M81> for ; Sat, 21 Oct 2006 16:05:39 -0400 Message-ID: <000901c6f54c$481345a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 21 Oct 2006 13:05:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: Great Script Debate "the Next Generation"... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson wrote: > As I mentioned, registering a *language* variant subtag for this > (digit preference for **generated** decimal digits, not (generated) > spellout digits) would be inappropriate, I think (I would not support > such a registration, at least). So would using a private use subtag. I'd say those mechanisms are quite a bit more appropriate than the REGION subtag for making that distinction. If you were making the argument that Thai as used in Thailand uses one convention for digits whereas Thai as used in some other country uses another convention, then I could see your point. What we are talking about is the decision someone made when naming a locale. If you are not comfortable with using a variant (more analogous to "1901" and "1996" than to the others) or a private-use tag, or even -- God forbid -- an extension RFC, to identify this convention, then I think we will simply have to agree than locales and language tags are not the same thing and cannot always match 1-to-1. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 17:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbOHL-0001if-Ru; Sat, 21 Oct 2006 17:21:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbOHK-0001iX-Ep for ltru@ietf.org; Sat, 21 Oct 2006 17:21:14 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbOHJ-0008Sy-4h for ltru@ietf.org; Sat, 21 Oct 2006 17:21:14 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:61280 helo=chalmers95a69n) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GbOHH-0006dJ-5V; Sat, 21 Oct 2006 23:21:12 +0200 From: "Kent Karlsson" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sat, 21 Oct 2006 23:20:45 +0200 Message-ID: <002b01c6f556$c5e660c0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <000901c6f54c$481345a0$6501a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GbOHH-0006dJ-5V. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1GbOHH-0006dJ-5V efc353a5d4a9263afc41a6a1bfd4b89d X-Spam-Score: 2.3 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > I'd say those mechanisms are quite a bit more appropriate than the > REGION subtag for making that distinction. No, the current name uses the region subtag twice, but I suggested to use the SCRIPT subtag explicitly for making the distinction "th_Thai" vs. "th". > or even -- > God forbid -- an extension RFC, to identify this convention, then I Addison seems to think that extension(s) would be appropriate for this. While I don't find it ideal, its not the worst suggestion regarding this (my nomination for worst suggestion would be the use of private-use subtags for this). /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 21 19:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbQP8-0000Ru-2O; Sat, 21 Oct 2006 19:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbQP6-0000QW-Ru for ltru@ietf.org; Sat, 21 Oct 2006 19:37:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbQP5-0005Ye-Gm for ltru@ietf.org; Sat, 21 Oct 2006 19:37:24 -0400 Received: by wx-out-0506.google.com with SMTP id h30so1442669wxd for ; Sat, 21 Oct 2006 16:37:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=l+ZnSf0qbBr4WCL/vHi5HbVGzeK23jgtOCZoBAdjqhjWNrlW+sXjIMgZ6JIrIWJqr7QgCHRN9x6UyZRoq5oHNEwHweIpRI/aLcL0G1At8eK3VHOLQnc2aj0hgfffcquMd6pyEFJIAhjO+vN/Gdg4UfwKbOoo1+/5Zm0y1hxvoyU= Received: by 10.90.105.20 with SMTP id d20mr1737330agc; Sat, 21 Oct 2006 16:37:21 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sat, 21 Oct 2006 16:37:21 -0700 (PDT) Message-ID: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com> Date: Sat, 21 Oct 2006 16:37:21 -0700 From: "Mark Davis" To: "Kent Karlsson" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <002b01c6f556$c5e660c0$6500a8c0@chalmers95a69n> MIME-Version: 1.0 References: <000901c6f54c$481345a0$6501a8c0@DGBP7M81> <002b01c6f556$c5e660c0$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: bd4a910e4112f76e X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1457896843==" Errors-To: ltru-bounces@ietf.org --===============1457896843== Content-Type: multipart/alternative; boundary="----=_Part_92989_16354810.1161473841154" ------=_Part_92989_16354810.1161473841154 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It makes no sense to try to use the script Thai to distinguish between orthographic variants of Thai that are only different according to whether native digits are used or not. The absence of the script tag clearly does not mean "use latin digits but otherwise not latin characters"). If such a distinction is needed, then the only way to do it with language tags is via a variant or extension. Mark On 10/21/06, Kent Karlsson wrote: > > > Doug Ewell wrote: > > > I'd say those mechanisms are quite a bit more appropriate than the > > REGION subtag for making that distinction. > > No, the current name uses the region subtag twice, but I suggested to use > the SCRIPT subtag explicitly for making the distinction "th_Thai" vs. > "th". > > > or even -- > > God forbid -- an extension RFC, to identify this convention, then I > > Addison seems to think that extension(s) would be appropriate for this. > While I don't find it ideal, its not the worst suggestion regarding this > (my nomination for worst suggestion would be the use of private-use > subtags for this). > > /kent k > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_92989_16354810.1161473841154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline It makes no sense to try to use the script Thai to distinguish between orthographic variants of Thai that are only different according to whether native digits are used or not. The absence of the script tag clearly does not mean "use latin digits but otherwise not latin characters"). If such a distinction is needed, then the only way to do it with language tags is via a variant or extension.

Mark

On 10/21/06, Kent Karlsson <kent.karlsson14@comhem.se> wrote:

Doug Ewell wrote:

> I'd say those mechanisms are quite a bit more appropriate than the
> REGION subtag for making that distinction.

No, the current name uses the region subtag twice, but I suggested to use
the SCRIPT subtag explicitly for making the distinction "th_Thai" vs. "th".

> or even --
> God forbid -- an extension RFC, to identify this convention, then I

Addison seems to think that extension(s) would be appropriate for this.
While I don't find it ideal, its not the worst suggestion regarding this
(my nomination for worst suggestion would be the use of private-use
subtags for this).

                /kent k


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

------=_Part_92989_16354810.1161473841154-- --===============1457896843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1457896843==-- From ltru-bounces@ietf.org Sun Oct 22 00:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbUae-0003RF-PK; Sun, 22 Oct 2006 00:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbUac-0003R6-Tc for ltru@ietf.org; Sun, 22 Oct 2006 00:05:34 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbUab-0003x7-Mr for ltru@ietf.org; Sun, 22 Oct 2006 00:05:34 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GbUab-0001Jc-1Y; Sun, 22 Oct 2006 00:05:33 -0400 Date: Sun, 22 Oct 2006 00:05:33 -0400 To: Mark Davis Subject: Re: [Ltru] Re: Inversions and other problems Message-ID: <20061022040532.GA884@ccil.org> References: <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Now, I am, as I have said many times, not in favor of inversion. But > if we are going to invert, we should make at least *some* effort to > make it work consistently. We aren't the right target for that: the ISO RA/MAs are. > Given *all* the other inversions, it is > not, at least prima facie, absurd to have: [snip] > Guiyang Hmong, Northern > Guiyang Hmong, Southern > Guiyang Hmong, Southwestern Or is it "Hmong, Northern Guiyang" etc.? We don't know and we shouldn't strive to find out. > >Where we have an inverted form we should use it, because it contains > >more information than the uninverted form. Where we have only an > >uninverted form, we must live with it. I stand by what I said. -- What is the sound of Perl? Is it not the John Cowan sound of a [Ww]all that people have stopped cowan@ccil.org banging their head against? --Larry http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 22 01:10:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbVbY-00023V-QZ; Sun, 22 Oct 2006 01:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbVbX-00023Q-QK for ltru@lists.ietf.org; Sun, 22 Oct 2006 01:10:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbVbW-0001yC-H7 for ltru@lists.ietf.org; Sun, 22 Oct 2006 01:10:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbVbR-00035v-5x for ltru@lists.ietf.org; Sun, 22 Oct 2006 07:10:29 +0200 Received: from pd9fba954.dip0.t-ipconnect.de ([217.251.169.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 07:10:29 +0200 Received: from nobody by pd9fba954.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 07:10:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 22 Oct 2006 06:52:04 +0200 Organization: Lines: 17 Message-ID: <453AF8F4.234D@xyzzy.claranet.de> References: <45345D42.342B@xyzzy.claranet.de> <30b660a20610170749k2ea3c02bk8f7058da03f1d9ea@mail.gmail.com> <4534F776.8090306@yahoo-inc.com> <4534FD40.1030704@yahoo-inc.com> <6.0.0.20.2.20061018170124.0adf76d0@localhost> <30b660a20610181848s7c524e15n9bd42d3abaa20924@mail.gmail.com> <20061019133928.GC4622@ccil.org> <30b660a20610190651m590282dai2967385d9c765c62@mail.gmail.com> <20061019141032.GF4622@ccil.org> <30b660a20610191012n3abc4887xee5fb8fe4faaee90@mail.gmail.com> <20061022040532.GA884@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba954.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > We aren't the right target for that: the ISO RA/MAs are. We could collect such questions and submit the collection, and then decide what to do in 4646bis based on the answer. The beautification of descriptions is no showstopper, the RFC 4646 procedure to update descriptions can handle bulk updates - at least in theory. In practice there's a lot of stuff piling up: the script issues, the review issues, the language type/scope issue, some type "C" oddities, now the descriptions, etc. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 22 07:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbbU3-00052T-U0; Sun, 22 Oct 2006 07:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbbU2-00052N-Ip for ltru@ietf.org; Sun, 22 Oct 2006 07:27:14 -0400 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbbU1-0002pC-3g for ltru@ietf.org; Sun, 22 Oct 2006 07:27:14 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:61551 helo=chalmers95a69n) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GbbTy-0004lm-4g; Sun, 22 Oct 2006 13:27:12 +0200 From: "Kent Karlsson" To: "'Mark Davis'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 22 Oct 2006 13:26:34 +0200 Message-ID: <001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GbbTy-0004lm-4g. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1GbbTy-0004lm-4g 8cbb0fb02b6929c2856b96cdd4fd3b33 X-Spam-Score: 2.4 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0320525594==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0320525594== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C6F5DD.B4CD0370" This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C6F5DD.B4CD0370 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mark Davis wrote: It makes no sense to try to use the script Thai to distinguish between = orthographic variants of Thai that are only different according to = whether native digits are used or not. The absence of the script tag = clearly does not mean "use latin digits but otherwise not latin = characters").=20 That holds even more true for using the region tag for making this = distinction. But the difference does have something to do which which = *script* is used... If such a distinction is needed, then the only way to do it with = language tags is via a variant or extension.=20 So it cannot currently be made using registered subtags. =20 /kent k =20 ------=_NextPart_000_001E_01C6F5DD.B4CD0370 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message
Mark Davis wrote:
It makes no sense to try to use the script Thai to distinguish = between=20 orthographic variants of Thai that are only different according to = whether=20 native digits are used or not. The absence of the script tag clearly = does not=20 mean "use latin digits but otherwise not latin characters"). 
That holds even more true for using the region tag for = making this=20 distinction. But the difference does have something to = do which=20 which *script* is used...
 If such a = distinction is=20 needed, then the only way to do it with language tags is via a variant = or=20 extension. 
So it cannot currently be made using registered=20 subtags.
 
       &nbs= p;/kent k
 
------=_NextPart_000_001E_01C6F5DD.B4CD0370-- --===============0320525594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0320525594==-- From ltru-bounces@ietf.org Sun Oct 22 11:53:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbfdB-00013y-IE; Sun, 22 Oct 2006 11:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbfdA-00013t-FB for ltru@ietf.org; Sun, 22 Oct 2006 11:52:56 -0400 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbfd9-0006uS-6x for ltru@ietf.org; Sun, 22 Oct 2006 11:52:56 -0400 Received: by wx-out-0506.google.com with SMTP id h30so1563393wxd for ; Sun, 22 Oct 2006 08:52:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=sLO/1lKFth+zt4zBh70A4D/3xKnVDJJQ6WlWX5wsfBeZ+nYEr0Li/13CRma2X9Em0LsZ0W04/um+f5JgS4uCr5ysi97C6gv+QI0qDdu0J+adBZiYezwyWNr9Ylyp25a6b06YJvQABrv5vDB8PMW9qbvs05q+230piD28c5Opfms= Received: by 10.90.28.12 with SMTP id b12mr1767105agb; Sun, 22 Oct 2006 08:52:54 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 22 Oct 2006 08:52:54 -0700 (PDT) Message-ID: <30b660a20610220852v5bea9ad7xc3987919cb3d59b8@mail.gmail.com> Date: Sun, 22 Oct 2006 08:52:54 -0700 From: "Mark Davis" To: "Kent Karlsson" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n> MIME-Version: 1.0 References: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com> <001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: 7de606991207e483 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1588232472==" Errors-To: ltru-bounces@ietf.org --===============1588232472== Content-Type: multipart/alternative; boundary="----=_Part_95744_32749468.1161532374808" ------=_Part_95744_32749468.1161532374808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline No. Nor can many other choices. That's why systems such as CLDR have additional variants to provide for finer distinctions in the orthography. Mark On 10/22/06, Kent Karlsson wrote: > > Mark Davis wrote: > > It makes no sense to try to use the script Thai to distinguish between > orthographic variants of Thai that are only different according to whether > native digits are used or not. The absence of the script tag clearly does > not mean "use latin digits but otherwise not latin characters"). > > That holds even more true for using the region tag for making this > distinction. But the difference *does* have something to do which which ** > script** is used... > > If such a distinction is needed, then the only way to do it with language > tags is via a variant or extension. > > So it cannot currently be made using registered subtags. > > /kent k > > ------=_Part_95744_32749468.1161532374808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline No. Nor can many other choices. That's why systems such as CLDR have additional variants to provide for finer distinctions in the orthography.

Mark

On 10/22/06, Kent Karlsson <kent.karlsson14@comhem.se> wrote:
Mark Davis wrote:
It makes no sense to try to use the script Thai to distinguish between orthographic variants of Thai that are only different according to whether native digits are used or not. The absence of the script tag clearly does not mean "use latin digits but otherwise not latin characters"). 
That holds even more true for using the region tag for making this distinction. But the difference does have something to do which which *script* is used...
 If such a distinction is needed, then the only way to do it with language tags is via a variant or extension. 
So it cannot currently be made using registered subtags.
 
        /kent k
 

------=_Part_95744_32749468.1161532374808-- --===============1588232472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1588232472==-- From ltru-bounces@ietf.org Sun Oct 22 14:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbhnD-0000zF-Ju; Sun, 22 Oct 2006 14:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbhnC-0000z2-Qi for ltru@ietf.org; Sun, 22 Oct 2006 14:11:26 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbhnB-00064u-6j for ltru@ietf.org; Sun, 22 Oct 2006 14:11:26 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061022181124.VNWP9984.mta9.adelphia.net@DGBP7M81>; Sun, 22 Oct 2006 14:11:24 -0400 Message-ID: <00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com> <001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n> <30b660a20610220852v5bea9ad7xc3987919cb3d59b8@mail.gmail.com> Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 22 Oct 2006 11:11:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Kent Karlsson X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just so I understand the discussion correctly: Are we talking about language tags per se, or are we talking about locale names transformed int olanguage-tag syntax? Language tags will never incorporate all of the distinctions that are made in locales. Look at the locale names that have been invented to identify character set, sort order, euro vs. non-euro, and so forth. CLDR allows for these distinctions because it is a LOCALE data repository, but it should not be inferred that they should necessarily propagate back to language tags. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ----- Original Message ----- From: Mark Davis To: Kent Karlsson Cc: Doug Ewell ; LTRU Working Group Sent: Sunday, October 22, 2006 8:52 Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... No. Nor can many other choices. That's why systems such as CLDR have additional variants to provide for finer distinctions in the orthography. Mark On 10/22/06, Kent Karlsson wrote: Mark Davis wrote: It makes no sense to try to use the script Thai to distinguish between orthographic variants of Thai that are only different according to whether native digits are used or not. The absence of the script tag clearly does not mean "use latin digits but otherwise not latin characters"). That holds even more true for using the region tag for making this distinction. But the difference does have something to do which which *script* is used... If such a distinction is needed, then the only way to do it with language tags is via a variant or extension. So it cannot currently be made using registered subtags. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 22 14:20:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbhw1-00049S-KP; Sun, 22 Oct 2006 14:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbhw0-00048J-Jj for ltru@ietf.org; Sun, 22 Oct 2006 14:20:32 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbhvz-0007SE-91 for ltru@ietf.org; Sun, 22 Oct 2006 14:20:32 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061022182026.ECFN13047.mta13.adelphia.net@DGBP7M81> for ; Sun, 22 Oct 2006 14:20:26 -0400 Message-ID: <00c601c6f606$bfbd9ff0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 22 Oct 2006 11:20:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: Inversions and other problems X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > In practice there's a lot of stuff piling up: the script > issues, the review issues, the language type/scope issue, > some type "C" oddities, now the descriptions, etc. I agree, and feel that the chairs need to assist in sorting out and triaging the various change requests. Many are not in the charter, and some might need to charter to be revised before they can be considered. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 22 15:45:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbjFc-0002GP-ED; Sun, 22 Oct 2006 15:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbjFb-0002FE-5H for ltru@ietf.org; Sun, 22 Oct 2006 15:44:51 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbjFX-0003MF-Hg for ltru@ietf.org; Sun, 22 Oct 2006 15:44:51 -0400 Received: from c83-248-26-17.bredband.comhem.se ([83.248.26.17]:62996 helo=chalmers95a69n) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1GbjFK-0000Ik-8u; Sun, 22 Oct 2006 21:44:35 +0200 From: "Kent Karlsson" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 22 Oct 2006 21:44:02 +0200 Message-ID: <003a01c6f612$6d17fa50$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scan-Result: No virus found in message 1GbjFK-0000Ik-8u. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1GbjFK-0000Ik-8u b66df55ee3864a69907d3831a9e36c31 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Just so I understand the discussion correctly: >=20 > Are we talking about language tags per se, or are we talking about=20 > locale names transformed int olanguage-tag syntax? The difference is quite fuzzy. And indeed W3C's LTLI makes no difference, and CLDR makes very little difference. > Language tags will never incorporate all of the distinctions that are=20 > made in locales. Look at the locale names that have been invented to=20 > identify character set, Has no business in locales. I know that POSIX locales incorporate this rather major design flaw. > sort order, Seems to belong in locales (or rather locale data sets, being selected by locale name). > euro vs. non-euro, Has no business in locales. The unit of a value can never be determined by a locale. I know that there are locale systems that incorporate this major design mistake. No well-written program should ever rely on that part of a locale system that incorporates that. 1$ and 1=C2=A5 are really different, and the unit must be tied to the value *regardless* of locale. TRANSLATING unit names (including currency names) can well be done in locales. > and so forth.=20 Like paper size? Again, that has no business in locales. (Page size a per-printer default, and may be overridden by documents that include a page size, which then even may vary per page.) Like "imperial" vs. SI units? See above re. currency (and other!!) = units. > CLDR allows for these distinctions because it is a LOCALE data=20 > repository, but it should not be inferred that they should=20 > necessarily propagate back to language tags. Most of the variant designations in CLDR do properly belong as language variant subtags (but a registration may change the name used). SAAHO designates a dialect, and LSTR has already dialect variants. I see no immediate reason why SAAHO should not be registered as a variant subtag in LSTR. POLYTONI and REFORMED refers to spell reforms, and LSTR already has spell reform variants. I see no immediate reason why these spell reforms should not be registered in LSTR (under different names). POSIX and "root" are indeed special cases, though I think a private use variant (or indeed an extension variant) should be used for POSIX; but it is indeed a special case. The case of decimal digit script has already been made a locale difference, and I see no particular mistake or special case being warranted for demoting this from being a (properly designed) locale difference. I do think it should be designated by a *language tag* name. Either by using the script subtag as an "emphasis" (which I still find to be the best in the particular case of Thai digit = generation) or by using extension subtags (NOT private use). In this particular case I don't think an ordinary variant should be used, but I'll abide with that if one is registered. Think of web forms. The language tag, and language "negotiation", seems to be an appropriate way of choosing between having number and date fields in Thai digits or in "Latin" digits in an otherwise Thai language form. (Using spellout, and which kind of spellout, seems much less appropriate to select in that way. But I agree that that may be a borderline case, especially for CJK.) /kent k > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages >=20 > ----- Original Message -----=20 > From: Mark Davis > To: Kent Karlsson > Cc: Doug Ewell ; LTRU Working Group > Sent: Sunday, October 22, 2006 8:52 > Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... >=20 >=20 > No. Nor can many other choices. That's why systems such as CLDR have=20 > additional variants to provide for finer distinctions in the=20 > orthography. >=20 > Mark >=20 >=20 > On 10/22/06, Kent Karlsson wrote: > Mark Davis wrote: > It makes no sense to try to use the script Thai to=20 > distinguish between=20 > orthographic variants of Thai that are only different according to=20 > whether native digits are used or not. The absence of the script tag=20 > clearly does not mean "use latin digits but otherwise not latin=20 > characters"). > That holds even more true for using the region tag for making this=20 > distinction. But the difference does have something to do which which=20 > *script* is used... > If such a distinction is needed, then the only way to do it with=20 > language tags is via a variant or extension. > So it cannot currently be made using registered subtags. >=20 > /kent k=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 22 17:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbkwV-0006LP-1W; Sun, 22 Oct 2006 17:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbkwT-0006LK-S1 for ltru@ietf.org; Sun, 22 Oct 2006 17:33:13 -0400 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbkwO-0007b9-9G for ltru@ietf.org; Sun, 22 Oct 2006 17:33:13 -0400 Received: by wx-out-0506.google.com with SMTP id h30so1615704wxd for ; Sun, 22 Oct 2006 14:33:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=o5YcwdiQrOJa65C5OzXAkoU+RTHf3tRP1KvDsFrhbSl24ocBIes/7arxEc6U6YCPVaCYDAb34x9c5tOE/6zYW9ruhFrguE9wHc8YdYLmD3WpRDtVp4m6YOSy784LKS/UQKMGpIBojGBY/qi1K6FGh85THHxgin21ypMcrwzNXok= Received: by 10.90.94.2 with SMTP id r2mr1845215agb; Sun, 22 Oct 2006 14:33:07 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 22 Oct 2006 14:33:07 -0700 (PDT) Message-ID: <30b660a20610221433i3c0f9596yc5b4e4545377c0b@mail.gmail.com> Date: Sun, 22 Oct 2006 14:33:07 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81> MIME-Version: 1.0 References: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com> <001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n> <30b660a20610220852v5bea9ad7xc3987919cb3d59b8@mail.gmail.com> <00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81> X-Google-Sender-Auth: 5f943c13bc8fdc57 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: CLDR list , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238300665==" Errors-To: ltru-bounces@ietf.org --===============0238300665== Content-Type: multipart/alternative; boundary="----=_Part_96964_17641124.1161552787780" ------=_Part_96964_17641124.1161552787780 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I need to correct some core misconceptions. While CLDR has what is called a locale ID, for historical reasons, it really functions (with a couple of exceptions) as a language ID, and accesses language-based data. There used to be some information that was improperly included in the language-based data, like default currency and weekend ranges, but that was removed over time; moved to supplemental files like http://unicode.org/cldr/data/common/supplemental/ (for an HTML view, see http://www.unicode.org/cldr/data/charts/supplemental/index.html). This is not even really "locale" data so much as it is just non-language data. And as to the specific items mentioned, - CLDR locales have never been distinguished by charset: all of the data is in Unicode. (There are tools for generating POSIX charset-specific data, but those are separate.) - Euro vs non-Euro is not part of the language-based data - Sort order is part of the language-based data, and to my mind properly so: sort order is keyed off of language. Now, what are the exceptions I mentioned above? For backwards compatibility, CLDR IDs do permit setting a default calendar, currency, and timezone. All of these are really orthogonal to language-data: - The use of a timezone in a CLDR ID would be a pretty clear case of the use of a CLDR ID as signifying a locale, according to most concepts of what a "locale" means. - The choice of calendar is somewhat fuzzier, but probably would be included in what many people mean by a locale. - A currency is really a property of a transaction, and not really properly part of a locale at all. For ICU, a major implementation using CLDR, these are actually not necessary; there are alternate, preferred mechanisms for dealing with these objects. For example, a Currency is supplied directly to the API that formats a monetary amount. Mark On 10/22/06, Doug Ewell wrote: > > Just so I understand the discussion correctly: > > Are we talking about language tags per se, or are we talking about > locale names transformed int olanguage-tag syntax? > > Language tags will never incorporate all of the distinctions that are > made in locales. Look at the locale names that have been invented to > identify character set, sort order, euro vs. non-euro, and so forth. > CLDR allows for these distinctions because it is a LOCALE data > repository, but it should not be inferred that they should necessarily > propagate back to language tags. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > ----- Original Message ----- > From: Mark Davis > To: Kent Karlsson > Cc: Doug Ewell ; LTRU Working Group > Sent: Sunday, October 22, 2006 8:52 > Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... > > > No. Nor can many other choices. That's why systems such as CLDR have > additional variants to provide for finer distinctions in the > orthography. > > Mark > > > On 10/22/06, Kent Karlsson wrote: > Mark Davis wrote: > It makes no sense to try to use the script Thai to distinguish between > orthographic variants of Thai that are only different according to > whether native digits are used or not. The absence of the script tag > clearly does not mean "use latin digits but otherwise not latin > characters"). > That holds even more true for using the region tag for making this > distinction. But the difference does have something to do which which > *script* is used... > If such a distinction is needed, then the only way to do it with > language tags is via a variant or extension. > So it cannot currently be made using registered subtags. > > /kent k > > ------=_Part_96964_17641124.1161552787780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I need to correct some core misconceptions. While CLDR has what is called a locale ID, for historical reasons, it really functions (with a couple of exceptions) as a language ID, and accesses language-based data. There used to be some information that was improperly included in the language-based data, like default currency and weekend ranges, but that was removed over time; moved to supplemental files like http://unicode.org/cldr/data/common/supplemental/ (for an HTML view, see http://www.unicode.org/cldr/data/charts/supplemental/index.html ). This is not even really "locale" data so much as it is just non-language data.

And as to the specific items mentioned,
  • CLDR locales have never been distinguished by charset: all of the data is in Unicode. (There are tools for generating POSIX charset-specific data, but those are separate.)
  • Euro vs non-Euro is not part of the language-based data
  • Sort order is part of the language-based data, and to my mind properly so: sort order is keyed off of language.
Now, what are the exceptions I mentioned above? For backwards compatibility, CLDR IDs do permit setting a default calendar, currency, and timezone. All of these are really orthogonal to language-data:
  • The use of a timezone in a CLDR ID would be a pretty clear case of the use of a CLDR ID as signifying a locale, according to most concepts of what a "locale" means.
  • The choice of calendar is somewhat fuzzier, but probably would be included in what many people mean by a locale.
  • A currency is really a property of a transaction, and not really properly part of a locale at all.
For ICU, a major implementation using CLDR, these are actually not necessary; there are alternate, preferred mechanisms for dealing with these objects. For example, a Currency is supplied directly to the API that formats a monetary amount.

Mark

On 10/22/06, Doug Ewell < dewell@adelphia.net> wrote:
Just so I understand the discussion correctly:

Are we talking about language tags per se, or are we talking about
locale names transformed int olanguage-tag syntax?

Language tags will never incorporate all of the distinctions that are
made in locales.  Look at the locale names that have been invented to
identify character set, sort order, euro vs. non-euro, and so forth.
CLDR allows for these distinctions because it is a LOCALE data
repository, but it should not be inferred that they should necessarily
propagate back to language tags.

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

----- Original Message -----
From: Mark Davis
To: Kent Karlsson
Cc: Doug Ewell ; LTRU Working Group
Sent: Sunday, October 22, 2006 8:52
Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"...


No. Nor can many other choices. That's why systems such as CLDR have
additional variants to provide for finer distinctions in the
orthography.

Mark


On 10/22/06, Kent Karlsson <kent.karlsson14@comhem.se> wrote:
Mark Davis wrote:
It makes no sense to try to use the script Thai to distinguish between
orthographic variants of Thai that are only different according to
whether native digits are used or not. The absence of the script tag
clearly does not mean "use latin digits but otherwise not latin
characters").
That holds even more true for using the region tag for making this
distinction. But the difference does have something to do which which
*script* is used...
If such a distinction is needed, then the only way to do it with
language tags is via a variant or extension.
So it cannot currently be made using registered subtags.

        /kent k


------=_Part_96964_17641124.1161552787780-- --===============0238300665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0238300665==-- From ltru-bounces@ietf.org Sun Oct 22 18:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GblMP-0004lS-In; Sun, 22 Oct 2006 18:00:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GblLJ-0002Lj-1A for ltru@ietf.org; Sun, 22 Oct 2006 17:58:53 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GblAR-0002DX-3k for ltru@ietf.org; Sun, 22 Oct 2006 17:47:41 -0400 Received: by wx-out-0506.google.com with SMTP id i26so1396183wxd for ; Sun, 22 Oct 2006 14:47:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=l2g44XZcrLjVJ9h0x8TtOe4L69O3Wvv3/06EMrZ/dOco1UwfgUIi1ZBvl3xpULo6fBKkOHnrs/2tmw5Qtic0ezB/Be0g4lGmCtbD48LngVjn6+PLRLEy03F39GfGnXWSGv6aL7IcTSW3/AvCIKGACxNipVmlPfekIB+rGAfi5Q4= Received: by 10.90.71.12 with SMTP id t12mr1899311aga; Sun, 22 Oct 2006 14:47:36 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Sun, 22 Oct 2006 14:47:36 -0700 (PDT) Message-ID: <30b660a20610221447t23c95334v8e411a4d4eb99230@mail.gmail.com> Date: Sun, 22 Oct 2006 14:47:36 -0700 From: "Mark Davis" To: "Kent Karlsson" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: <003a01c6f612$6d17fa50$6500a8c0@chalmers95a69n> MIME-Version: 1.0 References: <00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81> <003a01c6f612$6d17fa50$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: 221d969688808b52 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824477393==" Errors-To: ltru-bounces@ietf.org --===============0824477393== Content-Type: multipart/alternative; boundary="----=_Part_97108_24485273.1161553656637" ------=_Part_97108_24485273.1161553656637 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline V2Ugd291bGQgbGlrZSB0byBub3QgbmVlZCBhbnkgc3BlY2lhbCBDTERSIHZhcmlhbnQgc3VidGFn cy4gV2Ugb25seSBoYXZlIGEKZmV3IChub24tZGVwcmVjYXRlZCBvbmVzKSBpbiBDTERSIDEuNC4K CiAgIC0gaHlfQU1fUkVWSVNFRCB3aWxsIGJlIHJlcGxhY2VkIGJ5IHRoZSByZWNlbnQgdmFyaWFu dHMgZm9yIGFybWVuaWFuCiAgIGFkZGVkIHRvIHRoZSBMVFIuCiAgIC0gYXJfRVJfU0FBSE8gd2ls bCBiZSByZXBsYWNlZCBvbmNlIHdlIGhhdmUgc3N5LgogICAtIGVsX1BPTFlUT05JLiBUaGUgaWRl YWwgcmVzdWx0IGZvciB0aGlzIHdvdWxkIGJlIGluIHRoZSBzY3JpcHQKICAgcG9zaXRpb24sIHNp bmNlIHRoYXQgd2lsbCBmdW5jdGlvbiBiZXR0ZXIuIEJ1dCB0aGUgc2NyaXB0IEpBQywgd2hpbGUg aGFwcHkKICAgdG8gcmVnaXN0ZXIgb3RoZXIgdGhpbmdzIHRoYXQgYXJlbid0IHNjcmlwdHMsIGhh cyByZWplY3RlZCBpdC4gU28gd2UnbGwKICAgcHJvYmFibHkgYXBwbHkgZm9yIGEgcmVnaXN0ZXJl ZCB2YXJpYW50LCBldmVuIHRobycgdGhhdCB3aWxsIGJlIHN1Ym9wdGltYWwKICAgZm9yIHBvbHl0 b25pYyB1c2Vycy4KICAgLSBlbl9VU19QT1NJWC4gVGhpcyBpcyBhIGJpdCB0cmlja3kuIFBPU0lY IGlzIGFuIGFydGlmaWNhbCB2YXJpYW50CiAgIHVzZWQgdG8gZ2V0IHRoZSBkZWZhdWx0ICJDIiBz dHlsZSBmb3IgbnVtYmVycywgZGF0ZXMsIGV0Yy4gSXQnZCBiZSBoYW5keSB0bwogICBnZXQgaXQg cmVnaXN0ZXJlZCwgYnV0IEkgZG91YnQgdGhhdCB0aGVyZSBhcmUgZW5vdWdoIHByYWdtYXRpc3Rz IG9uIHRoZQogICBpZXRmLWxhbmd1YWdlcyBncm91cCB0byBnZXQgaXQgZG9uZS4KCk1hcmsKCk9u IDEwLzIyLzA2LCBLZW50IEthcmxzc29uIDxrZW50Lmthcmxzc29uMTRAY29taGVtLnNlPiB3cm90 ZToKPgo+IERvdWcgRXdlbGwgd3JvdGU6Cj4gPiBKdXN0IHNvIEkgdW5kZXJzdGFuZCB0aGUgZGlz Y3Vzc2lvbiBjb3JyZWN0bHk6Cj4gPgo+ID4gQXJlIHdlIHRhbGtpbmcgYWJvdXQgbGFuZ3VhZ2Ug dGFncyBwZXIgc2UsIG9yIGFyZSB3ZSB0YWxraW5nIGFib3V0Cj4gPiBsb2NhbGUgbmFtZXMgdHJh bnNmb3JtZWQgaW50IG9sYW5ndWFnZS10YWcgc3ludGF4Pwo+Cj4gVGhlIGRpZmZlcmVuY2UgaXMg cXVpdGUgZnV6enkuIEFuZCBpbmRlZWQgVzNDJ3MgTFRMSSBtYWtlcwo+IG5vIGRpZmZlcmVuY2Us IGFuZCBDTERSIG1ha2VzIHZlcnkgbGl0dGxlIGRpZmZlcmVuY2UuCj4KPiA+IExhbmd1YWdlIHRh Z3Mgd2lsbCBuZXZlciBpbmNvcnBvcmF0ZSBhbGwgb2YgdGhlIGRpc3RpbmN0aW9ucyB0aGF0IGFy ZQo+ID4gbWFkZSBpbiBsb2NhbGVzLiAgTG9vayBhdCB0aGUgbG9jYWxlIG5hbWVzIHRoYXQgaGF2 ZSBiZWVuIGludmVudGVkIHRvCj4KPiA+IGlkZW50aWZ5IGNoYXJhY3RlciBzZXQsCj4KPiBIYXMg bm8gYnVzaW5lc3MgaW4gbG9jYWxlcy4gSSBrbm93IHRoYXQgUE9TSVggbG9jYWxlcyBpbmNvcnBv cmF0ZQo+IHRoaXMgcmF0aGVyIG1ham9yIGRlc2lnbiBmbGF3Lgo+Cj4gPiBzb3J0IG9yZGVyLAo+ Cj4gU2VlbXMgdG8gYmVsb25nIGluIGxvY2FsZXMgKG9yIHJhdGhlciBsb2NhbGUgZGF0YSBzZXRz LCBiZWluZwo+IHNlbGVjdGVkIGJ5IGxvY2FsZSBuYW1lKS4KPgo+ID4gZXVybyB2cy4gbm9uLWV1 cm8sCj4KPiBIYXMgbm8gYnVzaW5lc3MgaW4gbG9jYWxlcy4gVGhlIHVuaXQgb2YgYSB2YWx1ZSBj YW4gbmV2ZXIgYmUKPiBkZXRlcm1pbmVkIGJ5IGEgbG9jYWxlLiBJIGtub3cgdGhhdCB0aGVyZSBh cmUgbG9jYWxlIHN5c3RlbXMKPiB0aGF0IGluY29ycG9yYXRlIHRoaXMgbWFqb3IgZGVzaWduIG1p c3Rha2UuIE5vIHdlbGwtd3JpdHRlbgo+IHByb2dyYW0gc2hvdWxkIGV2ZXIgcmVseSBvbiB0aGF0 IHBhcnQgb2YgYSBsb2NhbGUgc3lzdGVtIHRoYXQKPiBpbmNvcnBvcmF0ZXMgdGhhdC4gMSQgYW5k IDHCpSBhcmUgcmVhbGx5IGRpZmZlcmVudCwgYW5kIHRoZSB1bml0Cj4gbXVzdCBiZSB0aWVkIHRv IHRoZSB2YWx1ZSAqcmVnYXJkbGVzcyogb2YgbG9jYWxlLiBUUkFOU0xBVElORwo+IHVuaXQgbmFt ZXMgKGluY2x1ZGluZyBjdXJyZW5jeSBuYW1lcykgY2FuIHdlbGwgYmUgZG9uZSBpbiBsb2NhbGVz Lgo+Cj4gPiBhbmQgc28gZm9ydGguCj4KPiBMaWtlIHBhcGVyIHNpemU/IEFnYWluLCB0aGF0IGhh cyBubyBidXNpbmVzcyBpbiBsb2NhbGVzLiAoUGFnZSBzaXplCj4gYSBwZXItcHJpbnRlciBkZWZh dWx0LCBhbmQgbWF5IGJlIG92ZXJyaWRkZW4gYnkgZG9jdW1lbnRzIHRoYXQKPiBpbmNsdWRlIGEg cGFnZSBzaXplLCB3aGljaCB0aGVuIGV2ZW4gbWF5IHZhcnkgcGVyIHBhZ2UuKQo+Cj4gTGlrZSAi aW1wZXJpYWwiIHZzLiBTSSB1bml0cz8gU2VlIGFib3ZlIHJlLiBjdXJyZW5jeSAoYW5kIG90aGVy ISEpIHVuaXRzLgo+Cj4gPiBDTERSIGFsbG93cyBmb3IgdGhlc2UgZGlzdGluY3Rpb25zIGJlY2F1 c2UgaXQgaXMgYSBMT0NBTEUgZGF0YQo+ID4gcmVwb3NpdG9yeSwgYnV0IGl0IHNob3VsZCBub3Qg YmUgaW5mZXJyZWQgdGhhdCB0aGV5IHNob3VsZAo+ID4gbmVjZXNzYXJpbHkgcHJvcGFnYXRlIGJh Y2sgdG8gbGFuZ3VhZ2UgdGFncy4KPgo+IE1vc3Qgb2YgdGhlIHZhcmlhbnQgZGVzaWduYXRpb25z IGluIENMRFIgZG8gcHJvcGVybHkgYmVsb25nIGFzCj4gbGFuZ3VhZ2UgdmFyaWFudCBzdWJ0YWdz IChidXQgYSByZWdpc3RyYXRpb24gbWF5IGNoYW5nZSB0aGUgbmFtZSB1c2VkKS4KPiBTQUFITyBk ZXNpZ25hdGVzIGEgZGlhbGVjdCwgYW5kIExTVFIgaGFzIGFscmVhZHkgZGlhbGVjdCB2YXJpYW50 cy4KPiBJIHNlZSBubyBpbW1lZGlhdGUgcmVhc29uIHdoeSBTQUFITyBzaG91bGQgbm90IGJlIHJl Z2lzdGVyZWQKPiBhcyBhIHZhcmlhbnQgc3VidGFnIGluIExTVFIuIFBPTFlUT05JIGFuZCBSRUZP Uk1FRCByZWZlcnMgdG8KPiBzcGVsbCByZWZvcm1zLCBhbmQgTFNUUiBhbHJlYWR5IGhhcyBzcGVs bCByZWZvcm0gdmFyaWFudHMuIEkgc2VlIG5vCj4gaW1tZWRpYXRlIHJlYXNvbiB3aHkgdGhlc2Ug c3BlbGwgcmVmb3JtcyBzaG91bGQgbm90IGJlIHJlZ2lzdGVyZWQKPiBpbiBMU1RSICh1bmRlciBk aWZmZXJlbnQgbmFtZXMpLiBQT1NJWCBhbmQgInJvb3QiIGFyZSBpbmRlZWQgc3BlY2lhbAo+IGNh c2VzLCB0aG91Z2ggSSB0aGluayBhIHByaXZhdGUgdXNlIHZhcmlhbnQgKG9yIGluZGVlZCBhbiBl eHRlbnNpb24KPiB2YXJpYW50KSBzaG91bGQgYmUgdXNlZCBmb3IgUE9TSVg7IGJ1dCBpdCBpcyBp bmRlZWQgYSBzcGVjaWFsIGNhc2UuCj4KPiBUaGUgY2FzZSBvZiBkZWNpbWFsIGRpZ2l0IHNjcmlw dCBoYXMgYWxyZWFkeSBiZWVuIG1hZGUgYSBsb2NhbGUKPiBkaWZmZXJlbmNlLCBhbmQgSSBzZWUg bm8gcGFydGljdWxhciBtaXN0YWtlIG9yIHNwZWNpYWwgY2FzZSBiZWluZwo+IHdhcnJhbnRlZCBm b3IgZGVtb3RpbmcgdGhpcyBmcm9tIGJlaW5nIGEgKHByb3Blcmx5IGRlc2lnbmVkKSBsb2NhbGUK PiBkaWZmZXJlbmNlLiBJIGRvIHRoaW5rIGl0IHNob3VsZCBiZSBkZXNpZ25hdGVkIGJ5IGEgKmxh bmd1YWdlIHRhZyoKPiBuYW1lLiBFaXRoZXIgYnkgdXNpbmcgdGhlIHNjcmlwdCBzdWJ0YWcgYXMg YW4gImVtcGhhc2lzIiAod2hpY2ggSQo+IHN0aWxsIGZpbmQgdG8gYmUgdGhlIGJlc3QgaW4gdGhl IHBhcnRpY3VsYXIgY2FzZSBvZiBUaGFpIGRpZ2l0IGdlbmVyYXRpb24pCj4gb3IgYnkgdXNpbmcg ZXh0ZW5zaW9uIHN1YnRhZ3MgKE5PVCBwcml2YXRlIHVzZSkuIEluIHRoaXMgcGFydGljdWxhcgo+ IGNhc2UgSSBkb24ndCB0aGluayBhbiBvcmRpbmFyeSB2YXJpYW50IHNob3VsZCBiZSB1c2VkLCBi dXQgSSdsbCBhYmlkZQo+IHdpdGggdGhhdCBpZiBvbmUgaXMgcmVnaXN0ZXJlZC4KPgo+IFRoaW5r IG9mIHdlYiBmb3Jtcy4gVGhlIGxhbmd1YWdlIHRhZywgYW5kIGxhbmd1YWdlICJuZWdvdGlhdGlv biIsCj4gc2VlbXMgdG8gYmUgYW4gYXBwcm9wcmlhdGUgd2F5IG9mIGNob29zaW5nIGJldHdlZW4g aGF2aW5nIG51bWJlcgo+IGFuZCBkYXRlIGZpZWxkcyBpbiBUaGFpIGRpZ2l0cyBvciBpbiAiTGF0 aW4iIGRpZ2l0cyBpbiBhbiBvdGhlcndpc2UKPiBUaGFpIGxhbmd1YWdlIGZvcm0uIChVc2luZyBz cGVsbG91dCwgYW5kIHdoaWNoIGtpbmQgb2Ygc3BlbGxvdXQsCj4gc2VlbXMgbXVjaCBsZXNzIGFw cHJvcHJpYXRlIHRvIHNlbGVjdCBpbiB0aGF0IHdheS4gQnV0IEkgYWdyZWUgdGhhdAo+IHRoYXQg bWF5IGJlIGEgYm9yZGVybGluZSBjYXNlLCBlc3BlY2lhbGx5IGZvciBDSksuKQo+Cj4gICAgICAg ICAva2VudCBrCj4KPiA+IC0tCj4gPiBEb3VnIEV3ZWxsICAqICBGdWxsZXJ0b24sIENhbGlmb3Ju aWEsIFVTQSAgKiAgUkZDIDQ2NDUgICogIFVUTiAjMTQKPiA+IGh0dHA6Ly91c2Vycy5hZGVscGhp YS5uZXQvfmRld2VsbC8KPiA+IGh0dHA6Ly93d3cxLmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbHRy dS1jaGFydGVyLmh0bWwKPiA+IGh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3Rp bmZvL2lldGYtbGFuZ3VhZ2VzCj4gPgo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ ID4gRnJvbTogTWFyayBEYXZpcwo+ID4gVG86IEtlbnQgS2FybHNzb24KPiA+IENjOiBEb3VnIEV3 ZWxsIDsgTFRSVSBXb3JraW5nIEdyb3VwCj4gPiBTZW50OiBTdW5kYXksIE9jdG9iZXIgMjIsIDIw MDYgODo1Mgo+ID4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogR3JlYXQgU2NyaXB0IERlYmF0ZSAi dGhlIE5leHQgR2VuZXJhdGlvbiIuLi4KPiA+Cj4gPgo+ID4gTm8uIE5vciBjYW4gbWFueSBvdGhl ciBjaG9pY2VzLiBUaGF0J3Mgd2h5IHN5c3RlbXMgc3VjaCBhcyBDTERSIGhhdmUKPiA+IGFkZGl0 aW9uYWwgdmFyaWFudHMgdG8gcHJvdmlkZSBmb3IgZmluZXIgZGlzdGluY3Rpb25zIGluIHRoZQo+ ID4gb3J0aG9ncmFwaHkuCj4gPgo+ID4gTWFyawo+ID4KPiA+Cj4gPiBPbiAxMC8yMi8wNiwgS2Vu dCBLYXJsc3NvbiA8a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZT4gd3JvdGU6Cj4gPiBNYXJrIERh dmlzIHdyb3RlOgo+ID4gSXQgbWFrZXMgbm8gc2Vuc2UgdG8gdHJ5IHRvIHVzZSB0aGUgc2NyaXB0 IFRoYWkgdG8KPiA+IGRpc3Rpbmd1aXNoIGJldHdlZW4KPiA+IG9ydGhvZ3JhcGhpYyB2YXJpYW50 cyBvZiBUaGFpIHRoYXQgYXJlIG9ubHkgZGlmZmVyZW50IGFjY29yZGluZyB0bwo+ID4gd2hldGhl ciBuYXRpdmUgZGlnaXRzIGFyZSB1c2VkIG9yIG5vdC4gVGhlIGFic2VuY2Ugb2YgdGhlIHNjcmlw dCB0YWcKPiA+IGNsZWFybHkgZG9lcyBub3QgbWVhbiAidXNlIGxhdGluIGRpZ2l0cyBidXQgb3Ro ZXJ3aXNlIG5vdCBsYXRpbgo+ID4gY2hhcmFjdGVycyIpLgo+ID4gVGhhdCBob2xkcyBldmVuIG1v cmUgdHJ1ZSBmb3IgdXNpbmcgdGhlIHJlZ2lvbiB0YWcgZm9yIG1ha2luZyB0aGlzCj4gPiBkaXN0 aW5jdGlvbi4gQnV0IHRoZSBkaWZmZXJlbmNlIGRvZXMgaGF2ZSBzb21ldGhpbmcgdG8gZG8gd2hp Y2ggd2hpY2gKPiA+ICpzY3JpcHQqIGlzIHVzZWQuLi4KPiA+ICBJZiBzdWNoIGEgZGlzdGluY3Rp b24gaXMgbmVlZGVkLCB0aGVuIHRoZSBvbmx5IHdheSB0byBkbyBpdCB3aXRoCj4gPiBsYW5ndWFn ZSB0YWdzIGlzIHZpYSBhIHZhcmlhbnQgb3IgZXh0ZW5zaW9uLgo+ID4gU28gaXQgY2Fubm90IGN1 cnJlbnRseSBiZSBtYWRlIHVzaW5nIHJlZ2lzdGVyZWQgc3VidGFncy4KPiA+Cj4gPiAgICAgICAg IC9rZW50IGsKPiA+Cj4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KPiA+IEx0cnUgbWFpbGluZyBsaXN0Cj4gPiBMdHJ1QGlldGYub3JnCj4gPiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4gPgo+Cj4KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEx0cnUgbWFpbGlu ZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2x0cnUKPgo= ------=_Part_97108_24485273.1161553656637 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PHNwYW4+V2Ugd291bGQgbGlrZSB0byBub3QgbmVlZCBhbnkgc3BlY2lhbCBDTERSIHZhcmlhbnQg c3VidGFncy4gV2Ugb25seSBoYXZlIGEgZmV3IChub24tZGVwcmVjYXRlZCBvbmVzKSBpbiBDTERS IDEuNC48YnI+PC9zcGFuPjx1bD48bGk+PHNwYW4+aHlfQU1fUkVWSVNFRCB3aWxsIGJlIHJlcGxh Y2VkIGJ5IHRoZSByZWNlbnQgdmFyaWFudHMgZm9yIGFybWVuaWFuIGFkZGVkIHRvIHRoZSBMVFIu Cjwvc3Bhbj48L2xpPjxsaT48c3Bhbj5hcl9FUl9TQUFITyB3aWxsIGJlIHJlcGxhY2VkIG9uY2Ug d2UgaGF2ZSBzc3kuPC9zcGFuPjwvbGk+PGxpPjxzcGFuPmVsX1BPTFlUT05JLiBUaGUgaWRlYWwg cmVzdWx0IGZvciB0aGlzIHdvdWxkIGJlIGluIHRoZSBzY3JpcHQgcG9zaXRpb24sIHNpbmNlIHRo YXQgd2lsbCBmdW5jdGlvbiBiZXR0ZXIuIEJ1dCB0aGUgc2NyaXB0IEpBQywgd2hpbGUgaGFwcHkg dG8gcmVnaXN0ZXIgb3RoZXIgdGhpbmdzIHRoYXQgYXJlbid0IHNjcmlwdHMsIGhhcyByZWplY3Rl ZCBpdC4gU28gd2UnbGwgcHJvYmFibHkgYXBwbHkgZm9yIGEgcmVnaXN0ZXJlZCB2YXJpYW50LCBl dmVuIHRobycgdGhhdCB3aWxsIGJlIHN1Ym9wdGltYWwgZm9yIHBvbHl0b25pYyB1c2Vycy4KPC9z cGFuPjwvbGk+PGxpPjxzcGFuPmVuX1VTX1BPU0lYLiA8L3NwYW4+PHNwYW4+VGhpcyBpcyBhIGJp dCB0cmlja3kuIFBPU0lYIGlzIGFuIGFydGlmaWNhbCB2YXJpYW50IHVzZWQgdG8gZ2V0IHRoZSBk ZWZhdWx0ICZxdW90O0MmcXVvdDsgc3R5bGUgZm9yIG51bWJlcnMsIGRhdGVzLCBldGMuIEl0J2Qg YmUgaGFuZHkgdG8gZ2V0IGl0IHJlZ2lzdGVyZWQsIGJ1dCBJIGRvdWJ0IHRoYXQgdGhlcmUgYXJl IGVub3VnaCBwcmFnbWF0aXN0cyBvbiB0aGUgaWV0Zi1sYW5ndWFnZXMgZ3JvdXAgdG8gZ2V0IGl0 IGRvbmUuCjxicj48L3NwYW4+PC9saT48L3VsPjxzcGFuPjwvc3Bhbj48c3Bhbj5NYXJrPGJyPjxi cj5PbiAxMC8yMi8wNiwgS2VudCBLYXJsc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQua2Fy bHNzb24xNEBjb21oZW0uc2UiPmtlbnQua2FybHNzb24xNEBjb21oZW0uc2U8L2E+Jmd0OyB3cm90 ZTo8YnI+Jmd0OyA8YnI+Jmd0OyBEb3VnIEV3ZWxsIHdyb3RlOjxicj4mZ3Q7ICZndDsgSnVzdCBz byBJIHVuZGVyc3RhbmQgdGhlIGRpc2N1c3Npb24gY29ycmVjdGx5Ogo8YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgJmd0OyBBcmUgd2UgdGFsa2luZyBhYm91dCBsYW5ndWFnZSB0YWdzIHBlciBzZSwgb3Ig YXJlIHdlIHRhbGtpbmcgYWJvdXQ8YnI+Jmd0OyAmZ3Q7IGxvY2FsZSBuYW1lcyB0cmFuc2Zvcm1l ZCBpbnQgb2xhbmd1YWdlLXRhZyBzeW50YXg/PGJyPiZndDsgPGJyPiZndDsgVGhlIGRpZmZlcmVu Y2UgaXMgcXVpdGUgZnV6enkuIEFuZCBpbmRlZWQgVzNDJ3MgTFRMSSBtYWtlcwo8YnI+Jmd0OyBu byBkaWZmZXJlbmNlLCBhbmQgQ0xEUiBtYWtlcyB2ZXJ5IGxpdHRsZSBkaWZmZXJlbmNlLjxicj4m Z3Q7IDxicj4mZ3Q7ICZndDsgTGFuZ3VhZ2UgdGFncyB3aWxsIG5ldmVyIGluY29ycG9yYXRlIGFs bCBvZiB0aGUgZGlzdGluY3Rpb25zIHRoYXQgYXJlPGJyPiZndDsgJmd0OyBtYWRlIGluIGxvY2Fs ZXMuJm5ic3A7Jm5ic3A7TG9vayBhdCB0aGUgbG9jYWxlIG5hbWVzIHRoYXQgaGF2ZSBiZWVuIGlu dmVudGVkIHRvCjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgaWRlbnRpZnkgY2hhcmFjdGVyIHNldCw8 YnI+Jmd0OyA8YnI+Jmd0OyBIYXMgbm8gYnVzaW5lc3MgaW4gbG9jYWxlcy4gSSBrbm93IHRoYXQg UE9TSVggbG9jYWxlcyBpbmNvcnBvcmF0ZTxicj4mZ3Q7IHRoaXMgcmF0aGVyIG1ham9yIGRlc2ln biBmbGF3Ljxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgc29ydCBvcmRlciw8YnI+Jmd0OyA8YnI+Jmd0 OyBTZWVtcyB0byBiZWxvbmcgaW4gbG9jYWxlcyAob3IgcmF0aGVyIGxvY2FsZSBkYXRhIHNldHMs IGJlaW5nCjxicj4mZ3Q7IHNlbGVjdGVkIGJ5IGxvY2FsZSBuYW1lKS48YnI+Jmd0OyA8YnI+Jmd0 OyAmZ3Q7IGV1cm8gdnMuIG5vbi1ldXJvLDxicj4mZ3Q7IDxicj4mZ3Q7IEhhcyBubyBidXNpbmVz cyBpbiBsb2NhbGVzLiBUaGUgdW5pdCBvZiBhIHZhbHVlIGNhbiBuZXZlciBiZTxicj4mZ3Q7IGRl dGVybWluZWQgYnkgYSBsb2NhbGUuIEkga25vdyB0aGF0IHRoZXJlIGFyZSBsb2NhbGUgc3lzdGVt cwo8YnI+Jmd0OyB0aGF0IGluY29ycG9yYXRlIHRoaXMgbWFqb3IgZGVzaWduIG1pc3Rha2UuIE5v IHdlbGwtd3JpdHRlbjxicj4mZ3Q7IHByb2dyYW0gc2hvdWxkIGV2ZXIgcmVseSBvbiB0aGF0IHBh cnQgb2YgYSBsb2NhbGUgc3lzdGVtIHRoYXQ8YnI+Jmd0OyBpbmNvcnBvcmF0ZXMgdGhhdC4gMSQg YW5kIDHCpSBhcmUgcmVhbGx5IGRpZmZlcmVudCwgYW5kIHRoZSB1bml0PGJyPiZndDsgbXVzdCBi ZSB0aWVkIHRvIHRoZSB2YWx1ZSAqcmVnYXJkbGVzcyogb2YgbG9jYWxlLiBUUkFOU0xBVElORwo8 YnI+Jmd0OyB1bml0IG5hbWVzIChpbmNsdWRpbmcgY3VycmVuY3kgbmFtZXMpIGNhbiB3ZWxsIGJl IGRvbmUgaW4gbG9jYWxlcy48YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7IGFuZCBzbyBmb3J0aC48YnI+ Jmd0OyA8YnI+Jmd0OyBMaWtlIHBhcGVyIHNpemU/IEFnYWluLCB0aGF0IGhhcyBubyBidXNpbmVz cyBpbiBsb2NhbGVzLiAoUGFnZSBzaXplPGJyPiZndDsgYSBwZXItcHJpbnRlciBkZWZhdWx0LCBh bmQgbWF5IGJlIG92ZXJyaWRkZW4gYnkgZG9jdW1lbnRzIHRoYXQKPGJyPiZndDsgaW5jbHVkZSBh IHBhZ2Ugc2l6ZSwgd2hpY2ggdGhlbiBldmVuIG1heSB2YXJ5IHBlciBwYWdlLik8YnI+Jmd0OyA8 YnI+Jmd0OyBMaWtlICZxdW90O2ltcGVyaWFsJnF1b3Q7IHZzLiBTSSB1bml0cz8gU2VlIGFib3Zl IHJlLiBjdXJyZW5jeSAoYW5kIG90aGVyISEpIHVuaXRzLjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsg Q0xEUiBhbGxvd3MgZm9yIHRoZXNlIGRpc3RpbmN0aW9ucyBiZWNhdXNlIGl0IGlzIGEgTE9DQUxF IGRhdGEKPGJyPiZndDsgJmd0OyByZXBvc2l0b3J5LCBidXQgaXQgc2hvdWxkIG5vdCBiZSBpbmZl cnJlZCB0aGF0IHRoZXkgc2hvdWxkPGJyPiZndDsgJmd0OyBuZWNlc3NhcmlseSBwcm9wYWdhdGUg YmFjayB0byBsYW5ndWFnZSB0YWdzLjxicj4mZ3Q7IDxicj4mZ3Q7IE1vc3Qgb2YgdGhlIHZhcmlh bnQgZGVzaWduYXRpb25zIGluIENMRFIgZG8gcHJvcGVybHkgYmVsb25nIGFzPGJyPiZndDsgbGFu Z3VhZ2UgdmFyaWFudCBzdWJ0YWdzIChidXQgYSByZWdpc3RyYXRpb24gbWF5IGNoYW5nZSB0aGUg bmFtZSB1c2VkKS4KPGJyPiZndDsgU0FBSE8gZGVzaWduYXRlcyBhIGRpYWxlY3QsIGFuZCBMU1RS IGhhcyBhbHJlYWR5IGRpYWxlY3QgdmFyaWFudHMuPGJyPiZndDsgSSBzZWUgbm8gaW1tZWRpYXRl IHJlYXNvbiB3aHkgU0FBSE8gc2hvdWxkIG5vdCBiZSByZWdpc3RlcmVkPGJyPiZndDsgYXMgYSB2 YXJpYW50IHN1YnRhZyBpbiBMU1RSLiBQT0xZVE9OSSBhbmQgUkVGT1JNRUQgcmVmZXJzIHRvPGJy PiZndDsgc3BlbGwgcmVmb3JtcywgYW5kIExTVFIgYWxyZWFkeSBoYXMgc3BlbGwgcmVmb3JtIHZh cmlhbnRzLiBJIHNlZSBubwo8YnI+Jmd0OyBpbW1lZGlhdGUgcmVhc29uIHdoeSB0aGVzZSBzcGVs bCByZWZvcm1zIHNob3VsZCBub3QgYmUgcmVnaXN0ZXJlZDxicj4mZ3Q7IGluIExTVFIgKHVuZGVy IGRpZmZlcmVudCBuYW1lcykuIFBPU0lYIGFuZCAmcXVvdDtyb290JnF1b3Q7IGFyZSBpbmRlZWQg c3BlY2lhbDxicj4mZ3Q7IGNhc2VzLCB0aG91Z2ggSSB0aGluayBhIHByaXZhdGUgdXNlIHZhcmlh bnQgKG9yIGluZGVlZCBhbiBleHRlbnNpb24KPGJyPiZndDsgdmFyaWFudCkgc2hvdWxkIGJlIHVz ZWQgZm9yIFBPU0lYOyBidXQgaXQgaXMgaW5kZWVkIGEgc3BlY2lhbCBjYXNlLjxicj4mZ3Q7IDxi cj4mZ3Q7IFRoZSBjYXNlIG9mIGRlY2ltYWwgZGlnaXQgc2NyaXB0IGhhcyBhbHJlYWR5IGJlZW4g bWFkZSBhIGxvY2FsZTxicj4mZ3Q7IGRpZmZlcmVuY2UsIGFuZCBJIHNlZSBubyBwYXJ0aWN1bGFy IG1pc3Rha2Ugb3Igc3BlY2lhbCBjYXNlIGJlaW5nCjxicj4mZ3Q7IHdhcnJhbnRlZCBmb3IgZGVt b3RpbmcgdGhpcyBmcm9tIGJlaW5nIGEgKHByb3Blcmx5IGRlc2lnbmVkKSBsb2NhbGU8YnI+Jmd0 OyBkaWZmZXJlbmNlLiBJIGRvIHRoaW5rIGl0IHNob3VsZCBiZSBkZXNpZ25hdGVkIGJ5IGEgKmxh bmd1YWdlIHRhZyo8YnI+Jmd0OyBuYW1lLiBFaXRoZXIgYnkgdXNpbmcgdGhlIHNjcmlwdCBzdWJ0 YWcgYXMgYW4gJnF1b3Q7ZW1waGFzaXMmcXVvdDsgKHdoaWNoIEkKPGJyPiZndDsgc3RpbGwgZmlu ZCB0byBiZSB0aGUgYmVzdCBpbiB0aGUgcGFydGljdWxhciBjYXNlIG9mIFRoYWkgZGlnaXQgZ2Vu ZXJhdGlvbik8YnI+Jmd0OyBvciBieSB1c2luZyBleHRlbnNpb24gc3VidGFncyAoTk9UIHByaXZh dGUgdXNlKS4gSW4gdGhpcyBwYXJ0aWN1bGFyPGJyPiZndDsgY2FzZSBJIGRvbid0IHRoaW5rIGFu IG9yZGluYXJ5IHZhcmlhbnQgc2hvdWxkIGJlIHVzZWQsIGJ1dCBJJ2xsIGFiaWRlCjxicj4mZ3Q7 IHdpdGggdGhhdCBpZiBvbmUgaXMgcmVnaXN0ZXJlZC48YnI+Jmd0OyA8YnI+Jmd0OyBUaGluayBv ZiB3ZWIgZm9ybXMuIFRoZSBsYW5ndWFnZSB0YWcsIGFuZCBsYW5ndWFnZSAmcXVvdDtuZWdvdGlh dGlvbiZxdW90Oyw8YnI+Jmd0OyBzZWVtcyB0byBiZSBhbiBhcHByb3ByaWF0ZSB3YXkgb2YgY2hv b3NpbmcgYmV0d2VlbiBoYXZpbmcgbnVtYmVyPGJyPiZndDsgYW5kIGRhdGUgZmllbGRzIGluIFRo YWkgZGlnaXRzIG9yIGluICZxdW90O0xhdGluJnF1b3Q7IGRpZ2l0cyBpbiBhbiBvdGhlcndpc2UK PGJyPiZndDsgVGhhaSBsYW5ndWFnZSBmb3JtLiAoVXNpbmcgc3BlbGxvdXQsIGFuZCB3aGljaCBr aW5kIG9mIHNwZWxsb3V0LDxicj4mZ3Q7IHNlZW1zIG11Y2ggbGVzcyBhcHByb3ByaWF0ZSB0byBz ZWxlY3QgaW4gdGhhdCB3YXkuIEJ1dCBJIGFncmVlIHRoYXQ8YnI+Jmd0OyB0aGF0IG1heSBiZSBh IGJvcmRlcmxpbmUgY2FzZSwgZXNwZWNpYWxseSBmb3IgQ0pLLik8YnI+Jmd0OyA8YnI+CiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2tlbnQgazxi cj4mZ3Q7IDxicj4mZ3Q7ICZndDsgLS08YnI+Jmd0OyAmZ3Q7IERvdWcgRXdlbGwmbmJzcDsmbmJz cDsqJm5ic3A7Jm5ic3A7RnVsbGVydG9uLCBDYWxpZm9ybmlhLCBVU0EmbmJzcDsmbmJzcDsqJm5i c3A7Jm5ic3A7UkZDIDQ2NDUmbmJzcDsmbmJzcDsqJm5ic3A7Jm5ic3A7VVROICMxNDxicj4mZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLyI+aHR0cDov L3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLzwvYT4KPGJyPiZndDsgJmd0OyA8YSBocmVmPSJo dHRwOi8vd3d3MS5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sIj5odHRw Oi8vd3d3MS5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sPC9hPjxicj4m Z3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGlu Zm8vaWV0Zi1sYW5ndWFnZXMiPmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3Rp bmZvL2lldGYtbGFuZ3VhZ2VzCjwvYT48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyBGcm9tOiBNYXJrIERhdmlzPGJyPiZn dDsgJmd0OyBUbzogS2VudCBLYXJsc3Nvbjxicj4mZ3Q7ICZndDsgQ2M6IERvdWcgRXdlbGwgOyBM VFJVIFdvcmtpbmcgR3JvdXA8YnI+Jmd0OyAmZ3Q7IFNlbnQ6IFN1bmRheSwgT2N0b2JlciAyMiwg MjAwNiA4OjUyPGJyPgomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogR3JlYXQgU2Ny aXB0IERlYmF0ZSAmcXVvdDt0aGUgTmV4dCBHZW5lcmF0aW9uJnF1b3Q7Li4uPGJyPiZndDsgJmd0 Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IE5vLiBOb3IgY2FuIG1hbnkgb3RoZXIgY2hvaWNl cy4gVGhhdCdzIHdoeSBzeXN0ZW1zIHN1Y2ggYXMgQ0xEUiBoYXZlPGJyPiZndDsgJmd0OyBhZGRp dGlvbmFsIHZhcmlhbnRzIHRvIHByb3ZpZGUgZm9yIGZpbmVyIGRpc3RpbmN0aW9ucyBpbiB0aGUK PGJyPiZndDsgJmd0OyBvcnRob2dyYXBoeS48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBNYXJr PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IE9uIDEwLzIyLzA2LCBLZW50 IEthcmxzc29uICZsdDs8YSBocmVmPSJtYWlsdG86a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZSI+ a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZTwvYT4mZ3Q7IHdyb3RlOjxicj4mZ3Q7ICZndDsgTWFy ayBEYXZpcyB3cm90ZToKPGJyPiZndDsgJmd0OyBJdCBtYWtlcyBubyBzZW5zZSB0byB0cnkgdG8g dXNlIHRoZSBzY3JpcHQgVGhhaSB0bzxicj4mZ3Q7ICZndDsgZGlzdGluZ3Vpc2ggYmV0d2Vlbjxi cj4mZ3Q7ICZndDsgb3J0aG9ncmFwaGljIHZhcmlhbnRzIG9mIFRoYWkgdGhhdCBhcmUgb25seSBk aWZmZXJlbnQgYWNjb3JkaW5nIHRvPGJyPiZndDsgJmd0OyB3aGV0aGVyIG5hdGl2ZSBkaWdpdHMg YXJlIHVzZWQgb3Igbm90LiBUaGUgYWJzZW5jZSBvZiB0aGUgc2NyaXB0IHRhZwo8YnI+Jmd0OyAm Z3Q7IGNsZWFybHkgZG9lcyBub3QgbWVhbiAmcXVvdDt1c2UgbGF0aW4gZGlnaXRzIGJ1dCBvdGhl cndpc2Ugbm90IGxhdGluPGJyPiZndDsgJmd0OyBjaGFyYWN0ZXJzJnF1b3Q7KS48YnI+Jmd0OyAm Z3Q7IFRoYXQgaG9sZHMgZXZlbiBtb3JlIHRydWUgZm9yIHVzaW5nIHRoZSByZWdpb24gdGFnIGZv ciBtYWtpbmcgdGhpczxicj4mZ3Q7ICZndDsgZGlzdGluY3Rpb24uIEJ1dCB0aGUgZGlmZmVyZW5j ZSBkb2VzIGhhdmUgc29tZXRoaW5nIHRvIGRvIHdoaWNoIHdoaWNoCjxicj4mZ3Q7ICZndDsgKnNj cmlwdCogaXMgdXNlZC4uLjxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDtJZiBzdWNoIGEgZGlzdGlu Y3Rpb24gaXMgbmVlZGVkLCB0aGVuIHRoZSBvbmx5IHdheSB0byBkbyBpdCB3aXRoPGJyPiZndDsg Jmd0OyBsYW5ndWFnZSB0YWdzIGlzIHZpYSBhIHZhcmlhbnQgb3IgZXh0ZW5zaW9uLjxicj4mZ3Q7 ICZndDsgU28gaXQgY2Fubm90IGN1cnJlbnRseSBiZSBtYWRlIHVzaW5nIHJlZ2lzdGVyZWQgc3Vi dGFncy4KPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL2tlbnQgazxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 PGJyPiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4mZ3Q7ICZndDsgTHRydSBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPgo8YnI+Jmd0OyAmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUiPmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPiZndDsgJmd0Ozxi cj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsgTHRydSBtYWlsaW5nIGxpc3QKPGJyPiZndDsgPGEgaHJl Zj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+PGJyPiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSI+aHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48YnI+Jmd0OyA8YnI+PGJyPjwv c3Bhbj4K ------=_Part_97108_24485273.1161553656637-- --===============0824477393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0824477393==-- From ltru-bounces@ietf.org Sun Oct 22 20:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbo2T-0001N9-Te; Sun, 22 Oct 2006 20:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbo2S-0001My-FE for ltru@ietf.org; Sun, 22 Oct 2006 20:51:36 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbo2R-0002hd-4D for ltru@ietf.org; Sun, 22 Oct 2006 20:51:36 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061023005130.TUDE13047.mta13.adelphia.net@DGBP7M81>; Sun, 22 Oct 2006 20:51:30 -0400 Message-ID: <00df01c6f63d$61eedd80$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , "CLDR list" References: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com> <001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n> <30b660a20610220852v5bea9ad7xc3987919cb3d59b8@mail.gmail.com> <00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81> <30b660a20610221433i3c0f9596yc5b4e4545377c0b@mail.gmail.com> Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 22 Oct 2006 17:51:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > I need to correct some core misconceptions. While CLDR has what is > called a locale ID, for historical reasons, it really functions (with > a couple of exceptions) as a language ID, and accesses language-based > data. There used to be some information that was improperly included > in the language-based data, like default currency and weekend ranges, > but that was removed over time; moved to supplemental files.... This > is not even really "locale" data so much as it is just non-language > data. "Locale data" is a very gray area; if you give N informed people a long-enough list of items (sort order, script, charset, calendar, currency, time zone, SI vs. imperial units) and ask them to pick which ones belong in a locale and which ones don't, you will likely get at least (N - 1) result sets. I don't want to belabor that, except to say that "locale data" often does include items that go beyond "language identification" and probably don't belong in RFC 4646(bis). Only one specific item: > Sort order is part of the language-based data, and to my mind properly > so: sort order is keyed off of language. Here's what I meant: Internet Explorer 7, which has come a long way by adopting RFC 4646 tags to indicate "languages," still identifies "es-ES" with "Spanish (International Sort)". There are a lot of differences between Spanish in Spain (which itself is not uniform) and Spanish elsewhere, such as pronunciation and vocabulary and vosotros/ustedes, that may be more linguistically important than the pre-1994 sort order. There is a fine line, somewhere between pure language distinctions and things that are clearly not language, and I'm sure we could battle for ages on exactly where that line is. I do think we should try to avoid using RFC 4646 directly for things that are clearly not language. (Using it indirectly, as CLDR does, is fine.) In particular: > en_US_POSIX. This is a bit tricky. POSIX is an artifical variant used > to get the default "C" style for numbers, dates, etc. It'd be handy to > get it registered, but I doubt that there are enough pragmatists on > the ietf-languages group to get it done. ... you can definitely count me as one of the pragmatists in this case. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 22 22:45:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbpom-0003x0-QI; Sun, 22 Oct 2006 22:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbpol-0003wY-MA for ltru@ietf.org; Sun, 22 Oct 2006 22:45:35 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbpok-0002sJ-AX for ltru@ietf.org; Sun, 22 Oct 2006 22:45:35 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nfUriAl97msEPxmXo+DgGWbyyXO6ACE7Lhhg2jkVjApThZnokDP0gIbltiuN2jWu; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.3.18] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gbpod-0000CC-9h for ltru@ietf.org; Sun, 22 Oct 2006 22:45:27 -0400 Message-ID: <004501c6f64d$f3860880$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20610211637r60965ce7i44b5254a90b5fb5c@mail.gmail.com><001d01c6f5cc$f1443370$6500a8c0@chalmers95a69n><30b660a20610220852v5bea9ad7xc3987919cb3d59b8@mail.gmail.com><00b801c6f605$7ccb85a0$6501a8c0@DGBP7M81><30b660a20610221433i3c0f9596yc5b4e4545377c0b@mail.gmail.com> <00df01c6f63d$61eedd80$6501a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 22 Oct 2006 19:50:01 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6d4c45f989e3300f471b787536cd9eeba350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.3.18 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - To everyone and no one in particular.... This thread is veering far from this working group's chartered space: language tag registry update. Please focus on the work at hand, as spelled out by our charter. And as we are working with tags for the identification of languages, please be aware that while there may be all sorts of other possible tags for various purposes, they are outside our scope. These other discussions, while perhaps interesting to some, belong elsewhere. Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 23 01:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbsPk-0003J8-3N; Mon, 23 Oct 2006 01:31:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbsPj-0003J3-Gd for ltru@ietf.org; Mon, 23 Oct 2006 01:31:55 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbsPf-0000oy-0C for ltru@ietf.org; Mon, 23 Oct 2006 01:31:55 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Sun, 22 Oct 2006 22:31:50 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Oct 2006 22:31:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... Date: Sun, 22 Oct 2006 22:31:44 -0700 Message-ID: In-Reply-To: <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Great Script Debate "the Next Generation"... Thread-Index: Acb1DEVxvZlMKvl6T+aOhTZ6zmGLSQBV+LlQ References: <6.0.0.20.2.20061021102638.092a6a70@localhost> <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> From: Peter Constable To: LTRU Working Group X-OriginalArrivalTime: 23 Oct 2006 05:31:50.0189 (UTC) FILETIME=[8A2B3DD0:01C6F664] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org IMO, this is clearly a case where the distinction between a locale ID and a language tag that I've talked about for several years is critical: the use of digit substitution in certain processes on a particular computer system has nothing whatsoever to do with describing the linguistic attributes of content. IMO, digit substitution as part of a CLDR locale is out of scope for RFC 4646 language tags. Peter -----Original Message----- From: Kent Karlsson [mailto:kent.karlsson14@comhem.se]=20 Sent: Saturday, October 21, 2006 5:26 AM To: 'Martin Duerst'; 'Mark Davis' Cc: 'LTRU Working Group' Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... So how would you suggest dealing with the (existing!) locale currently named th_TH_TH if one were to rename it more in the spirit of RFC4646 language tags? Granted, locale names are not necessarily bound by how IETF language tags are formed. Almost all locales in CLDR are named according to IETF language tags, with the exceptions hy_AM_REVISED, aa_ER_SAAHO, and el_POLYTONI, for which I do think variant=20 language subtags would be warranted, en_US_POSIX, and root which are indeed special cases. th_TH_TH isn't a CLDR locale, but I don't want to make another exception for it in naming, CLDR or not. There is still a need to support th_TH_TH (*and* th_TH, but th_TH_TH will likely be more used than th_TH for the applications I have in mind, which use generated digits quite a lot), but I'd rather see its name mapped to something more up-to-date. And I would guess there is a similar need for other languages, Indic ones in particular. As I mentioned, registering a *language* variant subtag for this (digit preference for **generated** decimal digits, not (generated) spellout digits) would be inappropriate, I think (I would not support such a registration, at least). So would using a private use subtag. /kent k > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp]=20 > Sent: Saturday, October 21, 2006 3:28 AM > To: Mark Davis; Kent Karlsson > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... >=20 >=20 > I agree with Mark and others that it's a bad idea to let the presence > or absence of a script tag indicate the useage of a certain kind of > digits. This is not what the script tag was/is intended for, and it's > very brittle. >=20 > Regards, Martin. >=20 > At 01:06 06/10/20, Mark Davis wrote: > >It would be really impractical to depend on any consistent=20 > distinction > >ever being drawn between th-Thai and th, either as languages or as > >locales (in the CLDR sense, which is essentially the same as > >language). The only difference would be that in matching, th could > >match th-Latn (a romanization), for example. But that is going to be > >extremely rare cases. > > > >Mark > > > >On 10/19/06, Kent Karlsson wrote: > >> > >> > >> > >> > >> > > >> > > 8. A script subtag SHOULD NOT be used if the content=20 > being tagged is > >> > > written in the script customarily used for the vast majority of > >> > > content in that language (e.g. en-Latn SHOULD NOT be used). > >> > >> There may be exceptions. While the following is about=20 > locale naming rather > >> than language tagging (ready-made) text content, those are=20 > closely related, > >> and a language tag can well be used to select the (almost)=20 > same-named > >> locale. > >> > >> While 'th' currently has a Suppress-Script of 'Thai', and=20 > would still be > >> covered > >> by the above "SHOULD" if we remove "Suppress-Script", 'th'=20 > and 'th-Thai' > >> (or as a locale name 'th_Thai'), in that generated digits=20 > (generated from > >> some > >> computation, or some database access, or similar) may be formatted > >> differently > >> for presentation: 'th' would imply the use of the digits=20 > 0-9 (which I > >> understand > >> is common in modern Thai), while 'th-Thai' (or rather a=20 > 'th_Thai' locale) > >> would > >> imply that they are presented using the Thai digits=20 > (U+0E50-U+0E59). > >> > >> Similarly, Arabic mixes the use of 0-9 and Arabic-Indic=20 > digits, and one may > >> want to have separate locales for presenting computed=20 > number/date values > >> using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). > >> > >> It would be possible to use variants for this, but that=20 > seems needless. Or > >> would > >> you consider such use as described above of script subtags=20 > as inappropriate? > >> > >> /kent k > >> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > >> > >> > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp =20 > mailto:duerst@it.aoyama.ac.jp =20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 24 10:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcN3l-0004mf-NR; Tue, 24 Oct 2006 10:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcN3k-0004ma-1d for ltru@ietf.org; Tue, 24 Oct 2006 10:15:16 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcN3S-0005qt-Vy for ltru@ietf.org; Tue, 24 Oct 2006 10:15:16 -0400 Received: by wr-out-0506.google.com with SMTP id i20so467685wra for ; Tue, 24 Oct 2006 07:14:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RDmCal4IjseX+8BIMMz8zYvOn17PZcvcf/fJHLtvLFanXjOIIHOO5uyCCc/Tua1vsIlRVA2Vu9Wvh0Ivc0tf+JBQNKxqan7Wa7q8ncFVcTR0H9SyMxlWuxsCuNppNSSwRb/MgL86KldDOIz05UBesX1wX3eHBm2kULxPZ+Uq+XE= Received: by 10.90.80.8 with SMTP id d8mr3020064agb; Tue, 24 Oct 2006 07:14:58 -0700 (PDT) Received: by 10.90.92.11 with HTTP; Tue, 24 Oct 2006 07:14:58 -0700 (PDT) Message-ID: <30b660a20610240714i2e46a4a5h55bd0e727e6d7f8f@mail.gmail.com> Date: Tue, 24 Oct 2006 07:14:58 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... In-Reply-To: MIME-Version: 1.0 References: <6.0.0.20.2.20061021102638.092a6a70@localhost> <000701c6f50c$0c9ce7a0$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: e0241a7264b834fa X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0460683291==" Errors-To: ltru-bounces@ietf.org --===============0460683291== Content-Type: multipart/alternative; boundary="----=_Part_3570_5672145.1161699298549" ------=_Part_3570_5672145.1161699298549 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Once again, I have to correct some misperceptions. There is no "digit substitution as part of a CLDR locale". Before people talk about CLDR it might be a good idea to look at it first. And Randy's right -- this is getting way off topic. Mark On 10/22/06, Peter Constable wrote: > > IMO, this is clearly a case where the distinction between a locale ID > and a language tag that I've talked about for several years is critical: > the use of digit substitution in certain processes on a particular > computer system has nothing whatsoever to do with describing the > linguistic attributes of content. IMO, digit substitution as part of a > CLDR locale is out of scope for RFC 4646 language tags. > > > Peter > > > > -----Original Message----- > From: Kent Karlsson [mailto: kent.karlsson14@comhem.se] > Sent: Saturday, October 21, 2006 5:26 AM > To: 'Martin Duerst'; 'Mark Davis' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"... > > So how would you suggest dealing with the (existing!) locale > currently named th_TH_TH if one were to rename it more > in the spirit of RFC4646 language tags? Granted, locale > names are not necessarily bound by how IETF language tags > are formed. Almost all locales in CLDR are named according to > IETF language tags, with the exceptions hy_AM_REVISED, > aa_ER_SAAHO, and el_POLYTONI, for which I do think variant > language subtags would be warranted, en_US_POSIX, and root > which are indeed special cases. th_TH_TH isn't a CLDR > locale, but I don't want to make another exception for it in > naming, CLDR or not. There is still a need to support > th_TH_TH (*and* th_TH, but th_TH_TH will likely be more > used than th_TH for the applications I have in mind, which > use generated digits quite a lot), but I'd rather see its name > mapped to something more up-to-date. And I would guess > there is a similar need for other languages, Indic ones in > particular. > > As I mentioned, registering a *language* variant subtag for > this (digit preference for **generated** decimal digits, not > (generated) spellout digits) would be inappropriate, I think > (I would not support such a registration, at least). So would > using a private use subtag. > > /kent k > > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: Saturday, October 21, 2006 3:28 AM > > To: Mark Davis; Kent Karlsson > > Cc: LTRU Working Group > > Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"... > > > > > > I agree with Mark and others that it's a bad idea to let the presence > > or absence of a script tag indicate the useage of a certain kind of > > digits. This is not what the script tag was/is intended for, and it's > > very brittle. > > > > Regards, Martin. > > > > At 01:06 06/10/20, Mark Davis wrote: > > >It would be really impractical to depend on any consistent > > distinction > > >ever being drawn between th-Thai and th, either as languages or as > > >locales (in the CLDR sense, which is essentially the same as > > >language). The only difference would be that in matching, th could > > >match th-Latn (a romanization), for example. But that is going to be > > >extremely rare cases. > > > > > >Mark > > > > > >On 10/19/06, Kent Karlsson wrote: > > >> > > >> > > >> > > >> > > >> > > > >> > > 8. A script subtag SHOULD NOT be used if the content > > being tagged is > > >> > > written in the script customarily used for the vast majority of > > >> > > content in that language ( e.g. en-Latn SHOULD NOT be used). > > >> > > >> There may be exceptions. While the following is about > > locale naming rather > > >> than language tagging (ready-made) text content, those are > > closely related, > > >> and a language tag can well be used to select the (almost) > > same-named > > >> locale. > > >> > > >> While 'th' currently has a Suppress-Script of 'Thai', and > > would still be > > >> covered > > >> by the above "SHOULD" if we remove "Suppress-Script", 'th' > > and 'th-Thai' > > >> (or as a locale name 'th_Thai'), in that generated digits > > (generated from > > >> some > > >> computation, or some database access, or similar) may be formatted > > >> differently > > >> for presentation: 'th' would imply the use of the digits > > 0-9 (which I > > >> understand > > >> is common in modern Thai), while 'th-Thai' (or rather a > > 'th_Thai' locale) > > >> would > > >> imply that they are presented using the Thai digits > > (U+0E50-U+0E59). > > >> > > >> Similarly, Arabic mixes the use of 0-9 and Arabic-Indic > > digits, and one may > > >> want to have separate locales for presenting computed > > number/date values > > >> using 0-9 (ar) or using Arabic-Indic digits (ar-Arab). > > >> > > >> It would be possible to use variants for this, but that > > seems needless. Or > > >> would > > >> you consider such use as described above of script subtags > > as inappropriate? > > >> > > >> /kent k > > >> > > >> _______________________________________________ > > >> Ltru mailing list > > >> Ltru@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ltru > > >> > > >> > > >> > > > > > >_______________________________________________ > > >Ltru mailing list > > >Ltru@ietf.org > > >https://www1.ietf.org/mailman/listinfo/ltru > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > > #-#-# http://www.sw.it.aoyama.ac.jp > > mailto: duerst@it.aoyama.ac.jp > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_3570_5672145.1161699298549 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Once again, I have to correct some misperceptions. There is no "digit substitution as part of a
CLDR locale".

Before people talk about CLDR it might be a good idea to look at it first. And Randy's right -- this is getting way off topic.

Mark

On 10/22/06, Peter Constable < petercon@microsoft.com> wrote:
IMO, this is clearly a case where the distinction between a locale ID
and a language tag that I've talked about for several years is critical:
the use of digit substitution in certain processes on a particular
computer system has nothing whatsoever to do with describing the
linguistic attributes of content. IMO, digit substitution as part of a
CLDR locale is out of scope for RFC 4646 language tags.


Peter



-----Original Message-----
From: Kent Karlsson [mailto: kent.karlsson14@comhem.se]
Sent: Saturday, October 21, 2006 5:26 AM
To: 'Martin Duerst'; 'Mark Davis'
Cc: 'LTRU Working Group'
Subject: RE: [Ltru] Re: Great Script Debate "the Next Generation"...

So how would you suggest dealing with the (existing!) locale
currently named th_TH_TH if one were to rename it more
in the spirit of RFC4646 language tags? Granted, locale
names are not necessarily bound by how IETF language tags
are formed. Almost all locales in CLDR are named according to
IETF language tags, with the exceptions hy_AM_REVISED,
aa_ER_SAAHO, and el_POLYTONI, for which I do think variant
language subtags would be warranted, en_US_POSIX, and root
which are indeed special cases.  th_TH_TH isn't a CLDR
locale, but I don't want to make another exception for it in
naming, CLDR or not. There is still a need to support
th_TH_TH (*and* th_TH, but th_TH_TH will likely be more
used than th_TH for the applications I have in mind, which
use generated digits quite a lot), but I'd rather see its name
mapped to something more up-to-date. And I would guess
there is a similar need for other languages, Indic ones in
particular.

As I mentioned, registering a *language* variant subtag for
this (digit preference for **generated** decimal digits, not
(generated) spellout digits) would be inappropriate, I think
(I would not support such a registration, at least). So would
using a private use subtag.

        /kent k


> -----Original Message-----
> From: Martin Duerst [mailto: duerst@it.aoyama.ac.jp]
> Sent: Saturday, October 21, 2006 3:28 AM
> To: Mark Davis; Kent Karlsson
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Re: Great Script Debate "the Next Generation"...
>
>
> I agree with Mark and others that it's a bad idea to let the presence
> or absence of a script tag indicate the useage of a certain kind of
> digits. This is not what the script tag was/is intended for, and it's
> very brittle.
>
> Regards,    Martin.
>
> At 01:06 06/10/20, Mark Davis wrote:
> >It would be really impractical to depend on any consistent
> distinction
> >ever being drawn between th-Thai and th, either as languages or as
> >locales (in the CLDR sense, which is essentially the same as
> >language). The only difference would be that in matching, th could
> >match th-Latn (a romanization), for example. But that is going to be
> >extremely rare cases.
> >
> >Mark
> >
> >On 10/19/06, Kent Karlsson <kent.karlsson14@comhem.se> wrote:
> >>
> >>
> >>
> >>
> >> >
> >> > > 8.  A script subtag SHOULD NOT be used if the content
> being tagged is
> >> > > written in the script customarily used for the vast majority of
> >> > > content in that language ( e.g. en-Latn SHOULD NOT be used).
> >>
> >> There may be exceptions. While the following is about
> locale naming rather
> >> than language tagging (ready-made) text content, those are
> closely related,
> >> and a language tag can well be used to select the (almost)
> same-named
> >> locale.
> >>
> >> While 'th' currently has a Suppress-Script of 'Thai', and
> would still be
> >> covered
> >> by the above "SHOULD" if we remove "Suppress-Script", 'th'
> and 'th-Thai'
> >> (or as a locale name 'th_Thai'), in that generated digits
> (generated from
> >> some
> >> computation, or some database access, or similar) may be formatted
> >> differently
> >> for presentation: 'th' would imply the use of the digits
> 0-9 (which I
> >> understand
> >> is common in modern Thai), while 'th-Thai' (or rather a
> 'th_Thai' locale)
> >> would
> >> imply that they are presented using the Thai digits
> (U+0E50-U+0E59).
> >>
> >> Similarly, Arabic mixes the use of 0-9 and Arabic-Indic
> digits, and one may
> >> want to have separate locales for presenting computed
> number/date values
> >> using 0-9 (ar) or using Arabic-Indic digits (ar-Arab).
> >>
> >> It would be possible to use variants for this, but that
> seems needless. Or
> >> would
> >> you consider such use as described above of script subtags
> as inappropriate?
> >>
> >>         /kent k
> >>
> >> _______________________________________________
> >> Ltru mailing list
> >> Ltru@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ltru
> >>
> >>
> >>
> >
> >_______________________________________________
> >Ltru mailing list
> >Ltru@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp
> mailto: duerst@it.aoyama.ac.jp
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
>


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

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

------=_Part_3570_5672145.1161699298549-- --===============0460683291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0460683291==-- From ltru-bounces@ietf.org Tue Oct 24 10:40:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNSa-00039B-AF; Tue, 24 Oct 2006 10:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNSZ-000395-JJ for ltru@ietf.org; Tue, 24 Oct 2006 10:40:55 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNSU-0002jK-5P for ltru@ietf.org; Tue, 24 Oct 2006 10:40:55 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061024144049.NNJD9984.mta9.adelphia.net@DGBP7M81> for ; Tue, 24 Oct 2006 10:40:49 -0400 Message-ID: <008a01c6f77a$66c2c8b0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 24 Oct 2006 07:40:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: Great Script Debate "the Next Generation"... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Sorry to post again on this OT subject, but I wanted to correct my own misstatement. I wrote: >> en_US_POSIX. This is a bit tricky. POSIX is an artifical variant used >> to get the default "C" style for numbers, dates, etc. It'd be handy >> to get it registered, but I doubt that there are enough pragmatists >> on the ietf-languages group to get it done. > > ... you can definitely count me as one of the pragmatists in this > case. What I meant was, you can count me as one of the "idealists" or "purists" (or pick your favorite opposite of "pragmatists") who does *not* want to register things in the LSR that are not for language-identification purposes. The rest of my message should have made my position clear. Sorry about the hasty and bogus reply. I promise to leave this thread now. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 26 11:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd70B-0004bV-06; Thu, 26 Oct 2006 11:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd709-0004Yr-37 for ltru@ietf.org; Thu, 26 Oct 2006 11:18:37 -0400 Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6su-00049h-DS for ltru@ietf.org; Thu, 26 Oct 2006 11:11:13 -0400 Received: from kotus.fi (pc094.kotus.fi [193.166.18.94]) by suomi.kotus.fi (8.13.7+Sun/8.13.7) with ESMTP id k9QFAvBF008081; Thu, 26 Oct 2006 18:10:57 +0300 (EEST) Message-ID: <4540D001.1060100@kotus.fi> Date: Thu, 26 Oct 2006 18:10:57 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Marion Gunn Subject: Re: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by suomi.kotus.fi id k9QFAvBF008081 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: TC46-L Information and Documentation Technology List , Sue Ellen Wright , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'm a little late in adding my comment, but I have quite some difficulty=20 in understanding this. To me, IPA is but one of the surprisingly many=20 phonetic alphabets of this world, albeit probably the most commonly=20 used. Others include e.g. UPA (the Uralic Phonetic Alphabet) and LMA=20 (the Swedish Landsm=E5lsalfabetet), both of which I'm somewhat familiar=20 with, since I've been involved in the encoding of them in the=20 UCS/Unicode. The usage of the phonetic alphabets also has a tendency to=20 be based on extensive cross-boundary character loans even from other=20 scripts than the Latin script, under which they are now listed. However, it would make a lot of sense to be able to identify a text=20 as having been written using _some_ phonetic alphabet (for which a=20 separate script code could be used if a more suitable solution cannot be=20 found). This could then be further identified by the code for the=20 specific, most dominant alphabet, such as IPA, used to write the text.=20 My point is that the IPA identification problem should not be solved by=20 such a special treatment that it could not be applied to the other=20 phonetic alphabets. Sincerely, Erkki I. Kolehmainen Marion Gunn wrote: > To say Ireland (NSAI) is responsible for the refusal to register IPA a= s=20 > an ISO 15924 script is as unfair as it is untrue. >=20 > I am writing to confirm that Irish users were as put out by that =20 > negative decision as users elsewhere, and that that negative decision =20 > was not made by NSAI. >=20 > ISO 15924 is nominally the responsibility of ISO/TC 46, although not =20 > under normal TC 46 control, either, and that negative decision was mad= e=20 > by the ISO 15924 advisory committee, currently made up as follows: > One representative of the Registration Authority: > Michael Everson, Evertype > One representative of the ISO 639-2/RA: > Randall K. Barry, Library of Congress > One representative of ISO TC37: > H=E5vard Hjulstad, Spr=E5k- og terminologitjenester > One representative of ISO TC46: > Fran=E7ois Demay, Encyclopaedia Universalis > Two representatives of ISO/IEC JTC1/SC2: > Rick McGowan, Unicode Consortium > Ken Whistler, Sybase >=20 > That AC failed to offer a cogent argument against tagging IPA in ISO =20 > 15924 and, during a public exchange on the LTRU list, its members all =20 > failed to address most of the points raised, for example, when Mark =20 > Davis of International Components for Unicode pointed out that [ISO =20 > 15924] already "incorporates variations which are essentially =20 > orthography (Hant vs Hans), and other differences that are simply =20 > glyphic variation (Fraktur Latin)" their answer was silence. >=20 > The grounds for registering IPA as a script have been long since =20 > established: it looks like a script, behaves like a script and only =20 > requires standard ISO tagging to facilitate proper electronic script =20 > processing. An IPA tag is urgently needed by NSAI's Irish-speaking =20 > communities, (so I must continue pressing for it), as well as being =20 > needed by university researchers and practical speech therapists in so= =20 > many countries that a positive decision to tag it for use needs to mad= e=20 > without delay, to open the door for Net searches for texts written in = IPA. >=20 > Because that particular ISO AC was set up with a built-in US majority =20 > (4 out of 6), it is the logical responsibility of ANSI (_not_ NSAI) to= =20 > ensure that such overloading in a big country's favour not be any =20 > excuse for refusing/delaying reasonable service requests from smaller =20 > countries. No country, however big it is, has any right to have such =20 > control over any international standards =97 however obtained, that =20 > amount of control carries with it an equal amount of answerability for= =20 > concomitant results. >=20 > Accordingly, I respectfully request that ANSI use its influence to to =20 > good effect, to persuade such members of the ISO 15924 AC as it can =20 > influence to reverse their negative decision in re registering IPA in =20 > ISO 15924. >=20 > FWIW, I wish to affirm that I still believe in ISO 15924's potential =20 > quite as much as I did many years ago, when I was NSAI's sole =20 > representative in ISO/TC 37, where I first brought its first NWI draft= =20 > to ISO/TC 37's attention (and after it was blocked in TC 37, supported= =20 > its adoption in ISO/TC 46), that I regard its inception by Michael=20 > Everson as something very much to his credit, and that I would also=20 > regard it as to Mr Everson's credit were he now to reverse his vote=20 > (withdraw his opposition to registing IPA as a script). >=20 > I hold it as a reasonable expectation that the rest would probably fol= low. > mg > Convener, NSAI ISO/TC 46 IG >=20 > - - > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 26 13:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8oz-0004dS-5m; Thu, 26 Oct 2006 13:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8ow-0004Xf-Ol for ltru@ietf.org; Thu, 26 Oct 2006 13:15:11 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8ot-0001x2-7F for ltru@ietf.org; Thu, 26 Oct 2006 13:15:10 -0400 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id 29BE114EC; Thu, 26 Oct 2006 20:15:00 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 31176-09; Thu, 26 Oct 2006 20:14:59 +0300 (EEST) Received: from mustatilhi.cs.tut.fi (mustatilhi.cs.tut.fi [130.230.4.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id A3C2D106F; Thu, 26 Oct 2006 20:14:51 +0300 (EEST) Date: Thu, 26 Oct 2006 20:14:51 +0300 (EEST) From: "Jukka K. Korpela" To: LTRU Working Group Subject: Re: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] In-Reply-To: <4540D001.1060100@kotus.fi> Message-ID: References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie> <4540D001.1060100@kotus.fi> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1161881521=:27236" Content-ID: X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1161881521=:27236 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Thu, 26 Oct 2006, Erkki Kolehmainen wrote: > However, it would make a lot of sense to be able to identify a text as= =20 > having been written using _some_ phonetic alphabet I'm afraid I fail to see reasons to that. "Phonetic" is just a general=20 attribute here, referring to the principle that a writing system tries to= =20 represent the sounds of speech exactly, as opposite to systems that more=20 or less reflect historical developments or apply the principle of using=20 the same spelling for a phoneme, irrespectively of allophonic variation. So it's not a matter of having a "phonetic script" as opposite to all=20 other scripts, but a class or property of scripts. In practice, the=20 attribute "phonetic" tends to exclude scripts that are actually used for=20 writing human languages, as opposite to writing systems used in=20 linguistic research or teaching. > This=20 > could then be further identified by the code for the specific, most domin= ant=20 > alphabet, such as IPA, used to write the text. A phonetic writing system need not have _anything_ to do with IPA, except= =20 for the very abstract principle of representing sounds by characters (for= =20 some meaning of "sound"). > My point is that the IPA=20 > identification problem should not be solved by such a special treatment t= hat=20 > it could not be applied to the other phonetic alphabets. I can't follow that logic, but I think I can see the implicit argument=20 that registering the IPA would be a precedent to endless requests for=20 registering different phonetic writing systems - or, so to say, would open= =20 a can of worms. What puzzles me most is that the _reasons_ for registering scripts and=20 using script metainformation have not been discussed. This isn't just a=20 game of labeling things, is it? There must be something practical to be=20 achieved, even if it is practical only for the progress of theoretical=20 research (in linguistics, for example). But what _are_ the realistic=20 applications? For example, if I didn't misunderstand some of the previous discussion,=20 labeling text as being written in IPA is expected to help in searching for= =20 information on the web. While this is surely _imaginable_, I cannot regard= =20 it as realistic. We already have experience about _language_=20 identification, which is a much easier thing and more understandable to=20 the layman. Yet, the vast majority of web pages contain either no language= =20 metainformation or, much worse, _wrong_ metainformation, like pages=20 claiming to be in Sanskrit when they are in Northern S=E1mi or pages=20 claiming to be in English just because that's the default of an authoring= =20 program. Thus, it is quite understandable that _no_ significant web search engine uses language metainformation at all but instead applies heuristics to=20 guess the language. I see little reason to expect that script information= =20 would be treated differently. If, on the other hand, script information would be used by database=20 applications, language processing software, or dedicated site-specific=20 search systems, for example, then the question is what these applications= =20 would need. I would expect them to have rather specific needs, and any=20 general method of specifying script information would be just one=20 interesting possibility _if it is useful enough_. Embedding script=20 information into a language (or locale) code might be feasible, but that=20 would be overkill if you just need, for example, to keep track of which=20 strings are in normal writing and which strings are in a phonetic=20 notation. --=20 Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ ---559023410-851401618-1161881521=:27236 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ---559023410-851401618-1161881521=:27236-- From ltru-bounces@ietf.org Thu Oct 26 13:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8t9-0005sy-PC; Thu, 26 Oct 2006 13:19:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8t9-0005so-0K for ltru@ietf.org; Thu, 26 Oct 2006 13:19:31 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8t3-0002bi-Fa for ltru@ietf.org; Thu, 26 Oct 2006 13:19:30 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.665.7; Thu, 26 Oct 2006 10:19:24 -0700 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 10:19:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] Date: Thu, 26 Oct 2006 10:18:42 -0700 Message-ID: <19A328037921AA42847A717566D1D6A1092E174E@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <4540D001.1060100@kotus.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] Thread-Index: Acb5EiDvb7lebv8YSqSG1k3QTHJEdwAEH0tw From: Peter Constable To: Erkki Kolehmainen , Marion Gunn X-OriginalArrivalTime: 26 Oct 2006 17:19:24.0399 (UTC) FILETIME=[E216D7F0:01C6F922] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Working Group , Sue Ellen Wright , TC46-L Information and Documentation Technology List , LTRU X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hence my suggestion a while back: a script-variant ID in 15924 for = Latin-based phonetic transcription systems, "Lphn". Peter > -----Original Message----- > From: Erkki Kolehmainen [mailto:erkki.kolehmainen@kotus.fi] > Sent: Thursday, October 26, 2006 8:11 AM > To: Marion Gunn > Cc: TC46-L Information and Documentation Technology List; Sue Ellen = Wright; LTRU > Working Group > Subject: Re: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] >=20 > I'm a little late in adding my comment, but I have quite some = difficulty > in understanding this. To me, IPA is but one of the surprisingly many > phonetic alphabets of this world, albeit probably the most commonly > used. Others include e.g. UPA (the Uralic Phonetic Alphabet) and LMA > (the Swedish Landsm=E5lsalfabetet), both of which I'm somewhat = familiar > with, since I've been involved in the encoding of them in the > UCS/Unicode. The usage of the phonetic alphabets also has a tendency = to > be based on extensive cross-boundary character loans even from other > scripts than the Latin script, under which they are now listed. >=20 > However, it would make a lot of sense to be able to identify a text > as having been written using _some_ phonetic alphabet (for which a > separate script code could be used if a more suitable solution cannot = be > found). This could then be further identified by the code for the > specific, most dominant alphabet, such as IPA, used to write the text. > My point is that the IPA identification problem should not be solved = by > such a special treatment that it could not be applied to the other > phonetic alphabets. >=20 > Sincerely, Erkki I. Kolehmainen >=20 > Marion Gunn wrote: >=20 > > To say Ireland (NSAI) is responsible for the refusal to register IPA = as > > an ISO 15924 script is as unfair as it is untrue. > > > > I am writing to confirm that Irish users were as put out by that > > negative decision as users elsewhere, and that that negative = decision > > was not made by NSAI. > > > > ISO 15924 is nominally the responsibility of ISO/TC 46, although not > > under normal TC 46 control, either, and that negative decision was = made > > by the ISO 15924 advisory committee, currently made up as follows: > > One representative of the Registration Authority: > > Michael Everson, Evertype > > One representative of the ISO 639-2/RA: > > Randall K. Barry, Library of Congress > > One representative of ISO TC37: > > H=E5vard Hjulstad, Spr=E5k- og terminologitjenester > > One representative of ISO TC46: > > Fran=E7ois Demay, Encyclopaedia Universalis > > Two representatives of ISO/IEC JTC1/SC2: > > Rick McGowan, Unicode Consortium > > Ken Whistler, Sybase > > > > That AC failed to offer a cogent argument against tagging IPA in ISO > > 15924 and, during a public exchange on the LTRU list, its members = all > > failed to address most of the points raised, for example, when Mark > > Davis of International Components for Unicode pointed out that [ISO > > 15924] already "incorporates variations which are essentially > > orthography (Hant vs Hans), and other differences that are simply > > glyphic variation (Fraktur Latin)" their answer was silence. > > > > The grounds for registering IPA as a script have been long since > > established: it looks like a script, behaves like a script and only > > requires standard ISO tagging to facilitate proper electronic script > > processing. An IPA tag is urgently needed by NSAI's Irish-speaking > > communities, (so I must continue pressing for it), as well as being > > needed by university researchers and practical speech therapists in = so > > many countries that a positive decision to tag it for use needs to = made > > without delay, to open the door for Net searches for texts written = in IPA. > > > > Because that particular ISO AC was set up with a built-in US = majority > > (4 out of 6), it is the logical responsibility of ANSI (_not_ NSAI) = to > > ensure that such overloading in a big country's favour not be any > > excuse for refusing/delaying reasonable service requests from = smaller > > countries. No country, however big it is, has any right to have such > > control over any international standards =97 however obtained, that > > amount of control carries with it an equal amount of answerability = for > > concomitant results. > > > > Accordingly, I respectfully request that ANSI use its influence to = to > > good effect, to persuade such members of the ISO 15924 AC as it can > > influence to reverse their negative decision in re registering IPA = in > > ISO 15924. > > > > FWIW, I wish to affirm that I still believe in ISO 15924's potential > > quite as much as I did many years ago, when I was NSAI's sole > > representative in ISO/TC 37, where I first brought its first NWI = draft > > to ISO/TC 37's attention (and after it was blocked in TC 37, = supported > > its adoption in ISO/TC 46), that I regard its inception by Michael > > Everson as something very much to his credit, and that I would also > > regard it as to Mr Everson's credit were he now to reverse his vote > > (withdraw his opposition to registing IPA as a script). > > > > I hold it as a reasonable expectation that the rest would probably = follow. > > mg > > Convener, NSAI ISO/TC 46 IG > > > > - - > > Marion Gunn * EGTeo (Estab.1991) > > 27 P=E1irc an Fh=E9ithlinn, Baile an > > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > > * mgunn@egt.ie * eamonn@egt.ie * > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 26 13:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd91z-0002iQ-Ph; Thu, 26 Oct 2006 13:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd91y-0002gn-Hf for ltru@ietf.org; Thu, 26 Oct 2006 13:28:38 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd91w-0003yW-2Y for ltru@ietf.org; Thu, 26 Oct 2006 13:28:38 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Thu, 26 Oct 2006 10:28:35 -0700 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 10:28:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] Date: Thu, 26 Oct 2006 10:28:20 -0700 Message-ID: <19A328037921AA42847A717566D1D6A1092E1785@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] Thread-Index: Acb5IlIGqP6ym54hQSqeW2os4Zal+QAAKiOg From: Peter Constable To: "Jukka K. Korpela" , LTRU Working Group X-OriginalArrivalTime: 26 Oct 2006 17:28:35.0240 (UTC) FILETIME=[2A6A8280:01C6F924] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: TC46-L Information and Documentation Technology List X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You asked for application scenarios: - The various repositories that are part of the Open Language Archive = Community have a real need to tag content that is in some kind of = phonetic transcription. OLAC allows for content in the distributed = repository to be search according to the language/written-form = attributes, and the distinction between practical orthography and = phonetic transcription is part of that. - There are several entities that create applications for linguistic or = anthroplogical analysis in which phonetic transcription as well as = practical orthographies need to be supported. Those applications need a = tag for infrastructure use to associate certain data with appropriate = data categories within their database structure as well as resources = that need to be used for that data -- locale IDs, as it were, with = separate IDs for (e.g.) Lahu text in some practical orthography vs. a = phonetic transcription. Peter > -----Original Message----- > From: Jukka K. Korpela [mailto:jkorpela@cs.tut.fi] > Sent: Thursday, October 26, 2006 10:15 AM > To: LTRU Working Group > Cc: TC46-L Information and Documentation Technology List > Subject: Re: [Ltru] IPA as a script [was: IPA, NSAI and ANSI] >=20 > On Thu, 26 Oct 2006, Erkki Kolehmainen wrote: >=20 > > However, it would make a lot of sense to be able to identify a text = as > > having been written using _some_ phonetic alphabet >=20 > I'm afraid I fail to see reasons to that. "Phonetic" is just a general > attribute here, referring to the principle that a writing system tries = to > represent the sounds of speech exactly, as opposite to systems that = more > or less reflect historical developments or apply the principle of = using > the same spelling for a phoneme, irrespectively of allophonic = variation. >=20 > So it's not a matter of having a "phonetic script" as opposite to all > other scripts, but a class or property of scripts. In practice, the > attribute "phonetic" tends to exclude scripts that are actually used = for > writing human languages, as opposite to writing systems used in > linguistic research or teaching. >=20 > > This > > could then be further identified by the code for the specific, most = dominant > > alphabet, such as IPA, used to write the text. >=20 > A phonetic writing system need not have _anything_ to do with IPA, = except > for the very abstract principle of representing sounds by characters = (for > some meaning of "sound"). >=20 > > My point is that the IPA > > identification problem should not be solved by such a special = treatment that > > it could not be applied to the other phonetic alphabets. >=20 > I can't follow that logic, but I think I can see the implicit argument > that registering the IPA would be a precedent to endless requests for > registering different phonetic writing systems - or, so to say, would = open > a can of worms. >=20 > What puzzles me most is that the _reasons_ for registering scripts and > using script metainformation have not been discussed. This isn't just = a > game of labeling things, is it? There must be something practical to = be > achieved, even if it is practical only for the progress of theoretical > research (in linguistics, for example). But what _are_ the realistic > applications? >=20 > For example, if I didn't misunderstand some of the previous = discussion, > labeling text as being written in IPA is expected to help in searching = for > information on the web. While this is surely _imaginable_, I cannot = regard > it as realistic. We already have experience about _language_ > identification, which is a much easier thing and more understandable = to > the layman. Yet, the vast majority of web pages contain either no = language > metainformation or, much worse, _wrong_ metainformation, like pages > claiming to be in Sanskrit when they are in Northern S=E1mi or pages > claiming to be in English just because that's the default of an = authoring > program. >=20 > Thus, it is quite understandable that _no_ significant web search = engine > uses language metainformation at all but instead applies heuristics to > guess the language. I see little reason to expect that script = information > would be treated differently. >=20 > If, on the other hand, script information would be used by database > applications, language processing software, or dedicated site-specific > search systems, for example, then the question is what these = applications > would need. I would expect them to have rather specific needs, and any > general method of specifying script information would be just one > interesting possibility _if it is useful enough_. Embedding script > information into a language (or locale) code might be feasible, but = that > would be overkill if you just need, for example, to keep track of = which > strings are in normal writing and which strings are in a phonetic > notation. >=20 > -- > Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 26 22:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHh2-0003Bg-Jb; Thu, 26 Oct 2006 22:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHh1-00032S-0t for ltru@ietf.org; Thu, 26 Oct 2006 22:43:35 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdHgy-0007tq-99 for ltru@ietf.org; Thu, 26 Oct 2006 22:43:35 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9R2hVI7005702 for ; Fri, 27 Oct 2006 11:43:31 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1e6d_ee8422f0_6564_11db_9f2e_0014221fa3c9; Fri, 27 Oct 2006 11:43:30 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53488) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 27 Oct 2006 11:43:09 +0900 Message-Id: <6.0.0.20.2.20061027112820.08e255e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 27 Oct 2006 11:29:01 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Ltru] Fwd: Update to Internet-Draft and RFC Boilerplate X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org FYI, mainly for our editors. Martin. >To: IETF Announcement list >From: IETF Chair >Date: Thu, 26 Oct 2006 21:19:59 -0400 >A small update to BCP 78 was recently approved by the IESG as >RFC 4748, to update the boilerplate (i.e., standard legal text) in >RFCs and Internet-Drafts to recognize the IETF Trust as a rights >holder, instead of ISOC. > >The actual boilerplate changes are given below this message. > >Starting as soon as reasonably possible, all authors of Internet-Drafts >are requested to use the new boilerplate. The RFC Editor will in any case >be inserting it in all RFCs issued from 2006-11-01. (The rights held by >ISOC in older RFCs will be administratively transferred to the IETF >Trust.) > >The public ID Nits checker already accepts I-Ds with old or new >boilerplate. >The Secretariat has started accepting I-Ds with old or new boilerplate > >XML2RFC version 1.32 will generate the new boilerplate. >Users of I-D templates are requested to update them appropriately. > >http://www.ietf.org/ID-Checklist.html and >http://www.ietf.org/ietf/1id-guidelines.html are being updated. > >Starting December, the public ID Nits checker will issue warnings for >old boilerplate. > >Starting February 2007, the Secretariat will refuse >the old boilerplate in Internet-Drafts. > >We are sorry for the inconvenience, but this change cannot >be avoided. > > IETF Chair > IETF Secretariat > TOOLS Team > >-------- > >Copyright Notice (required for all IETF Documents) > > (Normally placed at the end of the IETF Document.) > >NOTE: by convention, the first line of the copyright statement >is usually placed near the beginning of each document. This must >also be updated. > >OLD > "Copyright (C) The Internet Society (year). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > >NEW > "Copyright (C) The IETF Trust (year). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > >Disclaimer (required in all IETF Documents) > > (Normally placed at the end of the IETF Document after the copyright > notice.) > > >OLD > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > >NEW > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE." > >Exceptions > > In MIB modules, PIB modules and similar material commonly > extracted from IETF Documents, except for material that is being > placed under IANA maintenance, the following abbreviated notice > shall be included in the body of the material that will be > extracted in lieu of the notices otherwise required by Section 5: > >OLD > "Copyright (C) The Internet Society . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > >NEW > "Copyright (C) The IETF Trust . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > When the MIB or PIB module is the initial version of a module that > is to be maintained by the IANA, the following abbreviated notice > shall be included: > >OLD > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > >NEW > "Copyright (C) The IETF Trust . The initial > version of this MIB module was published in RFC XXXX; for full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 26 22:46:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHk4-000099-Tu; Thu, 26 Oct 2006 22:46:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHk3-00006j-M7 for ltru@ietf.org; Thu, 26 Oct 2006 22:46:43 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdHk0-0008MP-Lr for ltru@ietf.org; Thu, 26 Oct 2006 22:46:43 -0400 Received: from [10.72.76.78] (snvvpn2-10-72-76-c78.corp.yahoo.com [10.72.76.78]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9R2kSAK004198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Oct 2006 19:46:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=ybxtIoi+otgqyRFmoVDpApN+mfE3VVYx9Mkbmncrtdwyki/ivytKw1OgtLUN6XAR Message-ID: <45417304.3020104@yahoo-inc.com> Date: Thu, 26 Oct 2006 19:46:28 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Fwd: Update to Internet-Draft and RFC Boilerplate References: <6.0.0.20.2.20061027112820.08e255e0@localhost> In-Reply-To: <6.0.0.20.2.20061027112820.08e255e0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Cool. Thanks! Guess I have to get the latest xml2rfc :-). Addison Martin Duerst wrote: > FYI, mainly for our editors. Martin. > > >> To: IETF Announcement list >> From: IETF Chair >> Date: Thu, 26 Oct 2006 21:19:59 -0400 > >> A small update to BCP 78 was recently approved by the IESG as >> RFC 4748, to update the boilerplate (i.e., standard legal text) in >> RFCs and Internet-Drafts to recognize the IETF Trust as a rights >> holder, instead of ISOC. >> >> The actual boilerplate changes are given below this message. >> >> Starting as soon as reasonably possible, all authors of Internet-Drafts >> are requested to use the new boilerplate. The RFC Editor will in any case >> be inserting it in all RFCs issued from 2006-11-01. (The rights held by >> ISOC in older RFCs will be administratively transferred to the IETF >> Trust.) >> >> The public ID Nits checker already accepts I-Ds with old or new >> boilerplate. >> The Secretariat has started accepting I-Ds with old or new boilerplate >> >> XML2RFC version 1.32 will generate the new boilerplate. >> Users of I-D templates are requested to update them appropriately. >> >> http://www.ietf.org/ID-Checklist.html and >> http://www.ietf.org/ietf/1id-guidelines.html are being updated. >> >> Starting December, the public ID Nits checker will issue warnings for >> old boilerplate. >> >> Starting February 2007, the Secretariat will refuse >> the old boilerplate in Internet-Drafts. >> >> We are sorry for the inconvenience, but this change cannot >> be avoided. >> >> IETF Chair >> IETF Secretariat >> TOOLS Team >> >> -------- >> >> Copyright Notice (required for all IETF Documents) >> >> (Normally placed at the end of the IETF Document.) >> >> NOTE: by convention, the first line of the copyright statement >> is usually placed near the beginning of each document. This must >> also be updated. >> >> OLD >> "Copyright (C) The Internet Society (year). >> >> This document is subject to the rights, licenses and restrictions >> contained in BCP 78, and except as set forth therein, the authors >> retain all their rights. >> >> NEW >> "Copyright (C) The IETF Trust (year). >> >> This document is subject to the rights, licenses and restrictions >> contained in BCP 78, and except as set forth therein, the authors >> retain all their rights. >> >> >> Disclaimer (required in all IETF Documents) >> >> (Normally placed at the end of the IETF Document after the copyright >> notice.) >> >> >> OLD >> "This document and the information contained herein are provided >> on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND >> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, >> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT >> THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR >> ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >> PARTICULAR PURPOSE." >> >> >> NEW >> "This document and the information contained herein are provided >> on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE >> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL >> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY >> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE >> ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS >> FOR A PARTICULAR PURPOSE." >> >> Exceptions >> >> In MIB modules, PIB modules and similar material commonly >> extracted from IETF Documents, except for material that is being >> placed under IANA maintenance, the following abbreviated notice >> shall be included in the body of the material that will be >> extracted in lieu of the notices otherwise required by Section 5: >> >> OLD >> "Copyright (C) The Internet Society . This version of >> this MIB module is part of RFC XXXX; see the RFC itself for >> full legal notices." >> >> NEW >> "Copyright (C) The IETF Trust . This version of >> this MIB module is part of RFC XXXX; see the RFC itself for >> full legal notices." >> >> When the MIB or PIB module is the initial version of a module that >> is to be maintained by the IANA, the following abbreviated notice >> shall be included: >> >> OLD >> "Copyright (C) The Internet Society . The initial >> version of this MIB module was published in RFC XXXX; for full >> legal notices see the RFC itself. Supplementary information >> may be available at: >> http://www.ietf.org/copyrights/ianamib.html." >> >> NEW >> "Copyright (C) The IETF Trust . The initial >> version of this MIB module was published in RFC XXXX; for full >> legal notices see the RFC itself. Supplementary information >> may be available at: >> http://www.ietf.org/copyrights/ianamib.html." >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf-announce > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 27 04:58:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdNXG-0004Dk-A5; Fri, 27 Oct 2006 04:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdNXE-0004A9-UT for ltru@lists.ietf.org; Fri, 27 Oct 2006 04:57:52 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdNX8-0005Hb-G3 for ltru@lists.ietf.org; Fri, 27 Oct 2006 04:57:52 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdNWK-0000lv-CI for ltru@lists.ietf.org; Fri, 27 Oct 2006 10:56:56 +0200 Received: from pd9fba94b.dip0.t-ipconnect.de ([217.251.169.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 10:56:56 +0200 Received: from nobody by pd9fba94b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 10:56:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 27 Oct 2006 10:52:44 +0200 Organization: Lines: 40 Message-ID: <4541C8DC.4BB8@xyzzy.claranet.de> References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie> <4540D001.1060100@kotus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba94b.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Jukka K. Korpela wrote: > I think I can see the implicit argument that registering the IPA would be > a precedent to endless requests for registering different phonetic writing > systems - or, so to say, would open a can of worms. Maybe not "endless", but enough for a decent extension registry managed by those who are supposed to know what they do / need / want. The arguments that IPA is only one of many similar "non-scripts" were convincing - that it's the most important "non-script" is beside the point. > What puzzles me most is that the _reasons_ for registering scripts and > using script metainformation have not been discussed. This isn't just a > game of labeling things, is it? There must be something practical to be > achieved, even if it is practical only for the progress of theoretical > research (in linguistics, for example). But what _are_ the realistic > applications? IIRC we've discussed this here when LTRU started. From my POV it's mainly a kludge. Without Unicode if I get Latin-1 or similar charsets I know, or rather my applications know, that I can read it / they can handle it. Without Unicode if I get some Cyrillic charset I know that I can't read it. Maybe I can display it, but one year in school some decades ago isn't good enough for me to decode say the charset registrations for "obscure" (my POV) kz-charsets. For other traditional charsets it's perfectly clear that I can't read it, and my applications can't display it. This crude but working zoo^Wsystem of traditional charsets is about to be destroyed by Unicode. Folks get documents and have no clue at all how much of it they can display or read. Maybe it's orcish written in Shavian. Therefore they need scripts as a hint, e.g. "Latn" means "there's a good chance that I can read and display some of these Unicode points" (modulo conversion to windows-1252 depending on the application). "Shav" means "forget it, don't waste time trying to download this 2.5MB PDF with a modem unless you have fonts for that script". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 27 10:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSLA-0000rJ-Np; Fri, 27 Oct 2006 10:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSL9-0000r6-Qf for ltru@lists.ietf.org; Fri, 27 Oct 2006 10:05:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdSL5-0008G9-H5 for ltru@lists.ietf.org; Fri, 27 Oct 2006 10:05:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GdSL5-00031Q-3x for ltru@lists.ietf.org; Fri, 27 Oct 2006 10:05:39 -0400 Date: Fri, 27 Oct 2006 10:05:39 -0400 To: ltru@lists.ietf.org Subject: Re: [Ltru] Re: IPA as a script Message-ID: <20061027140538.GA1043@ccil.org> References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie> <4540D001.1060100@kotus.fi> <4541C8DC.4BB8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4541C8DC.4BB8@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Jukka K. Korpela scripsit: > What puzzles me most is that the _reasons_ for registering scripts and > using script metainformation have not been discussed. This isn't just a > game of labeling things, is it? There must be something practical to be > achieved, even if it is practical only for the progress of theoretical > research (in linguistics, for example). But what _are_ the realistic > applications? Let us return to first principles. Why tag documents with language at all? Because if they are in the wrong language (with respect to the end user) they are utterly unreadable. Give me a document in Finnish and I can't do anything with it (except recycle the paper, if it's printed). For you it's quite otherwise. Similarly, why tag documents with script? Because even if the language is English (the only language I fully command), if the script is Braille, it might as well be in Finnish for all I can do with it. And while I like Frank can decipher short stretches of English in Cyrillic, I certainly wouldn't read a whole book unless my life depended on it. The utility of script tagging is completely separate from questions of encoding and fonts. It applies just as much to paper documents as to electronic ones, and its utility would remain even if all systems were equally Unicode-capable and had very complete sets of fonts. Fortunately, most languages are written in only one script (a) except in very particular circumstances, such as IPA and Braille transcription. Some languages, however, are (b) very frequently written in alien scripts (Chinese and Yiddish, e.g.), some languages have (c) no dominant script, and some languages have (d) changed scripts, sometimes repeatedly. Factors a through d, taken jointly, make it worthwhile to allow script metainformation to be incorporated into language tags. Frank Ellerman scripsit: > Maybe it's orcish written in Shavian. Therefore they need scripts as > a hint, e.g. "Latn" means "there's a good chance that I can read and > display some of these Unicode points" (modulo conversion to windows-1252 > depending on the application). "Shav" means "forget it, don't waste > time trying to download this 2.5MB PDF with a modem unless you have > fonts for that script". Don't bother at all, in fact, unless you can read Shavian script -- the fonts make that possible, but not easy. (Not to mention the fact that Orkish cannot be written in Shavian, which lacks some necessary letters.) -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 27 15:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXUu-0002Xw-T0; Fri, 27 Oct 2006 15:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXUt-0002Wo-4G for ltru@lists.ietf.org; Fri, 27 Oct 2006 15:36:07 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdXUp-0005IN-Jo for ltru@lists.ietf.org; Fri, 27 Oct 2006 15:36:07 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=o5fXX30N+lF+aQxZRao6b2a59OQzaBedxcBd5twkrVfQgEIKrRbAovzlpqe9L9Ml; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.160] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GdXUn-0003Y4-LI for ltru@lists.ietf.org; Fri, 27 Oct 2006 15:36:02 -0400 Message-ID: <005701c6f9ff$1f4c2b20$6601a8c0@oemcomputer> From: "Randy Presuhn" To: References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie><4540D001.1060100@kotus.fi><4541C8DC.4BB8@xyzzy.claranet.de> <20061027140538.GA1043@ccil.org> Subject: Re: [Ltru] Re: IPA as a script Date: Fri, 27 Oct 2006 12:35:54 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6a12c9f035d5f75c06089a9f5f5753bf8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: > Sent: Friday, October 27, 2006 7:05 AM > Subject: Re: [Ltru] Re: IPA as a script ... > The utility of script tagging is completely separate from questions of > encoding and fonts. It applies just as much to paper documents as to > electronic ones, and its utility would remain even if all systems were > equally Unicode-capable and had very complete sets of fonts. I think this is a very important point. The inclusion of script (or any other information conveyed by a tag) is not for the convenience of the software. (Even admitting that there are a few cases where knowledge of the language *might* be used by an excessively refined rendering system.) > Fortunately, most languages are written in only one script (a) except > in very particular circumstances, such as IPA and Braille transcription. > Some languages, however, are (b) very frequently written in alien scripts > (Chinese and Yiddish, e.g.), some languages have (c) no dominant script, > and some languages have (d) changed scripts, sometimes repeatedly. > Factors a through d, taken jointly, make it worthwhile to allow script > metainformation to be incorporated into language tags. And the key question here is whether this WG is willing to produce a coherent framework for handling phonetic / phonemic transcriptions in general, or would prefer to give a partial solution that addresses the most widely-used one, namely IPA. If the WG goes the general route, then the question of how much information (phonetic vs phonemic, transcription "system", etc.) needs to be encoded in the subtag(s) should be decided. I think, however, that we need to keep in mind the reason for tagging in the first place: to be able to label content in a way so that users can select information in representations that they think they might be able to use. So, going back to the days when I did linguistics work, what would *I* have cared about when searching for documents? (1) language (of course) and possibly region (2) script - I'm comfortable with IPA, and not the others, including the "Latin only" ones I've used (3) phonetic / phonemic / broad / narrow distinctions. (1) and (2) fit in nicely with what we already have. What about (3)? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 27 18:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaWL-0007tj-Vn; Fri, 27 Oct 2006 18:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaWK-0007te-U4 for ltru@lists.ietf.org; Fri, 27 Oct 2006 18:49:48 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdaWJ-0007ZQ-Jl for ltru@lists.ietf.org; Fri, 27 Oct 2006 18:49:48 -0400 Received: from [10.72.76.78] (snvvpn2-10-72-76-c78.corp.yahoo.com [10.72.76.78]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9RMnWKo053283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Oct 2006 15:49:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=izjRS87nBfXjOjGaHQrQaZlsoG0TSz6oro/W6ARBHOhJL5YKJQ/A7TkMLGv7wabI Message-ID: <45428CFA.4080706@yahoo-inc.com> Date: Fri, 27 Oct 2006 15:49:30 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: IPA as a script References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie><4540D001.1060100@kotus.fi><4541C8DC.4BB8@xyzzy.claranet.de> <20061027140538.GA1043@ccil.org> <005701c6f9ff$1f4c2b20$6601a8c0@oemcomputer> In-Reply-To: <005701c6f9ff$1f4c2b20$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > > I think this is a very important point. The inclusion of script (or any > other information conveyed by a tag) is not for the convenience of > the software. (Even admitting that there are a few cases where > knowledge of the language *might* be used by an excessively refined > rendering system.) > You mean "... is not *just* for the convenience of the software", right? Software can use language tags to extract meaning from content. There are many applications which need to know the language in order to provide the best processing (which sometimes includes rendering). Currently many of these must use heuristics to determine language. Web search, for example, depends on the language of the content and search terms. More prevalent and consistent use of language tags would help generalized search applications greatly. Their non-use in applications of this nature is more a function of the relative lack of consistent use than a lack of necessity. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 27 23:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdefc-0006BZ-Hd; Fri, 27 Oct 2006 23:15:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdefb-0006BP-CM for ltru@ietf.org; Fri, 27 Oct 2006 23:15:39 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdefZ-0005R3-St for ltru@ietf.org; Fri, 27 Oct 2006 23:15:39 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LBMLIJn55jJIcM07oBhW7Jz2NgT+TdTjevGWFe1AvS4uXBePJHPEuh4Phwwatozz; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.37.160] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GdefX-0005Ad-8e for ltru@ietf.org; Fri, 27 Oct 2006 23:15:35 -0400 Message-ID: <000801c6fa3f$4b5ce2a0$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <11150EA5-38E9-4451-A4E9-527B6852BFBA@egt.ie><4540D001.1060100@kotus.fi><4541C8DC.4BB8@xyzzy.claranet.de> <20061027140538.GA1043@ccil.org> <005701c6f9ff$1f4c2b20$6601a8c0@oemcomputer> <45428CFA.4080706@yahoo-inc.com> Subject: Re: [Ltru] Re: IPA as a script Date: Fri, 27 Oct 2006 20:15:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee6589bc50a6c7e64c4bea1dcc274a9a6f6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" > Cc: > Sent: Friday, October 27, 2006 3:49 PM > Subject: Re: [Ltru] Re: IPA as a script > > Randy Presuhn wrote: > > > > I think this is a very important point. The inclusion of script (or any > > other information conveyed by a tag) is not for the convenience of > > the software. (Even admitting that there are a few cases where > > knowledge of the language *might* be used by an excessively refined > > rendering system.) > > > > You mean "... is not *just* for the convenience of the software", right? Actualy, I did not. The primary motivations for language tagging have to do with helping humans get stuff they can understand. Everything else is just "gravy", in my personal opinion. This very old-fashioned attitude is consistent with BCP 18, which, even while giving many other reasons why language tagging is desirable, as I read it gives the most emphasis to the needs of humans to obtain material in languages they can understand. > Software can use language tags to extract meaning from content. There > are many applications which need to know the language in order to > provide the best processing (which sometimes includes rendering). > Currently many of these must use heuristics to determine language. Web > search, for example, depends on the language of the content and search > terms. I'd still categorize this as finding material in a language the user wants. Yes, I realize there are additional implications for non-isolating / inflected languages, but adding transcriptions to the mix doesn't change this problem one bit. The question of whether to add support for IPA as a one-off or as part of a general framework for transcriptions is what this thread is all about. There are all sorts of language-related attributes one might want to include, but if we are to finish this work in a reasonable time, we should stick to the minimum set that can handle what we see as the important use cases. > More prevalent and consistent use of language tags would help > generalized search applications greatly. Their non-use in applications > of this nature is more a function of the relative lack of consistent use > than a lack of necessity. ... No argument. But the only reason for doing this at all is to reduce the amount of unintelligible stuff returned in response to a user's request. And so the question remains: what is a reasonable level of granularity for handling transcriptions? For example, do we need something horribly elaborate like -{transcription}-{phonetic/phonemic/morphological/whatever}-{system} to further qualify these? Or would one simply infer the granularity of the transcription from the system, even though doing so would prevent doing a wildcard search for, say, any phonetic transcriptions of frs, regardless of the system used? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 00:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdfpP-0006aK-6y; Sat, 28 Oct 2006 00:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdfpO-0006a6-1p for ltru@ietf.org; Sat, 28 Oct 2006 00:29:50 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdfpL-0001IQ-Pk for ltru@ietf.org; Sat, 28 Oct 2006 00:29:50 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061028042943.FJSC9984.mta9.adelphia.net@DGBP7M81> for ; Sat, 28 Oct 2006 00:29:43 -0400 Message-ID: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 27 Oct 2006 21:29:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > FYI, mainly for our editors. Martin. If I use the online XML2RFC, do I get the new boilerplate for free? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 (still waiting for next 4646bis draft before I can do mine) http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 00:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdfsw-0006P9-Ev; Sat, 28 Oct 2006 00:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdfsv-0006P4-FF for ltru@ietf.org; Sat, 28 Oct 2006 00:33:29 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdfsu-0001uh-6N for ltru@ietf.org; Sat, 28 Oct 2006 00:33:29 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061028043327.DAHV3601.mta11.adelphia.net@DGBP7M81> for ; Sat, 28 Oct 2006 00:33:27 -0400 Message-ID: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 27 Oct 2006 21:33:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > And the key question here is whether this WG is willing to produce a > coherent framework for handling phonetic / phonemic transcriptions in > general, or would prefer to give a partial solution that addresses the > most widely-used one, namely IPA. If the WG goes the general route, > then the question of how much information (phonetic vs phonemic, > transcription "system", etc.) needs to be encoded in the subtag(s) > should be decided. I'm all for using the framework we already designed into the 4646 syntax: extension subtags. The question of "how much information" would then be offloaded onto the individual or body creating the extension RFC. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 01:48:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdh39-00086i-4G; Sat, 28 Oct 2006 01:48:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdh37-00086Z-Dr for ltru@ietf.org; Sat, 28 Oct 2006 01:48:05 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdh36-0005Pi-0z for ltru@ietf.org; Sat, 28 Oct 2006 01:48:05 -0400 Received: from [10.72.76.78] (snvvpn2-10-72-76-c78.corp.yahoo.com [10.72.76.78]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9S5lwgR074223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Oct 2006 22:47:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Ri4xJ4VMVPLezmB36ny9NBVJZOp5vtTzogm1PGt9LBmwS4HNjk7vl/RAE0yYpYc6 Message-ID: <4542EF0D.1090706@yahoo-inc.com> Date: Fri, 27 Oct 2006 22:47:57 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> In-Reply-To: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Yes. Or download the darned thing. The Tcl/Tk interface makes generating a new copy even easier than the Web interface. And, in your case, avoids the Really Big Upload. > (still waiting for next 4646bis draft before I can do mine) You'll be waiting until the pub-freeze for IETF 67 ends. Addison Doug Ewell wrote: > Martin Duerst wrote: > >> FYI, mainly for our editors. Martin. > > If I use the online XML2RFC, do I get the new boilerplate for free? > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > (still waiting for next 4646bis draft before I can do mine) > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 05:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdkRM-00070I-7w; Sat, 28 Oct 2006 05:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdkRL-00070D-Fy for ltru@ietf.org; Sat, 28 Oct 2006 05:25:19 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdkRG-0003a8-Kf for ltru@ietf.org; Sat, 28 Oct 2006 05:25:19 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9S9PBGp008688 for ; Sat, 28 Oct 2006 18:25:11 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1749_35b60f56_6666_11db_9fca_0014221f2a2d; Sat, 28 Oct 2006 18:25:10 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40224) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 28 Oct 2006 18:24:48 +0900 Message-Id: <6.0.0.20.2.20061028160314.0686c810@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 28 Oct 2006 16:10:59 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate In-Reply-To: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 13:29 06/10/28, Doug Ewell wrote: >Martin Duerst wrote: > >> FYI, mainly for our editors. Martin. > >If I use the online XML2RFC, do I get the new boilerplate for free? Contrary to Addison, I'm not sure. First, as of today, http://xml.resource.org/ still has version 1.31; you have to wait for the announced 1.32. Second, please check whether you need to change the attribute ipr="full3978" in the element (top). Regards, Martin. >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >(still waiting for next 4646bis draft before I can do mine) >http://users.adelphia.net/~dewell/ >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 06:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdl45-0000RW-6R; Sat, 28 Oct 2006 06:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdetG-0008Oc-83 for ltru@ietf.org; Fri, 27 Oct 2006 23:29:46 -0400 Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdetE-0007VN-Vn for ltru@ietf.org; Fri, 27 Oct 2006 23:29:46 -0400 Received: from eastrmwml04.mgt.cox.net ([172.18.52.69]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061028032947.JIOT27677.eastrmmtao04.cox.net@eastrmwml04.mgt.cox.net>; Fri, 27 Oct 2006 23:29:47 -0400 Message-ID: <9484838.1162006185975.JavaMail.root@eastrmwml04.mgt.cox.net> Date: Fri, 27 Oct 2006 23:29:45 -0400 From: volksawagen_auto_uk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) Sensitivity: Normal X-Spam-Score: 1.6 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Sat, 28 Oct 2006 06:05:20 -0400 Subject: [Ltru] VOLKSWAGEN END OF YEAR PROMO. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: claimsagent_swankjeff@yahoo.ie List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org THE LOTTERY DEPARTMENT =20 Volkswagen Automobiles=20 22 Garden Close, Stamford,=20 Lincs, PE9 2YP, London=20 United Kingdom=20 www.volkswagen.co.uk=20 =20 OFFICIAL PRIZE NOTIFICATION=20 This is to inform you that have been selected for a cash prize of =C2=A3100= ,000.00 (ONE Hundred Thousand Great British Pounds) and a brand new Volkswagen Car,= International=20 Programs held on the 27TH of OCTOBER 2006 in the London Uk. =20 Description of Volkswagen Car to be shipped to you. (Shipped to you Free) =20 BRAND:........................................Fifth Edition MODEL:.......................................2006 Model COLOUR:......................................Metallic Blue ENGINE TYPE:...........................1973cc 4-cylinder=20 POWER:........................................145bhp TRANSMISSIONS:.......................Adaptive Automatic Transmission=20 FUEL:............................................29.1mpg (combined The selection process was carried out through random selection in our compu= terized=20 Email selection system (ess) from a database of over 250,000 email addres= ses drawn from all the continents of the world. =20 The Volkswagen Car Promotional Lottery is approved by the British Gaming Bo= ard and its also Licensed by the International Association of Gaming Regula= tors (IAGR). This lottery is the 3rd of its kind and we intend to sensitize= the public. =20 To begin the claiming process of your prize you are to contact our accredi= ted claims officer with the information you shall find below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. robort van 22 Garden Close, Stamford , Lincs , PE9 2YP , London United Kingdom E-mail: claimsagent_swankjef@mail2world.com Phone Number: +447031972566 Fax Number:+441375643277 Time to call (6am to 6pm London time) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please provide him with your secret pin cFrom ltru-bounces@ietf.org Sat Oct 28 06:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdl45-0000RW-6R; Sat, 28 Oct 2006 06:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdetG-0008Oc-83 for ltru@ietf.org; Fri, 27 Oct 2006 23:29:46 -0400 Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdetE-0007VN-Vn for ltru@ietf.org; Fri, 27 Oct 2006 23:29:46 -0400 Received: from eastrmwml04.mgt.cox.net ([172.18.52.69]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061028032947.JIOT27677.eastrmmtao04.cox.net@eastrmwml04.mgt.cox.net>; Fri, 27 Oct 2006 23:29:47 -0400 Message-ID: <9484838.1162006185975.JavaMail.root@eastrmwml04.mgt.cox.net> Date: Fri, 27 Oct 2006 23:29:45 -0400 From: volksawagen_auto_uk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) Sensitivity: Normal X-Spam-Score: 1.6 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Sat, 28 Oct 2006 06:05:20 -0400 Subject: [Ltru] VOLKSWAGEN END OF YEAR PROMO. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: claimsagent_swankjeff@yahoo.ie List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org THE LOTTERY DEPARTMENT =20 Volkswagen Automobiles=20 22 Garden Close, Stamford,=20 Lincs, PE9 2YP, London=20 United Kingdom=20 www.volkswagen.co.uk=20 =20 OFFICIAL PRIZE NOTIFICATION=20 This is to inform you that have been selected for a cash prize of =C2=A3100= ,000.00 (ONE Hundred Thousand Great British Pounds) and a brand new Volkswagen Car,= International=20 Programs held on the 27TH of OCTOBER 2006 in the London Uk. =20 Description of Volkswagen Car to be shipped to you. (Shipped to you Free) =20 BRAND:........................................Fifth Edition MODEL:.......................................2006 Model COLOUR:......................................Metallic Blue ENGINE TYPE:...........................1973cc 4-cylinder=20 POWER:........................................145bhp TRANSMISSIONS:.......................Adaptive Automatic Transmission=20 FUEL:............................................29.1mpg (combined The selection process was carried out through random selection in our compu= terized=20 Email selection system (ess) from a database of over 250,000 email addres= ses drawn from all the continents of the world. =20 The Volkswagen Car Promotional Lottery is approved by the British Gaming Bo= ard and its also Licensed by the International Association of Gaming Regula= tors (IAGR). This lottery is the 3rd of its kind and we intend to sensitize= the public. =20 To begin the claiming process of your prize you are to contact our accredi= ted claims officer with the information you shall find below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. robort van 22 Garden Close, Stamford , Lincs , PE9 2YP , London United Kingdom E-mail: claimsagent_swankjef@mail2world.com Phone Number: +447031972566 Fax Number:+441375643277 Time to call (6am to 6pm London time) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please provide him with your secret pin code which is x7pwyz2006 and your r= eference =20 Number WV: 12052006/21.You are also advised to provide him with the under l= isted information As soon as possible: Claims Requirements:=20 1.Name in full-------------------------------------------------------------= --=20 2.Address------------------------------------------------------------------= --=20 3.Sex----------------------------------------------------------------------= -----=20 4.Nationality--------------------------------------------------------------= ----=20 5.Maritual Status----------------------------------------------------------= -=20 6. Age---------------------------------------------------------------------= -----=20 7.Next Of Kin--------------------------------------------------------------= ---=20 8.Occupation---------------------------------------------------------------= -=20 9.Phone/Fax----------------------------------------------------------------= --=20 10.Present Country--------------------------------------------------------= =20 11.Winning Email Address:---------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 If you do not contact your claims agent within 7 working days of this noti= fication, your winnings would be revoked. Winners are advised to keep their= winning details/information from the public to avoid fraudulent claim (IM= PORTANT)pending the transfer/claim by Winner.=20 *Winner under the age of 18 are automatically disqualified.=20 *Staff of the Volks Wagen Company are not to partake in this Car Promotion= al Lottery.=20 Accept my hearty congratulations once again!=20 With Best Regards=20 =20 Mr swank jefferson Lottery Manager. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 06:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdl45-0000RN-43; Sat, 28 Oct 2006 06:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdesz-0007Hh-Ri for ltru@ietf.org; Fri, 27 Oct 2006 23:29:29 -0400 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdesu-0007Sg-IH for ltru@ietf.org; Fri, 27 Oct 2006 23:29:29 -0400 Received: from eastrmwml04.mgt.cox.net ([172.18.52.69]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061028032926.OCSW19165.eastrmmtao03.cox.net@eastrmwml04.mgt.cox.net>; Fri, 27 Oct 2006 23:29:26 -0400 Message-ID: <11199465.1162006165572.JavaMail.root@eastrmwml04.mgt.cox.net> Date: Fri, 27 Oct 2006 23:29:25 -0400 From: volksawagen_auto_uk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) Sensitivity: Normal X-Spam-Score: 1.6 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Sat, 28 Oct 2006 06:05:20 -0400 Subject: [Ltru] VOLKSWAGEN END OF YEAR PROMO. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: claimsagent_swankjeff@yahoo.ie List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org THE LOTTERY DEPARTMENT =20 Volkswagen Automobiles=20 22 Garden Close, Stamford,=20 Lincs, PE9 2YP, London=20 United Kingdom=20 www.volkswagen.co.uk=20 =20 OFFICIAL PRIZE NOTIFICATION=20 This is to inform you that have been selected foode which is x7pwyz2006 and your r= eference =20 Number WV: 12052006/21.You are also advised to provide him with the under l= isted information As soon as possible: Claims Requirements:=20 1.Name in full-------------------------------------------------------------= --=20 2.Address------------------------------------------------------------------= --=20 3.Sex----------------------------------------------------------------------= -----=20 4.Nationality--------------------------------------------------------------= ----=20 5.Maritual Status----------------------------------------------------------= -=20 6. Age---------------------------------------------------------------------= -----=20 7.Next Of Kin--------------------------------------------------------------= ---=20 8.Occupation---------------------------------------------------------------= -=20 9.Phone/Fax----------------------------------------------------------------= --=20 10.Present Country--------------------------------------------------------= =20 11.Winning Email Address:---------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 If you do not contact your claims agent within 7 working days of this noti= fication, your winnings would be revoked. Winners are advised to keep their= winning details/information from the public to avoid fraudulent claim (IM= PORTANT)pending the transfer/claim by Winner.=20 *Winner under the age of 18 are automatically disqualified.=20 *Staff of the Volks Wagen Company are not to partake in this Car Promotion= al Lottery.=20 Accept my hearty congratulations once again!=20 With Best Regards=20 =20 Mr swank jefferson Lottery Manager. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 06:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdl45-0000RN-43; Sat, 28 Oct 2006 06:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdesz-0007Hh-Ri for ltru@ietf.org; Fri, 27 Oct 2006 23:29:29 -0400 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdesu-0007Sg-IH for ltru@ietf.org; Fri, 27 Oct 2006 23:29:29 -0400 Received: from eastrmwml04.mgt.cox.net ([172.18.52.69]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061028032926.OCSW19165.eastrmmtao03.cox.net@eastrmwml04.mgt.cox.net>; Fri, 27 Oct 2006 23:29:26 -0400 Message-ID: <11199465.1162006165572.JavaMail.root@eastrmwml04.mgt.cox.net> Date: Fri, 27 Oct 2006 23:29:25 -0400 From: volksawagen_auto_uk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) Sensitivity: Normal X-Spam-Score: 1.6 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Sat, 28 Oct 2006 06:05:20 -0400 Subject: [Ltru] VOLKSWAGEN END OF YEAR PROMO. X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: claimsagent_swankjeff@yahoo.ie List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org THE LOTTERY DEPARTMENT =20 Volkswagen Automobiles=20 22 Garden Close, Stamford,=20 Lincs, PE9 2YP, London=20 United Kingdom=20 www.volkswagen.co.uk=20 =20 OFFICIAL PRIZE NOTIFICATION=20 This is to inform you that have been selected for a cash prize of =C2=A3100= ,000.00 (ONE Hundred Thousand Great British Pounds) and a brand new Volkswagen Car,= International=20 Programs held on the 27TH of OCTOBER 2006 in the London Uk. =20 Description of Volkswagen Car to be shipped to you. (Shipped to you Free) =20 BRAND:........................................Fifth Edition MODEL:.......................................2006 Model COLOUR:......................................Metallic Blue ENGINE TYPE:...........................1973cc 4-cylinder=20 POWER:........................................145bhp TRANSMISSIONS:.......................Adaptive Automatic Transmission=20 FUEL:............................................29.1mpg (combined The selection process was carried out through random selection in our compu= terized=20 Email selection system (ess) from a database of over 250,000 email addres= ses drawn from all the continents of the world. =20 The Volkswagen Car Promotional Lottery is approved by the British Gaming Bo= ard and its also Licensed by the International Association of Gaming Regula= tors (IAGR). This lottery is the 3rd of its kind and we intend to sensitize= the public. =20 To begin the claiming process of your prize you are to contact our accredi= ted claims officer with the information you shall find below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. robort van 22 Garden Close, Stamford , Lincs , PE9 2YP , London United Kingdom E-mail: claimsagent_swankjef@mail2world.com Phone Number: +447031972566 Fax Number:+441375643277 Time to call (6am to 6pm London time) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please provide him with your secret pin code which is x7pwyz2006 and your r= eference =20 Number WV: 12052006/21.You are also advised to provide him with the under l= isted information As soon as possible: Claims Requirements:=20 1.Name in full-------------------------------------------------------------= --=20 2.Address------------------------------------------------------------------= --=20 3.Sex----------------------------------------------------------------------= -----=20 4.Nationality--------------------------------------------------------------= ----=20 5.Maritual Status----------------------------------------------------------= -=20 6. Age---------------------------------------------------------------------= -----=20 7.Next Of Kin--------------------------------------------------------------= ---=20 8.Occupation---------------------------------------------------------------= -=20 9.Phone/Fax----------------------------------------------------------------= --=20 10.Present Country--------------------------------------------------------= =20 11.Winning Email Address:---------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 If you do not contact your claims agent within 7 working days of this noti= fication, your winnings would be revoked. Winners are advised to keep their= winning details/information from the public to avoid fraudulent claim (IM= PORTANT)pending the transfer/claim by Winner.=20 *Winner under the age of 18 are automatically disqualified.=20 *Staff of the Volks Wagen Company are not to partake in this Car Promotion= al Lottery.=20 Accept my hearty congratulations once again!=20 With Best Regards=20 =20 Mr swank jefferson Lottery Manager. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru r a cash prize of =C2=A3100= ,000.00 (ONE Hundred Thousand Great British Pounds) and a brand new Volkswagen Car,= International=20 Programs held on the 27TH of OCTOBER 2006 in the London Uk. =20 Description of Volkswagen Car to be shipped to you. (Shipped to you Free) =20 BRAND:........................................Fifth Edition MODEL:.......................................2006 Model COLOUR:......................................Metallic Blue ENGINE TYPE:...........................1973cc 4-cylinder=20 POWER:........................................145bhp TRANSMISSIONS:.......................Adaptive Automatic Transmission=20 FUEL:............................................29.1mpg (combined The selection process was carried out through random selection in our compu= terized=20 Email selection system (ess) from a database of over 250,000 email addres= ses drawn from all the continents of the world. =20 The Volkswagen Car Promotional Lottery is approved by the British Gaming Bo= ard and its also Licensed by the International Association of Gaming Regula= tors (IAGR). This lottery is the 3rd of its kind and we intend to sensitize= the public. =20 To begin the claiming process of your prize you are to contact our accredi= ted claims officer with the information you shall find below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mr. robort van 22 Garden Close, Stamford , Lincs , PE9 2YP , London United Kingdom E-mail: claimsagent_swankjef@mail2world.com Phone Number: +447031972566 Fax Number:+441375643277 Time to call (6am to 6pm London time) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please provide him with your secret pin code which is x7pwyz2006 and your r= eference =20 Number WV: 12052006/21.You are also advised to provide him with the under l= isted information As soon as possible: Claims Requirements:=20 1.Name in full-------------------------------------------------------------= --=20 2.Address------------------------------------------------------------------= --=20 3.Sex----------------------------------------------------------------------= -----=20 4.Nationality--------------------------------------------------------------= ----=20 5.Maritual Status----------------------------------------------------------= -=20 6. Age---------------------------------------------------------------------= -----=20 7.Next Of Kin--------------------------------------------------------------= ---=20 8.Occupation---------------------------------------------------------------= -=20 9.Phone/Fax----------------------------------------------------------------= --=20 10.Present Country--------------------------------------------------------= =20 11.Winning Email Address:---------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 If you do not contact your claims agent within 7 working days of this noti= fication, your winnings would be revoked. Winners are advised to keep their= winning details/information from the public to avoid fraudulent claim (IM= PORTANT)pending the transfer/claim by Winner.=20 *Winner under the age of 18 are automatically disqualified.=20 *Staff of the Volks Wagen Company are not to partake in this Car Promotion= al Lottery.=20 Accept my hearty congratulations once again!=20 With Best Regards=20 =20 Mr swank jefferson Lottery Manager. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 12:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdrEv-0001n1-Lj; Sat, 28 Oct 2006 12:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdrEu-0001mw-Qt for ltru@ietf.org; Sat, 28 Oct 2006 12:40:56 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdrEq-0006hj-He for ltru@ietf.org; Sat, 28 Oct 2006 12:40:56 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061028164047.XWXM9984.mta9.adelphia.net@DGBP7M81>; Sat, 28 Oct 2006 12:40:47 -0400 Message-ID: <000f01c6faaf$d2ec4c40$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> <6.0.0.20.2.20061028160314.0686c810@localhost> Subject: Re: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate Date: Sat, 28 Oct 2006 09:40:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> If I use the online XML2RFC, do I get the new boilerplate for free? > > Contrary to Addison, I'm not sure. First, as of today, > http://xml.resource.org/ still has version 1.31; you have to wait for > the announced 1.32. There is a version 1.32pre2 available at http://xml.resource.org/experimental.html, with suitable warnings about being a development version and living on the edge and so forth. The text claims that this version supports the new boilerplate. I suppose I could use both, then compare the outputs and make sure there are no undesired differences. > Second, please check whether you need to change the attribute > ipr="full3978" in the element (top). To what? "full4748"? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 12:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdrRS-0005xq-Fj; Sat, 28 Oct 2006 12:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdrRR-0005uF-Ql for ltru@ietf.org; Sat, 28 Oct 2006 12:53:53 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdrRQ-0008G7-7K for ltru@ietf.org; Sat, 28 Oct 2006 12:53:53 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061028165351.AIG13047.mta13.adelphia.net@DGBP7M81>; Sat, 28 Oct 2006 12:53:51 -0400 Message-ID: <001101c6fab1$a5fffbd0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> <4542EF0D.1090706@yahoo-inc.com> Subject: Re: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate Date: Sat, 28 Oct 2006 09:53:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Yes. Or download the darned thing. The Tcl/Tk interface makes > generating a new copy even easier than the Web interface. I remember investigating this over a year ago, and balking at the idea of installing a new scripting subsystem. Probably it reminded me of the MKS or Cygwin approach of "completely convert your Windows machine into a Unix lookalike." > And, in your case, avoids the Really Big Upload. I solved the RBU problem by uploading from home, using cable modem instead of the "faster" T1 at work. >> (still waiting for next 4646bis draft before I can do mine) > > You'll be waiting until the pub-freeze for IETF 67 ends. Thanks, I had forgotten about the freeze. I'm still surprised that list discussion on these proposed changes has dropped to almost zero. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Oct 28 14:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdse0-0003Wf-De; Sat, 28 Oct 2006 14:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdsdz-0003UC-21 for ltru@ietf.org; Sat, 28 Oct 2006 14:10:55 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdsdw-00044C-L7 for ltru@ietf.org; Sat, 28 Oct 2006 14:10:54 -0400 Received: from [10.72.76.78] (snvvpn2-10-72-76-c78.corp.yahoo.com [10.72.76.78]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k9SIAabU095783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Oct 2006 11:10:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=FDjkBFlrDvfCoxLxbhBrlRM8VF+J/b0Sk2qPH6jI+Tg1URG0xrOZ+fOphBO6pccj Message-ID: <45439D1C.5000600@yahoo-inc.com> Date: Sat, 28 Oct 2006 11:10:36 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] OT editorial chitchat about tools References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> <4542EF0D.1090706@yahoo-inc.com> <001101c6fab1$a5fffbd0$6501a8c0@DGBP7M81> In-Reply-To: <001101c6fab1$a5fffbd0$6501a8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > Addison Phillips wrote: > >> Yes. Or download the darned thing. The Tcl/Tk interface makes >> generating a new copy even easier than the Web interface. > > I remember investigating this over a year ago, and balking at the idea > of installing a new scripting subsystem. Probably it reminded me of the > MKS or Cygwin approach of "completely convert your Windows machine into > a Unix lookalike." I've found that Tcl is more-or-less and install-and-forget experience. I'm on my third or fourth machine since starting to use xml2rfc. Basically, I just download the ActiveState Tcl for Windows, install it, and run xml2rfc. It hasn't interfered with anything else, especially since I don't use Tcl for anything. In fact, this morning I had to go looking for the darned thing just to remember what it was called! I Yahoo-ed "tcl" and "Windows" and it's the first item. Of course, my machine also has MKS, vim, and a host of Unixy things installed, so your experience may vary. >> >> You'll be waiting until the pub-freeze for IETF 67 ends. > > Thanks, I had forgotten about the freeze. I'm still surprised that list > discussion on these proposed changes has dropped to almost zero. > Yes. I'm sorry to have missed that particular deadline. But after it lifts I don't doubt that we'll make rapid progress. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 29 01:40:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge3PG-0005LQ-KD; Sun, 29 Oct 2006 01:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge3Oj-0005JK-Hb for ltru@ietf.org; Sun, 29 Oct 2006 01:39:53 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge3Of-00007M-37 for ltru@ietf.org; Sun, 29 Oct 2006 01:39:53 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Sat, 28 Oct 2006 22:39:46 -0700 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Sat, 28 Oct 2006 22:39:46 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {EC36D553-177B-4944-B6E4-DCEB90C802DB} MIME-Version: 1.0 x-cr-hashedpuzzle: KOg= Fr60 GtVT HICy Iwgc K0Rf Lnfy NFB0 Qq3l Q8pr R/x2 TUbk TaAX Tc+q VLNv VWzn; 2; ZABlAHcAZQBsAGwAQABhAGQAZQBsAHAAaABpAGEALgBuAGUAdAA7AGwAdAByAHUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {EC36D553-177B-4944-B6E4-DCEB90C802DB}; cABlAHQAZQByAGMAbwBuAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Sun, 29 Oct 2006 05:39:18 GMT; UgBFADoAIABbAEwAdAByAHUAXQAgAFIAZQA6ACAASQBQAEEAIABhAHMAIABhACAAcwBjAHIAaQBwAHQA Content-Class: urn:content-classes:message Subject: RE: [Ltru] Re: IPA as a script Date: Sat, 28 Oct 2006 22:39:17 -0700 Message-ID: <19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: IPA as a script Thread-Index: Acb6Sjma27BYLcErTQaY1pzCpwgSdgA0as7Q References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> From: Peter Constable To: Doug Ewell , LTRU Working Group X-OriginalArrivalTime: 29 Oct 2006 05:39:46.0433 (UTC) FILETIME=[A482CF10:01C6FB1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630864547==" Errors-To: ltru-bounces@ietf.org --===============0630864547== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Class: urn:content-classes:message QXMgSSBzdWdnZXN0ZWQgaW4gdGhlIHBhc3QsIEkgdGhpbmsgcmVsZWdhdGluZyB0cmFuc2NyaXB0 aW9uIGVudGlyZWx5IHRvIGFuIGV4dGVuc2lvbiB3b3VsZCBiZSB1bmRlc2lyYWJsZSBiZWNhdXNl IGl0IHdvdWxkIGJlIGlnbm9yZWQgYnkgYW55IHByb2Nlc3MgdGhhdCBoYWQgbm8ga25vd2xlZGdl IG9mIHRoZSBleHRlbnNpb24sIHdoaWNoIHdvdWxkIGJlIG1hbnkuIA0KDQpPciB0byBwdXQgaXQg aW4gUmFuZHkncyB0ZXJtcywgaW4gdGhlIGNhc2Ugb2YgYSB0eXBpY2FsIGltcGxlbWVudGF0aW9u IGFjY2Vzc2luZyBhIHNlcnZlciB0aGF0IGhhZCB0cmFuc2NyaXB0aW9uIGFuZCAibm9ybWFsIiBj b250ZW50LCBpdCB3b3VsZCBmYWlsIHRvIGRlbGl2ZXIgd2hhdCB0aGUgdXNlciB3YW50ZWQgLyBm YWlsIHRvIGZpbHRlciBvdXQgdW5pbnRlbGxpZ2libGUgc3R1ZmYuDQoNCldoYXQgd291bGQgd29y ayBiZXR0ZXIgd291bGQgYmUgdG8gaGF2ZSBhIHNjcmlwdC12YXJpYW50IHN1YnRhZyBmb3IgTGF0 aW4tYmFzZWQgdHJhbnNjcmlwdGlvbnMgYW5kIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiBkaWZmZXJlbnQga2luZHMgb2YgdHJhbnNjcmlwdGlvbiAvIHRyYW5zbGl0 ZXJhdGlvbi4NCg0KDQoNClBldGVyDQoNCg0KDQpGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3 ZWxsQGFkZWxwaGlhLm5ldF0gDQoNCj4gQW5kIHRoZSBrZXkgcXVlc3Rpb24gaGVyZSBpcyB3aGV0 aGVyIHRoaXMgV0cgaXMgd2lsbGluZyB0byBwcm9kdWNlIGEgDQo+IGNvaGVyZW50IGZyYW1ld29y ayBmb3IgaGFuZGxpbmcgcGhvbmV0aWMgLyBwaG9uZW1pYyB0cmFuc2NyaXB0aW9ucyBpbiANCj4g Z2VuZXJhbCwgb3Igd291bGQgcHJlZmVyIHRvIGdpdmUgYSBwYXJ0aWFsIHNvbHV0aW9uIHRoYXQg YWRkcmVzc2VzIHRoZSANCj4gbW9zdCB3aWRlbHktdXNlZCBvbmUsIG5hbWVseSBJUEEuICBJZiB0 aGUgV0cgZ29lcyB0aGUgZ2VuZXJhbCByb3V0ZSwgDQo+IHRoZW4gdGhlIHF1ZXN0aW9uIG9mIGhv dyBtdWNoIGluZm9ybWF0aW9uIChwaG9uZXRpYyB2cyBwaG9uZW1pYywgDQo+IHRyYW5zY3JpcHRp b24gInN5c3RlbSIsIGV0Yy4pIG5lZWRzIHRvIGJlIGVuY29kZWQgaW4gdGhlIHN1YnRhZyhzKSAN Cj4gc2hvdWxkIGJlIGRlY2lkZWQuDQoNCkknbSBhbGwgZm9yIHVzaW5nIHRoZSBmcmFtZXdvcmsg d2UgYWxyZWFkeSBkZXNpZ25lZCBpbnRvIHRoZSA0NjQ2IA0Kc3ludGF4OiBleHRlbnNpb24gc3Vi dGFncy4NCg0KVGhlIHF1ZXN0aW9uIG9mICJob3cgbXVjaCBpbmZvcm1hdGlvbiIgd291bGQgdGhl biBiZSBvZmZsb2FkZWQgb250byB0aGUgDQppbmRpdmlkdWFsIG9yIGJvZHkgY3JlYXRpbmcgdGhl IGV4dGVuc2lvbiBSRkMuDQoNCi0tDQpEb3VnIEV3ZWxsICAqICBGdWxsZXJ0b24sIENhbGlmb3Ju aWEsIFVTQSAgKiAgUkZDIDQ2NDUgICogIFVUTiAjMTQNCmh0dHA6Ly91c2Vycy5hZGVscGhpYS5u ZXQvfmRld2VsbC8NCmh0dHA6Ly93d3cxLmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbHRydS1jaGFy dGVyLmh0bWwNCmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9tYWlsbWFuL2xpc3RpbmZvL2lldGYt bGFuZ3VhZ2VzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkx0cnUgbWFpbGluZyBsaXN0DQpMdHJ1QGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo= --===============0630864547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0630864547==-- From ltru-bounces@ietf.org Sun Oct 29 15:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeHM0-0005uP-BL; Sun, 29 Oct 2006 15:34:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeHLy-0005uK-RP for ltru@ietf.org; Sun, 29 Oct 2006 15:33:58 -0500 Received: from nz-out-0102.google.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeHLx-0006Fd-Dv for ltru@ietf.org; Sun, 29 Oct 2006 15:33:58 -0500 Received: by nz-out-0102.google.com with SMTP id 13so1016350nzn for ; Sun, 29 Oct 2006 12:33:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Z08lw9LueoHmHP/kUhtpOBoiske5u/1DGJakKpwk58XAbr2LsjHxAUM6Cxo8ll1nFsmMwkV1NryHa9pAI4MuoXbouqw/ixqCBjSC8hD4pHpTbcRQsT7iL/07NqfEPuUJY1V+v/t48dPnhbj+H9pXMbOM51anRw6Cy4QJcLoA5M4= Received: by 10.65.237.19 with SMTP id o19mr3252326qbr; Sun, 29 Oct 2006 12:33:56 -0800 (PST) Received: by 10.65.211.11 with HTTP; Sun, 29 Oct 2006 12:33:56 -0800 (PST) Message-ID: <30b660a20610291233k3a97ef31y5b25d3cff3b1de40@mail.gmail.com> Date: Sun, 29 Oct 2006 12:33:56 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: IPA as a script In-Reply-To: <19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> MIME-Version: 1.0 References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> <19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> X-Google-Sender-Auth: bd030bb6b56ebbf8 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1892731608==" Errors-To: ltru-bounces@ietf.org --===============1892731608== Content-Type: multipart/alternative; boundary="----=_Part_67520_5294464.1162154036774" ------=_Part_67520_5294464.1162154036774 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Peter on this. When we were first talking about scripts, we figured that we didn't need registered script variants -- that the script group would be pragmatic enough. Perhaps we were wrong.... Mark On 10/28/06, Peter Constable wrote: > > As I suggested in the past, I think relegating transcription entirely to > an extension would be undesirable because it would be ignored by any process > that had no knowledge of the extension, which would be many. > > Or to put it in Randy's terms, in the case of a typical implementation > accessing a server that had transcription and "normal" content, it would > fail to deliver what the user wanted / fail to filter out unintelligible > stuff. > > What would work better would be to have a script-variant subtag for > Latin-based transcriptions and have an extension to differentiate between > different kinds of transcription / transliteration. > > > > Peter > > > > From: Doug Ewell [mailto:dewell@adelphia.net] > > > And the key question here is whether this WG is willing to produce a > > coherent framework for handling phonetic / phonemic transcriptions in > > general, or would prefer to give a partial solution that addresses the > > most widely-used one, namely IPA. If the WG goes the general route, > > then the question of how much information (phonetic vs phonemic, > > transcription "system", etc.) needs to be encoded in the subtag(s) > > should be decided. > > I'm all for using the framework we already designed into the 4646 > syntax: extension subtags. > > The question of "how much information" would then be offloaded onto the > individual or body creating the extension RFC. > > -- > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 > http://users.adelphia.net/~dewell/ > http://www1.ietf.org/html.charters/ltru-charter.html > http://www.alvestrand.no/mailman/listinfo/ietf-languages > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > ------=_Part_67520_5294464.1162154036774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Peter on this. When we were first talking about scripts, we figured that we didn't need registered script variants -- that the script group would be pragmatic enough. Perhaps we were wrong....

Mark

On 10/28/06, Peter Constable <petercon@microsoft.com> wrote:
As I suggested in the past, I think relegating transcription entirely to an extension would be undesirable because it would be ignored by any process that had no knowledge of the extension, which would be many.

Or to put it in Randy's terms, in the case of a typical implementation accessing a server that had transcription and "normal" content, it would fail to deliver what the user wanted / fail to filter out unintelligible stuff.

What would work better would be to have a script-variant subtag for Latin-based transcriptions and have an extension to differentiate between different kinds of transcription / transliteration.



Peter



From: Doug Ewell [mailto:dewell@adelphia.net]

> And the key question here is whether this WG is willing to produce a
> coherent framework for handling phonetic / phonemic transcriptions in
> general, or would prefer to give a partial solution that addresses the
> most widely-used one, namely IPA.  If the WG goes the general route,
> then the question of how much information (phonetic vs phonemic,
> transcription "system", etc.) needs to be encoded in the subtag(s)
> should be decided.

I'm all for using the framework we already designed into the 4646
syntax: extension subtags.

The question of "how much information" would then be offloaded onto the
individual or body creating the extension RFC.

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


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

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



------=_Part_67520_5294464.1162154036774-- --===============1892731608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1892731608==-- From ltru-bounces@ietf.org Sun Oct 29 16:16:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeI15-0005Iy-6V; Sun, 29 Oct 2006 16:16:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeI0q-00051g-5T for ltru@lists.ietf.org; Sun, 29 Oct 2006 16:16:12 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeI0h-0005v6-QH for ltru@lists.ietf.org; Sun, 29 Oct 2006 16:16:12 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GeI0Z-0007Km-S3 for ltru@lists.ietf.org; Sun, 29 Oct 2006 22:15:55 +0100 Received: from du-001-011.access.de.clara.net ([212.82.227.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Oct 2006 22:15:55 +0100 Received: from nobody by du-001-011.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Oct 2006 22:15:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 29 Oct 2006 22:15:32 +0100 Organization: Lines: 22 Message-ID: <454519F4.4262@xyzzy.claranet.de> References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> <6.0.0.20.2.20061028160314.0686c810@localhost> <000f01c6faaf$d2ec4c40$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-011.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Fwd: Update to Internet-Draft and RFC Boilerplate X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > There is a version 1.32pre2 available at > http://xml.resource.org/experimental.html, with suitable warnings > about being a development version and living on the edge and so forth. These pre-releases are generally fine. Sometimes new features are kicked in the next stable version, but that won't affect the newest "fullsh*t" legalese (perfectly harmless this time, it only replaces ISOC by the new IETF Trust). > "full4748"? LOL, no, not this time. Once bitten (3678 => 3978) twice shy. If you don't like the xml2rfc pre-releases stick to the stable version. Brian wrote that "old" boilerplates will be still accepted for four months, a stable xml2rfc 1.32 will be released in time. Nothing to worry about if you use one of the two online versions for 4645bis. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 29 16:56:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeIde-0004br-5Y; Sun, 29 Oct 2006 16:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeIdd-0004bm-KL for ltru@lists.ietf.org; Sun, 29 Oct 2006 16:56:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeIdb-0003FZ-B4 for ltru@lists.ietf.org; Sun, 29 Oct 2006 16:56:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GeIdT-0007Ms-JY for ltru@lists.ietf.org; Sun, 29 Oct 2006 22:56:07 +0100 Received: from du-001-011.access.de.clara.net ([212.82.227.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Oct 2006 22:56:07 +0100 Received: from nobody by du-001-011.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Oct 2006 22:56:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 29 Oct 2006 22:29:28 +0100 Organization: Lines: 14 Message-ID: <45451D38.28AB@xyzzy.claranet.de> References: <001601c6fa49$b14c92e0$6501a8c0@DGBP7M81> <4542EF0D.1090706@yahoo-inc.com> <001101c6fab1$a5fffbd0$6501a8c0@DGBP7M81> <45439D1C.5000600@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-011.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Re: OT editorial chitchat about tools X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I Yahoo-ed "tcl" and "Windows" and it's the first item. Blasphemy in two completely unrelated religions... > I don't doubt that we'll make rapid progress. Apparently we have consensus to use the new boilerplate when available. Okay, it's one of my more sarcastic days. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 29 17:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJ3w-0007CD-Qe; Sun, 29 Oct 2006 17:23:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJ34-000700-CR for ltru@lists.ietf.org; Sun, 29 Oct 2006 17:22:34 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJ32-0004h2-2B for ltru@lists.ietf.org; Sun, 29 Oct 2006 17:22:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GeJ2z-0004Kw-Dt for ltru@lists.ietf.org; Sun, 29 Oct 2006 23:22:29 +0100 Received: from du-001-011.access.de.clara.net ([212.82.227.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Oct 2006 23:22:29 +0100 Received: from nobody by du-001-011.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 Oct 2006 23:22:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 29 Oct 2006 23:21:18 +0100 Organization: Lines: 27 Message-ID: <4545295E.4C9E@xyzzy.claranet.de> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> <19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-011.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > As I suggested in the past, I think relegating transcription entirely > to an extension would be undesirable because it would be ignored by any > process that had no knowledge of the extension, which would be many. Why's that a bad thing ? My use case would be Latn dictionaries, and I won't care which phonetic alphabet they use. Probably they also offer wav-files. > What would work better would be to have a script-variant subtag for > Latin-based transcriptions and have an extension to differentiate > between different kinds of transcription / transliteration. I don't see why that's better. With a variant subtag "slbtgsei" (some Latn based transcription gibberish, see extension info) plus extension t-whatever you get tags like en-slbtgsei-t-whatever That's longer than en-t-whatever, where or why would it work better ? With a script-variant "Latt" (Latn transcription specified elsewhere) a tag en-Latt-t-whatever could be even harmful, if it's my use case of a dictionary, and I could read its Latn-parts - but never get it if I filter out "Latt" as "non-Latn". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 01:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeQLm-0006jB-Re; Mon, 30 Oct 2006 01:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeQLl-0006iE-ME for ltru@lists.ietf.org; Mon, 30 Oct 2006 01:10:21 -0500 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeQLj-0005ss-1J for ltru@lists.ietf.org; Mon, 30 Oct 2006 01:10:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id EC0F4478D; Mon, 30 Oct 2006 15:09:52 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21038-20; Mon, 30 Oct 2006 15:09:52 +0900 (JST) Received: from [192.168.1.5] (p7140-ipad401marunouchi.tokyo.ocn.ne.jp [222.146.111.140]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 931CF475A; Mon, 30 Oct 2006 15:09:52 +0900 (JST) Subject: Re: [Ltru] Re: IPA as a script From: Felix Sasaki To: Frank Ellermann In-Reply-To: <4545295E.4C9E@xyzzy.claranet.de> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> <19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> <4545295E.4C9E@xyzzy.claranet.de> Content-Type: text/plain Organization: W3C Date: Mon, 30 Oct 2006 15:09:50 +0900 Message-Id: <1162188590.8156.8.camel@fsasaki-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fsasaki@w3.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, 2006-10-29 at 23:21 +0100, Frank Ellermann wrote: > Peter Constable wrote: > > > As I suggested in the past, I think relegating transcription entirely > > to an extension would be undesirable because it would be ignored by any > > process that had no knowledge of the extension, which would be many. > > Why's that a bad thing ? My use case In this thread, I saw a use case from Peter about linguistic data which might benefit from information about the choice of a transcription system. Are there other concrete use cases? Could you list them, and if possible, a list (or a link) about (even if potential) possible values? Such a "bottom-up" approach might make it easier to see whether this information needs to be provided as part of a language tag or could be in a different field (or e.g. XML attribute which is not xml:lang). Felix > would be Latn dictionaries, and I > won't care which phonetic alphabet they use. Probably they also offer > wav-files. > > > What would work better would be to have a script-variant subtag for > > Latin-based transcriptions and have an extension to differentiate > > between different kinds of transcription / transliteration. > > I don't see why that's better. With a variant subtag "slbtgsei" (some > Latn based transcription gibberish, see extension info) plus extension > t-whatever you get tags like en-slbtgsei-t-whatever > > That's longer than en-t-whatever, where or why would it work better ? > > With a script-variant "Latt" (Latn transcription specified elsewhere) > a tag en-Latt-t-whatever could be even harmful, if it's my use case of > a dictionary, and I could read its Latn-parts - but never get it if I > filter out "Latt" as "non-Latn". > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 01:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeQsQ-0005gt-78; Mon, 30 Oct 2006 01:44:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeQqL-00056S-0h for ltru@ietf.org; Mon, 30 Oct 2006 01:41:57 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeQj5-00062i-KU for ltru@ietf.org; Mon, 30 Oct 2006 01:34:29 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061030063426.BZGS4813.mta9.adelphia.net@DGBP7M81>; Mon, 30 Oct 2006 01:34:26 -0500 Message-ID: <001701c6fbed$72fbbfc0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 29 Oct 2006 22:34:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Frank Ellermann Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stop press -- I actually agreed with everything Frank had to say in a post. Frank Ellermann wrote: > Peter Constable wrote: > >> As I suggested in the past, I think relegating transcription entirely >> to an extension would be undesirable because it would be ignored by >> any process that had no knowledge of the extension, which would be >> many. > > Why's that a bad thing ? My use case would be Latn dictionaries, and > I won't care which phonetic alphabet they use. Probably they also > offer wav-files. > >> What would work better would be to have a script-variant subtag for >> Latin-based transcriptions and have an extension to differentiate >> between different kinds of transcription / transliteration. > > I don't see why that's better. With a variant subtag "slbtgsei" (some > Latn based transcription gibberish, see extension info) plus extension > t-whatever you get tags like en-slbtgsei-t-whatever > > That's longer than en-t-whatever, where or why would it work better ? > > With a script-variant "Latt" (Latn transcription specified elsewhere) > a tag en-Latt-t-whatever could be even harmful, if it's my use case of > a dictionary, and I could read its Latn-parts - but never get it if I > filter out "Latt" as "non-Latn". -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 04:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTnI-0006DB-DK; Mon, 30 Oct 2006 04:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTgk-0001eQ-Qi for ltru@lists.ietf.org; Mon, 30 Oct 2006 04:44:15 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeQSX-00089q-M5 for ltru@lists.ietf.org; Mon, 30 Oct 2006 01:17:21 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GeQEH-0002Rj-7p for ltru@lists.ietf.org; Mon, 30 Oct 2006 01:02:42 -0500 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Sun, 29 Oct 2006 22:02:34 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Sun, 29 Oct 2006 22:02:34 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: IPA as a script Date: Sun, 29 Oct 2006 22:02:39 -0800 Message-ID: <19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <4545295E.4C9E@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: IPA as a script Thread-Index: Acb7qN9ygESmLV20SI6Dkdxt4w6XswAPqWZg References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> <4545295E.4C9E@xyzzy.claranet.de> From: Peter Constable To: Frank Ellermann , X-OriginalArrivalTime: 30 Oct 2006 06:02:34.0394 (UTC) FILETIME=[FE4AD7A0:01C6FBE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Let's say you have a dictionary for English: most of the content of a given lexical entry is in the common orthographic writing system, and one portion of the entry is in phonetic transcription. So, most of the content is tagged en-US (or en-GB -- whatever), and the bit of phonetic transcription is tagged (suppose) en-Lphn-t-ipa. How is that harmful? If you search for en-US content, you'll get what you ask for.=20 On the other hand, suppose I'm searching for English content, but I really don't want phonetic transcription because it's all gibberish to me. If a site has a corpus of texts in phonetic transcription but they're all tagged en-t-ipa and the tools basically ignore the extension because they know nothing about it, then I get returned to me all that gibberish I'd rather not have to deal with. But if that same content were tagged en-Lphn-t-ipa, then those same tools *do* understand that Lphn is not the same as Latn and can filter out that content I don't want. Peter=20 -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 Sent: Sunday, October 29, 2006 2:21 PM To: ltru@lists.ietf.org Subject: [Ltru] Re: IPA as a script Peter Constable wrote: =20 > As I suggested in the past, I think relegating transcription entirely > to an extension would be undesirable because it would be ignored by any > process that had no knowledge of the extension, which would be many. Why's that a bad thing ? My use case would be Latn dictionaries, and I won't care which phonetic alphabet they use. Probably they also offer wav-files. > What would work better would be to have a script-variant subtag for > Latin-based transcriptions and have an extension to differentiate > between different kinds of transcription / transliteration. =20 I don't see why that's better. With a variant subtag "slbtgsei" (some Latn based transcription gibberish, see extension info) plus extension t-whatever you get tags like en-slbtgsei-t-whatever That's longer than en-t-whatever, where or why would it work better ? With a script-variant "Latt" (Latn transcription specified elsewhere) a tag en-Latt-t-whatever could be even harmful, if it's my use case of a dictionary, and I could read its Latn-parts - but never get it if I filter out "Latt" as "non-Latn". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 09:29:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeY8N-0002t2-90; Mon, 30 Oct 2006 09:29:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeY8L-0002sx-Oc for ltru@ietf.org; Mon, 30 Oct 2006 09:29:01 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeY8H-0006DI-Dh for ltru@ietf.org; Mon, 30 Oct 2006 09:29:01 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061030142856.JASQ14484.mta10.adelphia.net@DGBP7M81> for ; Mon, 30 Oct 2006 09:28:56 -0500 Message-ID: <003101c6fc2f$bcd843b0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 30 Oct 2006 06:28:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > On the other hand, suppose I'm searching for English content, but I > really don't want phonetic transcription because it's all gibberish to > me. If a site has a corpus of texts in phonetic transcription but > they're all tagged en-t-ipa and the tools basically ignore the > extension because they know nothing about it, then I get returned to > me all that gibberish I'd rather not have to deal with. But if that > same content were tagged en-Lphn-t-ipa, then those same tools *do* > understand that Lphn is not the same as Latn and can filter out that > content I don't want. The crux of this argument is that tag consumers -- including those for which normal Latin vs. IPA is an important distinction -- won't implement the extension mechanism, or won't have access to the RFC that defines the 't' extensions. To me this is similar to the argument that subtags, including new inventions like "script variants," need to be placed in such a way that remove-from-right matching won't cause them to be stripped, because tag consumers aren't going to implement the matching strategies in RFC 4647 anyway. It assumes that people won't use the mechanisms we invent, so we should discourage their use even as we introduce them. This is one main reason why I'm reluctant to support new inventions. I don't remember exactly who came up with the idea of extensions in the first place, but maybe one of the original proponents could explain what use he or she had in mind for them. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 15:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedKE-0006Bg-Qa; Mon, 30 Oct 2006 15:01:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedKE-00069r-GN for ltru@ietf.org; Mon, 30 Oct 2006 15:01:38 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GedKC-00026d-37 for ltru@ietf.org; Mon, 30 Oct 2006 15:01:38 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Kzl60r6Wom3uxeACVuG3lMOOE34b8dE9r8DJoaz5rIeQ4RgjSlRz1D76l6M+6sqh; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.127] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GedK9-00071K-Bp for ltru@ietf.org; Mon, 30 Oct 2006 15:01:33 -0500 Message-ID: <002e01c6fc5e$2ac4be20$6601a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de> <1162188590.8156.8.camel@fsasaki-desktop> Subject: Re: [Ltru] Re: IPA as a script Date: Mon, 30 Oct 2006 12:01:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888c29d63c4e37bdee68670d0bd300bf872ec7ebe8b05cf3be7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.127 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Felix Sasaki" > To: "Frank Ellermann" > Cc: > Sent: Sunday, October 29, 2006 10:09 PM > Subject: Re: [Ltru] Re: IPA as a script ... > In this thread, I saw a use case from Peter about linguistic data which > might benefit from information about the choice of a transcription > system. Are there other concrete use cases? Could you list them, and if > possible, a list (or a link) about (even if potential) possible values? > > Such a "bottom-up" approach might make it easier to see whether this > information needs to be provided as part of a language tag or could be > in a different field (or e.g. XML attribute which is not xml:lang). ... The case I had in mind is similar to what Peter decribed. In an earlier career, I worked with fairly large bodies of linguistic data. Some corpora consisted of transcriptions of spoken language. Unlike the case of a dictionary, where the transcriptions are only part of the content, these documents are almost entirely transcribed language, and in general do not carry that content in non-transcribed form. (There might be ancillary information identifying the transcriber, the date, setting, informant, and so on, but almost never would one see the "content" represented in conventional orthography in addition to the transcription.) Some of the difficulties: - knowing which transcription system was in use for a document - knowing whether the transcription was broadly or narrowly phonetic or phonemic - sometimes a document would in general be phonemic, with only the "interesting" parts in narrow phonetic transcription. I think this last problem fits in with the problem of "pronunciation" guides in dictionaries, and we can't fix it here. The first two, however, I think are things we could address. Now, the more fundamental question Felix raises is whether this information should be carried in a distinct attribute. Way back when we debated the addition of the script subtag the question was quite similar: should this be regarded as another attribute, distinct from the language. I still find this approach intellectually appealing. However, pragmatic considerations seem to have swayed the WG to pursue its current course of encoding these dimensions by using multiple subtags. Unless there is something about transcriptions that makes them fundamentally different from scripts, orthographies, and regionaly variations, it would probably make sense for us to handle them in the same general framework. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 17:56:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg3d-0002PB-0U; Mon, 30 Oct 2006 17:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg3c-0002Nw-Fs for ltru@ietf.org; Mon, 30 Oct 2006 17:56:40 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geg3Y-0008E6-8d for ltru@ietf.org; Mon, 30 Oct 2006 17:56:40 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Geg3R-0000pm-M3; Mon, 30 Oct 2006 17:56:29 -0500 Date: Mon, 30 Oct 2006 17:56:29 -0500 To: Randy Presuhn Subject: Re: [Ltru] Re: IPA as a script Message-ID: <20061030225629.GC30841@ccil.org> References: <1162188590.8156.8.camel@fsasaki-desktop> <002e01c6fc5e$2ac4be20$6601a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002e01c6fc5e$2ac4be20$6601a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Unless there is something about transcriptions that makes them > fundamentally different from scripts, orthographies, and regional > variations, it would probably make sense for us to handle them in the > same general framework. Note, however, that variant subtags need not represent regional variations (dialects in the strict sense). They may, for example, represent changes in orthography (1901, 1990), jargons (boont), sociolects (Rumantsch Grischun would be an example), or almost anything else. I propose that one new script subtag "phonetic transcription" be specified, analogous to "Brai" for Braille transcription, and that variants be registered to specify particular cases like intphon-broad and intphon-narrow. -- John Cowan Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. -- Calvin, giving Newton's First Law "in his own words" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 30 18:17:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GegNj-0001LG-Sv; Mon, 30 Oct 2006 18:17:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GegNj-0001LB-BK for ltru@ietf.org; Mon, 30 Oct 2006 18:17:27 -0500 Received: from nz-out-0102.google.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GegNf-0002vW-0I for ltru@ietf.org; Mon, 30 Oct 2006 18:17:27 -0500 Received: by nz-out-0102.google.com with SMTP id 13so1349248nzn for ; Mon, 30 Oct 2006 15:17:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=MklyJOiulWx9GiWHDFj6F+hA4jhewALgRRIr9LAPlZEMZT3olZu4bYmzHBWvg9bynrXkAnL28ZFgl2Z7QPfAhRCqYZjEs0d0CoHpL8YH78rrhCi2yBor3x8CGKO0OMjr8esOJ2y0lNEInESwg9OLpecNT0lqN0KibExslFLi5ik= Received: by 10.65.234.3 with SMTP id l3mr5631243qbr; Mon, 30 Oct 2006 15:17:20 -0800 (PST) Received: by 10.65.211.11 with HTTP; Mon, 30 Oct 2006 15:17:20 -0800 (PST) Message-ID: <30b660a20610301517r75bb3ec6m14e1b51c51445bb0@mail.gmail.com> Date: Mon, 30 Oct 2006 15:17:20 -0800 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: IPA as a script In-Reply-To: <20061030225629.GC30841@ccil.org> MIME-Version: 1.0 References: <1162188590.8156.8.camel@fsasaki-desktop> <002e01c6fc5e$2ac4be20$6601a8c0@oemcomputer> <20061030225629.GC30841@ccil.org> X-Google-Sender-Auth: 0813f0f8143720c8 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1305765552==" Errors-To: ltru-bounces@ietf.org --===============1305765552== Content-Type: multipart/alternative; boundary="----=_Part_83165_30869146.1162250240404" ------=_Part_83165_30869146.1162250240404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that's headed in the right direction. However, I doubt that the proposed tag would be viewed as a legitimate script. It might have a better chance as Lati (Latin script variant, with the addition of phonetic characters from IPA, etc.). (Corresponding script variants for other scripts could be added as needed.) Mark On 10/30/06, John Cowan wrote: > > Randy Presuhn scripsit: > > > Unless there is something about transcriptions that makes them > > fundamentally different from scripts, orthographies, and regional > > variations, it would probably make sense for us to handle them in the > > same general framework. > > Note, however, that variant subtags need not represent regional variations > (dialects in the strict sense). They may, for example, represent changes > in orthography (1901, 1990), jargons (boont), sociolects (Rumantsch > Grischun > would be an example), or almost anything else. > > I propose that one new script subtag "phonetic transcription" be > specified, analogous to "Brai" for Braille transcription, and that > variants be registered to specify particular cases like intphon-broad and > intphon-narrow. > > -- > John Cowan > Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. > -- Calvin, giving Newton's First Law "in his own words" > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_83165_30869146.1162250240404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that's headed in the right direction. However, I doubt that the proposed tag would be viewed as a legitimate script. It might have a better chance as Lati (Latin script variant, with the addition of phonetic characters from IPA, etc.). (Corresponding script variants for other scripts could be added as needed.)

Mark

On 10/30/06, John Cowan <cowan@ccil.org> wrote:
Randy Presuhn scripsit:

> Unless there is something about transcriptions that makes them
> fundamentally different from scripts, orthographies, and regional
> variations, it would probably make sense for us to handle them in the
> same general framework.

Note, however, that variant subtags need not represent regional variations
(dialects in the strict sense).  They may, for example, represent changes
in orthography (1901, 1990), jargons (boont), sociolects (Rumantsch Grischun
would be an example), or almost anything else.

I propose that one new script subtag "phonetic transcription" be
specified, analogous to "Brai" for Braille transcription, and that
variants be registered to specify particular cases like intphon-broad and
intphon-narrow.

--
John Cowan                                <cowan@ccil.org>
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    -- Calvin, giving Newton's First Law "in his own words"

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

------=_Part_83165_30869146.1162250240404-- --===============1305765552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1305765552==-- From ltru-bounces@ietf.org Tue Oct 31 00:40:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GemMU-0005H7-JR; Tue, 31 Oct 2006 00:40:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GemMT-0005Am-0T for ltru@ietf.org; Tue, 31 Oct 2006 00:40:33 -0500 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GemBD-0004aD-4U for ltru@ietf.org; Tue, 31 Oct 2006 00:28:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 5EE8B46C3; Tue, 31 Oct 2006 14:28:32 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06310-01; Tue, 31 Oct 2006 14:28:32 +0900 (JST) Received: from [133.27.246.247] (dhcp-246-247.mag.keio.ac.jp [133.27.246.247]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id E75A945E7; Tue, 31 Oct 2006 14:28:31 +0900 (JST) Message-ID: <4546DEFE.9000007@w3.org> Date: Tue, 31 Oct 2006 14:28:30 +0900 From: Felix Sasaki Organization: W3C User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: IPA as a script References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de> <1162188590.8156.8.camel@fsasaki-desktop> <002e01c6fc5e$2ac4be20$6601a8c0@oemcomputer> In-Reply-To: <002e01c6fc5e$2ac4be20$6601a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Randy, all Thank you very much for you explanations. A comment below. Randy Presuhn wrote: > Hi - > > As a technical contributor... > >> From: "Felix Sasaki" >> To: "Frank Ellermann" >> Cc: >> Sent: Sunday, October 29, 2006 10:09 PM >> Subject: Re: [Ltru] Re: IPA as a script > ... >> In this thread, I saw a use case from Peter about linguistic data which >> might benefit from information about the choice of a transcription >> system. Are there other concrete use cases? Could you list them, and if >> possible, a list (or a link) about (even if potential) possible values? >> >> Such a "bottom-up" approach might make it easier to see whether this >> information needs to be provided as part of a language tag or could be >> in a different field (or e.g. XML attribute which is not xml:lang). > ... > > The case I had in mind is similar to what Peter decribed. > > In an earlier career, I worked with fairly large bodies of linguistic data. > Some corpora consisted of transcriptions of spoken language. Unlike the case > of a dictionary, where the transcriptions are only part of the content, > these documents are almost entirely transcribed language, and in general > do not carry that content in non-transcribed form. (There might be ancillary > information identifying the transcriber, the date, setting, informant, and > so on, but almost never would one see the "content" represented in conventional > orthography in addition to the transcription.) > > Some of the difficulties: > - knowing which transcription system was in use for a document > - knowing whether the transcription was broadly or narrowly phonetic or phonemic > - sometimes a document would in general be phonemic, with only the "interesting" > parts in narrow phonetic transcription. > > I think this last problem fits in with the problem of "pronunciation" guides in > dictionaries, and we can't fix it here. The first two, however, I think are > things we could address. Now, the more fundamental question Felix raises > is whether this information should be carried in a distinct attribute. > > Way back when we debated the addition of the script subtag the question was quite > similar: should this be regarded as another attribute, distinct from the language. > I still find this approach intellectually appealing. However, pragmatic > considerations seem to have swayed the WG to pursue its current course > of encoding these dimensions by using multiple subtags. Unless there is something > about transcriptions that makes them fundamentally different from scripts, > orthographies, and regionaly variations, it would probably make sense for > us to handle them in the same general framework. The only difference I see is a use case, i.e. for SSML, see http://www.w3.org/TR/speech-synthesis/#S3.1.9 . You will find the following: "The alphabet attribute is an optional attribute that specifies the phonemic/phonetic alphabet." An example from SSML: tomato The current definition of the alphabet attribute in SSML does not rely on a registry for values, but that might be a topic for the future of SSML. Hence, I would be worried if the LTRU WG and others (e.g. within W3C) double their efforts (i.e. creation of registries) with overlapping purposes. In the context of SSML, it makes sense to have a separate field. Felix > > Randy > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 05:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeqWG-0005w7-Gl; Tue, 31 Oct 2006 05:06:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeqWF-0005w1-3Z for ltru@lists.ietf.org; Tue, 31 Oct 2006 05:06:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeqWB-0007Uz-Ia for ltru@lists.ietf.org; Tue, 31 Oct 2006 05:06:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GeqVx-00063Y-HK for ltru@lists.ietf.org; Tue, 31 Oct 2006 11:06:37 +0100 Received: from pd9fba970.dip0.t-ipconnect.de ([217.251.169.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 11:06:37 +0100 Received: from nobody by pd9fba970.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 11:06:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 31 Oct 2006 11:03:45 +0100 Organization: Lines: 39 Message-ID: <45471F81.30AC@xyzzy.claranet.de> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> <4545295E.4C9E@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba970.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Let's say you have a dictionary for English: most of the content of a > given lexical entry is in the common orthographic writing system, and > one portion of the entry is in phonetic transcription. So, most of the > content is tagged en-US (or en-GB -- whatever), and the bit of phonetic > transcription is tagged (suppose) en-Lphn-t-ipa. How is that harmful? It's fine, I thought you wanted to tag the complete document as "Lphn". And Felix' SSML example is also nice - certainly better than WAV files - if and when it's supported by popular browsers. This example is however about an element in its own namespace, not about the attribute xml:lang used everywhere. > If a site has a corpus of texts in phonetic transcription but they're > all tagged en-t-ipa and the tools basically ignore the extension > because they know nothing about it, then I get returned to me all that > gibberish I'd rather not have to deal with. Yes, assuming that applications will support "Lphn" but not "t-ipa", I've no idea what server and browser implementors plan. I'm also not sure why you would want "Lphn" instead of "Aphn" (A = any), but if it's in the position of a script subtag that's an issue for a "script-variant-list", or however that's organized, I didn't study all details of the 15924 page. Maybe the LTRU WG could somehow "officially" state that some "Lphn" or a similar solution would fit into the 4646 language tag scheme, but I'm not sure about that idea. If you want an LTRU resolution to reserve "Lphn" I'd abstain - I can't tell if "Lphn" is zero, one, or more scripts. I'd bet "not one script" if forced to bet, that leaves zero or more. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 06:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ges5T-0003CX-R4; Tue, 31 Oct 2006 06:47:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ges5S-0003CL-Jd for ltru@lists.ietf.org; Tue, 31 Oct 2006 06:47:22 -0500 Received: from mail07.svc.cra.dublin.eircom.net ([159.134.118.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ges5O-0003qt-A6 for ltru@lists.ietf.org; Tue, 31 Oct 2006 06:47:22 -0500 Received: (qmail 10090 messnum 2902864 invoked from network[194.125.174.84/ts09-084.dublin.indigo.ie]); 31 Oct 2006 11:47:15 -0000 Received: from ts09-084.dublin.indigo.ie (HELO ?194.125.174.84?) (194.125.174.84) by mail07.svc.cra.dublin.eircom.net (qp 10090) with SMTP; 31 Oct 2006 11:47:15 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <45471F81.30AC@xyzzy.claranet.de> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> <4545295E.4C9E@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> <45471F81.30AC@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: IPA as a script Date: Tue, 31 Oct 2006 11:51:01 +0000 To: ltru@lists.ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It has taken years to catalogue 1,000 upon 1,000s of IPA entries, =20 which I did by dint of rewriting the first line of each in "normal" =20 script(s) - now this material must be digitized: keyed in as written =20 (in IPA) for sorting and contextual searching that way. Those keying =20 it in do not necessarily come equipped with the ability to do as I =20 did (above). Among the projects the material is urgently needed to =20 serve, two have to do with synthesized speech. If anyone can think of =20= how to do this and share online by being able to mark it as being in =20 IPA script, then perhaps he/she would enlighten those of us who need =20 this service. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 08:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetKu-0002ON-Qd; Tue, 31 Oct 2006 08:07:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetKs-0002NG-Nm for ltru@lists.ietf.org; Tue, 31 Oct 2006 08:07:23 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GetKi-0001Yw-Q4 for ltru@lists.ietf.org; Tue, 31 Oct 2006 08:07:22 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Tue, 31 Oct 2006 05:07:12 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 05:07:12 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: IPA as a script Date: Tue, 31 Oct 2006 05:06:22 -0800 Message-ID: <19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <45471F81.30AC@xyzzy.claranet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: IPA as a script Thread-Index: Acb81F6fSASuIGaKTimF7v6Gp0pyNQAF+eXg References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> <45471F81.30AC@xyzzy.claranet.de> From: Peter Constable To: X-OriginalArrivalTime: 31 Oct 2006 13:07:12.0018 (UTC) FILETIME=[7A8D7F20:01C6FCED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de]=20 > It's fine, I thought you wanted to tag the complete document as "Lphn". ??!! > I'm also not sure why > you would want "Lphn" instead of "Aphn" (A =3D any), I think it's important to reflect the script that the transcription system is primarily derived from. Most I'm aware of are based on Latin, though I met one Korean linguist using an extension of Hangul for phonetic transcription. So, something like "Lphn" or "Latp" would be my suggestion. > Maybe the LTRU WG could somehow "officially" state that some "Lphn" or a > similar solution would fit into the 4646 language tag scheme, but I'm > not sure about that idea. That is certainly something I'd consider. This WG owns the 4646 LT space, so if it seems like the sensible solution to us and the 15924 JAC won't budge, we can ask them to reserve an ID. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 09:17:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuQZ-0000GL-Rd; Tue, 31 Oct 2006 09:17:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuQV-0000DB-MJ for ltru@lists.ietf.org; Tue, 31 Oct 2006 09:17:18 -0500 Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GeuQ9-0004Up-C0 for ltru@lists.ietf.org; Tue, 31 Oct 2006 09:17:15 -0500 Received: (qmail 13801 messnum 6387780 invoked from network[194.125.174.6/ts09-006.dublin.indigo.ie]); 31 Oct 2006 14:16:52 -0000 Received: from ts09-006.dublin.indigo.ie (HELO ?194.125.174.6?) (194.125.174.6) by mail00.svc.cra.dublin.eircom.net (qp 13801) with SMTP; 31 Oct 2006 14:16:52 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> <45471F81.30AC@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <31835182-D9EF-403F-8401-9A2A082F778E@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: IPA as a script Date: Tue, 31 Oct 2006 14:20:38 +0000 To: ltru@lists.ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On 31 Oct 2006, at 13:06, scr=EDobh Peter Constable: > ... > I think it's important to reflect the script that the transcription > system is primarily derived from... Why? And why complicate matters so? On the basis of what you have =20 said above, how would you categorize a combination of Latin and =20 Cyrillic?:-) mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 09:38:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeulI-0003Bp-Ab; Tue, 31 Oct 2006 09:38:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeulG-0003BQ-Sp for ltru@lists.ietf.org; Tue, 31 Oct 2006 09:38:43 -0500 Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Geul2-0007Uw-R5 for ltru@lists.ietf.org; Tue, 31 Oct 2006 09:38:42 -0500 Received: (qmail 5002 messnum 11073418 invoked from network[194.125.174.87/ts09-087.dublin.indigo.ie]); 31 Oct 2006 14:38:27 -0000 Received: from ts09-087.dublin.indigo.ie (HELO ?194.125.174.87?) (194.125.174.87) by mail11.svc.cra.dublin.eircom.net (qp 5002) with SMTP; 31 Oct 2006 14:38:27 -0000 In-Reply-To: <31835182-D9EF-403F-8401-9A2A082F778E@egt.ie> References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> <45471F81.30AC@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> <31835182-D9EF-403F-8401-9A2A082F778E@egt.ie> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <725B67BB-43BF-43FC-8A14-C385742F4EB5@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Re: IPA as a script Date: Tue, 31 Oct 2006 14:42:13 +0000 To: ltru@lists.ietf.org X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Historically speaking, to _underline_ the distinction between issues =20 to do with charsets and issues to do with scripts, which can, to some =20= LTRU list readers, seem fuzzy: a thousand years ago, Tironian Et =20 ("7") was no more than a part of a Roman/Latin system of notation, =20 but to Irish people today, it is seen as a quintessential part of our =20= traditional charset (most of us simply wouldn't associate it with any =20= other language, even Latin!), so, bearing in mind that getting =20 Tironian Et codified was a character set (non-script) issue which =20 should probably never have been handled by ISO not as a character set =20= issue in and of itself, but as a simple giorr=FAch=E1n (contraction) - =20= something which our understanding at the time may not have permitted =20 - IPA goes way beyond that because, to users (linguists) on the =20 ground today, as we speak, IPA is seen as a handy alternative script =20 (professional system of notation), that is, a tool serving more =20 languages than our own. mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 14:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezIq-0001IZ-SN; Tue, 31 Oct 2006 14:29:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezIp-0001IA-59 for ltru@lists.ietf.org; Tue, 31 Oct 2006 14:29:39 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezIe-0001nx-KP for ltru@lists.ietf.org; Tue, 31 Oct 2006 14:29:39 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Tue, 31 Oct 2006 11:29:28 -0800 Received: from RED-MSG-42.redmond.corp.microsoft.com ([157.54.61.167]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:29:25 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: IPA as a script Date: Tue, 31 Oct 2006 11:29:03 -0800 Message-ID: <19A328037921AA42847A717566D1D6A1094772B3@RED-MSG-42.redmond.corp.microsoft.com> In-Reply-To: <31835182-D9EF-403F-8401-9A2A082F778E@egt.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: IPA as a script Thread-Index: Acb891Kfn5Ir/jYWQOy2w19aUlj4xgAKpGZA References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81><19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com><4545295E.4C9E@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com><45471F81.30AC@xyzzy.claranet.de><19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> <31835182-D9EF-403F-8401-9A2A082F778E@egt.ie> From: Peter Constable To: X-OriginalArrivalTime: 31 Oct 2006 19:29:25.0429 (UTC) FILETIME=[DFEE4E50:01C6FD22] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Because if we have a single subtag that means simply "some system of = phonetic transcription", then e.g. I'm not going to find it helpful to = get results in a Hangul-based transcription that I can't understand; or, = e.g., it's not going to be really helpful to a Korean linguist to get a = ton of Latin-based phonetic transcription when what they're looking of = is Hangul-based transcriptions. Systems of phonetic transcription I'm = aware of are base primarily on one script; since we're talking about a = script / script-variant subtag, it's appropriate IMO to reflect what = that primary script is. Do you know of a specific system of phonetic transcription that is = derived equally from Latin and Cyrillic or is that just a hypothetical = scenario? (I suspect the latter.) Peter -----Original Message----- From: Marion Gunn [mailto:mgunn@egt.ie]=20 Sent: Tuesday, October 31, 2006 6:21 AM To: ltru@lists.ietf.org Subject: Re: [Ltru] Re: IPA as a script On 31 Oct 2006, at 13:06, scr=EDobh Peter Constable: > ... > I think it's important to reflect the script that the transcription > system is primarily derived from... Why? And why complicate matters so? On the basis of what you have =20 said above, how would you categorize a combination of Latin and =20 Cyrillic?:-) mg - - Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 16:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1SQ-0003Mo-Cb; Tue, 31 Oct 2006 16:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1SM-0003Mc-Lw for ltru@lists.ietf.org; Tue, 31 Oct 2006 16:47:40 -0500 Received: from nz-out-0102.google.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1SL-0004rT-80 for ltru@lists.ietf.org; Tue, 31 Oct 2006 16:47:38 -0500 Received: by nz-out-0102.google.com with SMTP id 13so1646477nzn for ; Tue, 31 Oct 2006 13:47:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TA+dioYn7IpeY03UtK60SqNn4veXQ2ARCTdJDs/rabVsotzzq3lu8QAKi1EB6F/zt6rDL7S1mn8rQEai0If2VOjEdJ9LxdOwRRharpoBvJd2dU0EJBfAD2Gfq/qBrzY92yBBGTSwOtzhfQRZFNlc2s+2IP5F1W1iMXCGgJWHzFk= Received: by 10.65.43.17 with SMTP id v17mr7667203qbj; Tue, 31 Oct 2006 13:47:34 -0800 (PST) Received: by 10.65.211.11 with HTTP; Tue, 31 Oct 2006 13:47:34 -0800 (PST) Message-ID: <30b660a20610311347t4e7acbe6u441755b4df517dfb@mail.gmail.com> Date: Tue, 31 Oct 2006 13:47:34 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: IPA as a script In-Reply-To: <19A328037921AA42847A717566D1D6A1094772B3@RED-MSG-42.redmond.corp.microsoft.com> MIME-Version: 1.0 References: <001a01c6fa4a$374042c0$6501a8c0@DGBP7M81> <19A328037921AA42847A717566D1D6A10935D520@RED-MSG-42.redmond.corp.microsoft.com> <4545295E.4C9E@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A10935D6DA@RED-MSG-42.redmond.corp.microsoft.com> <45471F81.30AC@xyzzy.claranet.de> <19A328037921AA42847A717566D1D6A109402B9F@RED-MSG-42.redmond.corp.microsoft.com> <31835182-D9EF-403F-8401-9A2A082F778E@egt.ie> <19A328037921AA42847A717566D1D6A1094772B3@RED-MSG-42.redmond.corp.microsoft.com> X-Google-Sender-Auth: 4bdaaba55a678193 X-Spam-Score: 1.1 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0921783150==" Errors-To: ltru-bounces@ietf.org --===============0921783150== Content-Type: multipart/alternative; boundary="----=_Part_13444_13698178.1162331254517" ------=_Part_13444_13698178.1162331254517 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIFBldGVyLiBJZiBzb21lb25lIHdhbnRzIEVuZ2xpc2ggd3JpdHRlbiBpbiBz b21lIEhhbmd1bAp0cmFuc2NyaXB0aW9uLCBvciBLb3JlYW4gd3JpdHRlbiBpbiBzb21lIExhdGlu IHRyYW5zY3JpcHRpb24sIHRoYXQgYWxyZWFkeQpleGlzdHM6IGVuLUhhbmcgYW5kIGtvLUxhdG4u IE5vdywgb25lIG1pZ2h0IHdhbnQgdG8gaGF2ZSBhIGZ1cnRoZXIKc3BlY2lmaWNhdGlvbiwgIktv cmVhbiB3cml0dGVuIGluIExhdGluIHRyYW5zY3JpcHRpb24gYWNjb3JkaW5nIHRvIHRoZQpNaW5p c3RyeSBvZiBFZHVjYXRpb24gVHJhbnNsaXRlcmF0aW9uIHdpdGggUnVsZSA4IjsgdGhhdCB3b3Vs ZCBiZSBhIGZ1dGhlcgpyZWZpbmVtZW50IG9mIGtvLUxhdG4sIGFuZCB0aGF0IG1pZ2h0IGJlIGEg cG9zc2liaWxpdHkgZm9yIGFuIGV4dGVuc2lvbi4gQnV0CmF0IGEgaGlnaCBsZXZlbCwgS29yZWFu IHdyaXR0ZW4gaW4gc29tZSBMYXRpbiB0cmFuc2NyaXB0aW9uIGNhbiBhbHJlYWR5IGJlCmRlc2Ny aWJlZC4KCldoYXQgd2UgZG9uJ3QgaGF2ZSBhbnkgd2F5IG9mIGV4cHJlc3NpbmcgaXMgRW5nbGlz aCB3cml0dGVuIGluIElQQSBvciBLb3JlYW4Kd3JpdHRlbiBpbiBJUEEgKG9yIGxlc3MgY29tbW9u IG9uZXMgc3VjaCBhcyBGaW5uby1VZ3JpYyBvciBBbWVyaWNhbmlzdCkuCgplbi1YWFhYLCB3aGVy ZSBYWFhYIG1lYW5zIHRoYXQgdGhlICdlbicgaXMgd3JpdHRlbiBpbiAic29tZSBwaG9uZXRpYwp0 cmFuc2NyaXB0aW9uIGJ1dCB3ZSdyZSBub3QgZ29pbmcgdG8gdGVsbCB5b3Ugd2hhdCBzY3JpcHQg aXQgaXMgYmFzZWQgb24iLCBJCmRvbid0IHRoaW5rIHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1c2Vm dWwgYXQgYWxsLgoKTWFyawoKT24gMTAvMzEvMDYsIFBldGVyIENvbnN0YWJsZSA8cGV0ZXJjb25A bWljcm9zb2Z0LmNvbT4gd3JvdGU6Cj4KPiBCZWNhdXNlIGlmIHdlIGhhdmUgYSBzaW5nbGUgc3Vi dGFnIHRoYXQgbWVhbnMgc2ltcGx5ICJzb21lIHN5c3RlbSBvZgo+IHBob25ldGljIHRyYW5zY3Jp cHRpb24iLCB0aGVuIGUuZy4gSSdtIG5vdCBnb2luZyB0byBmaW5kIGl0IGhlbHBmdWwgdG8gZ2V0 Cj4gcmVzdWx0cyBpbiBhIEhhbmd1bC1iYXNlZCB0cmFuc2NyaXB0aW9uIHRoYXQgSSBjYW4ndCB1 bmRlcnN0YW5kOyBvciwgZS5nLiwKPiBpdCdzIG5vdCBnb2luZyB0byBiZSByZWFsbHkgaGVscGZ1 bCB0byBhIEtvcmVhbiBsaW5ndWlzdCB0byBnZXQgYSB0b24gb2YKPiBMYXRpbi1iYXNlZCBwaG9u ZXRpYyB0cmFuc2NyaXB0aW9uIHdoZW4gd2hhdCB0aGV5J3JlIGxvb2tpbmcgb2YgaXMKPiBIYW5n dWwtYmFzZWQgdHJhbnNjcmlwdGlvbnMuIFN5c3RlbXMgb2YgcGhvbmV0aWMgdHJhbnNjcmlwdGlv biBJJ20gYXdhcmUgb2YKPiBhcmUgYmFzZSBwcmltYXJpbHkgb24gb25lIHNjcmlwdDsgc2luY2Ug d2UncmUgdGFsa2luZyBhYm91dCBhIHNjcmlwdCAvCj4gc2NyaXB0LXZhcmlhbnQgc3VidGFnLCBp dCdzIGFwcHJvcHJpYXRlIElNTyB0byByZWZsZWN0IHdoYXQgdGhhdCBwcmltYXJ5Cj4gc2NyaXB0 IGlzLgo+Cj4gRG8geW91IGtub3cgb2YgYSBzcGVjaWZpYyBzeXN0ZW0gb2YgcGhvbmV0aWMgdHJh bnNjcmlwdGlvbiB0aGF0IGlzIGRlcml2ZWQKPiBlcXVhbGx5IGZyb20gTGF0aW4gYW5kIEN5cmls bGljIG9yIGlzIHRoYXQganVzdCBhIGh5cG90aGV0aWNhbCBzY2VuYXJpbz8gKEkKPiBzdXNwZWN0 IHRoZSBsYXR0ZXIuKQo+Cj4KPiBQZXRlcgo+Cj4KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQo+IEZyb206IE1hcmlvbiBHdW5uIFttYWlsdG86bWd1bm5AZWd0LmllXQo+IFNlbnQ6IFR1ZXNk YXksIE9jdG9iZXIgMzEsIDIwMDYgNjoyMSBBTQo+IFRvOiBsdHJ1QGxpc3RzLmlldGYub3JnCj4g U3ViamVjdDogUmU6IFtMdHJ1XSBSZTogSVBBIGFzIGEgc2NyaXB0Cj4KPiBPbiAzMSBPY3QgMjAw NiwgYXQgMTM6MDYsIHNjcsOtb2JoIFBldGVyIENvbnN0YWJsZToKPiA+IC4uLgo+ID4gSSB0aGlu ayBpdCdzIGltcG9ydGFudCB0byByZWZsZWN0IHRoZSBzY3JpcHQgdGhhdCB0aGUgdHJhbnNjcmlw dGlvbgo+ID4gc3lzdGVtIGlzIHByaW1hcmlseSBkZXJpdmVkIGZyb20uLi4KPgo+IFdoeT8gQW5k IHdoeSBjb21wbGljYXRlIG1hdHRlcnMgc28/IE9uIHRoZSBiYXNpcyBvZiB3aGF0IHlvdSBoYXZl Cj4gc2FpZCBhYm92ZSwgaG93IHdvdWxkIHlvdSBjYXRlZ29yaXplIGEgY29tYmluYXRpb24gb2Yg TGF0aW4gYW5kCj4gQ3lyaWxsaWM/Oi0pCj4gbWcKPgo+Cj4gLSAtCj4gTWFyaW9uIEd1bm4gKiBF R1RlbyAoRXN0YWIuMTk5MSkKPiAyNyBQw6FpcmMgYW4gRmjDqWl0aGxpbm4sIEJhaWxlIGFuCj4g QmjDs3RoYWlyLCBDby4gw4F0aGEgQ2xpYXRoLCDDiWlyZS4KPiAqIG1ndW5uQGVndC5pZSAqIGVh bW9ubkBlZ3QuaWUgKgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1 QGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+ Cg== ------=_Part_13444_13698178.1162331254517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIFBldGVyLiBJZiBzb21lb25lIHdhbnRzIEVuZ2xpc2ggd3JpdHRlbiBpbiBz b21lIEhhbmd1bCB0cmFuc2NyaXB0aW9uLCBvciBLb3JlYW4gd3JpdHRlbiBpbiBzb21lIExhdGlu IHRyYW5zY3JpcHRpb24sIHRoYXQgYWxyZWFkeSBleGlzdHM6IGVuLUhhbmcgYW5kIGtvLUxhdG4u IE5vdywgb25lIG1pZ2h0IHdhbnQgdG8gaGF2ZSBhIGZ1cnRoZXIgc3BlY2lmaWNhdGlvbiwgJnF1 b3Q7S29yZWFuIHdyaXR0ZW4gaW4gTGF0aW4gdHJhbnNjcmlwdGlvbiBhY2NvcmRpbmcgdG8gdGhl IE1pbmlzdHJ5IG9mIEVkdWNhdGlvbiBUcmFuc2xpdGVyYXRpb24gd2l0aCBSdWxlIDgmcXVvdDs7 IHRoYXQgd291bGQgYmUgYSBmdXRoZXIgcmVmaW5lbWVudCBvZiBrby1MYXRuLCBhbmQgdGhhdCBt aWdodCBiZSBhIHBvc3NpYmlsaXR5IGZvciBhbiBleHRlbnNpb24uIEJ1dCBhdCBhIGhpZ2ggbGV2 ZWwsIEtvcmVhbiB3cml0dGVuIGluIHNvbWUgTGF0aW4gdHJhbnNjcmlwdGlvbiBjYW4gYWxyZWFk eSBiZSBkZXNjcmliZWQuCjxicj48YnI+V2hhdCB3ZSBkb24ndCBoYXZlIGFueSB3YXkgb2YgZXhw cmVzc2luZyBpcyBFbmdsaXNoIHdyaXR0ZW4gaW4gSVBBIG9yIEtvcmVhbiB3cml0dGVuIGluIElQ QSAob3IgbGVzcyBjb21tb24gb25lcyBzdWNoIGFzIEZpbm5vLVVncmljIG9yIEFtZXJpY2FuaXN0 KS48YnI+PGJyPmVuLVhYWFgsIHdoZXJlIFhYWFggbWVhbnMgdGhhdCB0aGUgJ2VuJyBpcyB3cml0 dGVuIGluICZxdW90O3NvbWUgcGhvbmV0aWMgdHJhbnNjcmlwdGlvbiBidXQgd2UncmUgbm90IGdv aW5nIHRvIHRlbGwgeW91IHdoYXQgc2NyaXB0IGl0IGlzIGJhc2VkIG9uJnF1b3Q7LCBJIGRvbid0 IHRoaW5rIHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1c2VmdWwgYXQgYWxsLgo8YnI+PGJyPk1hcms8 YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAxMC8zMS8wNiwgPGIgY2xh c3M9ImdtYWlsX3NlbmRlcm5hbWUiPlBldGVyIENvbnN0YWJsZTwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwZXRlcmNvbkBtaWNyb3NvZnQuY29tIj5wZXRlcmNvbkBtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJv cmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQg MHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpCZWNhdXNlIGlmIHdlIGhhdmUgYSBzaW5n bGUgc3VidGFnIHRoYXQgbWVhbnMgc2ltcGx5ICZxdW90O3NvbWUgc3lzdGVtIG9mIHBob25ldGlj IHRyYW5zY3JpcHRpb24mcXVvdDssIHRoZW4gZS5nLiBJJ20gbm90IGdvaW5nIHRvIGZpbmQgaXQg aGVscGZ1bCB0byBnZXQgcmVzdWx0cyBpbiBhIEhhbmd1bC1iYXNlZCB0cmFuc2NyaXB0aW9uIHRo YXQgSSBjYW4ndCB1bmRlcnN0YW5kOyBvciwgCmUuZy4sIGl0J3Mgbm90IGdvaW5nIHRvIGJlIHJl YWxseSBoZWxwZnVsIHRvIGEgS29yZWFuIGxpbmd1aXN0IHRvIGdldCBhIHRvbiBvZiBMYXRpbi1i YXNlZCBwaG9uZXRpYyB0cmFuc2NyaXB0aW9uIHdoZW4gd2hhdCB0aGV5J3JlIGxvb2tpbmcgb2Yg aXMgSGFuZ3VsLWJhc2VkIHRyYW5zY3JpcHRpb25zLiBTeXN0ZW1zIG9mIHBob25ldGljIHRyYW5z Y3JpcHRpb24gSSdtIGF3YXJlIG9mIGFyZSBiYXNlIHByaW1hcmlseSBvbiBvbmUgc2NyaXB0OyBz aW5jZSB3ZSdyZSB0YWxraW5nIGFib3V0IGEgc2NyaXB0IC8gc2NyaXB0LXZhcmlhbnQgc3VidGFn LCBpdCdzIGFwcHJvcHJpYXRlIElNTyB0byByZWZsZWN0IHdoYXQgdGhhdCBwcmltYXJ5IHNjcmlw dCBpcy4KPGJyPjxicj5EbyB5b3Uga25vdyBvZiBhIHNwZWNpZmljIHN5c3RlbSBvZiBwaG9uZXRp YyB0cmFuc2NyaXB0aW9uIHRoYXQgaXMgZGVyaXZlZCBlcXVhbGx5IGZyb20gTGF0aW4gYW5kIEN5 cmlsbGljIG9yIGlzIHRoYXQganVzdCBhIGh5cG90aGV0aWNhbCBzY2VuYXJpbz8gKEkgc3VzcGVj dCB0aGUgbGF0dGVyLik8YnI+PGJyPjxicj5QZXRlcjxicj48YnI+PGJyPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCjxicj5Gcm9tOiBNYXJpb24gR3VubiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzptZ3VubkBlZ3QuaWUiPm1ndW5uQGVndC5pZTwvYT5dPGJyPlNlbnQ6IFR1ZXNkYXksIE9jdG9i ZXIgMzEsIDIwMDYgNjoyMSBBTTxicj5UbzogPGEgaHJlZj0ibWFpbHRvOmx0cnVAbGlzdHMuaWV0 Zi5vcmciPmx0cnVAbGlzdHMuaWV0Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFJlOiBbTHRydV0gUmU6 IElQQSBhcyBhIHNjcmlwdAo8YnI+PGJyPk9uIDMxIE9jdCAyMDA2LCBhdCAxMzowNiwgc2Nyw61v YmggUGV0ZXIgQ29uc3RhYmxlOjxicj4mZ3Q7IC4uLjxicj4mZ3Q7IEkgdGhpbmsgaXQncyBpbXBv cnRhbnQgdG8gcmVmbGVjdCB0aGUgc2NyaXB0IHRoYXQgdGhlIHRyYW5zY3JpcHRpb248YnI+Jmd0 OyBzeXN0ZW0gaXMgcHJpbWFyaWx5IGRlcml2ZWQgZnJvbS4uLjxicj48YnI+V2h5PyBBbmQgd2h5 IGNvbXBsaWNhdGUgbWF0dGVycyBzbz8gT24gdGhlIGJhc2lzIG9mIHdoYXQgeW91IGhhdmUKPGJy PnNhaWQgYWJvdmUsIGhvdyB3b3VsZCB5b3UgY2F0ZWdvcml6ZSBhIGNvbWJpbmF0aW9uIG9mIExh dGluIGFuZDxicj5DeXJpbGxpYz86LSk8YnI+bWc8YnI+PGJyPjxicj4tIC08YnI+TWFyaW9uIEd1 bm4gKiBFR1RlbyAoRXN0YWIuMTk5MSk8YnI+MjcgUMOhaXJjIGFuIEZow6lpdGhsaW5uLCBCYWls ZSBhbjxicj5CaMOzdGhhaXIsIENvLiDDgXRoYSBDbGlhdGgsIMOJaXJlLjxicj4qIDxhIGhyZWY9 Im1haWx0bzptZ3VubkBlZ3QuaWUiPgptZ3VubkBlZ3QuaWU8L2E+ICogPGEgaHJlZj0ibWFpbHRv OmVhbW9ubkBlZ3QuaWUiPmVhbW9ubkBlZ3QuaWU8L2E+ICo8YnI+PGJyPjxicj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxpbmcgbGlz dDxicj48YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSI+Cmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjxicj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxp bmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwv YT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRy dSI+Cmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjwv YmxvY2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_13444_13698178.1162331254517-- --===============0921783150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0921783150==-- From ltru-bounces@ietf.org Tue Oct 31 18:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3EL-0004e3-Ef; Tue, 31 Oct 2006 18:41:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3EK-0004dH-1z for ltru@ietf.org; Tue, 31 Oct 2006 18:41:16 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3EG-0000cs-OD for ltru@ietf.org; Tue, 31 Oct 2006 18:41:16 -0500 Received: from DGBP7M81 ([68.67.66.131]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20061031234112.CLRA13446.mta9.adelphia.net@DGBP7M81> for ; Tue, 31 Oct 2006 18:41:12 -0500 Message-ID: <002301c6fd46$0d54d800$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 31 Oct 2006 15:41:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: IPA as a script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > en-XXXX, where XXXX means that the 'en' is written in "some phonetic > transcription but we're not going to tell you what script it is based > on", I don't think would be particularly useful at all. Just to play devil's advocate here: 1a. Roughly how many phonetic transcription systems are there that need encoding? or 1b. Roughly how many scripts have phonetic transcription systems based on them that need encoding? and 2. Do we want to petition ISO 15924/RA to add that number of "script" subtags, for things that are at least arguably not scripts? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 31 19:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3Wd-0000Ag-5j; Tue, 31 Oct 2006 19:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3Wa-0000AE-PV for ltru@ietf.org; Tue, 31 Oct 2006 19:00:09 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3WW-0003Pa-I1 for ltru@ietf.org; Tue, 31 Oct 2006 19:00:08 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Gf3WW-0000s5-89; Tue, 31 Oct 2006 19:00:04 -0500 Date: Tue, 31 Oct 2006 19:00:04 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: IPA as a script Message-ID: <20061101000004.GH8281@ccil.org> References: <002301c6fd46$0d54d800$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002301c6fd46$0d54d800$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > 1a. Roughly how many phonetic transcription systems are there that need > encoding? About a dozen, if you mean transcriptions into systems that can potentially handle any speech sound. > 1b. Roughly how many scripts have phonetic transcription systems based > on them that need encoding? About one in common use; who knows how many individual oddities. > 2. Do we want to petition ISO 15924/RA to add that number of "script" > subtags, for things that are at least arguably not scripts? I wouldn't want to petition for more than one. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Original line from The Warrior's Apprentice by Lois McMaster Bujold: "Only on Barrayar would pulling a loaded needler start a stampede toward one." English-to-Russian-to-English mangling thereof: "Only on Barrayar you risk to lose support instead of finding it when you threat with the charged weapon." _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru