From ltru-bounces@ietf.org Tue Oct 02 00:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZcQ-0004ZC-4c; Tue, 02 Oct 2007 00:44:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IcZcO-0004Yt-Jy for ltru-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 00:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcZcN-0004YX-OB for ltru@ietf.org; Tue, 02 Oct 2007 00:44:23 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcZcI-0004ey-Eq for ltru@ietf.org; Tue, 02 Oct 2007 00:44:23 -0400 Received: from [10.72.78.37] (snvvpn2-10-72-78-c37.corp.yahoo.com [10.72.78.37]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l924hu8V049518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Oct 2007 21:43: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:subject: content-type:content-transfer-encoding; b=WdRJ7UcYeCfV0DvowAJ7IlF+Px2wIl3WyDdMtoJFzsh4TDfgthzyVzFwgIb5kWO9 Message-ID: <4701CC77.1070500@yahoo-inc.com> Date: Mon, 01 Oct 2007 21:43:35 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: d6b246023072368de71562c0ab503126 Subject: [Ltru] teleconference information... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 All, We had a teleconference last week as a kick-off. We'll be holding a follow-on call this week, on Wednesday 3 October 16:00 UTC. Time: 9:00-10:00 Pacific Daylight Time USA Dial-In #:+1.888.371.8922 International Dial-In #:+1.617.224.4792 Participant Passcode: 58371972 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 03 14:07:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8bf-0008L8-78; Wed, 03 Oct 2007 14:05:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Id8bd-0008L0-Sv for ltru-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:05:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8bd-0008Ko-Hm for ltru@ietf.org; Wed, 03 Oct 2007 14:05:57 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id8bd-0002Ap-1z for ltru@ietf.org; Wed, 03 Oct 2007 14:05:57 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mKBkGKTedTtQWKM444jIGGepTExk02jtI4jf4U/37z53E3GYXUTU2dsk1HeCC8N3; 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 [64.105.136.240] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Id8bc-0004a1-A5 for ltru@ietf.org; Wed, 03 Oct 2007 14:05:56 -0400 Message-ID: <000501c805e8$97d30640$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 3 Oct 2007 11:09: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a43a4ad06bf8abf954f3fb9392e87bed3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.240 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ltru] Summary of 2007-10-03 teleconference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 - There was a teleconference to discuss remaining open issues in the ltru drafts this morning. I volunteered to serve as scribe. I hope I got it right. If I didn't, I'm sure someone will correct me. In any case, let's see if we can finish this discussion by working through the tradeoffs and agreeing on something, since it's pretty clear at this point that neither approach is perfect. The primary topic of discussion was the question of what to do about macrolanguages and extlangs. The two major alternatives both had implications for matching. There was general agreement that remove-from-right matching is not a panacea. There was less agreement about whether a macrolanguage- extlang construct is ever helpful, or actually counterproductive, in its interactions with matching. One consequence of the "flat" approach (not including encapsulating subtags in a language tag encoding) is that more intelligent matching would require additional information from the registry, which would increase the risk that someone might build applications that would read the registry, presenting a possible DoS with respect to IANA. There was some disagreement about what is meant by a macrolanguage subtag by itself. Two examples: does zh mean the same thing as zh-cmn, and does ar mean the same thing as ar-arb? A *rough* consensus of those participating in the teleconference (this must not be understood as a determination of WG consensus) was that they mean different things. In this view, "zh" means "undifferentiated Chinese" (much of which happens to be "zh-cmn"), and "ar" means "undifferentiated Arabic". A minority perspective was that because so much content tagged with "zh" is "zh-cmn", they should be understood as effectively synonymous. In fleshing out the details of the alternative approaches, we need to consider the potential for synonyms, and what guidance we provide to taggers in the cases where synonyms could arise, as well as the extent that we might want to distinguish between "true" and "effective" ones. There was a side discussion about the possibility of additional macrolanguages being registered, and about the possibility of the registration of additional exncapsulated languages. None of the likely scenarios appeared to create any serious problems for either proposal. Yet another consideration discussed is the extent to which either approach would require the retagging of existing data. A final consideration will be how to explain it all to the BCP's users. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 03 18:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCMh-0006PG-It; Wed, 03 Oct 2007 18:06:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdCMe-0006Nk-JV for ltru-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 18:06:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCMd-0006Jf-Nl for ltru@ietf.org; Wed, 03 Oct 2007 18:06:43 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdCKb-00005n-TX for ltru@ietf.org; Wed, 03 Oct 2007 18:04:38 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TLE750I7C9i74dVr63b4jPiMJ6XGE4lGm4e4mApvhUlJ6IBW2fQ3V6POouhpteKW; 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 [66.167.206.108] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IdCKa-0007cV-2m for ltru@ietf.org; Wed, 03 Oct 2007 18:04:37 -0400 Message-ID: <001701c80609$ee5cf180$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 3 Oct 2007 15:08: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31ad14e60812ec141869cd7b91e890a7b8e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.108 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Clarifying Suppress-Script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Based on recent discussion on the ietf-languages@iana.org list, as a technical contributor I think we should clarify section 3.1.8 in the current draft by adding the following paragraph to that section: Suppress-Script is a compatibility measure, and as such is only appropriate for languages whose subtags were added to the registry before RFC 4646 was approved. Even for such languages, Supress-Script SHOULD NOT be used unless there exists a significant body (as determined by the Language Subtag Reviewer) of material tagged before the approval of RFC 4646 without a script subtag. Thoughts? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 03 20:35:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEgB-0003JQ-4L; Wed, 03 Oct 2007 20:35:03 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdEg9-0003F5-LW for ltru-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 20:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdEg9-0003Eu-Br for ltru@ietf.org; Wed, 03 Oct 2007 20:35:01 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdEg2-0007xt-Qo for ltru@ietf.org; Wed, 03 Oct 2007 20:35:01 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IdEfr-0007Tt-IZ; Wed, 03 Oct 2007 20:34:43 -0400 Date: Wed, 3 Oct 2007 20:34:43 -0400 To: Randy Presuhn Subject: Re: [Ltru] Clarifying Suppress-Script Message-ID: <20071004003443.GA27520@mercury.ccil.org> References: <001701c80609$ee5cf180$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701c80609$ee5cf180$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > Suppress-Script is a compatibility measure, and as such is > only appropriate for languages whose subtags were added to > the registry before RFC 4646 was approved. +1 > Even for such > languages, Supress-Script SHOULD NOT be used unless there > exists a significant body (as determined by the Language > Subtag Reviewer) of material tagged before the approval of > RFC 4646 without a script subtag. Neither the LSR nor anyone else (not even people who work for search-engine companies) is in a position to make any such determination. Not all tagged material is open to public scrutiny. I am therefore opposed to adding this sentence. -- With techies, I've generally found John Cowan If your arguments lose the first round http://www.ccil.org/~cowan Make it rhyme, make it scan cowan@ccil.org Then you generally can Make the same stupid point seem profound! --Jonathan Robie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 12:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdT8K-0005Ii-6n; Thu, 04 Oct 2007 12:01:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdT8I-0004vx-Es for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 12:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdT8H-0004oZ-Qt for ltru@ietf.org; Thu, 04 Oct 2007 12:01:01 -0400 Received: from [216.65.151.51] (helo=mail2.sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdT8F-0006Go-S9 for ltru@ietf.org; Thu, 04 Oct 2007 12:01:01 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 467D91E1305; Thu, 4 Oct 2007 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at sharplabs.com Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiEDW3MzKc8M; Thu, 4 Oct 2007 09:00:28 -0700 (PDT) Received: from wabex1.enet.sharplabs.com (wabex1.sharpamericas.com [172.29.224.8]) by mail2.sharplabs.com (Postfix) with ESMTP; Thu, 4 Oct 2007 08:59:40 -0700 (PDT) Received: from wabex2.sharpamericas.com ([172.29.224.9]) by wabex1.enet.sharplabs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 08:59:36 -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] Clarifying Suppress-Script Date: Thu, 4 Oct 2007 08:59:35 -0700 Message-ID: In-Reply-To: <20071004003443.GA27520@mercury.ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Clarifying Suppress-Script Thread-Index: AcgGHrBMDgruXEgeQKCiJS3zlfH8sAAiMJHg From: "McDonald, Ira" To: "John Cowan" , "Randy Presuhn" X-OriginalArrivalTime: 04 Oct 2007 15:59:36.0410 (UTC) FILETIME=[8FE9F3A0:01C8069F] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Hi, I object to this whole paragraph. Because RFC 4646 *inserted* scripts between the two previously main subtags (language and region), Suppress-Script is necessary for MANY languages tagged in the future. It has nothing to do with an existing body of tagged material. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG 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 03, 2007 7:35 PM To: Randy Presuhn Cc: LTRU Working Group Subject: Re: [Ltru] Clarifying Suppress-Script Randy Presuhn scripsit: > Suppress-Script is a compatibility measure, and as such is > only appropriate for languages whose subtags were added to > the registry before RFC 4646 was approved. +1 > Even for such > languages, Supress-Script SHOULD NOT be used unless there > exists a significant body (as determined by the Language > Subtag Reviewer) of material tagged before the approval of > RFC 4646 without a script subtag. Neither the LSR nor anyone else (not even people who work for search-engine companies) is in a position to make any such = determination. Not all tagged material is open to public scrutiny. I am therefore opposed to adding this sentence. --=20 With techies, I've generally found John Cowan If your arguments lose the first round = http://www.ccil.org/~cowan Make it rhyme, make it scan cowan@ccil.org Then you generally can Make the same stupid point seem profound! --Jonathan Robie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.488 / Virus Database: 269.14.0/1049 - Release Date: = 10/4/2007 8:59 AM =20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 13:07:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUA7-0003PA-Gj; Thu, 04 Oct 2007 13:06:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdUA5-0003LR-Sv for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUA5-0003J6-I0 for ltru@ietf.org; Thu, 04 Oct 2007 13:06:57 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdUA0-0008Mm-20 for ltru@ietf.org; Thu, 04 Oct 2007 13:06:57 -0400 Received: by wa-out-1112.google.com with SMTP id k40so394529wah for ; Thu, 04 Oct 2007 10:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=QgioBPeh+dIfQRUNPhp0as5A08QJWAoleSzRf6ggzRU=; b=Ba1Nn1asgFcJ5TFCP6VcpS6uCThNnXx2wmu3hAs7AYpbEPm1DCUh36SrYM6ahcXivx4SNo2fSJy7swyhdsCFbUM+YZN5xMTcLcGkIIU08O7eecnqs/KIuehKLx4lXH+YLAYdmbr30XIOWyY5mVQFJ8NfEKCKcM0kKjv75SCvBmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fzYO+9EmSO/QZ3Osux7xEOsgdzcf/3izMgHIQd+v7IgWt5YOclOnc97qzV1Ztufp3Rocnl1xDRaL4NOvOqrwP96chII7hlEiiyKsSidUnPP6wn8rFAmPjA54X/AXaPP2i9ExUjyz3VF50hX+0HUH2gOQfj7tdopE04idQGMBC5Y= Received: by 10.114.52.1 with SMTP id z1mr6178396waz.1191517574601; Thu, 04 Oct 2007 10:06:14 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 4 Oct 2007 10:06:14 -0700 (PDT) Message-ID: <30b660a20710041006h4eba1458kef8819719dd7f51e@mail.gmail.com> Date: Thu, 4 Oct 2007 10:06:14 -0700 From: "Mark Davis" To: "McDonald, Ira" Subject: Re: [Ltru] Clarifying Suppress-Script In-Reply-To: MIME-Version: 1.0 References: <20071004003443.GA27520@mercury.ccil.org> X-Google-Sender-Auth: c9488d7fbbea1580 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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="===============0706273258==" Errors-To: ltru-bounces@ietf.org --===============0706273258== Content-Type: multipart/alternative; boundary="----=_Part_32314_19983158.1191517574588" ------=_Part_32314_19983158.1191517574588 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am pulled in different directions on this. What people should do when tagging is inexorably linked with what implementers should do when interpreting tags. If there is a mismatch in expectations, then we get problems. What I as an implementer want to know is: when I see xxx-YY and xxx-ZZZZ-YY, what am I to do? 1. Do I treat these as essentially synonyms for filtering and lookup? (eg en-US and en-Latn-US) 2. Do I treat them as completely different for filtering and lookup (eg ru-RU and ru-Latn-RU, or zh-CN and zh-Latn-CN) 3. Do I treat them as different for filtering, but as synonyms for lookup (eg zh-CN and zh-Hans-CN, or zh-TW and zh-Hant-TW) On the one hand, Suppress Script, as discussed before, is a very imperfect tool: it doesn't tell me about case 3, and it is ambiguous -- being missing could mean that there are multiple common scripts for a language, or could mean that there is no information available. On the other hand, whether or not the language code was pre or post 4646 doesn't seem to make much difference as far as the question of what I should do when interpreting these codes, so it seems from that that we should not make Suppress-Script depend on pre or post 4646. Mark On 10/4/07, McDonald, Ira wrote: > > Hi, > > I object to this whole paragraph. Because RFC 4646 > *inserted* scripts between the two previously main > subtags (language and region), Suppress-Script is > necessary for MANY languages tagged in the future. > It has nothing to do with an existing body of tagged > material. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > 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 03, 2007 7:35 PM > To: Randy Presuhn > Cc: LTRU Working Group > Subject: Re: [Ltru] Clarifying Suppress-Script > > > Randy Presuhn scripsit: > > > Suppress-Script is a compatibility measure, and as such is > > only appropriate for languages whose subtags were added to > > the registry before RFC 4646 was approved. > > +1 > > > Even for such > > languages, Supress-Script SHOULD NOT be used unless there > > exists a significant body (as determined by the Language > > Subtag Reviewer) of material tagged before the approval of > > RFC 4646 without a script subtag. > > Neither the LSR nor anyone else (not even people who work for > search-engine companies) is in a position to make any such determination. > Not all tagged material is open to public scrutiny. I am therefore > opposed to adding this sentence. > > -- > With techies, I've generally found John Cowan > If your arguments lose the first round http://www.ccil.org/~cowan > Make it rhyme, make it scan cowan@ccil.org > Then you generally can > Make the same stupid point seem profound! --Jonathan Robie > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.14.0/1049 - Release Date: 10/4/2007 > 8:59 AM > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_32314_19983158.1191517574588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am pulled in different directions on this. What people should do when tagging is inexorably linked with what implementers should do when interpreting tags. If there is a mismatch in expectations, then we get problems.

What I as an implementer want to know is: when I see xxx-YY and xxx-ZZZZ-YY, what am I to do?
  1. Do I treat these as essentially synonyms for filtering and lookup? (eg en-US and en-Latn-US)
  2. Do I treat them as completely different for filtering and lookup (eg ru-RU and ru-Latn-RU, or zh-CN and zh-Latn-CN)
  3. Do I treat them as different for filtering, but as synonyms for lookup (eg zh-CN and zh-Hans-CN, or zh-TW and zh-Hant-TW)
On the one hand, Suppress Script, as discussed before, is a very imperfect tool: it doesn't tell me about case 3, and it is ambiguous -- being missing could mean that there are multiple common scripts for a language, or could mean that there is no information available.

On the other hand, whether or not the language code was pre or post 4646 doesn't seem to make much difference as far as the question of what I should do when interpreting these codes, so it seems from that that we should not make Suppress-Script depend on pre or post 4646.

Mark

On 10/4/07, McDonald, Ira <imcdonald@sharplabs.com> wrote:
Hi,

I object to this whole paragraph.  Because RFC 4646
*inserted* scripts between the two previously main
subtags (language and region), Suppress-Script is
necessary for MANY languages tagged in the future.
It has nothing to do with an existing body of tagged
material.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
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 03, 2007 7:35 PM
To: Randy Presuhn
Cc: LTRU Working Group
Subject: Re: [Ltru] Clarifying Suppress-Script


Randy Presuhn scripsit:

>   Suppress-Script is a compatibility measure, and as such is
>   only appropriate for languages whose subtags were added to
>    the registry before RFC 4646 was approved.

+1

>   Even for such
>   languages, Supress-Script SHOULD NOT be used unless there
>   exists a significant body (as determined by the Language
>   Subtag Reviewer) of material tagged before the approval of
>   RFC 4646 without a script subtag.

Neither the LSR nor anyone else (not even people who work for
search-engine companies) is in a position to make any such determination.
Not all tagged material is open to public scrutiny.  I am therefore
opposed to adding this sentence.

--
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.ccil.org/~cowan
    Make it rhyme, make it scan                 cowan@ccil.org
    Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie


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

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.0/1049 - Release Date: 10/4/2007 8:59 AM



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



--
Mark ------=_Part_32314_19983158.1191517574588-- --===============0706273258== 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 --===============0706273258==-- From ltru-bounces@ietf.org Thu Oct 04 13:20:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUND-0000l4-1A; Thu, 04 Oct 2007 13:20:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdUNB-0000kN-LN for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUNB-0000kF-Bp for ltru@ietf.org; Thu, 04 Oct 2007 13:20:29 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdUN1-0000Ou-TM for ltru@ietf.org; Thu, 04 Oct 2007 13:20:29 -0400 Received: by wa-out-1112.google.com with SMTP id k40so400650wah for ; Thu, 04 Oct 2007 10:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=hIWyvRTZ5vQAq2cX76Iq4+LqMiSih8T6b8zSTKJQWXA=; b=nogsKS90nw3XFbQVe+5LXOFgbiaumXM73E9epJah3uNDxtO9IW31MMyb+y/AGEtw6HFonbGpv/EvTN8TFE2P58zGh/GinpGJkpG1Fc/Di6y/Bh2XTe/yA1+gP5QiK4IyRblJRO219r3e51ySnmU+pbHVX1smy8RbFLQIQtxtgqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=kAsrxh5QkIZHWW3jLdjdd8IusgUsBnHgBNNw6UpTODv2SGIKfkp1a8yset3t79/Of/S114JdEuoDz+0XztYIUMVm/wycCIHDGk5NI730iqeMKyUY62Mdl7XBLxgV2x1DTld0M56aLrlDSuWd+nKNj5TlgFpRHfI4wbM+2EDYY20= Received: by 10.114.159.1 with SMTP id h1mr6191520wae.1191518405090; Thu, 04 Oct 2007 10:20:05 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 4 Oct 2007 10:20:05 -0700 (PDT) Message-ID: <30b660a20710041020t45ff450g964d8ff1ae6ab2df@mail.gmail.com> Date: Thu, 4 Oct 2007 10:20:05 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Summary of 2007-10-03 teleconference In-Reply-To: <000501c805e8$97d30640$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <000501c805e8$97d30640$6801a8c0@oemcomputer> X-Google-Sender-Auth: a215ed693d032179 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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="===============0002650403==" Errors-To: ltru-bounces@ietf.org --===============0002650403== Content-Type: multipart/alternative; boundary="----=_Part_32407_5298106.1191518405085" ------=_Part_32407_5298106.1191518405085 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/3/07, Randy Presuhn wrote: > > Hi - > > There was a teleconference to discuss remaining open issues in > the ltru drafts this morning. I volunteered to serve as scribe. > I hope I got it right. If I didn't, I'm sure someone will > correct me. In any case, let's see if we can finish this discussion > by working through the tradeoffs and agreeing on something, since > it's pretty clear at this point that neither approach is perfect. > > The primary topic of discussion was the question of what to do > about macrolanguages and extlangs. The two major alternatives > both had implications for matching. > > There was general agreement that remove-from-right matching is not > a panacea. There was less agreement about whether a macrolanguage- > extlang construct is ever helpful, or actually counterproductive, > in its interactions with matching. > > One consequence of the "flat" approach (not including encapsulating > subtags in a language tag encoding) is that more intelligent matching is that some people felt [this was not universal] would require additional information from the registry, which would > increase the risk that someone might build applications that would > read the registry, presenting a possible DoS with respect to IANA. (Suppress Script already requires access to the registry. One could theoretically argue that this is only required on the tagging side, not the matching side, but in practice any reasonable application is going to probably need to have a snapshot of information from the registry.) There was some disagreement about what is meant by a macrolanguage > subtag by itself. Two examples: does zh mean the same thing as zh-cmn, > and does ar mean the same thing as ar-arb? A *rough* consensus > of those participating in the teleconference (this must not be > understood as a determination of WG consensus) was that they mean > different things. In this view, "zh" means "undifferentiated Chinese" > (much of which happens to be "zh-cmn"), and "ar" means "undifferentiated > Arabic". A minority perspective was that because so much content > tagged with "zh" is "zh-cmn", they should be understood as effectively > synonymous. One of the key issues we need to face are the problems introduced by either of the models: no-NO nn-NO (or no-nn-NO*) nb-NO (or no-nb-NO*) vs. zh-Hant-HK zh-yue-Hant-HK or yue-Hant-HK zh-cmn-Hant-HK or cmn-Hant-HK While theoretically no-NO and nb-NO are different, in practice every implementation I know of ends up having to treat them as synonyms -- that wouldn't have changed if they had been encoded as no-nb-NO and no-NO. The same is true of zh-Hant-HK and zh-cmn-Hant-HK, or ar-SA and ar-arb-SA. In fleshing out the details of the alternative approaches, we need to > consider the potential for synonyms, and what guidance we provide to > taggers in the cases where synonyms could arise, as well as the extent > that we might want to distinguish between "true" and "effective" ones. > > There was a side discussion about the possibility of additional > macrolanguages being registered, and about the possibility of the > registration of additional exncapsulated languages. None of the > likely scenarios appeared to create any serious problems for either > proposal. > > Yet another consideration discussed is the extent to which either approach > would require the retagging of existing data. > > A final consideration will be how to explain it all to the BCP's users. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_32407_5298106.1191518405085 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/3/07, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

There was a teleconference to discuss remaining open issues in
the ltru drafts this morning.  I volunteered to serve as scribe.
I hope I got it right.  If I didn't, I'm sure someone will
correct me.  In any case, let's see if we can finish this discussion
by working through the tradeoffs and agreeing on something, since
it's pretty clear at this point that neither approach is perfect.

The primary topic of discussion was the question of what to do
about macrolanguages and extlangs.  The two major alternatives
both had implications for matching.

There was general agreement that remove-from-right matching is not
a panacea.  There was less agreement about whether a macrolanguage-
extlang construct is ever helpful, or actually counterproductive,
in its interactions with matching.

One consequence of the "flat" approach (not including encapsulating
subtags in a language tag encoding) is that more intelligent matching

is that some people felt
[this was not universal]

would require additional information from the registry, which would
increase the risk that someone might build applications that would
read the registry, presenting a possible DoS with respect to IANA.

(Suppress Script already requires access to the registry. One could theoretically argue that this is only required on the tagging side, not the matching side, but in practice any reasonable application is going to probably need to have a snapshot of information from the registry.)

There was some disagreement about what is meant by a macrolanguage
subtag by itself.  Two examples: does zh mean the same thing as zh-cmn,
and does ar mean the same thing as ar-arb?  A *rough* consensus
of those participating in the teleconference (this must not be
understood as a determination of WG consensus) was that they mean
different things.  In this view, "zh" means "undifferentiated Chinese"
(much of which happens to be "zh-cmn"), and "ar" means "undifferentiated
Arabic".  A minority perspective was that because so much content
tagged with "zh" is "zh-cmn", they should be understood as effectively
synonymous.

One of the key issues we need to face are the problems introduced by either of the models:

no-NO
nn-NO (or no-nn-NO*)
nb-NO (or no-nb-NO*)

vs.

zh-Hant-HK
zh-yue-Hant-HK or yue-Hant-HK
zh-cmn-Hant-HK or cmn-Hant-HK

While theoretically no-NO and nb-NO are different, in practice every implementation I know of ends up having to treat them as synonyms -- that wouldn't have changed if they had been encoded as no-nb-NO and no-NO. The same is true of zh-Hant-HK and zh-cmn-Hant-HK, or ar-SA and ar-arb-SA.


In fleshing out the details of the alternative approaches, we need to
consider the potential for synonyms, and what guidance we provide to
taggers in the cases where synonyms could arise, as well as the extent
that we might want to distinguish between "true" and "effective" ones.

There was a side discussion about the possibility of additional
macrolanguages being registered, and about the possibility of the
registration of additional exncapsulated languages.  None of the
likely scenarios appeared to create any serious problems for either
proposal.

Yet another consideration discussed is the extent to which either approach
would require the retagging of existing data.

A final consideration will be how to explain it all to the BCP's users.

Randy



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



--
Mark ------=_Part_32407_5298106.1191518405085-- --===============0002650403== 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 --===============0002650403==-- From ltru-bounces@ietf.org Thu Oct 04 13:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUfE-0004uD-CO; Thu, 04 Oct 2007 13:39:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdUfA-0004jr-Ip for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:39:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUf9-0004cm-Kl for ltru@ietf.org; Thu, 04 Oct 2007 13:39:03 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdUf9-0007hT-7h for ltru@ietf.org; Thu, 04 Oct 2007 13:39:03 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=S64xG7fu9DIMa7AdBqrLc31t+vEQvyIOMCbIaZNdoeYOwnOYvLpF9RT0fqqgQ2oV; 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 [64.105.35.175] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IdUf8-0007ls-KB for ltru@ietf.org; Thu, 04 Oct 2007 13:39:02 -0400 Message-ID: <002f01c806ae$01bb7e00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20071004003443.GA27520@mercury.ccil.org> <30b660a20710041006h4eba1458kef8819719dd7f51e@mail.gmail.com> Subject: Re: [Ltru] Clarifying Suppress-Script Date: Thu, 4 Oct 2007 10:42:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31abdf4ad766b6b1be47be454d50beb5aac350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.175 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "Mark Davis" > To: "McDonald, Ira" > Cc: "John Cowan" ; "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, October 04, 2007 10:06 AM > Subject: Re: [Ltru] Clarifying Suppress-Script ... > On the other hand, whether or not the language code was pre or post 4646 > doesn't seem to make much difference as far as the question of what I should > do when interpreting these codes, so it seems from that that we should not > make Suppress-Script depend on pre or post 4646. ... As I recall, we added Suppress-Script because there was a large body of already-tagged material which lacked script subtags, and we wanted to be able to process that material as though it had been given script subtags. In this context, suppress-script is only meaningful for coping with such material. Somewhere along the way, the language in what became RFC 4646 got a bit stronger, eventually ending up as "5. There MUST be at most one script subtag in a language tag, and 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." This is still OK with me, but... There seems to be a bit of semantic drift in the understanding of "Suppress- Script", from its original meaning as a legacy data compatibility kluge to a way of indicating for a particular language that a script subtag would probably not add "distinguishing value". It's clear from this discussion that not all of us (myself included) have made such a shift. If we as a WG want to adopt such a semantic shift, we should do so consciously and explicitly, because it has a dramatic impact on the number of languages for which the ietf-languages@iana.org list will have to debate the merits of adding this information to the registry. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 13:44:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUkh-0008IP-CR; Thu, 04 Oct 2007 13:44:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdUkg-0008ID-Ah for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUkg-0008I0-12 for ltru@ietf.org; Thu, 04 Oct 2007 13:44:46 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdUkZ-00019V-Mw for ltru@ietf.org; Thu, 04 Oct 2007 13:44:46 -0400 Received: by wa-out-1112.google.com with SMTP id k40so411105wah for ; Thu, 04 Oct 2007 10:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=lgthBB2DnJQIzjupcEG3BEUIvDSWwdEhWhSaRt9DWuM=; b=X2Su+ioqlteXPjzbEJhNatfyCeCyIjZD6+9xOiFyhupFVyYYJ8zHQK7eruX/NlXRzyjR/PnODeuI2I5ITocyBvZUuGAFF3tL4nkAFCHUuqSSm29aMcPCAp01bG/0wT5ofMin7AHlk3MZkzTbJCWbrkKWA6ihC4lmNPVXtGKEygE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=mEsQNWKfFPeRVJwe7piWlWDI0Qyzv/SJ6Uyajd43XuT/pXMbsOS+CI0/w2MW7iTQmyCZTAZ/OuX1fLh6s63gG2PxFQggHp0WQptpInS+HPPwJfnsSygT1rfv0IeNXSjuH9WKQm1cdIQrMQ+rmnJuXirdMs/922VnnWwM2VBH6fw= Received: by 10.114.174.2 with SMTP id w2mr9480622wae.1191519857420; Thu, 04 Oct 2007 10:44:17 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 4 Oct 2007 10:44:17 -0700 (PDT) Message-ID: <30b660a20710041044vbec0bas4a5e0dde6cf9d1c0@mail.gmail.com> Date: Thu, 4 Oct 2007 10:44:17 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Clarifying Suppress-Script In-Reply-To: <002f01c806ae$01bb7e00$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <20071004003443.GA27520@mercury.ccil.org> <30b660a20710041006h4eba1458kef8819719dd7f51e@mail.gmail.com> <002f01c806ae$01bb7e00$6801a8c0@oemcomputer> X-Google-Sender-Auth: 441f839f3f440a93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0275268949==" Errors-To: ltru-bounces@ietf.org --===============0275268949== Content-Type: multipart/alternative; boundary="----=_Part_32533_30931594.1191519857402" ------=_Part_32533_30931594.1191519857402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that we need to have clearer language, whichever way we go. As I said, I'm not sure of the right answer; I could see going either direction. Mark On 10/4/07, Randy Presuhn wrote: > > Hi - > > As a technical contributor... > > > From: "Mark Davis" > > To: "McDonald, Ira" > > Cc: "John Cowan" ; "Randy Presuhn" < > randy_presuhn@mindspring.com>; "LTRU Working Group" > > Sent: Thursday, October 04, 2007 10:06 AM > > Subject: Re: [Ltru] Clarifying Suppress-Script > ... > > On the other hand, whether or not the language code was pre or post 4646 > > doesn't seem to make much difference as far as the question of what I > should > > do when interpreting these codes, so it seems from that that we should > not > > make Suppress-Script depend on pre or post 4646. > ... > > As I recall, we added Suppress-Script because there was a large body > of already-tagged material which lacked script subtags, and we wanted > to be able to process that material as though it had been given > script subtags. In this context, suppress-script is only meaningful > for coping with such material. > > Somewhere along the way, the language in what became RFC 4646 got a bit > stronger, eventually ending up as "5. There MUST be at most one script > subtag in a language tag, and 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." This is still OK with me, but... > > There seems to be a bit of semantic drift in the understanding of > "Suppress- > Script", from its original meaning as a legacy data compatibility kluge > to a way of indicating for a particular language that a script subtag > would probably not add "distinguishing value". It's clear from this > discussion that not all of us (myself included) have made such a shift. > > If we as a WG want to adopt such a semantic shift, we should do so > consciously > and explicitly, because it has a dramatic impact on the number of > languages > for which the ietf-languages@iana.org list will have to debate the merits > of > adding this information to the registry. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_32533_30931594.1191519857402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that we need to have clearer language, whichever way we go. As I said, I'm not sure of the right answer; I could see going either direction.

Mark

On 10/4/07, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

As a technical contributor...

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "McDonald, Ira" < imcdonald@sharplabs.com>
> Cc: "John Cowan" <cowan@ccil.org>; "Randy Presuhn" <randy_presuhn@mindspring.com >; "LTRU Working Group" <ltru@ietf.org>
> Sent: Thursday, October 04, 2007 10:06 AM
> Subject: Re: [Ltru] Clarifying Suppress-Script
...
> On the other hand, whether or not the language code was pre or post 4646
> doesn't seem to make much difference as far as the question of what I should
> do when interpreting these codes, so it seems from that that we should not
> make Suppress-Script depend on pre or post 4646.
...

As I recall, we added Suppress-Script because there was a large body
of already-tagged material which lacked script subtags, and we wanted
to be able to process that material as though it had been given
script subtags.  In this context, suppress-script is only meaningful
for coping with such material.

Somewhere along the way, the language in what became RFC 4646 got a bit
stronger, eventually ending up as "5.  There MUST be at most one script
subtag in a language tag, and 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."  This is still OK with me, but...

There seems to be a bit of semantic drift in the understanding of "Suppress-
Script", from its original meaning as a legacy data compatibility kluge
to a way of indicating for a particular language that a script subtag
would probably not add "distinguishing value".  It's clear from this
discussion that not all of us (myself included) have made such a shift.

If we as a WG want to adopt such a semantic shift, we should do so consciously
and explicitly, because it has a dramatic impact on the number of languages
for which the ietf-languages@iana.org list will have to debate the merits of
adding this information to the registry.

Randy



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



--
Mark ------=_Part_32533_30931594.1191519857402-- --===============0275268949== 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 --===============0275268949==-- From ltru-bounces@ietf.org Thu Oct 04 14:01:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdV0C-0007Fh-Mh; Thu, 04 Oct 2007 14:00:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdV0B-0007FX-DB for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 14:00:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdV0B-00079L-1m for ltru@ietf.org; Thu, 04 Oct 2007 14:00:47 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdV05-0008MO-H1 for ltru@ietf.org; Thu, 04 Oct 2007 14:00:41 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gvFKCMND219dEy8WxHRK7AZVwCwN97VeKC3Oq/ylWg8fiwmbY6isuvj41RoVL4EG; 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 [64.105.35.175] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IdV04-0003fv-O1 for ltru@ietf.org; Thu, 04 Oct 2007 14:00:41 -0400 Message-ID: <003701c806b1$0798eda0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000501c805e8$97d30640$6801a8c0@oemcomputer> <30b660a20710041020t45ff450g964d8ff1ae6ab2df@mail.gmail.com> Subject: Re: [Ltru] Summary of 2007-10-03 teleconference Date: Thu, 4 Oct 2007 11:04:37 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31ae1a7cda7c652a656ff891741256f5575350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.175 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Mark Davis" > To: "Randy Presuhn" > Cc: "LTRU Working Group" > Sent: Thursday, October 04, 2007 10:20 AM > Subject: Re: [Ltru] Summary of 2007-10-03 teleconference ... > One of the key issues we need to face are the problems introduced by either > of the models: > > no-NO > nn-NO (or no-nn-NO*) > nb-NO (or no-nb-NO*) > > vs. > > zh-Hant-HK > zh-yue-Hant-HK or yue-Hant-HK > zh-cmn-Hant-HK or cmn-Hant-HK > > While theoretically no-NO and nb-NO are different, in practice every > implementation I know of ends up having to treat them as synonyms -- that > wouldn't have changed if they had been encoded as no-nb-NO and no-NO. The > same is true of zh-Hant-HK and zh-cmn-Hant-HK, or ar-SA and ar-arb-SA. ... We need to be careful when talking about "synonyms", when what we're really talking about are the statistical properties of imprecisely tagged data. Such tags are "synonyms" only for the purposes of some applications' heuristics. In hindsight, "no-nn"* / "no-nb"* would have been less horrible that the current mess, even if data (imprecisely due to broadening) tagged "no" would have been mostly of one type. (I read "zh" as "some kind of Chinese", and based on experience know that if a text is "some kind of Chinese" that it's most likely, but not guaranteed to be, Mandarin. An inevitable consequence of our work to make more precise tagging possible it that there will be legacy data tagged less precisely than we might like. There are some cases where the ability to tag imprecisely, and to match imprecisely, are useful. The question is the extent to which we want to support it directly in tag structure, rather than requiring more thorough registry knowledge to make use of it. Of course, it's legitimate to ask whether the cases where such imprecision is actually useful are worth supporting. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 15:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVxu-0000I2-Qf; Thu, 04 Oct 2007 15:02:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdVxt-0000Bc-Ue for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:02:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVxt-0007mk-Iu for ltru@ietf.org; Thu, 04 Oct 2007 15:02:29 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdVxg-0002Gp-IU for ltru@ietf.org; Thu, 04 Oct 2007 15:02:16 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IdVxd-0003Wf-Fo; Thu, 04 Oct 2007 15:02:13 -0400 Date: Thu, 4 Oct 2007 15:02:13 -0400 To: Randy Presuhn Subject: Re: [Ltru] Summary of 2007-10-03 teleconference Message-ID: <20071004190213.GL21367@mercury.ccil.org> References: <000501c805e8$97d30640$6801a8c0@oemcomputer> <30b660a20710041020t45ff450g964d8ff1ae6ab2df@mail.gmail.com> <003701c806b1$0798eda0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003701c806b1$0798eda0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > There are some cases where the ability to tag imprecisely, and to match imprecisely, > are useful. Indeed there are. For example, if I'm tagging documents of modern origin, I can recognize Chinese documents (in Han script) with pretty close to 100% reliability. That is, I can tell if a printed document is entirely in hanzi (with maybe some Latin) as opposed to being in kanji+kana or hanja+hangeul. But Mandarin or Cantonese? No clue. Simplified or traditional? Ya got me. Country of origin? A mystery. At present I can unequivocally and correctly tag these documents "zh". -- John Cowan http://www.ccil.org/~cowan It's like if you meet an really old, really rich guy covered in liver spots and breathing with an oxygen tank, and you say, "I want to be rich, too, so I'm going to start walking with a cane and I'm going to act crotchety and I'm going to get liver disease. --Wil Shipley _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 15:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdW6i-0002A0-76; Thu, 04 Oct 2007 15:11:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdW6g-00021m-2G for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdW6f-0001xK-D3 for ltru@ietf.org; Thu, 04 Oct 2007 15:11:33 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdW6Z-0004KO-5J for ltru@ietf.org; Thu, 04 Oct 2007 15:11:33 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IdW6Y-0004Dj-UB; Thu, 04 Oct 2007 15:11:26 -0400 Date: Thu, 4 Oct 2007 15:11:26 -0400 To: Randy Presuhn Subject: Re: [Ltru] Clarifying Suppress-Script Message-ID: <20071004191126.GN21367@mercury.ccil.org> References: <20071004003443.GA27520@mercury.ccil.org> <30b660a20710041006h4eba1458kef8819719dd7f51e@mail.gmail.com> <002f01c806ae$01bb7e00$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002f01c806ae$01bb7e00$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > As I recall, we added Suppress-Script because there was a large body > of already-tagged material which lacked script subtags, and we wanted > to be able to process that material as though it had been given > script subtags. In this context, suppress-script is only meaningful > for coping with such material. +1 > Somewhere along the way, the language in what became RFC 4646 got a bit > stronger, eventually ending up as "5. There MUST be at most one script > subtag in a language tag, and 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." This is still OK with me, but... The first half is just "Tag wisely". The second half says to apply Suppress-Script when it's available, but does not explain when it should be made available by ietf-languages. It's the latter that's now seen to be needed. -- John Cowan http://ccil.org/~cowan Micropayment advocates mistakenly believe that efficient allocation of resources is the purpose of markets. Efficiency is a byproduct of market systems, not their goal. The reasons markets work are not because users have embraced efficiency but because markets are the best place to allow users to maximize their preferences, and very often their preferences are not for conservation of cheap resources. --Clay Shirkey _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 15:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWny-00041u-Uf; Thu, 04 Oct 2007 15:56:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdWnw-00040X-W6 for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWnw-00040P-MK for ltru@ietf.org; Thu, 04 Oct 2007 15:56:16 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdWnn-0005jx-7v for ltru@ietf.org; Thu, 04 Oct 2007 15:56:16 -0400 Received: by nz-out-0506.google.com with SMTP id n1so255100nzf for ; Thu, 04 Oct 2007 12:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=x1i/gIKCgwrx0kaAuFoPc4CMhU9QYAp84Ad/X+c0r20=; b=qYwdwcDANlzj3GnkW1k/FnZb4fzmUYdp57zRmfNJp2Ryb3HXLiysJznULf6d7LQZ/8fN8pBkQECTJTZ5KC/kbRbT8LdqnWQ61HBW2XXCbLjI36nCcoKCG01ZCK46QiyqwKlZq8//s4DnT2w6ZPWsCpvKq09I5bTUPJstMcSFWnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=OUgOPVl16qo38dF4M+PKmloL/fSp4L3/xnP5dPUugXgha0C4md9FZFaP3LaeTWrq9Eg1B5XhHrseoIMNHZBxAsikoaFfsPdDGw39wLgWYWkrx4Q+qdfHluOPm2GMYR3brsDqwOObUYLpt3cEmqKWfiK8iPwytPQ404IJ/pKKh4s= Received: by 10.114.92.2 with SMTP id p2mr6211914wab.1191527744484; Thu, 04 Oct 2007 12:55:44 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 4 Oct 2007 12:55:44 -0700 (PDT) Message-ID: <30b660a20710041255i22c66db3p657b9b23e6b29f55@mail.gmail.com> Date: Thu, 4 Oct 2007 12:55:44 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Summary of 2007-10-03 teleconference In-Reply-To: <003701c806b1$0798eda0$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <000501c805e8$97d30640$6801a8c0@oemcomputer> <30b660a20710041020t45ff450g964d8ff1ae6ab2df@mail.gmail.com> <003701c806b1$0798eda0$6801a8c0@oemcomputer> X-Google-Sender-Auth: ca9ab7739e6f3b87 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb 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="===============1086064319==" Errors-To: ltru-bounces@ietf.org --===============1086064319== Content-Type: multipart/alternative; boundary="----=_Part_33370_10560161.1191527744275" ------=_Part_33370_10560161.1191527744275 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTAvNC8wNywgUmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4g d3JvdGU6Cj4KPiBIaSAtCj4KPiBBcyBhIHRlY2huaWNhbCBjb250cmlidXRvci4uLgo+Cj4gPiBG cm9tOiAiTWFyayBEYXZpcyIgPG1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnPgo+ID4gVG86ICJS YW5keSBQcmVzdWhuIiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4KPiA+IENjOiAiTFRS VSBXb3JraW5nIEdyb3VwIiA8bHRydUBpZXRmLm9yZz4KPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3Rv YmVyIDA0LCAyMDA3IDEwOjIwIEFNCj4gPiBTdWJqZWN0OiBSZTogW0x0cnVdIFN1bW1hcnkgb2Yg MjAwNy0xMC0wMyB0ZWxlY29uZmVyZW5jZQo+IC4uLgo+ID4gT25lIG9mIHRoZSBrZXkgaXNzdWVz IHdlIG5lZWQgdG8gZmFjZSBhcmUgdGhlIHByb2JsZW1zIGludHJvZHVjZWQgYnkKPiBlaXRoZXIK PiA+IG9mIHRoZSBtb2RlbHM6Cj4gPgo+ID4gbm8tTk8KPiA+IG5uLU5PIChvciBuby1ubi1OTyop Cj4gPiBuYi1OTyAob3Igbm8tbmItTk8qKQo+ID4KPiA+IHZzLgo+ID4KPiA+IHpoLUhhbnQtSEsK PiA+IHpoLXl1ZS1IYW50LUhLIG9yIHl1ZS1IYW50LUhLCj4gPiB6aC1jbW4tSGFudC1ISyBvciBj bW4tSGFudC1ISwo+ID4KPiA+IFdoaWxlIHRoZW9yZXRpY2FsbHkgbm8tTk8gYW5kIG5iLU5PIGFy ZSBkaWZmZXJlbnQsIGluIHByYWN0aWNlIGV2ZXJ5Cj4gPiBpbXBsZW1lbnRhdGlvbiBJIGtub3cg b2YgZW5kcyB1cCBoYXZpbmcgdG8gdHJlYXQgdGhlbSBhcyBzeW5vbnltcyAtLQo+IHRoYXQKPiA+ IHdvdWxkbid0IGhhdmUgY2hhbmdlZCBpZiB0aGV5IGhhZCBiZWVuIGVuY29kZWQgYXMgbm8tbmIt Tk8gYW5kIG5vLU5PLgo+IFRoZQo+ID4gc2FtZSBpcyB0cnVlIG9mIHpoLUhhbnQtSEsgYW5kIHpo LWNtbi1IYW50LUhLLCBvciBhci1TQSBhbmQgYXItYXJiLVNBLgo+IC4uLgo+Cj4gV2UgbmVlZCB0 byBiZSBjYXJlZnVsIHdoZW4gdGFsa2luZyBhYm91dCAic3lub255bXMiLCB3aGVuIHdoYXQgd2Un cmUKPiByZWFsbHkKPiB0YWxraW5nIGFib3V0IGFyZSB0aGUgc3RhdGlzdGljYWwgcHJvcGVydGll cyBvZiBpbXByZWNpc2VseSB0YWdnZWQgZGF0YS4KCgpUcnVlLiBCdXQgd2UgZG9uJ3Qgd2FudCB0 byBidWlsZCBhbiBpdm9yeS10b3dlciBzeXN0ZW0gdGhhdCB3b3JrcyBpbiB0aGVvcnkKYnV0IGZh aWxzIGluIHByYWN0aWNlOiB3ZSBhbHNvIGhhdmUgdG8gYnVpbGQgb24gdGhlIGV4cGVyaWVuY2Ug dGhhdCB3ZSBoYXZlCmluIGRlYWxpbmcgd2l0aCB0YWdzLiBXZSBrbm93IHRoYXQgdGFncyBhcmUg dW5kZXJzcGVjaWZpZWQgYW5kIG1pc3VzZWQsIGFuZApub3QganVzdCBpbiBlZGdlIGNhc2VzIC0t IGluIGxhcmdlIHBlcmNlbnRhZ2VzLiBTbyB3ZSBoYXZlIHRvIGJlIGNvZ25pemFudApvZiB0aGF0 LCBhbmQgZGVzaWduIGEgc3lzdGVtIHRoYXQgaXMgYXMgY2xlYXIgYW5kIHJvYnVzdCBhcyBwb3Nz aWJsZS4gVGhlCm1vcmUgY29tcGxpY2F0ZWQgd2UgbWFrZSB0aGUgc3lzdGVtLCB0aGUgbW9yZSBs aWtlbHkgaXQgaXMgdGhhdCBwZW9wbGUgd2lsbAptYWtlIGVycm9ycy4gSW4gdGhlIGFib3ZlIGNh c2VzLCBlc3NlbnRpYWxseSBldmVyeSBpbXBsZW1lbnRhdGlvbiB3aWxsIGVuZAp1cCBoYXZpbmcg dG8gdHJlYXQgdGhlc2UgYXMgc3lub255bXMgaWYgdGhleSB3YW50IHRvIGRlYWwgcmVhbGlzdGlj YWxseSB3aXRoCnRhZ3MuIFdlIGNhbiBpZ25vcmUgdGhhdCBmYWN0IGFuZCBlbmQgdXAgd2l0aCBh IGZyYWdpbGUgc3lzdGVtLCBvciB3ZSBjYW4KcmVjb2duaXplIHRoYXQgZmFjdCBhbmQgZW5kIHVw IHdpdGggYSBtb3JlIHJvYnVzdCBzeXN0ZW0uCgpBbmQgdGhlIHdob2xlIGdvYWwgbWVudGlvbmVk IGZvciBleHRsYW5nIGxpa2Ugc3VwcHJlc3Mtc2NyaXB0IGlzIGJhY2t3YXJkcwpjb21wYXRpYmls aXR5LiBJbiB0aGF0IGNhc2Ugd2UgYWJzb2x1dGVseSBkbyBoYXZlIHRvIGJlIGNvZ25pemFudCBv ZiBwYXN0CnVzYWdlIGFuZCBpbXBsaWNhdGlvbnMgb2Ygb3VyIG1vZGVsIGZvciB0aGF0LiBSZWNh bGwgdGhlIHdob2xlIGRpc2N1c3Npb24KYXJvdW5kICJnc3ciIGFzIG1lYW5pbmcgQWxlbWFuaXNo IHZzIFN3aXNzIEdlcm1hbi4KClN1Y2ggdGFncyBhcmUgInN5bm9ueW1zIiBvbmx5IGZvciB0aGUg cHVycG9zZXMgb2Ygc29tZSBhcHBsaWNhdGlvbnMnCj4gaGV1cmlzdGljcy4KPiBJbiBoaW5kc2ln aHQsICJuby1ubiIqIC8gIm5vLW5iIiogd291bGQgaGF2ZSBiZWVuIGxlc3MgaG9ycmlibGUgdGhh dCB0aGUKPiBjdXJyZW50IG1lc3MsIGV2ZW4gaWYgZGF0YSAoaW1wcmVjaXNlbHkgZHVlIHRvIGJy b2FkZW5pbmcpIHRhZ2dlZCAibm8iCj4gd291bGQgaGF2ZSBiZWVuIG1vc3RseSBvZiBvbmUgdHlw ZS4KCgpBY3R1YWxseSwgdGhlIGJlc3QgY2FzZSB3b3VsZCBoYXZlIGJlZW4gbmVpdGhlci4gSXQg d291bGQgaGF2ZSBiZWVuIGFkZAoqb25seSogIm5uIiAtLSBub3QgIm5iIiwgYW5kIGhhdmUgZG9j dW1lbnRhdGlvbiB0byB0aGUgZWZmZWN0IHRoYXQ6CkFsdGhvdWdoIHRoZW9yZXRpY2FsbHkgIm5v IiBtZWFucyBhbnkgTm9yd2VnaWFuLCBpbiBwcmFjdGljZSBpdCBpcwppbnRlcnByZXRlZCBhcyBC b2ttYWwuIFBlb3BsZSB0YWdnaW5nIG55bm9yc2sgYXJlIGVuY291cmFnZWQgdG8gdXNlICJubiIK aW5zdGVhZC4KCldlIHdvdWxkIGhhdmUgdGhlbiBlbmRlZCB1cCB3aXRob3V0IGhhdmluZyB0byBq dW1wIHRocm91Z2ggaG9vcHMuIE1vcmVvdmVyLApteSBjb250ZW50aW9uIGlzIHRoYXQgd2hlbiB5 b3UgYWN0dWFsbHkgbG9vayBhdCB0aGUgY29kZSwgaGF2aW5nIG5vLW5iCmluc3RlYWQgb2YgbmIg ZG9lc24ndCBtYWtlIGxpZmUgYW55IGVhc2llciBhdCBhbGw7IG92ZXJhbGwgaXQgc2ltcGx5IGFk ZHMKY29tcGxpY2F0aW9uIHdoaWNoIGlzIGJldHRlciBmb3Igc29tZSBhbGdvcml0aG1zIGFuZCB3 b3JzZSBmb3IgbW9yZS4KCkFuZCBhcyBJIHBvaW50ZWQgb3V0IGluIHRoZSBjYWxsLCBJU08gaXMg Z2l2aW5nIHVzIG5vIGd1aWRhbmNlIGhlcmUuIFRha2UKdGhlIGNhc2Ugb2YgT2xkIEN6ZWNoOyBp ZiBhIGNvZGUgaXMgaW50cm9kdWNlZCBmb3IgdGhhdCBkb2VzIHRoYXQgbmFycm93IHRoZQpzY29w ZSBvZiAiY3oiIHRvIGJlIGp1c3QgbW9kZXJuIEN6ZWNoLCBvciBkb2VzIGl0IGxlYXZlIGl0IGFz IGJyb2FkPyBJZiB0aGV5CmludHJvZHVjZSB0aGUgb2xkIGNvZGUsIHRoZW4gd2UgYXJlIHByb2Jh Ymx5IGJlc3QgZG9jdW1lbnRpbmcgImN6IiBhcyBiZXN0CnVzZWQgZm9yIGp1c3QgbW9kZXJuIEN6 ZWNoLCBqdXN0IGxpa2UgImVuIiBpcyBiZXN0IHVzZWQgZm9yIGp1c3QgbW9kZXJuCkVuZ2xpc2gs IGFuZCAiYW5nIiBmb3IgT2xkIEVuZ2xpc2guCgoKIChJIHJlYWQgInpoIiBhcyAic29tZSBraW5k IG9mIENoaW5lc2UiLAo+IGFuZCBiYXNlZCBvbiBleHBlcmllbmNlIGtub3cgdGhhdCBpZiBhIHRl eHQgaXMgInNvbWUga2luZCBvZiBDaGluZXNlIiB0aGF0Cj4gaXQncyBtb3N0IGxpa2VseSwgYnV0 IG5vdCBndWFyYW50ZWVkIHRvIGJlLCBNYW5kYXJpbi4KCgpJbiBhbiBpZGVhbCB3b3JsZCwgd2Ug bWlnaHQgbmV2ZXIgaGF2ZSB0aGlzIHNpdHVhdGlvbi4gQnV0IHRoZSBzaXR1YXRpb24gaXMKZmFy IGZyb20gY2xlYXIuIEhvdyBtYW55IHBlb3BsZSBoYXZlIGxvb2tlZCBhdCBpbnRlcmZhY2VzIHRo YXQgc2F5IHNpbXBseSAi5Lit5paHIgphbmQgdGhpbmsgInRoYXQgY291bGQgbWVhbiBNYW5kYXJp biBidXQgY291bGQgYWxzbyBtZWFuIEhha2thIiBhbmQgaG93IG1hbnkKdGhpbmsgInRoYXQgbWVh bnMganVzdCBNYW5kYXJpbiwgdGhleSBkb24ndCBvZmZlciBIYWtrYSBzbyBJJ2xsIHBpY2sKc29t ZXRoaW5nIGVsc2UiLCBhbmQgaG93IG1hbnkgdGhpbmsgInRoYXQgbWVhbnMganVzdCBNYW5kYXJp biwgdGhleSBkb24ndApvZmZlciBIYWtrYSwgYnV0IE1hbmRhcmluIGlzIHRoZSBjbG9zZXN0IHRv IEhha2thIHRoYXQgaXMgb2ZmZXJlZCBzbyBJJ2xsCnBpY2sgdGhhdC4iCgpBbiBpbmV2aXRhYmxl IGNvbnNlcXVlbmNlIG9mIG91ciB3b3JrIHRvIG1ha2UgbW9yZSBwcmVjaXNlIHRhZ2dpbmcgcG9z c2libGUKPiBpdCB0aGF0IHRoZXJlIHdpbGwgYmUgbGVnYWN5IGRhdGEgdGFnZ2VkIGxlc3MgcHJl Y2lzZWx5IHRoYW4gd2UgbWlnaHQKPiBsaWtlLgo+IFRoZXJlIGFyZSBzb21lIGNhc2VzIHdoZXJl IHRoZSBhYmlsaXR5IHRvIHRhZyBpbXByZWNpc2VseSwgYW5kIHRvIG1hdGNoCj4gaW1wcmVjaXNl bHksCj4gYXJlIHVzZWZ1bC4gVGhlIHF1ZXN0aW9uIGlzIHRoZSBleHRlbnQgdG8gd2hpY2ggd2Ug d2FudCB0byBzdXBwb3J0IGl0Cj4gZGlyZWN0bHkgaW4gdGFnIHN0cnVjdHVyZSwgcmF0aGVyIHRo YW4gcmVxdWlyaW5nIG1vcmUgdGhvcm91Z2ggcmVnaXN0cnkKPiBrbm93bGVkZ2UgdG8gbWFrZSB1 c2Ugb2YgaXQuCgoKWWVzLCBJIHRoaW5rIHRoYXQgaXMgdGhlIGNydXggb2YgdGhlIG1hdHRlci4g IE15IHBvc2l0aW9uIGlzIHRoYXQgd2Ugd2lsbApoYXZlIG1vcmUgc2F0aXNmYWN0b3J5IHJlc3Vs dHMgb3ZlcmFsbCBpZiB3ZSAoYSkgdHJlYXQgYWxsIGxhbmd1YWdlcyBhcwplcXVhbCwgYW5kIG5v dCBiYWtlIGluIHNvbWUgb2YgdGhlbSBpbnRvIGEgc2Vjb25kYXJ5IHBvc2l0aW9uLCBhbmQgKGIp CnByb3ZpZGUgdGhlIG1hY3JvIGxhbmd1YWdlIGluZm9ybWF0aW9uIHNvIHRoYXQgcGVvcGxlIGNh biB1c2UgaWYgaWYgdGhleQp3YW50LgoKSWYgd2UgYmFrZSBpdCBpbiwgdGhlbiBldmVyeSBzaW1w bGUgYWxnb3JpdGhtIHdpbGwgaW4gcHJhY3RpY2UgYXV0b21hdGljYWxseQpmYWxsIGJhY2sgZnJv bSBDYW50b25lc2UgdG8gTWFuZGFyaW4sIGZhbGwgYmFjayBmcm9tIERhcmkgdG8gUGVyc2lhbiwg ZmFsbApiYWNrIGZyb20gS2hldHJhbmkgdG8gTGFobmRhIC0tIGFuZCBpbiBkb2luZyBzbywgc3Ry aXAgdGhlIHNjcmlwdCBhbmQKY291bnRyeSBpbmZvcm1hdGlvbi4gVGhhdCwgdW5sZXNzIHRoZXkg Zml4IHRoZSBhbGdvcml0aG0gdG8gcHJldGVuZCB0aGF0IHRoZQpzZWNvbmRhcnkgbGFuZ3VhZ2Ug aXMgaW4gZmFjdCBhIHByaW1hcnkgbGFuZ3VhZ2UuIFNvIHdlIGFyZSBmb3JjaW5nIHBlb3BsZQpp bnRvIGEgbW9kZWwgdGhhdCBpcyBvZnRlbiwgb3IgbW9zdGx5LCB3cm9uZy4gSWYgd2Ugc3VwcGx5 IHRoZSBpbmZvcm1hdGlvbgppbiB0aGUgcmVnaXN0cnksIHRoZW4gaW1wbGVtZW50YXRpb25zIGNh biBjaG9vc2Ugd2hhdGV2ZXIgdGhleSB0aGluayBpcwphcHByb3ByaWF0ZSwgZ2l2ZW4gdGhlIHBh cnRpY3VsYXIgZmFjdHMgYWJvdXQgbGFuZ3VhZ2VzIGFuZCB0aGUgcGFydGljdWxhcgpuZWVkcyBv ZiB0aGVpciBhcHBsaWNhdGlvbnMgd2l0aG91dCBoYXZpbmcgdG8gd29yayBhcm91bmQgdGhlIGV4 dGxhbmcKbWVjaGFuaXNtLgoKSSdtIHJlbWluZGVkIGFnYWluIG9mIGEgc2ltaWxhciBjYXNlIHdp dGggQysrLiBUaGUgYXNzaWdubWVudCBvcGVyYXRvciBnZXRzCmEgZGVmYXVsdCBpbXBsZW1lbnRh dGlvbi4gVGhhdCBtdXN0IGhhdmUgc2VlbWVkIGxpa2UgYSBuaWNlIGNvbnZlbmllbmNlIGZvcgp0 aGUgdXNlciwgYnV0IGV4Y2VwdCBmb3IgdG95IHByb2dyYW1zLCBpdCBpcyBhbHdheXMsIGFsd2F5 cyB3cm9uZy4gU28Kc3VwcGx5aW5nIHRoYXQgZGVmYXVsdCBqdXN0IG1lYW5zIHRoYXQgcGVvcGxl IHVzdWFsbHkgaGF2ZSB0byB0YWtlIGV4dHJhCnN0ZXBzIHRvIGRpc2FibGUgaXQsIGFuZCBwcmV2 ZW50IGl0IGZyb20gY2F1c2luZyBidWdzIGluIHRoZWlyIHByb2dyYW1zLiBJJ20Kd29ycmllZCBh Ym91dCB0aGlzIGJlaW5nIHNpbWlsYXIuCgpJdCBpcyBjbGVhciB0aGF0IGNvbXBhbmllcyBsaWtl IEdvb2dsZSBvciBZYWhvbyBjYW4gd29yayBhcm91bmQgdGhlIHByb2JsZW1zCndpdGggZXh0bGFu ZyAtLSB3aGF0IEknbSB3b3JyaWVkIGFib3V0IGFyZSB0aGUgcGVvcGxlIHdobyBkb24ndCBoYXZl IGEgbG90Cm9mIGV4cGVyaWVuY2Ugd2l0aCB0aGVzZSBtYXR0ZXJzLCBhbmQgYXJlIGp1c3QgbGVk IGRvd24gYSBnYXJkZW4gcGF0aC4gSSdtCnJlYWxseSBub3QgdHJ5aW5nIHRvIGJlIG9ic3RyZXBl cm91cyBvbiB0aGlzIGlzc3VlLCBidXQgdGhlcmUgZG9lcyBzZWVtIHRvCmJlIGEgcG9zaXRpdmUg Y29ycmVsYXRpb24gYmV0d2VlbiB0aGUgcGVvcGxlIHdobyBoYXZlIGhhZCBkZXRhaWxlZAppbXBs ZW1lbnRhdGlvbiBleHBlcmllbmNlIHdpdGggZmlsdGVyaW5nIGFuZCBtYXRjaGluZyB0aGVzZSB0 YWdzIGluCnByb2R1Y3Rpb24gZW52aXJvbm1lbnRzIGFuZCB0aG9zZSB3aG8gYXJlIGhhdmUgZG91 YnRzIGFib3V0IGV4dGxhbmcuCgpPZiBjb3Vyc2UsIGl0J3MgbGVnaXRpbWF0ZSB0byBhc2sgd2hl dGhlciB0aGUgY2FzZXMgd2hlcmUgc3VjaCBpbXByZWNpc2lvbgo+IGlzIGFjdHVhbGx5IHVzZWZ1 bCBhcmUgd29ydGggc3VwcG9ydGluZy4KPgo+IFJhbmR5Cj4KPgo+Cj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+IEx0 cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 Cj4KCgoKLS0gCk1hcmsK ------=_Part_33370_10560161.1191527744275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTAvNC8wNywgPGIgY2xh c3M9ImdtYWlsX3NlbmRlcm5hbWUiPlJhbmR5IFByZXN1aG48L2I+ICZsdDs8YSBocmVmPSJtYWls dG86cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbSI+cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5n LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2lu OiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KSGkgLTxicj48YnI+QXMg YSB0ZWNobmljYWwgY29udHJpYnV0b3IuLi48YnI+PGJyPiZndDsgRnJvbTogJnF1b3Q7TWFyayBE YXZpcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3Jn Ij5tYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZzwvYT4mZ3Q7PGJyPiZndDsgVG86ICZxdW90O1Jh bmR5IFByZXN1aG4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5keV9wcmVzdWhuQG1pbmRz cHJpbmcuY29tIj4KcmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbTwvYT4mZ3Q7PGJyPiZndDsg Q2M6ICZxdW90O0xUUlUgV29ya2luZyBHcm91cCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx0 cnVAaWV0Zi5vcmciPmx0cnVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5 LCBPY3RvYmVyIDA0LCAyMDA3IDEwOjIwIEFNPGJyPiZndDsgU3ViamVjdDogUmU6IFtMdHJ1XSBT dW1tYXJ5IG9mIDIwMDctMTAtMDMgdGVsZWNvbmZlcmVuY2UKPGJyPi4uLjxicj4mZ3Q7IE9uZSBv ZiB0aGUga2V5IGlzc3VlcyB3ZSBuZWVkIHRvIGZhY2UgYXJlIHRoZSBwcm9ibGVtcyBpbnRyb2R1 Y2VkIGJ5IGVpdGhlcjxicj4mZ3Q7IG9mIHRoZSBtb2RlbHM6PGJyPiZndDs8YnI+Jmd0OyBuby1O Tzxicj4mZ3Q7IG5uLU5PIChvciBuby1ubi1OTyopPGJyPiZndDsgbmItTk8gKG9yIG5vLW5iLU5P Kik8YnI+Jmd0Ozxicj4mZ3Q7IHZzLjxicj4mZ3Q7Cjxicj4mZ3Q7IHpoLUhhbnQtSEs8YnI+Jmd0 OyB6aC15dWUtSGFudC1ISyBvciB5dWUtSGFudC1ISzxicj4mZ3Q7IHpoLWNtbi1IYW50LUhLIG9y IGNtbi1IYW50LUhLPGJyPiZndDs8YnI+Jmd0OyBXaGlsZSB0aGVvcmV0aWNhbGx5IG5vLU5PIGFu ZCBuYi1OTyBhcmUgZGlmZmVyZW50LCBpbiBwcmFjdGljZSBldmVyeTxicj4mZ3Q7IGltcGxlbWVu dGF0aW9uIEkga25vdyBvZiBlbmRzIHVwIGhhdmluZyB0byB0cmVhdCB0aGVtIGFzIHN5bm9ueW1z IC0tIHRoYXQKPGJyPiZndDsgd291bGRuJiMzOTt0IGhhdmUgY2hhbmdlZCBpZiB0aGV5IGhhZCBi ZWVuIGVuY29kZWQgYXMgbm8tbmItTk8gYW5kIG5vLU5PLiBUaGU8YnI+Jmd0OyBzYW1lIGlzIHRy dWUgb2YgemgtSGFudC1ISyBhbmQgemgtY21uLUhhbnQtSEssIG9yIGFyLVNBIGFuZCBhci1hcmIt U0EuPGJyPi4uLjxicj48YnI+V2UgbmVlZCB0byBiZSBjYXJlZnVsIHdoZW4gdGFsa2luZyBhYm91 dCAmcXVvdDtzeW5vbnltcyZxdW90Oywgd2hlbiB3aGF0IHdlJiMzOTtyZSByZWFsbHkKPGJyPnRh bGtpbmcgYWJvdXQgYXJlIHRoZSBzdGF0aXN0aWNhbCBwcm9wZXJ0aWVzIG9mIGltcHJlY2lzZWx5 IHRhZ2dlZCBkYXRhLjwvYmxvY2txdW90ZT48ZGl2Pjxicj5UcnVlLiBCdXQgd2UgZG9uJiMzOTt0 IHdhbnQgdG8gYnVpbGQgYW4gaXZvcnktdG93ZXIgc3lzdGVtIHRoYXQgd29ya3MgaW4gdGhlb3J5 IGJ1dCBmYWlscyBpbiBwcmFjdGljZTogd2UgYWxzbyBoYXZlIHRvIGJ1aWxkIG9uIHRoZSBleHBl cmllbmNlIHRoYXQgd2UgaGF2ZSBpbiBkZWFsaW5nIHdpdGggdGFncy4gV2Uga25vdyB0aGF0IHRh Z3MgYXJlIHVuZGVyc3BlY2lmaWVkIGFuZCBtaXN1c2VkLCBhbmQgbm90IGp1c3QgaW4gZWRnZSBj YXNlcyAtLSBpbiBsYXJnZSBwZXJjZW50YWdlcy4gU28gd2UgaGF2ZSB0byBiZSBjb2duaXphbnQg b2YgdGhhdCwgYW5kIGRlc2lnbiBhIHN5c3RlbSB0aGF0IGlzIGFzIGNsZWFyIGFuZCByb2J1c3Qg YXMgcG9zc2libGUuIFRoZSBtb3JlIGNvbXBsaWNhdGVkIHdlIG1ha2UgdGhlIHN5c3RlbSwgdGhl IG1vcmUgbGlrZWx5IGl0IGlzIHRoYXQgcGVvcGxlIHdpbGwgbWFrZSBlcnJvcnMuIEluIHRoZSBh Ym92ZSBjYXNlcywgZXNzZW50aWFsbHkgZXZlcnkgaW1wbGVtZW50YXRpb24gd2lsbCBlbmQgdXAg aGF2aW5nIHRvIHRyZWF0IHRoZXNlIGFzIHN5bm9ueW1zIGlmIHRoZXkgd2FudCB0byBkZWFsIHJl YWxpc3RpY2FsbHkgd2l0aCB0YWdzLiBXZSBjYW4gaWdub3JlIHRoYXQgZmFjdCBhbmQgZW5kIHVw IHdpdGggYSBmcmFnaWxlIHN5c3RlbSwgb3Igd2UgY2FuIHJlY29nbml6ZSB0aGF0IGZhY3QgYW5k IGVuZCB1cCB3aXRoIGEgbW9yZSByb2J1c3Qgc3lzdGVtLgo8YnI+PGJyPkFuZCB0aGUgd2hvbGUg Z29hbCBtZW50aW9uZWQgZm9yIGV4dGxhbmcgbGlrZSBzdXBwcmVzcy1zY3JpcHQgaXMgYmFja3dh cmRzIGNvbXBhdGliaWxpdHkuIEluIHRoYXQgY2FzZSB3ZSBhYnNvbHV0ZWx5IGRvIGhhdmUgdG8g YmUgY29nbml6YW50IG9mIHBhc3QgdXNhZ2UgYW5kIGltcGxpY2F0aW9ucyBvZiBvdXIgbW9kZWwg Zm9yIHRoYXQuIFJlY2FsbCB0aGUgd2hvbGUgZGlzY3Vzc2lvbiBhcm91bmQgJnF1b3Q7Z3N3JnF1 b3Q7IGFzIG1lYW5pbmcgQWxlbWFuaXNoIHZzIFN3aXNzIEdlcm1hbi4KPGJyPjwvZGl2Pjxicj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNv bGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGlu Zy1sZWZ0OiAxZXg7Ij5TdWNoIHRhZ3MgYXJlICZxdW90O3N5bm9ueW1zJnF1b3Q7IG9ubHkgZm9y IHRoZSBwdXJwb3NlcyBvZiBzb21lIGFwcGxpY2F0aW9ucyYjMzk7IGhldXJpc3RpY3MuCjxicj5J biBoaW5kc2lnaHQsICZxdW90O25vLW5uJnF1b3Q7KiAvICZxdW90O25vLW5iJnF1b3Q7KiB3b3Vs ZCBoYXZlIGJlZW4gbGVzcyBob3JyaWJsZSB0aGF0IHRoZTxicj5jdXJyZW50IG1lc3MsIGV2ZW4g aWYgZGF0YSAoaW1wcmVjaXNlbHkgZHVlIHRvIGJyb2FkZW5pbmcpIHRhZ2dlZCAmcXVvdDtubyZx dW90Ozxicj53b3VsZCBoYXZlIGJlZW4gbW9zdGx5IG9mIG9uZSB0eXBlLiZuYnNwOzwvYmxvY2tx dW90ZT4KPGRpdj48YnI+QWN0dWFsbHksIHRoZSBiZXN0IGNhc2Ugd291bGQgaGF2ZSBiZWVuIG5l aXRoZXIuIEl0IHdvdWxkIGhhdmUgYmVlbiBhZGQgKm9ubHkqICZxdW90O25uJnF1b3Q7IC0tIG5v dCAmcXVvdDtuYiZxdW90OywgYW5kIGhhdmUgZG9jdW1lbnRhdGlvbiB0byB0aGUgZWZmZWN0IHRo YXQ6PGJyPjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OiA0MHB4OyI+QWx0aG91Z2ggdGhlb3JldGlj YWxseSAmcXVvdDtubyZxdW90OyBtZWFucyBhbnkgTm9yd2VnaWFuLCBpbiBwcmFjdGljZSBpdCBp cyBpbnRlcnByZXRlZCBhcyBCb2ttYWwuIFBlb3BsZSB0YWdnaW5nIG55bm9yc2sgYXJlIGVuY291 cmFnZWQgdG8gdXNlICZxdW90O25uJnF1b3Q7IGluc3RlYWQuCjxicj48YnI+PC9kaXY+V2Ugd291 bGQgaGF2ZSB0aGVuIGVuZGVkIHVwIHdpdGhvdXQgaGF2aW5nIHRvIGp1bXAgdGhyb3VnaCBob29w cy4gTW9yZW92ZXIsIG15IGNvbnRlbnRpb24gaXMgdGhhdCB3aGVuIHlvdSBhY3R1YWxseSBsb29r IGF0IHRoZSBjb2RlLCBoYXZpbmcgbm8tbmIgaW5zdGVhZCBvZiBuYiBkb2VzbiYjMzk7dCBtYWtl IGxpZmUgYW55IGVhc2llciBhdCBhbGw7IG92ZXJhbGwgaXQgc2ltcGx5IGFkZHMgY29tcGxpY2F0 aW9uIHdoaWNoIGlzIGJldHRlciBmb3Igc29tZSBhbGdvcml0aG1zIGFuZCB3b3JzZSBmb3IgbW9y ZS4KPGJyPjxicj5BbmQgYXMgSSBwb2ludGVkIG91dCBpbiB0aGUgY2FsbCwgSVNPIGlzIGdpdmlu ZyB1cyBubyBndWlkYW5jZQpoZXJlLiBUYWtlIHRoZSBjYXNlIG9mIE9sZCBDemVjaDsgaWYgYSBj b2RlIGlzIGludHJvZHVjZWQgZm9yIHRoYXQgZG9lcyB0aGF0Cm5hcnJvdyB0aGUgc2NvcGUgb2Yg JnF1b3Q7Y3omcXVvdDsgdG8gYmUganVzdCBtb2Rlcm4gQ3plY2gsIG9yIGRvZXMgaXQgbGVhdmUg aXQKYXMgYnJvYWQ/IElmIHRoZXkgaW50cm9kdWNlIHRoZSBvbGQgY29kZSwgdGhlbiB3ZSBhcmUg cHJvYmFibHkgYmVzdApkb2N1bWVudGluZyAmcXVvdDtjeiZxdW90OyBhcyBiZXN0IHVzZWQgZm9y IGp1c3QgbW9kZXJuIEN6ZWNoLCBqdXN0IGxpa2UgJnF1b3Q7ZW4mcXVvdDsgaXMgYmVzdCB1c2Vk IGZvciBqdXN0IG1vZGVybiBFbmdsaXNoLCBhbmQgJnF1b3Q7YW5nJnF1b3Q7IGZvciBPbGQgRW5n bGlzaC48YnI+CjxzcGFuPjwvc3Bhbj48YnI+PC9kaXY+PHNwYW4+PGJyPjwvc3Bhbj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4mbmJzcDsoSSByZWFkICZxdW90O3poJnF1b3Q7IGFzICZxdW90O3NvbWUga2luZCBv ZiBDaGluZXNlJnF1b3Q7LAo8YnI+YW5kIGJhc2VkIG9uIGV4cGVyaWVuY2Uga25vdyB0aGF0IGlm IGEgdGV4dCBpcyAmcXVvdDtzb21lIGtpbmQgb2YgQ2hpbmVzZSZxdW90OyB0aGF0PGJyPml0JiMz OTtzIG1vc3QgbGlrZWx5LCBidXQgbm90IGd1YXJhbnRlZWQgdG8gYmUsIE1hbmRhcmluLjwvYmxv Y2txdW90ZT48ZGl2Pjxicj5JbiBhbiBpZGVhbCB3b3JsZCwgd2UgbWlnaHQgbmV2ZXIgaGF2ZSB0 aGlzIHNpdHVhdGlvbi4gQnV0IHRoZSBzaXR1YXRpb24gaXMgZmFyIGZyb20gY2xlYXIuIEhvdyBt YW55IHBlb3BsZSBoYXZlIGxvb2tlZCBhdCBpbnRlcmZhY2VzIHRoYXQgc2F5IHNpbXBseSAmcXVv dDsKPHNwYW4gdGl0bGU9InpoX0hhbnM6IFt6aMWNbmcgd8OpbiAoamnHjm4gdMeQKV0iPuS4reaW hyZxdW90OyBhbmQgdGhpbmsgJnF1b3Q7dGhhdCBjb3VsZCBtZWFuIE1hbmRhcmluIGJ1dCBjb3Vs ZCBhbHNvIG1lYW4gPC9zcGFuPkhha2thJnF1b3Q7IGFuZCBob3cgbWFueSB0aGluayAmcXVvdDt0 aGF0IG1lYW5zIGp1c3QgTWFuZGFyaW4sIHRoZXkgZG9uJiMzOTt0IG9mZmVyIEhha2thIHNvIEkm IzM5O2xsIHBpY2sgc29tZXRoaW5nIGVsc2UmcXVvdDssIGFuZCBob3cgbWFueSB0aGluayAmcXVv dDt0aGF0IG1lYW5zIGp1c3QgTWFuZGFyaW4sIHRoZXkgZG9uJiMzOTt0IG9mZmVyIEhha2thLCBi dXQgTWFuZGFyaW4gaXMgdGhlIGNsb3Nlc3QgdG8gSGFra2EgdGhhdCBpcyBvZmZlcmVkIHNvIEkm IzM5O2xsIHBpY2sgdGhhdC4mcXVvdDsKPC9kaXY+PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQp OyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPkFuIGluZXZp dGFibGUgY29uc2VxdWVuY2Ugb2Ygb3VyIHdvcmsgdG8gbWFrZSBtb3JlIHByZWNpc2UgdGFnZ2lu ZyBwb3NzaWJsZTxicj5pdCB0aGF0IHRoZXJlIHdpbGwgYmUgbGVnYWN5IGRhdGEgdGFnZ2VkIGxl c3MgcHJlY2lzZWx5IHRoYW4gd2UgbWlnaHQgbGlrZS4KPGJyPlRoZXJlIGFyZSBzb21lIGNhc2Vz IHdoZXJlIHRoZSBhYmlsaXR5IHRvIHRhZyBpbXByZWNpc2VseSwgYW5kIHRvIG1hdGNoIGltcHJl Y2lzZWx5LDxicj5hcmUgdXNlZnVsLiBUaGUgcXVlc3Rpb24gaXMgdGhlIGV4dGVudCB0byB3aGlj aCB3ZSB3YW50IHRvIHN1cHBvcnQgaXQ8YnI+ZGlyZWN0bHkgaW4gdGFnIHN0cnVjdHVyZSwgcmF0 aGVyIHRoYW4gcmVxdWlyaW5nIG1vcmUgdGhvcm91Z2ggcmVnaXN0cnkKPGJyPmtub3dsZWRnZSB0 byBtYWtlIHVzZSBvZiBpdC48L2Jsb2NrcXVvdGU+PGRpdj48YnI+WWVzLCBJIHRoaW5rIHRoYXQg aXMgdGhlIGNydXggb2YgdGhlIG1hdHRlci4mbmJzcDsgTXkgcG9zaXRpb24gaXMgdGhhdCB3ZSB3 aWxsIGhhdmUgbW9yZSBzYXRpc2ZhY3RvcnkgcmVzdWx0cyBvdmVyYWxsIGlmIHdlIChhKSB0cmVh dCBhbGwgbGFuZ3VhZ2VzIGFzIGVxdWFsLCBhbmQgbm90IGJha2UgaW4gc29tZSBvZiB0aGVtIGlu dG8gYSBzZWNvbmRhcnkgcG9zaXRpb24sIGFuZCAoYikgcHJvdmlkZSB0aGUgbWFjcm8gbGFuZ3Vh Z2UgaW5mb3JtYXRpb24gc28gdGhhdCBwZW9wbGUgY2FuIHVzZSBpZiBpZiB0aGV5IHdhbnQuCjxi cj48YnI+SWYgd2UgYmFrZSBpdCBpbiwgdGhlbiBldmVyeSBzaW1wbGUgYWxnb3JpdGhtIHdpbGwg aW4gcHJhY3RpY2UgYXV0b21hdGljYWxseSBmYWxsIGJhY2sgZnJvbSBDYW50b25lc2UgdG8gTWFu ZGFyaW4sIGZhbGwgYmFjayBmcm9tIERhcmkgdG8gUGVyc2lhbiwgZmFsbCBiYWNrIGZyb20gS2hl dHJhbmkgdG8gTGFobmRhIC0tIGFuZCBpbiBkb2luZyBzbywgc3RyaXAgdGhlIHNjcmlwdCBhbmQg Y291bnRyeSBpbmZvcm1hdGlvbi4gVGhhdCwgdW5sZXNzIHRoZXkgZml4IHRoZSBhbGdvcml0aG0g dG8gcHJldGVuZCB0aGF0IHRoZSBzZWNvbmRhcnkgbGFuZ3VhZ2UgaXMgaW4gZmFjdCBhIHByaW1h cnkgbGFuZ3VhZ2UuIFNvIHdlIGFyZSBmb3JjaW5nIHBlb3BsZSBpbnRvIGEgbW9kZWwgdGhhdCBp cyBvZnRlbiwgb3IgbW9zdGx5LCB3cm9uZy4gSWYgd2Ugc3VwcGx5IHRoZSBpbmZvcm1hdGlvbiBp biB0aGUgcmVnaXN0cnksIHRoZW4gaW1wbGVtZW50YXRpb25zIGNhbiBjaG9vc2Ugd2hhdGV2ZXIg dGhleSB0aGluayBpcyBhcHByb3ByaWF0ZSwgZ2l2ZW4gdGhlIHBhcnRpY3VsYXIgZmFjdHMgYWJv dXQgbGFuZ3VhZ2VzIGFuZCB0aGUgcGFydGljdWxhciBuZWVkcyBvZiB0aGVpciBhcHBsaWNhdGlv bnMgd2l0aG91dCBoYXZpbmcgdG8gd29yayBhcm91bmQgdGhlIGV4dGxhbmcgbWVjaGFuaXNtLgo8 YnI+PGJyPkkmIzM5O20gcmVtaW5kZWQgYWdhaW4gb2YgYSBzaW1pbGFyIGNhc2Ugd2l0aCBDKysu IFRoZSBhc3NpZ25tZW50IG9wZXJhdG9yIGdldHMgYSBkZWZhdWx0IGltcGxlbWVudGF0aW9uLiBU aGF0IG11c3QgaGF2ZSBzZWVtZWQgbGlrZSBhIG5pY2UgY29udmVuaWVuY2UgZm9yIHRoZSB1c2Vy LCBidXQgPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsiPmV4Y2VwdCBmb3IgdG95IHBy b2dyYW1zLCBpdCBpcyBhbHdheXMsIGFsd2F5cyB3cm9uZy4KPC9zcGFuPiBTbyBzdXBwbHlpbmcg dGhhdCBkZWZhdWx0IGp1c3QgbWVhbnMgdGhhdCBwZW9wbGUgdXN1YWxseSBoYXZlIHRvIHRha2Ug ZXh0cmEgc3RlcHMgdG8gZGlzYWJsZSBpdCwgYW5kIHByZXZlbnQgaXQgZnJvbSBjYXVzaW5nIGJ1 Z3MgaW4gdGhlaXIgcHJvZ3JhbXMuIEkmIzM5O20gd29ycmllZCBhYm91dCB0aGlzIGJlaW5nIHNp bWlsYXIuPGJyPjxicj5JdCBpcyBjbGVhciB0aGF0IGNvbXBhbmllcyBsaWtlIEdvb2dsZSBvciBZ YWhvbyBjYW4gd29yayBhcm91bmQgdGhlIHByb2JsZW1zIHdpdGggZXh0bGFuZyAtLSB3aGF0IEkm IzM5O20gd29ycmllZCBhYm91dCBhcmUgdGhlIHBlb3BsZSB3aG8gZG9uJiMzOTt0IGhhdmUgYSBs b3Qgb2YgZXhwZXJpZW5jZSB3aXRoIHRoZXNlIG1hdHRlcnMsIGFuZCBhcmUganVzdCBsZWQgZG93 biBhIGdhcmRlbiBwYXRoLiBJJiMzOTttIHJlYWxseSBub3QgdHJ5aW5nIHRvIGJlIG9ic3RyZXBl cm91cyBvbiB0aGlzIGlzc3VlLCBidXQgdGhlcmUgZG9lcyBzZWVtIHRvIGJlIGEgcG9zaXRpdmUg Y29ycmVsYXRpb24gYmV0d2VlbiB0aGUgcGVvcGxlIHdobyBoYXZlIGhhZCBkZXRhaWxlZCBpbXBs ZW1lbnRhdGlvbiBleHBlcmllbmNlIHdpdGggZmlsdGVyaW5nIGFuZCBtYXRjaGluZyB0aGVzZSB0 YWdzIGluIHByb2R1Y3Rpb24gZW52aXJvbm1lbnRzIGFuZCB0aG9zZSB3aG8gYXJlIGhhdmUgZG91 YnRzIGFib3V0IGV4dGxhbmcuCjxicj48L2Rpdj48YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7 IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+T2YgY291cnNl LCBpdCYjMzk7cyBsZWdpdGltYXRlIHRvIGFzayB3aGV0aGVyIHRoZSBjYXNlcyB3aGVyZSBzdWNo IGltcHJlY2lzaW9uCjxicj5pcyBhY3R1YWxseSB1c2VmdWwgYXJlIHdvcnRoIHN1cHBvcnRpbmcu PGJyPjxicj5SYW5keTxicj48YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWls dG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSI+Cmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJy IGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TWFyawo= ------=_Part_33370_10560161.1191527744275-- --===============1086064319== 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 --===============1086064319==-- From ltru-bounces@ietf.org Thu Oct 04 15:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWo3-00042T-73; Thu, 04 Oct 2007 15:56:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdWo1-00042D-DX for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 15:56:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdWo0-000421-Lc for ltru@ietf.org; Thu, 04 Oct 2007 15:56:21 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdWo0-00044L-25 for ltru@ietf.org; Thu, 04 Oct 2007 15:56:20 -0400 Received: by nz-out-0506.google.com with SMTP id n1so255238nzf for ; Thu, 04 Oct 2007 12:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=Pymy2fIYkcF4tkkZ1SnOEdJlhO7nEBlIChuIXGRdSs0=; b=II7jS05xl9VnKxNf/8EmMp9ESlBtJoLDvMfsO2SPwDYy9TJ4OvNduSZMh4D1hwtWw2VpXlvV96DFY4pWFDVx6V8TGhmcYXOwO5/AbicsNVlBS+7VDrMI3+B7h2L+ij+1UcTMUbVEF0WJ0YA3jmvD4qMlV1wxSUSxrh4p8Vb0SBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=cHvPIqBn9v2UMtklbbrX1zJjIiA3AObW5bp1HZa2YSFPb0tJTwE+50nZhD/wGYaoZTefTagZA3+cYHGK34AHSvfEfhe8asuicMPhXcS12K7Pg7ujFLYCZN6qhz1fg78Ot2W5YN9EekxuyStbdL8EbngG/EK7VbSMyF2FVAN8Nhc= Received: by 10.114.61.1 with SMTP id j1mr831744waa.1191527775255; Thu, 04 Oct 2007 12:56:15 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 4 Oct 2007 12:56:15 -0700 (PDT) Message-ID: <30b660a20710041256u343d2167h93b3756e3374ade2@mail.gmail.com> Date: Thu, 4 Oct 2007 12:56:15 -0700 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Summary of 2007-10-03 teleconference In-Reply-To: <20071004190213.GL21367@mercury.ccil.org> MIME-Version: 1.0 References: <000501c805e8$97d30640$6801a8c0@oemcomputer> <30b660a20710041020t45ff450g964d8ff1ae6ab2df@mail.gmail.com> <003701c806b1$0798eda0$6801a8c0@oemcomputer> <20071004190213.GL21367@mercury.ccil.org> X-Google-Sender-Auth: d39b62a7110d942d X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============0145567008==" Errors-To: ltru-bounces@ietf.org --===============0145567008== Content-Type: multipart/alternative; boundary="----=_Part_33375_24516304.1191527775236" ------=_Part_33375_24516304.1191527775236 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I can't tell whether "chat" is in French or English either. I'm not sure that's a good argument for having a code that means either. More seriously, one could argue for having a root for each set of languages could sometimes not be detectably different. So we'd have rom* for Romanian and Moldavian That is an interesting thought, though perhaps although difficult to draw the lines in: what or who determines what is detectably different? For example, you said that you personally couldn't tell whether some text was simplified or traditional -- but for any substantial body of text, they are pretty easy to tell apart statistically, and much easier for human readers. And from what John Jenkins has said, Cantonese text is also often distinguishable from Mandarin by character choice and phrasing. Anyway, when in doubt, one can use lists of the likely languages. Mark On 10/4/07, John Cowan wrote: > > Randy Presuhn scripsit: > > > There are some cases where the ability to tag imprecisely, and to match > imprecisely, > > are useful. > > Indeed there are. For example, if I'm tagging documents of modern > origin, I can recognize Chinese documents (in Han script) with pretty > close to 100% reliability. That is, I can tell if a printed document > is entirely in hanzi (with maybe some Latin) as opposed to being in > kanji+kana or hanja+hangeul. But Mandarin or Cantonese? No clue. > Simplified or traditional? Ya got me. Country of origin? A mystery. > > At present I can unequivocally and correctly tag these documents "zh". > > -- > John Cowan http://www.ccil.org/~cowan > It's like if you meet an really old, really rich guy covered in liver > spots and breathing with an oxygen tank, and you say, "I want to be > rich, too, so I'm going to start walking with a cane and I'm going to > act crotchety and I'm going to get liver disease. --Wil Shipley > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_33375_24516304.1191527775236 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I can't tell whether "chat" is in French or English either. I'm not sure that's a good argument for having a code that means either.

More seriously, one could argue for having a root for each set of languages could sometimes not be detectably different. So we'd have

rom*  for Romanian and Moldavian

That is an interesting thought, though perhaps although difficult to draw the lines in: what or who determines what is detectably different? For example, you said that you personally couldn't tell whether some text was simplified or traditional -- but for any substantial body of text, they are pretty easy to tell apart statistically, and much easier for human readers. And from what John Jenkins has said, Cantonese text is also often distinguishable from Mandarin by character choice and phrasing.

Anyway, when in doubt, one can use lists of the likely languages.

Mark

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

> There are some cases where the ability to tag imprecisely, and to match imprecisely,
> are useful.

Indeed there are.  For example, if I'm tagging documents of modern
origin, I can recognize Chinese documents (in Han script) with pretty
close to 100% reliability.  That is, I can tell if a printed document
is entirely in hanzi (with maybe some Latin) as opposed to being in
kanji+kana or hanja+hangeul.  But Mandarin or Cantonese?  No clue.
Simplified or traditional? Ya got me.  Country of origin?  A mystery.

At present I can unequivocally and correctly tag these documents "zh".

--
John Cowan <cowan@ccil.org>             http://www.ccil.org/~cowan
It's like if you meet an really old, really rich guy covered in liver
spots and breathing with an oxygen tank, and you say, "I want to be
rich, too, so I'm going to start walking with a cane and I'm going to
act crotchety and I'm going to get liver disease. --Wil Shipley


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



--
Mark ------=_Part_33375_24516304.1191527775236-- --===============0145567008== 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 --===============0145567008==-- From ltru-bounces@ietf.org Thu Oct 04 18:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZ5T-0006Qp-Bv; Thu, 04 Oct 2007 18:22:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdYJm-0006rr-Ex for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 17:33:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYJm-0006rj-2A for ltru@ietf.org; Thu, 04 Oct 2007 17:33:14 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdYJl-0000WR-HG for ltru@ietf.org; Thu, 04 Oct 2007 17:33:13 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 4 Oct 2007 14:33:12 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Thu, 4 Oct 2007 14:33:12 -0700 From: Shawn Steele To: "ltru@ietf.org" Date: Thu, 4 Oct 2007 14:33:05 -0700 Thread-Topic: Extended language tags Thread-Index: AcgGn71y5iG0YQagRpS0ug4uGekhiAAFHBGg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {3E991A72-F7F6-49C6-AEF5-ADF18F8398C6} x-cr-hashedpuzzle: DFP9 E0Uj E2yx FMQ6 FhTI FmXk GbGS GgYc HGQv H0aK IPcf IRV1 ISBC In3c JnCI KxFJ; 1; bAB0AHIAdQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {3E991A72-F7F6-49C6-AEF5-ADF18F8398C6}; cwBoAGEAdwBuAC4AcwB0AGUAZQBsAGUAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Thu, 04 Oct 2007 21:33:05 GMT;RQB4AHQAZQBuAGQAZQBkACAAbABhAG4AZwB1AGEAZwBlACAAdABhAGcAcwA= acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Thu, 04 Oct 2007 18:22:29 -0400 Subject: [Ltru] Extended 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 There's been lots of discussion about the extended language tags, but it do= esn't seem like there've been many conclusions. I've gleaned the following= points for the discussion: * We (the bigger software ecosystem we, tools, etc) have encouraged= use of zh-HK, etc for labeling both Mandarin and Cantonese. Whatever happ= ens in the future a large number of legacy documents, both Manderin and Can= tonese, will be labeled with the existing language tag. * Whether or not yue or zh-yue was used, it is a change from the cu= rrent label (in most cases). It seems that in nearly all cases this will r= equire a code change. In particular applications that want to include zh-H= K in lists containing zh-cmn-HK or cmn-HK will need extra awareness. * I don't think the Breton example applies. http-accept-lang allow= s for "br-FR;fr-FR" type fallback, so that is a solution. If an applicatio= n independently wanted to make this assumption that's fine by me, but this = seems orthogonal to the problem we're trying to solve here. * Lots of zh data right now is zh-cmn. Most of "us" seem to agree = that we can't narrow the meaning of zh because it does allow Cantonese. Ho= wever if some application wanted to make an assumption that zh =3D=3D zh-cm= n, then that seems up to the application for fallback. * Even for the current tags, many of the people in the teleconferen= ce seem to extend RFC 4647 in ways that are best for them. Strict use of 4= 647 behavior seems rare. It seems reasonable to me to expect that in the f= uture people may continue to do so and that RFC 4647 and the registry can o= nly provide guidelines. I don't think that it can solve all problems for a= ll applications, and I'm fine with that. * It was proposed that the registry could provide a link from cmn t= o zh for applications that want this. My experience has been that the regi= stry is good for providing recommendations, but in practice software is rar= ely kept current with the actual data currently in the registry. * FWIW: some documents are currently tagged zh-yue. * RFC 4646 strongly implies that that direction is zh-cmn rather th= an cmn. By itself this isn't a big concern to me, but taken with the grand= fathered and existing zh-yue data I would think there'd need to be a strong= case to change directions. So from these points, my conclusion is that the zh-cmn form is preferable. My reasoning is that either cmn by itself or zh-cmn will require code chang= e in nearly all cases, either to include or exclude existing data or fallba= ck rules. Either was will require a code change, and either way may requi= re knowledge that zh-HK might be interesting if the request is for {Mandari= n tag}-HK. Searching may need to include zh files for {Manderin tag} queri= es and exclude them for {Cantonese tag} queries, but the actual tag doesn't= really change this logic. Neither variation is likely to work with existi= ng code when the request is for the new name and the data is tagged with th= e old tag. The deciding factor for me is that to know that cmn is related to zh I'd ha= ve to look in the registry, but zh-cmn contains that information. Otherwis= e I don't really see advantages with either method. - Shawn SDE Windows International Visual Studio .Net Microsoft _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 21:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdbaW-0007Cx-FH; Thu, 04 Oct 2007 21:02:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdbaT-00078j-It for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 21:02:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdbaT-0006zJ-8f for ltru@ietf.org; Thu, 04 Oct 2007 21:02:41 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdbaJ-0000lG-3h for ltru@ietf.org; Thu, 04 Oct 2007 21:02:37 -0400 Received: by wr-out-0506.google.com with SMTP id 70so298598wra for ; Thu, 04 Oct 2007 18:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=i3TcOIQ0iaP2yKiMTJefkc76XuLUGDggCY9uEtC9Mlg=; b=B1pCRXzj5vyAVFPY+ambWAlh0j0Ma1QucPTdxLwTP5zSpLOJYAXF0iIe9ezrMSsUap9u4c/DswpW2TyRwDVv+FRoCwgjunH84AO6BPnZZ1hT5xd//yD02FMhMZrF4tuW3ftHPmtWGFWBITgwx45uoa3lawPCCvQBVsJFwHKCXXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DVfXvtZHZtsjCcoJ6uHBiS/mZWbHBSZNwnKafh/sLwHTFURsBxwht7GkdMEJRI/v1HL/3p/xuapK2FWmy1Zz4xDB6/LWfHK9Q70MCPwHoSE0Yxn5FyB+7DFsUwHSPw7dU4Npss/U7Qr3Oc7kFXzw3ibi5BZLG4PDltxc9anKzRw= Received: by 10.142.163.14 with SMTP id l14mr1293278wfe.1191546095657; Thu, 04 Oct 2007 18:01:35 -0700 (PDT) Received: by 10.142.87.14 with HTTP; Thu, 4 Oct 2007 18:01:35 -0700 (PDT) Message-ID: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> Date: Fri, 5 Oct 2007 11:01:35 +1000 From: "Andrew Cunningham" To: "Shawn Steele" Subject: Re: [Ltru] Extended language tags In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Throwing in my two cents worth: One aspect of language tagging is the preference for the tags to be as specific as possible. In some cases it is desirable to be less specific. An example i mentioned on the teleconference was the case of Dinka. In ISO-639-2 this is represented by the language code "din". While ISO-639-3 have the following language codes: dib South Central Dinka dik Southwestern Dinka dip Northeastern Dinka diw Northwestern Dinka dks Southeastern Dinka If I was applying a langauge tag to a Rek grammar, then i'd use "dik", for a collection of Ciec folktales I'd use "dib". For a collection of Bor proverbs I'd use "dks". To describe the literacy materials and class room materials being developed in Australia by the Dinka community, I'd use "din". Within the diaspora and in Australia specifically the literacy and language teachers, translators and interpreters are discussing a standardized approach to written Dinka. The original SPLA/M education policies highlighted Rek as a standard for written Dinka. What seems to be occurring is an amalgam based on Rek, but including aspects and vocab from other Dinka dialects. There will be a locally hosted conference next year to thrash out some of the issues. In this context "din": would be the most appropriate way of tagging the new educational material, while keeping the existing five iso-639-3 language tags to more accurately describe information and data written in one of the 20 odd specific dialects. from the perspective of the user community, an extlang approach would make more sense, i.e. Rek labeled as "din-dik" makes more sense than "dik". To the community Rek is a Dinka langauge, Dinak Rek, not a separate language called Rek. In this sense extlang reflects the communities understanding of their language. This is just an observation, i'm neither for or against extlang. Although from the perspective of web development and how CSS and web browsers handle psuedo langauge selectors and attribute selectors, I'd suggest that extlang approach simplifies things for those rare individuals amongst us that use these selectors. Andrew -- Andrew Cunningham State Library of Victoria, Australia andrewc@vicnet.net.au lang.support@gmail.com _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 21:26:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idbwu-0005g3-1T; Thu, 04 Oct 2007 21:25:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idbws-0005af-5x for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 21:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idbwr-0005V3-MM for ltru@ietf.org; Thu, 04 Oct 2007 21:25:49 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idbwl-0001FP-Am for ltru@ietf.org; Thu, 04 Oct 2007 21:25:49 -0400 Received: by wa-out-1112.google.com with SMTP id k40so571484wah for ; Thu, 04 Oct 2007 18:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=zV3JXC5UrDDnm2CQl6CERCAgEnBCyU7FFsVKOZKVzgA=; b=coK6ZBajDojMNvehh7CKT6lMJs5LHphTkGZ7eE74xTd1jtpQLWR+QUm8+o42hPSHeyRysOuYzeQ5yNQVj3a2tnaj/FFKWFd11nlg13tTYnrs+89Ou/WAbutuKVdIF7M0clqBjwRXIzTctGuTJ4B11yJ/3j4g3nUnH+DfWs+/cC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jS1LWUPX6UDdWMIdbCYjW5WmP2MYjd4hYWjb/ABptIZUYgXobeaVjS5TVaXX4a9YuAge4Op7zeq7uco2kcCLPJBHsEBRLTIVZwW24VZsqBh/CDLvwAtLWRG6TzVrQdtc0Z8q9inDAT859KFsHr1tqQTUfnlqOnwLQ92gt1PV8+U= Received: by 10.114.78.1 with SMTP id a1mr10256178wab.1191547532701; Thu, 04 Oct 2007 18:25:32 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 4 Oct 2007 18:25:27 -0700 (PDT) Message-ID: <30b660a20710041825l61956284l7380ed727bac9de2@mail.gmail.com> Date: Thu, 4 Oct 2007 18:25:27 -0700 From: "Mark Davis" To: "Andrew Cunningham" Subject: Re: [Ltru] Extended language tags In-Reply-To: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> MIME-Version: 1.0 References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> X-Google-Sender-Auth: 7ebc30ea4e94b6f5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "ltru@ietf.org" , Shawn Steele X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0931731350==" Errors-To: ltru-bounces@ietf.org --===============0931731350== Content-Type: multipart/alternative; boundary="----=_Part_34500_32676940.1191547527691" ------=_Part_34500_32676940.1191547527691 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline a small correction: > In this sense extlang reflects the communities understanding of their language. => In this sense macro languages reflects the communities understanding of their language. While the issue of synonyms is related to the issue of macro language registry info vs extlang, they aren't the same. Mark On 10/4/07, Andrew Cunningham wrote: > > Throwing in my two cents worth: > > One aspect of language tagging is the preference for the tags to be as > specific as possible. In some cases it is desirable to be less > specific. > > An example i mentioned on the teleconference was the case of Dinka. In > ISO-639-2 this is represented by the language code "din". > > While ISO-639-3 have the following language codes: > > dib South Central Dinka > dik Southwestern Dinka > dip Northeastern Dinka > diw Northwestern Dinka > dks Southeastern Dinka > > If I was applying a langauge tag to a Rek grammar, then i'd use "dik", > for a collection of Ciec folktales I'd use "dib". For a collection of > Bor proverbs I'd use "dks". > > To describe the literacy materials and class room materials being > developed in Australia by the Dinka community, I'd use "din". Within > the diaspora and in Australia specifically the literacy and language > teachers, translators and interpreters are discussing a standardized > approach to written Dinka. > > The original SPLA/M education policies highlighted Rek as a standard > for written Dinka. What seems to be occurring is an amalgam based on > Rek, but including aspects and vocab from other Dinka dialects. There > will be a locally hosted conference next year to thrash out some of > the issues. > > In this context "din": would be the most appropriate way of tagging > the new educational material, while keeping the existing five > iso-639-3 language tags to more accurately describe information and > data written in one of the 20 odd specific dialects. > > from the perspective of the user community, an extlang approach would > make more sense, i.e. Rek labeled as "din-dik" makes more sense than > "dik". To the community Rek is a Dinka langauge, Dinak Rek, not a > separate language called Rek. > > In this sense extlang reflects the communities understanding of their > language. > > This is just an observation, i'm neither for or against extlang. > > Although from the perspective of web development and how CSS and web > browsers handle psuedo langauge selectors and attribute selectors, I'd > suggest that extlang approach simplifies things for those rare > individuals amongst us that use these selectors. > > Andrew > -- > Andrew Cunningham > State Library of Victoria, Australia > > andrewc@vicnet.net.au > lang.support@gmail.com > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_34500_32676940.1191547527691 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline a small correction:
>  In this sense extlang reflects the communities understanding of their language.
=> In this sense macro languages reflects the communities understanding of their language.

While the issue of synonyms is related to the issue of macro language registry info vs extlang, they aren't the same.

Mark

On 10/4/07, Andrew Cunningham <lang.support@gmail.com> wrote:
Throwing in my two cents worth:

One aspect of language tagging is the preference for the tags to be as
specific as possible. In some cases it is desirable to be less
specific.

An example i mentioned on the teleconference was the case of Dinka. In
ISO-639-2 this is represented by the language code "din".

While ISO-639-3 have the following language codes:

dib     South Central Dinka
dik     Southwestern Dinka
dip     Northeastern Dinka
diw     Northwestern Dinka
dks     Southeastern Dinka

If I was applying a langauge tag to a Rek grammar, then i'd use "dik",
for a collection of Ciec folktales I'd use "dib". For a collection of
Bor proverbs I'd use "dks".

To describe the literacy materials and class room materials being
developed in Australia by the Dinka community, I'd use "din". Within
the diaspora and in Australia specifically the literacy and language
teachers, translators and interpreters are discussing a standardized
approach to written Dinka.

The original SPLA/M education policies highlighted Rek as a standard
for written Dinka. What seems to be occurring is an amalgam based on
Rek, but including aspects and vocab from other Dinka dialects. There
will be a locally hosted conference next year to thrash out some of
the issues.

In this context "din": would be the most appropriate way of tagging
the new educational material, while keeping the existing five
iso-639-3 language tags to more accurately describe information and
data written in one of the 20 odd specific dialects.

from the perspective of the user community, an extlang approach would
make more sense, i.e. Rek labeled as "din-dik" makes more sense than
"dik". To the community Rek is a Dinka langauge, Dinak Rek, not a
separate language called Rek.

In this sense extlang reflects the communities understanding of their language.

This is just an observation, i'm neither for or against extlang.

Although from the perspective of web development and how CSS and web
browsers handle psuedo langauge selectors and attribute selectors, I'd
suggest that extlang approach simplifies things for those rare
individuals amongst us that use these selectors.

Andrew
--
Andrew Cunningham
State Library of Victoria, Australia

andrewc@vicnet.net.au
lang.support@gmail.com


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



--
Mark ------=_Part_34500_32676940.1191547527691-- --===============0931731350== 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 --===============0931731350==-- From ltru-bounces@ietf.org Thu Oct 04 21:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdcAc-0008Lv-FY; Thu, 04 Oct 2007 21:40:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdcAa-0008Jk-PR for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 21:40:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdcAa-0008Ds-Dm for ltru@ietf.org; Thu, 04 Oct 2007 21:40:00 -0400 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdcAR-0008Ap-KL for ltru@ietf.org; Thu, 04 Oct 2007 21:39:52 -0400 Received: (qmail 31812 invoked from network); 4 Oct 2007 20:39:50 -0500 Received: from pool-71-252-61-101.washdc.east.verizon.net (HELO IBM92AA25595C4) (71.252.61.101) by 72.32.229.137 with SMTP; 4 Oct 2007 20:39:50 -0500 From: "Don Osborn" To: "'Andrew Cunningham'" , "'Shawn Steele'" References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> In-Reply-To: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> Subject: RE: [Ltru] Extended language tags Date: Thu, 4 Oct 2007 21:39:44 -0400 Message-ID: <002101c806f0$9c7dffc0$d579ff40$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgG63r0wRUkk5e7R7OOF2/JgQKd+QAAUg/w Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just to confirm that what Andrew is saying applies to a number of = languages in Africa. I've brought up similar concerns in the past wrt = (macro) languages like Fula and Manding (though the latter might be = called a cluster), though I believe I addressed them to the = ietf-languages list. These are just a few examples. I haven't been following the recent discussions here as much as I should = have, but do believe that if there is a bias in the system to = specificity, when specificity is not always the ideal approach, then it = will inevitably encounter calls for flexibility later. At this point I = can't say how extlang responds to this so can only offer these general = comments on the context of some languages. This is not to say that specificity in language tags is wrong, but that = they describe one aspect of a more complex reality. Large degrees of = interintelligibility, the sense of speakers regarding the essential = unity of a language (based on their experience and the common wisdom in = the culture), and the hopes and potentials for standardized versions, = all probably mean that less specific tags will become more important as = these languages emerge more fully into digital culture and the digital = economy. The language situations are dynamic, and the medium in which we are = trying to describe and categorize languages is adding a new dimension to = the development of lesser-resourced languages and their variants. Hope this makes some sense. Don Osborn Bisharat.net PanAfriL10n.org > -----Original Message----- > From: Andrew Cunningham [mailto:lang.support@gmail.com] > Sent: Thursday, October 04, 2007 9:02 PM > To: Shawn Steele > Cc: ltru@ietf.org > Subject: Re: [Ltru] Extended language tags >=20 > Throwing in my two cents worth: >=20 > One aspect of language tagging is the preference for the tags to be as > specific as possible. In some cases it is desirable to be less > specific. >=20 > An example i mentioned on the teleconference was the case of Dinka. In > ISO-639-2 this is represented by the language code "din". >=20 > While ISO-639-3 have the following language codes: >=20 > dib South Central Dinka > dik Southwestern Dinka > dip Northeastern Dinka > diw Northwestern Dinka > dks Southeastern Dinka >=20 > If I was applying a langauge tag to a Rek grammar, then i'd use "dik", > for a collection of Ciec folktales I'd use "dib". For a collection of > Bor proverbs I'd use "dks". >=20 > To describe the literacy materials and class room materials being > developed in Australia by the Dinka community, I'd use "din". Within > the diaspora and in Australia specifically the literacy and language > teachers, translators and interpreters are discussing a standardized > approach to written Dinka. >=20 > The original SPLA/M education policies highlighted Rek as a standard > for written Dinka. What seems to be occurring is an amalgam based on > Rek, but including aspects and vocab from other Dinka dialects. There > will be a locally hosted conference next year to thrash out some of > the issues. >=20 > In this context "din": would be the most appropriate way of tagging > the new educational material, while keeping the existing five > iso-639-3 language tags to more accurately describe information and > data written in one of the 20 odd specific dialects. >=20 > from the perspective of the user community, an extlang approach would > make more sense, i.e. Rek labeled as "din-dik" makes more sense than > "dik". To the community Rek is a Dinka langauge, Dinak Rek, not a > separate language called Rek. >=20 > In this sense extlang reflects the communities understanding of their > language. >=20 > This is just an observation, i'm neither for or against extlang. >=20 > Although from the perspective of web development and how CSS and web > browsers handle psuedo langauge selectors and attribute selectors, I'd > suggest that extlang approach simplifies things for those rare > individuals amongst us that use these selectors. >=20 > Andrew > -- > Andrew Cunningham > State Library of Victoria, Australia >=20 > andrewc@vicnet.net.au > lang.support@gmail.com >=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 04 21:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdcDu-0005SK-PV; Thu, 04 Oct 2007 21:43:26 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdcDt-0005QR-6l for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 21:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdcDs-0005QJ-TK for ltru@ietf.org; Thu, 04 Oct 2007 21:43:24 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdcDm-0001at-OF for ltru@ietf.org; Thu, 04 Oct 2007 21:43:24 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WLjtNPK6bYZn3/bJNK66CWuYktfBsYopehI2mjyRZXpSJEYkkQDFxp74UFiaAhTF; 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 [64.105.35.208] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IdcDa-0002oQ-3G for ltru@ietf.org; Thu, 04 Oct 2007 21:43:06 -0400 Message-ID: <000001c806f1$a041a200$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> Subject: Re: [Ltru] Extended language tags Date: Thu, 4 Oct 2007 18:44:52 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a423df0d7ed8cbfbd99d1784ccdb2c7e1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.208 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Andrew Cunningham" > To: "Shawn Steele" > Cc: > Sent: Thursday, October 04, 2007 6:01 PM > Subject: Re: [Ltru] Extended language tags ... > In this context "din": would be the most appropriate way of tagging > the new educational material, while keeping the existing five > iso-639-3 language tags to more accurately describe information and > data written in one of the 20 odd specific dialects. ... While agreeing with the thrust of this argument, something like "din-common" would make more sense to me in this example as a preferred way of tagging this educational material. I do not think it is desirable for a subtag to formally convey both the sense "some unspecified variety or varieties of this language family" and "the most common or standardardized variety". This would allow such material to be identified as a distinct variety, while recognizing the commonality that makes such standardization possible. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 22:24:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idcr8-0001i1-Ai; Thu, 04 Oct 2007 22:23:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idcr7-0001hq-7w for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 22:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idcr6-0001hi-Uk for ltru@ietf.org; Thu, 04 Oct 2007 22:23:56 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idcr1-0002dk-Oj for ltru@ietf.org; Thu, 04 Oct 2007 22:23:56 -0400 Received: by an-out-0708.google.com with SMTP id c17so75079anc for ; Thu, 04 Oct 2007 19:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3+2jU9nt1AuTUnF5OlaSxRSRTfwfZvSMx2F4RQTNG14=; b=KQ8NntLcgXJV0vL0STaWWFF4iUXMGEHyb5QFSlYzCSQV+Itrurv8eP+97FwH6gXIw0Phf765Xs1HTD2JdhA5Oxiuee6lMQOhbEkYtWnWeIiOyUh4ZjwqwI8xyqyKBp3PztnaRmGIZwa0iK6k0INdewF23FwsFMogi7cyJNc+SQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IIfWEk8m67OMYuxAPqaOPiN1BW8cGJFsJrvbMIUzjMXolfoEbhIUY3LWzctbq0RfbwQGJ6r2yt5Lb51eOd4PNG6FgtFU8SGKGyZo7blyTSGEZXuMZ+yBTj1NnZySMkMOkMnvPWVAbbgw6jrpHrBUzq3F1fwCFcINnNNRhNze6EA= Received: by 10.142.84.3 with SMTP id h3mr3124033wfb.1191551011385; Thu, 04 Oct 2007 19:23:31 -0700 (PDT) Received: by 10.142.87.14 with HTTP; Thu, 4 Oct 2007 19:23:31 -0700 (PDT) Message-ID: <9d70cb000710041923x5d369470hb9e5041df285f6e7@mail.gmail.com> Date: Fri, 5 Oct 2007 12:23:31 +1000 From: "Andrew Cunningham" To: "Mark Davis" Subject: Re: [Ltru] Extended language tags In-Reply-To: <30b660a20710041825l61956284l7380ed727bac9de2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <30b660a20710041825l61956284l7380ed727bac9de2@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "ltru@ietf.org" , Shawn Steele X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Mark for the correction, my use of terminology can be sloppy at times ;) On 05/10/2007, Mark Davis wrote: > a small correction: > > In this sense extlang reflects the communities understanding of their > language. > => In this sense macro languages reflects the communities understanding of > their language. > > While the issue of synonyms is related to the issue of macro language > registry info vs extlang, they aren't the same. > > Mark > > > On 10/4/07, Andrew Cunningham wrote: > > > > Throwing in my two cents worth: > > > > One aspect of language tagging is the preference for the tags to be as > > specific as possible. In some cases it is desirable to be less > > specific. > > > > An example i mentioned on the teleconference was the case of Dinka. In > > ISO-639-2 this is represented by the language code "din". > > > > While ISO-639-3 have the following language codes: > > > > dib South Central Dinka > > dik Southwestern Dinka > > dip Northeastern Dinka > > diw Northwestern Dinka > > dks Southeastern Dinka > > > > If I was applying a langauge tag to a Rek grammar, then i'd use "dik", > > for a collection of Ciec folktales I'd use "dib". For a collection of > > Bor proverbs I'd use "dks". > > > > To describe the literacy materials and class room materials being > > developed in Australia by the Dinka community, I'd use "din". Within > > the diaspora and in Australia specifically the literacy and language > > teachers, translators and interpreters are discussing a standardized > > approach to written Dinka. > > > > The original SPLA/M education policies highlighted Rek as a standard > > for written Dinka. What seems to be occurring is an amalgam based on > > Rek, but including aspects and vocab from other Dinka dialects. There > > will be a locally hosted conference next year to thrash out some of > > the issues. > > > > In this context "din": would be the most appropriate way of tagging > > the new educational material, while keeping the existing five > > iso-639-3 language tags to more accurately describe information and > > data written in one of the 20 odd specific dialects. > > > > from the perspective of the user community, an extlang approach would > > make more sense, i.e. Rek labeled as "din-dik" makes more sense than > > "dik". To the community Rek is a Dinka langauge, Dinak Rek, not a > > separate language called Rek. > > > > In this sense extlang reflects the communities understanding of their > language. > > > > This is just an observation, i'm neither for or against extlang. > > > > Although from the perspective of web development and how CSS and web > > browsers handle psuedo langauge selectors and attribute selectors, I'd > > suggest that extlang approach simplifies things for those rare > > individuals amongst us that use these selectors. > > > > Andrew > > -- > > Andrew Cunningham > > State Library of Victoria, Australia > > > > andrewc@vicnet.net.au > > lang.support@gmail.com > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > Mark -- Andrew Cunningham Language IT support Dinka Language Institute Australia http://home.vicnet.net.au/~andrewc/ http://home.vicnet.net.au/~agamlong/dlia/ http://www.openroad.net.au/languages/african/dinka/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 22:37:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idd4E-0003Lj-Lb; Thu, 04 Oct 2007 22:37:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idd4D-0003Lc-D3 for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 22:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idd4C-0003LP-R1 for ltru@ietf.org; Thu, 04 Oct 2007 22:37:28 -0400 Received: from hs-out-0708.google.com ([64.233.178.245] helo=hs-out-2021.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idd46-0002xO-OG for ltru@ietf.org; Thu, 04 Oct 2007 22:37:28 -0400 Received: by hs-out-2021.google.com with SMTP id 54so12730hsz for ; Thu, 04 Oct 2007 19:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ArbQsAqIyIXAyBueHl3SR1R+FlGAUxpusRFXgoxvP7c=; b=KXiufiy8sndRZUbKtJ2N80MERQO0biM24ryzwtd/Dh4wum2oUW2XWKhMrWOlAJb73UV8WI2l41fxL6hg0Z71D/sq3a7QygLXRRdfntI0JdbRrZ3DxBx2paQ9kfYqL33WN1soaPyGrEMDk3U+vH36SQjDNObhN28to2K+pV+o808= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LdmH8h3J1fa2poo46FO6jIlT8XEHDDpxYRWrf4olYPUfvsow6HzJ8/35kWK/ILmhJp1K9ggIehwlwkOH+Qcw+9b6AwHdZHNZnLPZmbopAnbykdoq/u01oxZ7h8g/tIqzuwnunXEIN9hlM/hG8iMGV3BoSkVYtdbb385FZA1DjEw= Received: by 10.142.163.14 with SMTP id l14mr1316543wfe.1191551805755; Thu, 04 Oct 2007 19:36:45 -0700 (PDT) Received: by 10.142.87.14 with HTTP; Thu, 4 Oct 2007 19:36:45 -0700 (PDT) Message-ID: <9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com> Date: Fri, 5 Oct 2007 12:36:45 +1000 From: "Andrew Cunningham" Subject: Re: [Ltru] Extended language tags Cc: ltru@ietf.org In-Reply-To: <000001c806f1$a041a200$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <000001c806f1$a041a200$6801a8c0@oemcomputer> X-Spam-Score: 1.6 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, On 05/10/2007, Randy Presuhn wrote: > I do not think it is desirable for a subtag > to formally convey both the sense "some unspecified variety or varieties of > this language family" and "the most common or standardardized variety". > True, and if a standardised Dinka is formalised then an approprian unspecified variety of Dinka not covered by the current ISO-639-3 codes". I'm not suggesting "din" be used for a standardised or common Dinka. Just at the moment things are heading in the development of a standardised Dinka (if that ever actually happens). At which time a more appropriate subtag may be put forward. if that makes sense. -- Andrew Cunningham _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 22:41:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idd7e-0002yh-OH; Thu, 04 Oct 2007 22:41:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idd7d-0002yc-SD for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 22:41:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idd7d-0002tZ-HR for ltru@ietf.org; Thu, 04 Oct 2007 22:41:01 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Idd7P-0001EH-7s for ltru@ietf.org; Thu, 04 Oct 2007 22:40:47 -0400 Received: by an-out-0708.google.com with SMTP id c17so75927anc for ; Thu, 04 Oct 2007 19:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Sh3rAFluwO/syltCjrof4hPBS/gxpPT1hLXI9kGrTH0=; b=t9r0pLmVpj0qkwmDvxNIH54jvVYEojywZVVBkbMg5AwCLD2iD8kHt/vHrhQPqKAsfapoRm9zoZCvQTUyU4iN6Mpfvodze9kiXUgqB5zCWu5Bjf+qn65w1URh2hHvun1fKVLX5T/Pf01biNcr7tFIHxFR0gVfJ50WloYmij9fr7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SovcBbPeyfYDdb+6RfafuF7PveIBpoQcRAE8jVTDpRPArg9vn3XkHqangn8vRyEN0EksHzWYfLXfJo5jfKJBAQqvjJ8Ctzc1EFhtgE608Lp2XeQxkneytcOMoaY+SRiu4GLYirhOBm9n5RaoOG0muechJgPVMJAcVmvxYbMK16Q= Received: by 10.142.237.20 with SMTP id k20mr1319022wfh.1191552045830; Thu, 04 Oct 2007 19:40:45 -0700 (PDT) Received: by 10.142.87.14 with HTTP; Thu, 4 Oct 2007 19:40:45 -0700 (PDT) Message-ID: <9d70cb000710041940w6df2268auc851423adba66511@mail.gmail.com> Date: Fri, 5 Oct 2007 12:40:45 +1000 From: "Andrew Cunningham" To: ltru@ietf.org Subject: Re: [Ltru] Extended language tags In-Reply-To: <9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <000001c806f1$a041a200$6801a8c0@oemcomputer> <9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org That should have read (and for some reason didn't): True, and if a standardised Dinka is formalised then an appropriate subtag should/may be registered. But at the moment, the way I'm using "din" is as an unspecified variety of Dinka not covered by the current ISO-639-3 codes". I'm not suggesting "din" be used for a standardised or common Dinka. Just saying that at the moment things are heading in the direction of the development of a standardised Dinka (if that ever actually happens). At which time a more appropriate subtag may be put forward. If that makes sense? -- Andrew Cunningham Language IT support Dinka Language Institute Australia http://home.vicnet.net.au/~andrewc/ http://home.vicnet.net.au/~agamlong/dlia/ http://www.openroad.net.au/languages/african/dinka/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 22:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddFD-0008MX-4M; Thu, 04 Oct 2007 22:48:51 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IddFC-0008MK-MQ for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 22:48:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddFC-0008J4-D0 for ltru@ietf.org; Thu, 04 Oct 2007 22:48:50 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IddF2-0003FN-5v for ltru@ietf.org; Thu, 04 Oct 2007 22:48:46 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nculOebU9YOC8X1eSaQIhHhd4otxjxyC7r1GKLQRzc0hvNN1HPw/ztRDeIjS141c; 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 [66.167.206.20] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IddEI-0008LB-V6 for ltru@ietf.org; Thu, 04 Oct 2007 22:47:55 -0400 Message-ID: <000601c806fa$ae9bdce0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com><000001c806f1$a041a200$6801a8c0@oemcomputer><9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com> <9d70cb000710041940w6df2268auc851423adba66511@mail.gmail.com> Subject: Re: [Ltru] Extended language tags Date: Thu, 4 Oct 2007 19:51: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a11cb7d2abbec867837cff6bf2bc3fef6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.20 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Andrew Cunningham" > To: > Sent: Thursday, October 04, 2007 7:40 PM > Subject: Re: [Ltru] Extended language tags > > That should have read (and for some reason didn't): > > True, and if a standardised Dinka is formalised then an > appropriate subtag should/may be registered. > > But at the moment, the way I'm using "din" is as an > unspecified variety of Dinka not covered by the current > ISO-639-3 codes". > > I'm not suggesting "din" be used for a standardised or > common Dinka. > > Just saying that at the moment things are heading in > the direction of the development of a standardised > Dinka (if that ever actually happens). At which time > a more appropriate subtag may be put forward. > > If that makes sense? ... We're in violent agreement. :-) Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 23:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddlR-0001X5-DX; Thu, 04 Oct 2007 23:22:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IddlN-0001Eo-F6 for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 23:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddlM-00018O-Fc for ltru@ietf.org; Thu, 04 Oct 2007 23:22:04 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IddlG-0004K0-7i for ltru@ietf.org; Thu, 04 Oct 2007 23:22:04 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Iddl9-0003Zq-8H; Thu, 04 Oct 2007 23:21:51 -0400 Date: Thu, 4 Oct 2007 23:21:51 -0400 To: Shawn Steele Subject: Re: [Ltru] Extended language tags Message-ID: <20071005032151.GG27520@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Shawn Steele scripsit: > * I don't think the Breton example applies. http-accept-lang allows for > "br-FR;fr-FR" type fallback, so that is a solution. If an application > independently wanted to make this assumption that's fine by me, but > this seems orthogonal to the problem we're trying to solve here. That works for filtering (which is what Accept-Lang does), but not so well in practice for lookup. Normally people don't specify multiple match patterns in lookup situations, they just say "I speak Breton, what's the best match you have?" -- You're a brave man! Go and break through the John Cowan lines, and remember while you're out there cowan@ccil.org risking life and limb through shot and shell, http://ccil.org/~cowan we'll be in here thinking what a sucker you are! --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 04 23:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddrC-0003tS-Iu; Thu, 04 Oct 2007 23:28:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IddrB-0003r8-Kn for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 23:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IddrB-0003qy-B8 for ltru@ietf.org; Thu, 04 Oct 2007 23:28:05 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iddr5-0004cb-3K for ltru@ietf.org; Thu, 04 Oct 2007 23:28:05 -0400 Received: from [10.72.73.32] (snvvpn1-10-72-73-c32.corp.yahoo.com [10.72.73.32]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l953RVPo016748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2007 20:27: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=Z1vlY+XsEohf3BcvZl7kMuUc6TYlXGZOjYICqNLUwUBPAczfAIHx+2Foi7b0ho+T Message-ID: <4705AF23.7070109@yahoo-inc.com> Date: Thu, 04 Oct 2007 20:27:31 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Extended language tags References: <20071005032151.GG27520@mercury.ccil.org> In-Reply-To: <20071005032151.GG27520@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "ltru@ietf.org" , Shawn Steele X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 don't think the Breton example applies. http-accept-lang allows for >> "br-FR;fr-FR" type fallback, so that is a solution. If an application >> independently wanted to make this assumption that's fine by me, but >> this seems orthogonal to the problem we're trying to solve here. > > That works for filtering (which is what Accept-Lang does), but not so > well in practice for lookup. Normally people don't specify multiple match patterns > in lookup situations, they just say "I speak Breton, what's the best > match you have?" > Although actual implementations of lookup, as specified, do allow for it. My implementations handle this situation well and it turns out to be pretty useful to use a language priority list for lookup. Traditional locale systems, however, work as John notes. I am hopeful that they will adapt. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 04 23:43:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ide5U-0005xk-Q2; Thu, 04 Oct 2007 23:42:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ide5T-0005uE-Ma for ltru-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 23:42:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ide5T-0005qt-Bx for ltru@ietf.org; Thu, 04 Oct 2007 23:42:51 -0400 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ide5O-0003JS-QF for ltru@ietf.org; Thu, 04 Oct 2007 23:42:47 -0400 Received: (qmail 598 invoked from network); 4 Oct 2007 22:42:34 -0500 Received: from pool-71-252-61-101.washdc.east.verizon.net (HELO IBM92AA25595C4) (71.252.61.101) by 72.32.229.137 with SMTP; 4 Oct 2007 22:42:34 -0500 From: "Don Osborn" To: "'Andrew Cunningham'" , References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <000001c806f1$a041a200$6801a8c0@oemcomputer> <9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com> <9d70cb000710041940w6df2268auc851423adba66511@mail.gmail.com> In-Reply-To: <9d70cb000710041940w6df2268auc851423adba66511@mail.gmail.com> Subject: RE: [Ltru] Extended language tags Date: Thu, 4 Oct 2007 23:42:30 -0400 Message-ID: <003901c80701$c202bc20$46083460$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgG+S/hYWXxb8r+TlK3F4nftuussAABPb3Q Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > -----Original Message----- > From: Andrew Cunningham [mailto:lang.support@gmail.com] ... > But at the moment, the way I'm using "din" is as an > unspecified variety of Dinka not covered by the current > ISO-639-3 codes". ... Which seems to be saying that in this case there is need for an = appropriate level of imprecision in the tagging, and that this is met by = the macrolanguage code alone (which is in 639-3 also, as I read it). I'm = thinking that this is not so much the exception, but a situation that = can arise with many other (macro)languages where there is no formal = standard. I can see the point of having a tag to describe a standardized form, if = such a formal standardization is arrived at (though I'm not sure where = discussions are re ar and Standard Arabic). But what if usages just keep = crossing or blurring the lines among "languages" within the = "macrolanguage"? This is not just limited to Dinka - there were a few = publications in Fulfulde a while back (one title was Janng'en Fulfulde = as I recall) that deliberately tried to address a range of speakers (to = the point of having footnotes to clarify usage in specific dialects = where these were markedly different). Nowadays, anyone could try that on = a website, blog or Wikipedia. In such a case wouldn't the ISO 639-1/2 = code (ff/ful) be appropriate? Maybe there's no argument here, but I wanted to underscore this = perspective before letting it be. Don _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 00:00:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdeMi-0005m4-GY; Fri, 05 Oct 2007 00:00:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdeMh-0005l5-TH for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 00:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdeMh-0005jZ-Ir for ltru@ietf.org; Fri, 05 Oct 2007 00:00:39 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdeMg-0005h0-0v for ltru@ietf.org; Fri, 05 Oct 2007 00:00:39 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IdeMe-0006WZ-DT; Fri, 05 Oct 2007 00:00:36 -0400 Date: Fri, 5 Oct 2007 00:00:36 -0400 To: Don Osborn Subject: Re: [Ltru] Extended language tags Message-ID: <20071005040036.GI27520@mercury.ccil.org> References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <000001c806f1$a041a200$6801a8c0@oemcomputer> <9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com> <9d70cb000710041940w6df2268auc851423adba66511@mail.gmail.com> <003901c80701$c202bc20$46083460$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003901c80701$c202bc20$46083460$@net> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Don Osborn scripsit: > I can see the point of having a tag to describe a standardized form, > if such a formal standardization is arrived at (though I'm not sure > where discussions are re ar and Standard Arabic). Arabic's like Chinese: there's a prestige variety, which has its own 639-3 code, and then there are the other varieties, which have 639-3 codes too. Each set is encompassed by a macrolanguage that is in both 639-2 and 639-3. Most textual documents are in the prestige variety (as an uncontroversial consequence of the prestige variety being the only one normally used for writing at all), and are tagged with the macrolanguage code (as an uncontroversial consequence of it being either the only code available or the only code that most people know about). Audio/video content may well be another story, but most of it is neither manually tagged nor (as yet) automatically taggable. Macrolanguages like Quechua or Zapotec are another story: there is no prestige variety particularly. The African cases sound like they are moving from the latter group toward the former, with the appearance of prestige varieties at least in the cities or the diaspora. -- Possession is said to be nine points of the law, John Cowan but that's not saying how many points the law might have. cowan@ccil.org --Thomas A. Cowan (law professor and my father) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 00:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idebc-0000n8-PE; Fri, 05 Oct 2007 00:16:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idebb-0000f9-HU for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 00:16:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idebb-0000Lk-5Z for ltru@ietf.org; Fri, 05 Oct 2007 00:16:03 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdebW-0004Lb-Hy for ltru@ietf.org; Fri, 05 Oct 2007 00:15:58 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Od3cSFVo5NV5V1y44oVMqQl2AEOcc6Hnv1nv0kszOsfLu8Z6pPD4h1il5TFlnE+H; 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 [64.105.34.248] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IdebV-0002Gv-K5 for ltru@ietf.org; Fri, 05 Oct 2007 00:15:57 -0400 Message-ID: <000a01c80706$faa3dbe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <000001c806f1$a041a200$6801a8c0@oemcomputer> <9d70cb000710041936l7ec4e361w770e9ae873cec4d2@mail.gmail.com><9d70cb000710041940w6df2268auc851423adba66511@mail.gmail.com> <003901c80701$c202bc20$46083460$@net> Subject: Re: [Ltru] Extended language tags Date: Thu, 4 Oct 2007 21:19: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a84537d0fcb6dda27850348cba474feb8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.248 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Don Osborn" > To: "'Andrew Cunningham'" ; > Sent: Thursday, October 04, 2007 8:42 PM > Subject: RE: [Ltru] Extended language tags ... > Which seems to be saying that in this case there is need for an appropriate level of > imprecision in the tagging, and that this is met by the macrolanguage code alone > (which is in 639-3 also, as I read it). I'm thinking that this is not so much the > exception, but a situation that can arise with many other (macro)languages where > there is no formal standard. ... I think we're mostly agreed on the need to be able to do this. The question that we need to resolve is which of three choices to make: (1) include the macrolanguage information in the registry and reflect it in the encoding of the language tag for the newly-added languages which are encompassed by a macrolanguage (2) do not include the macrolanguage information in the encoding of the language tag, but do include it in the registry so intelligent matching algorithms can act as though the information had been supplied (3) do not include the macrolanguage information in the tag encoding, and do not include it in the registry. There are other possibilities, but these seem to be the most defensible. Which of these makes the most sense seems to depend on the use case one has in mind. Overstating merely to drive home the point: The discussion of Dinka seems to favor (1). Discussion of Norwegian leads one to favor (2). Discussion of Breton leads one to (3). As co-chair... At this moment, the discussion seems to favor (1), but it's clear that we need to work through what we'd want do to the matching specification before we could declare consensus on this. If we find that an update to the matching specification is necessary, we'll need to ask our AD to get the IESG to add it to our charter. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 00:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ider6-0006dC-EL; Fri, 05 Oct 2007 00:32:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ider4-0006ct-8e for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 00:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ider3-0006cd-Tw for ltru@ietf.org; Fri, 05 Oct 2007 00:32:01 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ideqw-0006Xz-54 for ltru@ietf.org; Fri, 05 Oct 2007 00:32:01 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l954VlkY002209 for ; Fri, 5 Oct 2007 13:31:47 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7853_e25a0e86_72fb_11dc_92e6_0014221fa3c9; Fri, 05 Oct 2007 13:31:47 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40610) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 5 Oct 2007 13:28:25 +0900 Message-Id: <6.0.0.20.2.20071005100832.03ac5220@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 05 Oct 2007 10:10:11 +0900 To: "McDonald, Ira" , "John Cowan" , "Randy Presuhn" From: Martin Duerst Subject: RE: [Ltru] Clarifying Suppress-Script In-Reply-To: References: <20071004003443.GA27520@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) 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 At 00:59 07/10/05, McDonald, Ira wrote: >Hi, > >I object to this whole paragraph. Because RFC 4646 >*inserted* scripts between the two previously main >subtags (language and region), Suppress-Script is >necessary for MANY languages tagged in the future. >It has nothing to do with an existing body of tagged >material. I tend to agree. For me, "tag wisely" means "don't tag more than necessary", which implies "don't add script information if it's just plain obvious what script is being used, in the general case". Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 00:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdezN-00031s-AY; Fri, 05 Oct 2007 00:40:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdezM-00031I-7R for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 00:40:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdezL-00031A-TY for ltru@ietf.org; Fri, 05 Oct 2007 00:40:35 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdezL-0004uh-L6 for ltru@ietf.org; Fri, 05 Oct 2007 00:40:35 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IdezF-0001QN-KC; Fri, 05 Oct 2007 00:40:29 -0400 Date: Fri, 5 Oct 2007 00:40:29 -0400 To: Martin Duerst Subject: Re: [Ltru] Clarifying Suppress-Script Message-ID: <20071005044029.GJ27520@mercury.ccil.org> References: <20071004003443.GA27520@mercury.ccil.org> <6.0.0.20.2.20071005100832.03ac5220@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20071005100832.03ac5220@localhost> User-Agent: Mutt/1.5.13 (2006-08-11) 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 Martin Duerst scripsit: > I tend to agree. For me, "tag wisely" means > "don't tag more than necessary", which implies > "don't add script information if it's just plain > obvious what script is being used, in the general case". "Tag wisely" also means "don't tag less than necessary". -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow cowan@ccil.org Was para-dichloro- Diphenyltrichloroethane. (aka DDT) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 01:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfeY-0003F0-DM; Fri, 05 Oct 2007 01:23:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idfau-0007ra-5y for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 01:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idfat-0007r8-IR for ltru@ietf.org; Fri, 05 Oct 2007 01:19:23 -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 1Idfas-00081T-A2 for ltru@ietf.org; Fri, 05 Oct 2007 01:19:23 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 4 Oct 2007 22:19:21 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu, 4 Oct 2007 22:19:21 -0700 From: Shawn Steele To: Don Osborn , 'Andrew Cunningham' Date: Thu, 4 Oct 2007 22:14:32 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG63r0wRUkk5e7R7OOF2/JgQKd+QAAUg/wAAh2f4g= Message-ID: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com>, <002101c806f0$9c7dffc0$d579ff40$@net> In-Reply-To: <002101c806f0$9c7dffc0$d579ff40$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Fri, 05 Oct 2007 01:23:09 -0400 Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > but do believe that if there is a bias in the system to specificity, when= specificity is not always the ideal > approach, then it will inevitably encounter calls for flexibility later. My opinion is that I don't mind the extra detail. An application could cho= ose to ignore that detail if it wasn't warranted in their case, or use it i= f necessary, but if they don't have the detail available, then they don't h= ave the option. (And IMO having the detail as a field in the registry does= n't count as being readily available) In truth I don't mind much if we use extlang or not. To me it makes a litt= le more sense to have it and I don't see any disadvantages to its presence. What I would like to see is this question being resolved :) At some point = I have to turn any decision/RFC into code for our various products, and I'd= like as much time as possible. - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 01:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfeI-0002sL-3K; Fri, 05 Oct 2007 01:22:54 -0400 Received: fFrom ltru-bounces@ietf.org Fri Oct 05 01:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfeY-0003F0-DM; Fri, 05 Oct 2007 01:23:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Idfau-0007ra-5y for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 01:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idfat-0007r8-IR for ltru@ietf.org; Fri, 05 Oct 2007 01:19:23 -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 1Idfas-00081T-A2 for ltru@ietf.org; Fri, 05 Oct 2007 01:19:23 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 4 Oct 2007 22:19:21 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu, 4 Oct 2007 22:19:21 -0700 From: Shawn Steele To: Don Osborn , 'Andrew Cunningham' Date: Thu, 4 Oct 2007 22:14:32 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG63r0wRUkk5e7R7OOF2/JgQKd+QAAUg/wAAh2f4g= Message-ID: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com>, <002101c806f0$9c7dffc0$d579ff40$@net> In-Reply-To: <002101c806f0$9c7dffc0$d579ff40$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Fri, 05 Oct 2007 01:23:09 -0400 Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > but do believe that if there is a bias in the system to specificity, when= specificity is not always the ideal > approach, then it will inevitably encounter calls for flexibility later. My opinion is that I don't mind the extra detail. An application could cho= ose to ignore that detail if it wasn't warranted in their case, or use it i= f necessary, but if they don't have the detail available, then they don't h= ave the option. (And IMO having the detail as a field in the registry does= n't count as being readily available) In truth I don't mind much if we use extlang or not. To me it makes a litt= le more sense to have it and I don't see any disadvantages to its presence. What I would like to see is this question being resolved :) At some point = I have to turn any decision/RFC into code for our various products, and I'd= like as much time as possible. - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 01:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfeI-0002sL-3K; Fri, 05 Oct 2007 01:22:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdfUk-0005og-0O for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 01:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfUj-0005oY-Ki for ltru@ietf.org; Fri, 05 Oct 2007 01:13:01 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdfUd-0007q8-EC for ltru@ietf.org; Fri, 05 Oct 2007 01:13:01 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 4 Oct 2007 22:12:24 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Thu, 4 Oct 2007 22:12:24 -0700 From: Shawn Steele To: John Cowan Date: Thu, 4 Oct 2007 22:09:20 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG/uBqNGnCDMvGRzOXAAmnZKPSLgADwLF6 Message-ID: References: , <20071005032151.GG27520@mercury.ccil.org> In-Reply-To: <20071005032151.GG27520@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Fri, 05 Oct 2007 01:22:53 -0400 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 don't think the Breton example applies. http-accept-lang allows for >> "br-FR;fr-FR" type fallback, so that is a solution. If an application >> independently wanted to make this assumption that's fine by me, but >> this seems orthogonal to the problem we're trying to solve here. >That works for filtering (which is what Accept-Lang does), but not so >well in practice for lookup. Normally people don't specify multiple match= patterns >in lookup situations, they just say "I speak Breton, what's the best >match you have?" IMO if the user only provides Breton, then any further lookup is the applic= ation's best guess. To wildly mangle the analogy, if someone asked for en-= US, an application could say "gee, a bunch of en-US speakers also know span= ish, so I'll return es-US if I can't find en-US". Such decisions might be = appropriate for some applications and not for others. I just don't think fallback from Breton to French is appropriate at the reg= istry/RFC level. I think its more appropriately decided by the application= s that might want that fallback. - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru rom ltru by megatron.ietf.org with local (Exim 4.43) id 1IdfUk-0005og-0O for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 01:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdfUj-0005oY-Ki for ltru@ietf.org; Fri, 05 Oct 2007 01:13:01 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdfUd-0007q8-EC for ltru@ietf.org; Fri, 05 Oct 2007 01:13:01 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 4 Oct 2007 22:12:24 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Thu, 4 Oct 2007 22:12:24 -0700 From: Shawn Steele To: John Cowan Date: Thu, 4 Oct 2007 22:09:20 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG/uBqNGnCDMvGRzOXAAmnZKPSLgADwLF6 Message-ID: References: , <20071005032151.GG27520@mercury.ccil.org> In-Reply-To: <20071005032151.GG27520@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Fri, 05 Oct 2007 01:22:53 -0400 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 don't think the Breton example applies. http-accept-lang allows for >> "br-FR;fr-FR" type fallback, so that is a solution. If an application >> independently wanted to make this assumption that's fine by me, but >> this seems orthogonal to the problem we're trying to solve here. >That works for filtering (which is what Accept-Lang does), but not so >well in practice for lookup. Normally people don't specify multiple match= patterns >in lookup situations, they just say "I speak Breton, what's the best >match you have?" IMO if the user only provides Breton, then any further lookup is the applic= ation's best guess. To wildly mangle the analogy, if someone asked for en-= US, an application could say "gee, a bunch of en-US speakers also know span= ish, so I'll return es-US if I can't find en-US". Such decisions might be = appropriate for some applications and not for others. I just don't think fallback from Breton to French is appropriate at the reg= istry/RFC level. I think its more appropriately decided by the application= s that might want that fallback. - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 05 09:09:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdmvW-0000qS-4Q; Fri, 05 Oct 2007 09:09:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IdmvV-0000no-Pk for ltru-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 09:09:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdmvV-0000mz-Es for ltru@ietf.org; Fri, 05 Oct 2007 09:09:09 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdmvU-0004CC-Q8 for ltru@ietf.org; Fri, 05 Oct 2007 09:09:09 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IdmvS-0008MJ-Vu; Fri, 05 Oct 2007 09:09:07 -0400 Date: Fri, 5 Oct 2007 09:09:06 -0400 To: Randy Presuhn Subject: Re: [Ltru] Extended language tags Message-ID: <20071005130906.GA27369@mercury.ccil.org> References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <000001c806f1$a041a200$6801a8c0@oemcomputer> <003901c80701$c202bc20$46083460$@net> <000a01c80706$faa3dbe0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01c80706$faa3dbe0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > (1) [registry and extlang tag] > (2) [registry only] > (3) [neither] AFAIK no one is advocating for case 3; the split is between cases 1 and 2. > At this moment, the discussion seems to favor (1), but it's clear that > we need to work through what we'd want do to the matching specification > before we could declare consensus on this. If we find that an update > to the matching specification is necessary, we'll need to ask our AD > to get the IESG to add it to our charter. Based on Mark's and Addison's evidence (as discussed in the telcons), I propose that a new subsection be added to Section 3 of 4647, explaining how to do matching in the presence of extlang tags (case 1) or Macrolanguage headers (case 2). The trouble with directly using the 4647 algorithms is that they will fall back poorly in case 1, because all other types of subtags will have been disregarded before the conversion from zh-yue to zh is made. In case 2, of course, the algorithms will not fall back at all, unless by a private extension. Therefore, matchers SHOULD, given a range with a 'yue' language subtag (case 1), or 'zh-yue' language and extlang subtags (case 2), add to the range list the corresponding range with the macrolanguage 'zh'. Likewise, a matcher given a range with a language subtag of 'nn' SHOULD add to the range list the corresponding range with the macrolanguage 'no', provided the LSR is available. All this is orthogonal to the question of representation. I favor 1 over 2 simply because nothing in 4647 MUSTard requires the availability of the registry, and I'd like to see it stay that way. (Currently, matchers are "encouraged", a non-MUSTard term, to use the registry for canonicalization, and people who create language ranges (as opposed to matchers) SHOULD NOT include suppressed scripts.) -- The experiences of the past show John Cowan that there has always been a discrepancy cowan@ccil.org between plans and performance. http://www.ccil.org/~cowan --Emperor Hirohito, August 1945 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 07 02:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IePxp-0006OU-Uf; Sun, 07 Oct 2007 02:50:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IePxo-0006OP-T1 for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 02:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IePxk-0006JK-GG for ltru@ietf.org; Sun, 07 Oct 2007 02:50:04 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IePxe-0001zb-AD for ltru@ietf.org; Sun, 07 Oct 2007 02:50:04 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sat, 6 Oct 2007 23:49:27 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Sat, 6 Oct 2007 23:49:27 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Sat, 6 Oct 2007 23:49:27 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG650WUXKq4oH3SwSFINwonCmBrABwa93w Message-ID: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> In-Reply-To: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1136085055==" Errors-To: ltru-bounces@ietf.org --===============1136085055== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIERpbmthIGxhbmd1YWdlIGRldmVsb3BtZW50IGFjdGl2aXRpZXMgc291bmQgbGlrZSB0aGVy ZSBhcmUgc2ltaWxhcml0aWVzIHRvIHdoYXQgaGFzIGJlZW4gZ29pbmcgb24gaW4gdGhlIFBoaWxp cHBpbmVzLCB3aGVyZSBpdCB3YXMgZGVjaWRlZCB0byBlbmdpbmVlciBhIHBhbi1QaGlsaXBwaW5l IGxhbmd1YWdlICJGaWxpcGlubyIgYXMgYW4gYW1hbGdhbSB3aXRoIGdyZWF0ZXN0IGRlcGVuZGVu Y2UgaW5pdGlhbGx5IG9uIFRhZ2Fsb2cuDQoNCkluIHRoYXQgY2FzZSwgYSBuZXcgbGFuZ3VhZ2Ug bmFtZSB3YXMgY3JlYXRlZCAtLSBhbmQgYSBuZXcgSVNPIDYzOSBJRC4gT25lIGNvdWxkIGFwcGx5 IGEgc2ltaWxhciBhcHByb2FjaCBpbiB0aGUgRGlua2EgY2FzZSwgZXhjZXB0IHRoYXQgdGhlIHNv Y2lvbGluZ3Vpc3RpY3MgYXBwZWFyIHRvIGJlIGRpZmZlcmVudDogZnJvbSB5b3VyIGRlc2NyaXB0 aW9uLCBpdCBzb3VuZHMgbGlrZSB0aGUgc3BlYWtlciBjb21tdW5pdHkgaGFzIGEgY29uY2VwdGlv biBvZiBhbiBlbmNvbXBhc3NpbmcgbGluZ3Vpc3RpYyB1bml0eSwgYW5kIDYzOS0yIGhhcyBoYWQg YW4gSUQgdGhhdCBpcyBjb21wYXJhYmxlIGluIHNjb3BlLg0KDQoNClBldGVyDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmRyZXcgQ3VubmluZ2hhbSBbbWFpbHRvOmxhbmcu c3VwcG9ydEBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNCwgMjAwNyA2OjAy IFBNDQpUbzogU2hhd24gU3RlZWxlDQpDYzogbHRydUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtM dHJ1XSBFeHRlbmRlZCBsYW5ndWFnZSB0YWdzDQoNClRocm93aW5nIGluIG15IHR3byBjZW50cyB3 b3J0aDoNCg0KT25lIGFzcGVjdCBvZiBsYW5ndWFnZSB0YWdnaW5nIGlzIHRoZSBwcmVmZXJlbmNl IGZvciB0aGUgdGFncyB0byBiZSBhcw0Kc3BlY2lmaWMgYXMgcG9zc2libGUuIEluIHNvbWUgY2Fz ZXMgaXQgaXMgZGVzaXJhYmxlIHRvIGJlIGxlc3MNCnNwZWNpZmljLg0KDQpBbiBleGFtcGxlIGkg bWVudGlvbmVkIG9uIHRoZSB0ZWxlY29uZmVyZW5jZSB3YXMgdGhlIGNhc2Ugb2YgRGlua2EuIElu DQpJU08tNjM5LTIgdGhpcyBpcyByZXByZXNlbnRlZCBieSB0aGUgbGFuZ3VhZ2UgY29kZSAiZGlu Ii4NCg0KV2hpbGUgSVNPLTYzOS0zIGhhdmUgdGhlIGZvbGxvd2luZyBsYW5ndWFnZSBjb2RlczoN Cg0KZGliICAgICBTb3V0aCBDZW50cmFsIERpbmthDQpkaWsgICAgIFNvdXRod2VzdGVybiBEaW5r YQ0KZGlwICAgICBOb3J0aGVhc3Rlcm4gRGlua2ENCmRpdyAgICAgTm9ydGh3ZXN0ZXJuIERpbmth DQpka3MgICAgIFNvdXRoZWFzdGVybiBEaW5rYQ0KDQpJZiBJIHdhcyBhcHBseWluZyBhIGxhbmdh dWdlIHRhZyB0byBhIFJlayBncmFtbWFyLCB0aGVuIGknZCB1c2UgImRpayIsDQpmb3IgYSBjb2xs ZWN0aW9uIG9mIENpZWMgZm9sa3RhbGVzIEknZCB1c2UgImRpYiIuIEZvciBhIGNvbGxlY3Rpb24g b2YNCkJvciBwcm92ZXJicyBJJ2QgdXNlICJka3MiLg0KDQpUbyBkZXNjcmliZSB0aGUgbGl0ZXJh Y3kgbWF0ZXJpYWxzIGFuZCBjbGFzcyByb29tIG1hdGVyaWFscyBiZWluZw0KZGV2ZWxvcGVkIGlu IEF1c3RyYWxpYSBieSB0aGUgRGlua2EgY29tbXVuaXR5LCBJJ2QgdXNlICJkaW4iLiBXaXRoaW4N CnRoZSBkaWFzcG9yYSBhbmQgaW4gQXVzdHJhbGlhIHNwZWNpZmljYWxseSB0aGUgbGl0ZXJhY3kg YW5kIGxhbmd1YWdlDQp0ZWFjaGVycywgdHJhbnNsYXRvcnMgYW5kIGludGVycHJldGVycyBhcmUg ZGlzY3Vzc2luZyBhIHN0YW5kYXJkaXplZA0KYXBwcm9hY2ggdG8gd3JpdHRlbiBEaW5rYS4NCg0K VGhlIG9yaWdpbmFsIFNQTEEvTSBlZHVjYXRpb24gcG9saWNpZXMgaGlnaGxpZ2h0ZWQgUmVrIGFz IGEgc3RhbmRhcmQNCmZvciB3cml0dGVuIERpbmthLiBXaGF0IHNlZW1zIHRvIGJlIG9jY3Vycmlu ZyBpcyBhbiBhbWFsZ2FtIGJhc2VkIG9uDQpSZWssIGJ1dCBpbmNsdWRpbmcgYXNwZWN0cyBhbmQg dm9jYWIgZnJvbSBvdGhlciBEaW5rYSBkaWFsZWN0cy4gVGhlcmUNCndpbGwgYmUgYSBsb2NhbGx5 IGhvc3RlZCBjb25mZXJlbmNlIG5leHQgeWVhciB0byB0aHJhc2ggb3V0IHNvbWUgb2YNCnRoZSBp c3N1ZXMuDQoNCkluIHRoaXMgY29udGV4dCAiZGluIjogd291bGQgYmUgdGhlIG1vc3QgYXBwcm9w cmlhdGUgd2F5IG9mIHRhZ2dpbmcNCnRoZSBuZXcgZWR1Y2F0aW9uYWwgbWF0ZXJpYWwsIHdoaWxl IGtlZXBpbmcgdGhlIGV4aXN0aW5nIGZpdmUNCmlzby02MzktMyBsYW5ndWFnZSB0YWdzIHRvIG1v cmUgYWNjdXJhdGVseSBkZXNjcmliZSBpbmZvcm1hdGlvbiBhbmQNCmRhdGEgd3JpdHRlbiBpbiBv bmUgb2YgdGhlIDIwIG9kZCBzcGVjaWZpYyBkaWFsZWN0cy4NCg0KZnJvbSB0aGUgcGVyc3BlY3Rp dmUgb2YgdGhlIHVzZXIgY29tbXVuaXR5LCBhbiBleHRsYW5nIGFwcHJvYWNoIHdvdWxkDQptYWtl IG1vcmUgc2Vuc2UsIGkuZS4gUmVrIGxhYmVsZWQgYXMgImRpbi1kaWsiIG1ha2VzIG1vcmUgc2Vu c2UgdGhhbg0KImRpayIuIFRvIHRoZSBjb21tdW5pdHkgUmVrIGlzIGEgRGlua2EgbGFuZ2F1Z2Us IERpbmFrIFJlaywgbm90IGENCnNlcGFyYXRlIGxhbmd1YWdlIGNhbGxlZCBSZWsuDQoNCkluIHRo aXMgc2Vuc2UgZXh0bGFuZyByZWZsZWN0cyB0aGUgY29tbXVuaXRpZXMgdW5kZXJzdGFuZGluZyBv ZiB0aGVpciBsYW5ndWFnZS4NCg0KVGhpcyBpcyBqdXN0IGFuIG9ic2VydmF0aW9uLCBpJ20gbmVp dGhlciBmb3Igb3IgYWdhaW5zdCBleHRsYW5nLg0KDQpBbHRob3VnaCBmcm9tIHRoZSBwZXJzcGVj dGl2ZSBvZiB3ZWIgZGV2ZWxvcG1lbnQgYW5kIGhvdyBDU1MgYW5kIHdlYg0KYnJvd3NlcnMgaGFu ZGxlIHBzdWVkbyBsYW5nYXVnZSBzZWxlY3RvcnMgYW5kIGF0dHJpYnV0ZSBzZWxlY3RvcnMsIEkn ZA0Kc3VnZ2VzdCB0aGF0IGV4dGxhbmcgYXBwcm9hY2ggc2ltcGxpZmllcyB0aGluZ3MgZm9yIHRo b3NlIHJhcmUNCmluZGl2aWR1YWxzIGFtb25nc3QgdXMgdGhhdCB1c2UgdGhlc2Ugc2VsZWN0b3Jz Lg0KDQpBbmRyZXcNCi0tDQpBbmRyZXcgQ3VubmluZ2hhbQ0KU3RhdGUgTGlicmFyeSBvZiBWaWN0 b3JpYSwgQXVzdHJhbGlhDQoNCmFuZHJld2NAdmljbmV0Lm5ldC5hdQ0KbGFuZy5zdXBwb3J0QGdt YWlsLmNvbQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpMdHJ1IG1haWxpbmcgbGlzdA0KTHRydUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============1136085055== 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 --===============1136085055==-- From ltru-bounces@ietf.org Sun Oct 07 02:58:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeQ5H-0001Pm-89; Sun, 07 Oct 2007 02:57:51 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IeQ5G-0001Ph-KY for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 02:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeQ5G-0001PZ-B1 for ltru@ietf.org; Sun, 07 Oct 2007 02:57:50 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeQ5F-00026B-1d for ltru@ietf.org; Sun, 07 Oct 2007 02:57:50 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sat, 6 Oct 2007 23:57:48 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Sat, 6 Oct 2007 23:57:48 -0700 From: Peter Constable To: Don Osborn Date: Sat, 6 Oct 2007 23:57:48 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG63r0wRUkk5e7R7OOF2/JgQKd+QAAUg/wAHBqdNA= Message-ID: References: <9d70cb000710041801k44ee5016u7374af1e1a17f6bc@mail.gmail.com> <002101c806f0$9c7dffc0$d579ff40$@net> In-Reply-To: <002101c806f0$9c7dffc0$d579ff40$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -6.8 (------) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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="===============0558821993==" Errors-To: ltru-bounces@ietf.org --===============0558821993== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uLCBkbyB5b3UgaGF2ZSBhIHNlbnNlIG9mIGhvdyB3ZWxsIHRoZSBtYWNyb2xhbmd1YWdlIGVu dGl0aWVzIHRoYXQgaGF2ZSBiZWVuIGluIDYzOSBjb3ZlciB0aGUgc2V0IG9mIEFmcmljYW4gZGV2 ZWxvcGVkIG1hY3JvLXZhcmlldGllcyB0aGF0IHdlJ3JlIGxpa2VseSB0byBzZWUgZGV2ZWxvcGlu ZyBpbiB0aGUgbmV4dCAoc2F5KSAyMCB5ZWFycz8NCg0KUHV0IGFub3RoZXIgd2F5LCBhcmUgd2Ug bGlrZWx5IHRvIG5lZWQgYSBudW1iZXIgb2YgbmV3IElEcyBpbiA2MzkgKGFzIGluIHRoZSBOJ0tv IGNhc2UpPyBJZiBzbywgc2hvdWxkIHRoZXkgaGF2ZSBtYWNyb2xhbmd1YWdlIG1hcHBpbmdzIGlu IDYzOSB0byBzZXRzIG9mIGV4aXN0aW5nIGVudHJpZXM/IElmIHNvLCB3aGF0IGNhbiB3ZSBleHBl Y3QgdG8gaGFwcGVuIGluIHRoZSB3YXkgb2YgdGFnIHVzZSBpbiB0aGUgc2hvcnQgdGVybSwgd2hp bGUgdGhlc2UgdmFyaWV0aWVzIGhhdmUgbm90IHlldCBlbWVyZ2VkIG9yIGFyZSBvbmx5IGp1c3Qg c3RhcnRpbmcgdG8gZW1lcmdlLCBhbmQgd2hhdCB3b3VsZCBwcm9zL2NvbnMgYmUgb2YgdGhlIGV4 dGxhbmcgYXBwcm9hY2ggdG8gdGFnZ2luZz8NCg0KDQpQZXRlcg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRG9uIE9zYm9ybiBbbWFpbHRvOmR6b0BiaXNoYXJhdC5uZXRdDQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNCwgMjAwNyA2OjQwIFBNDQpUbzogJ0FuZHJldyBDdW5u aW5naGFtJzsgU2hhd24gU3RlZWxlDQpDYzogbHRydUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtM dHJ1XSBFeHRlbmRlZCBsYW5ndWFnZSB0YWdzDQoNCkp1c3QgdG8gY29uZmlybSB0aGF0IHdoYXQg QW5kcmV3IGlzIHNheWluZyBhcHBsaWVzIHRvIGEgbnVtYmVyIG9mIGxhbmd1YWdlcyBpbiBBZnJp Y2EuIEkndmUgYnJvdWdodCB1cCBzaW1pbGFyIGNvbmNlcm5zIGluIHRoZSBwYXN0IHdydCAobWFj cm8pIGxhbmd1YWdlcyBsaWtlIEZ1bGEgYW5kIE1hbmRpbmcgKHRob3VnaCB0aGUgbGF0dGVyIG1p Z2h0IGJlIGNhbGxlZCBhIGNsdXN0ZXIpLCB0aG91Z2ggSSBiZWxpZXZlIEkgYWRkcmVzc2VkIHRo ZW0gdG8gdGhlIGlldGYtbGFuZ3VhZ2VzIGxpc3QuIFRoZXNlIGFyZSBqdXN0IGEgZmV3IGV4YW1w bGVzLg0KDQpJIGhhdmVuJ3QgYmVlbiBmb2xsb3dpbmcgdGhlIHJlY2VudCBkaXNjdXNzaW9ucyBo ZXJlIGFzIG11Y2ggYXMgSSBzaG91bGQgaGF2ZSwgYnV0IGRvIGJlbGlldmUgdGhhdCBpZiB0aGVy ZSBpcyBhIGJpYXMgaW4gdGhlIHN5c3RlbSB0byBzcGVjaWZpY2l0eSwgd2hlbiBzcGVjaWZpY2l0 eSBpcyBub3QgYWx3YXlzIHRoZSBpZGVhbCBhcHByb2FjaCwgdGhlbiBpdCB3aWxsIGluZXZpdGFi bHkgZW5jb3VudGVyIGNhbGxzIGZvciBmbGV4aWJpbGl0eSBsYXRlci4gQXQgdGhpcyBwb2ludCBJ IGNhbid0IHNheSBob3cgZXh0bGFuZyByZXNwb25kcyB0byB0aGlzIHNvIGNhbiBvbmx5IG9mZmVy IHRoZXNlIGdlbmVyYWwgY29tbWVudHMgb24gdGhlIGNvbnRleHQgb2Ygc29tZSBsYW5ndWFnZXMu DQoNClRoaXMgaXMgbm90IHRvIHNheSB0aGF0IHNwZWNpZmljaXR5IGluIGxhbmd1YWdlIHRhZ3Mg aXMgd3JvbmcsIGJ1dCB0aGF0IHRoZXkgZGVzY3JpYmUgb25lIGFzcGVjdCBvZiBhIG1vcmUgY29t cGxleCByZWFsaXR5LiBMYXJnZSBkZWdyZWVzIG9mIGludGVyaW50ZWxsaWdpYmlsaXR5LCB0aGUg c2Vuc2Ugb2Ygc3BlYWtlcnMgcmVnYXJkaW5nIHRoZSBlc3NlbnRpYWwgdW5pdHkgb2YgYSBsYW5n dWFnZSAoYmFzZWQgb24gdGhlaXIgZXhwZXJpZW5jZSBhbmQgdGhlIGNvbW1vbiB3aXNkb20gaW4g dGhlIGN1bHR1cmUpLCBhbmQgdGhlIGhvcGVzIGFuZCBwb3RlbnRpYWxzIGZvciBzdGFuZGFyZGl6 ZWQgdmVyc2lvbnMsIGFsbCBwcm9iYWJseSBtZWFuIHRoYXQgbGVzcyBzcGVjaWZpYyB0YWdzIHdp bGwgYmVjb21lIG1vcmUgaW1wb3J0YW50IGFzIHRoZXNlIGxhbmd1YWdlcyBlbWVyZ2UgbW9yZSBm dWxseSBpbnRvIGRpZ2l0YWwgY3VsdHVyZSBhbmQgdGhlIGRpZ2l0YWwgZWNvbm9teS4NCg0KVGhl IGxhbmd1YWdlIHNpdHVhdGlvbnMgYXJlIGR5bmFtaWMsIGFuZCB0aGUgbWVkaXVtIGluIHdoaWNo IHdlIGFyZSB0cnlpbmcgdG8gZGVzY3JpYmUgYW5kIGNhdGVnb3JpemUgbGFuZ3VhZ2VzIGlzIGFk ZGluZyBhIG5ldyBkaW1lbnNpb24gdG8gdGhlIGRldmVsb3BtZW50IG9mIGxlc3Nlci1yZXNvdXJj ZWQgbGFuZ3VhZ2VzIGFuZCB0aGVpciB2YXJpYW50cy4NCg0KSG9wZSB0aGlzIG1ha2VzIHNvbWUg c2Vuc2UuDQoNCkRvbiBPc2Jvcm4NCkJpc2hhcmF0Lm5ldA0KUGFuQWZyaUwxMG4ub3JnDQoNCg0K DQoNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5kcmV3IEN1 bm5pbmdoYW0gW21haWx0bzpsYW5nLnN1cHBvcnRAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2Rh eSwgT2N0b2JlciAwNCwgMjAwNyA5OjAyIFBNDQo+IFRvOiBTaGF3biBTdGVlbGUNCj4gQ2M6IGx0 cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBFeHRlbmRlZCBsYW5ndWFnZSB0YWdz DQo+DQo+IFRocm93aW5nIGluIG15IHR3byBjZW50cyB3b3J0aDoNCj4NCj4gT25lIGFzcGVjdCBv ZiBsYW5ndWFnZSB0YWdnaW5nIGlzIHRoZSBwcmVmZXJlbmNlIGZvciB0aGUgdGFncyB0byBiZSBh cw0KPiBzcGVjaWZpYyBhcyBwb3NzaWJsZS4gSW4gc29tZSBjYXNlcyBpdCBpcyBkZXNpcmFibGUg dG8gYmUgbGVzcw0KPiBzcGVjaWZpYy4NCj4NCj4gQW4gZXhhbXBsZSBpIG1lbnRpb25lZCBvbiB0 aGUgdGVsZWNvbmZlcmVuY2Ugd2FzIHRoZSBjYXNlIG9mIERpbmthLiBJbg0KPiBJU08tNjM5LTIg dGhpcyBpcyByZXByZXNlbnRlZCBieSB0aGUgbGFuZ3VhZ2UgY29kZSAiZGluIi4NCj4NCj4gV2hp bGUgSVNPLTYzOS0zIGhhdmUgdGhlIGZvbGxvd2luZyBsYW5ndWFnZSBjb2RlczoNCj4NCj4gZGli ICAgU291dGggQ2VudHJhbCBEaW5rYQ0KPiBkaWsgICBTb3V0aHdlc3Rlcm4gRGlua2ENCj4gZGlw ICAgTm9ydGhlYXN0ZXJuIERpbmthDQo+IGRpdyAgIE5vcnRod2VzdGVybiBEaW5rYQ0KPiBka3Mg ICBTb3V0aGVhc3Rlcm4gRGlua2ENCj4NCj4gSWYgSSB3YXMgYXBwbHlpbmcgYSBsYW5nYXVnZSB0 YWcgdG8gYSBSZWsgZ3JhbW1hciwgdGhlbiBpJ2QgdXNlICJkaWsiLA0KPiBmb3IgYSBjb2xsZWN0 aW9uIG9mIENpZWMgZm9sa3RhbGVzIEknZCB1c2UgImRpYiIuIEZvciBhIGNvbGxlY3Rpb24gb2YN Cj4gQm9yIHByb3ZlcmJzIEknZCB1c2UgImRrcyIuDQo+DQo+IFRvIGRlc2NyaWJlIHRoZSBsaXRl cmFjeSBtYXRlcmlhbHMgYW5kIGNsYXNzIHJvb20gbWF0ZXJpYWxzIGJlaW5nDQo+IGRldmVsb3Bl ZCBpbiBBdXN0cmFsaWEgYnkgdGhlIERpbmthIGNvbW11bml0eSwgSSdkIHVzZSAiZGluIi4gV2l0 aGluDQo+IHRoZSBkaWFzcG9yYSBhbmQgaW4gQXVzdHJhbGlhIHNwZWNpZmljYWxseSB0aGUgbGl0 ZXJhY3kgYW5kIGxhbmd1YWdlDQo+IHRlYWNoZXJzLCB0cmFuc2xhdG9ycyBhbmQgaW50ZXJwcmV0 ZXJzIGFyZSBkaXNjdXNzaW5nIGEgc3RhbmRhcmRpemVkDQo+IGFwcHJvYWNoIHRvIHdyaXR0ZW4g RGlua2EuDQo+DQo+IFRoZSBvcmlnaW5hbCBTUExBL00gZWR1Y2F0aW9uIHBvbGljaWVzIGhpZ2hs aWdodGVkIFJlayBhcyBhIHN0YW5kYXJkDQo+IGZvciB3cml0dGVuIERpbmthLiBXaGF0IHNlZW1z IHRvIGJlIG9jY3VycmluZyBpcyBhbiBhbWFsZ2FtIGJhc2VkIG9uDQo+IFJlaywgYnV0IGluY2x1 ZGluZyBhc3BlY3RzIGFuZCB2b2NhYiBmcm9tIG90aGVyIERpbmthIGRpYWxlY3RzLiBUaGVyZQ0K PiB3aWxsIGJlIGEgbG9jYWxseSBob3N0ZWQgY29uZmVyZW5jZSBuZXh0IHllYXIgdG8gdGhyYXNo IG91dCBzb21lIG9mDQo+IHRoZSBpc3N1ZXMuDQo+DQo+IEluIHRoaXMgY29udGV4dCAiZGluIjog d291bGQgYmUgdGhlIG1vc3QgYXBwcm9wcmlhdGUgd2F5IG9mIHRhZ2dpbmcNCj4gdGhlIG5ldyBl ZHVjYXRpb25hbCBtYXRlcmlhbCwgd2hpbGUga2VlcGluZyB0aGUgZXhpc3RpbmcgZml2ZQ0KPiBp c28tNjM5LTMgbGFuZ3VhZ2UgdGFncyB0byBtb3JlIGFjY3VyYXRlbHkgZGVzY3JpYmUgaW5mb3Jt YXRpb24gYW5kDQo+IGRhdGEgd3JpdHRlbiBpbiBvbmUgb2YgdGhlIDIwIG9kZCBzcGVjaWZpYyBk aWFsZWN0cy4NCj4NCj4gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIHVzZXIgY29tbXVuaXR5 LCBhbiBleHRsYW5nIGFwcHJvYWNoIHdvdWxkDQo+IG1ha2UgbW9yZSBzZW5zZSwgaS5lLiBSZWsg bGFiZWxlZCBhcyAiZGluLWRpayIgbWFrZXMgbW9yZSBzZW5zZSB0aGFuDQo+ICJkaWsiLiBUbyB0 aGUgY29tbXVuaXR5IFJlayBpcyBhIERpbmthIGxhbmdhdWdlLCBEaW5hayBSZWssIG5vdCBhDQo+ IHNlcGFyYXRlIGxhbmd1YWdlIGNhbGxlZCBSZWsuDQo+DQo+IEluIHRoaXMgc2Vuc2UgZXh0bGFu ZyByZWZsZWN0cyB0aGUgY29tbXVuaXRpZXMgdW5kZXJzdGFuZGluZyBvZiB0aGVpcg0KPiBsYW5n dWFnZS4NCj4NCj4gVGhpcyBpcyBqdXN0IGFuIG9ic2VydmF0aW9uLCBpJ20gbmVpdGhlciBmb3Ig b3IgYWdhaW5zdCBleHRsYW5nLg0KPg0KPiBBbHRob3VnaCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBv ZiB3ZWIgZGV2ZWxvcG1lbnQgYW5kIGhvdyBDU1MgYW5kIHdlYg0KPiBicm93c2VycyBoYW5kbGUg cHN1ZWRvIGxhbmdhdWdlIHNlbGVjdG9ycyBhbmQgYXR0cmlidXRlIHNlbGVjdG9ycywgSSdkDQo+ IHN1Z2dlc3QgdGhhdCBleHRsYW5nIGFwcHJvYWNoIHNpbXBsaWZpZXMgdGhpbmdzIGZvciB0aG9z ZSByYXJlDQo+IGluZGl2aWR1YWxzIGFtb25nc3QgdXMgdGhhdCB1c2UgdGhlc2Ugc2VsZWN0b3Jz Lg0KPg0KPiBBbmRyZXcNCj4gLS0NCj4gQW5kcmV3IEN1bm5pbmdoYW0NCj4gU3RhdGUgTGlicmFy eSBvZiBWaWN0b3JpYSwgQXVzdHJhbGlhDQo+DQo+IGFuZHJld2NAdmljbmV0Lm5ldC5hdQ0KPiBs YW5nLnN1cHBvcnRAZ21haWwuY29tDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBt YWlsaW5nIGxpc3QNCkx0cnVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCg== --===============0558821993== 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 --===============0558821993==-- From ltru-bounces@ietf.org Sun Oct 07 03:04:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeQBQ-0000GN-WD; Sun, 07 Oct 2007 03:04:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IeQBP-0000GI-TH for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 03:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeQBP-0000G8-JZ for ltru@ietf.org; Sun, 07 Oct 2007 03:04:11 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeQBO-0002Bc-DX for ltru@ietf.org; Sun, 07 Oct 2007 03:04:11 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Sun, 7 Oct 2007 00:03:49 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Sun, 7 Oct 2007 00:03:49 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Sun, 7 Oct 2007 00:03:48 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgG/zlJDCs4o8kdRpu/8e5OeTjXFABsGp3A Message-ID: References: <20071005032151.GG27520@mercury.ccil.org> In-Reply-To: <20071005032151.GG27520@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org But I think Shawn's point is that the Breton/French example doesn't really = tell us much of anything of interest wrt extlangs -- neither language has a= ny macrolanguage / extlang issues involved. For Lookup, the best fallback f= or Dyirbal is probably English; the best fallback for Ainu is Japanese. So? Peter -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: Thursday, October 04, 2007 8:22 PM To: Shawn Steele Cc: ltru@ietf.org Subject: Re: [Ltru] Extended language tags Shawn Steele scripsit: > * I don't think the Breton example applies. http-accept-lang allows for > "br-FR;fr-FR" type fallback, so that is a solution. If an application > independently wanted to make this assumption that's fine by me, but > this seems orthogonal to the problem we're trying to solve here. That works for filtering (which is what Accept-Lang does), but not so well in practice for lookup. Normally people don't specify multiple match = patterns in lookup situations, they just say "I speak Breton, what's the best match you have?" -- You're a brave man! Go and break through the John Cowan lines, and remember while you're out there cowan@ccil.org risking life and limb through shot and shell, http://ccil.org/~co= wan we'll be in here thinking what a sucker you are! --Rufus T. Firefly _______________________________________________ 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 07 13:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeZfi-00063E-1e; Sun, 07 Oct 2007 13:12:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IeZfg-00062q-NM for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 13:12:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeZfg-0005AX-CZ for ltru@ietf.org; Sun, 07 Oct 2007 13:12:04 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeZez-0006pq-KE for ltru@ietf.org; Sun, 07 Oct 2007 13:11:22 -0400 Received: from [10.72.77.22] (snvvpn2-10-72-77-c22.corp.yahoo.com [10.72.77.22]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l97HBJUq004021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2007 10:11: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=Dk3PAGFdmZX/HM5tb9s942zyA0X+AczeYGVEI6PxlqqdMbMvGrXl+fSo/2tC+9Jk Message-ID: <47091337.705@yahoo-inc.com> Date: Sun, 07 Oct 2007 10:11:19 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Extended language tags References: <20071005032151.GG27520@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think this is a mis-reading of Mark's example. His presupposition goes something like: "suppose Breton had a macrolanguage of Celtic..." It would be a more effective example, I think, if we used an actual enclosed language. I've been writing a long email in response to Shawn's (and various responses thereto) that I haven't quite been able to make myself send. Part of it includes this rephrasing of the example: -- Let me rephrase Mark's Breton case: when you want Chippewa, any old Ojibwa (its macrolanguage) -- which might be a language such as Ottawa -- will not do. It could be unintelligible (I don't actually know). If it is unintelligible, you're probably better off *not* mapping Chippewa to Ojibwa. You're better off serving some useful default (for Chippewa, this is probably English, but the default is up to the application, not something RFC 4647 or the registry do). Or the app could fail to find content. -- When considered like this, the Breton vs. French example is more useful. Otherwise it is pointless. Addison Peter Constable wrote: > But I think Shawn's point is that the Breton/French example doesn't really tell us much of anything of interest wrt extlangs -- neither language has any macrolanguage / extlang issues involved. For Lookup, the best fallback for Dyirbal is probably English; the best fallback for Ainu is Japanese. So? > > > Peter > > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Thursday, October 04, 2007 8:22 PM > To: Shawn Steele > Cc: ltru@ietf.org > Subject: Re: [Ltru] Extended language tags > > Shawn Steele scripsit: > >> * I don't think the Breton example applies. http-accept-lang allows for >> "br-FR;fr-FR" type fallback, so that is a solution. If an application >> independently wanted to make this assumption that's fine by me, but >> this seems orthogonal to the problem we're trying to solve here. > > That works for filtering (which is what Accept-Lang does), but not so > well in practice for lookup. Normally people don't specify multiple match patterns > in lookup situations, they just say "I speak Breton, what's the best > match you have?" > > -- > You're a brave man! Go and break through the John Cowan > lines, and remember while you're out there cowan@ccil.org > risking life and limb through shot and shell, http://ccil.org/~cowan > we'll be in here thinking what a sucker you are! > --Rufus T. Firefly > > > _______________________________________________ > 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. Chair -- W3C Internationalization Core WG 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 07 13:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeZk7-0004rb-2F; Sun, 07 Oct 2007 13:16:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IeZk5-0004rU-Kq for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 13:16:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeZk5-0004rM-8n for ltru@ietf.org; Sun, 07 Oct 2007 13:16:37 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeZk3-0006uy-Sk for ltru@ietf.org; Sun, 07 Oct 2007 13:16:37 -0400 Received: from [10.72.77.22] (snvvpn2-10-72-77-c22.corp.yahoo.com [10.72.77.22]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l97HGV5v004226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2007 10:16:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=m4KDDGDlEgk47KODVgv6MUKfhlRGk8+edzGtsKG4eWUd1/Ggt2oLb6kvk+QQmmlz Message-ID: <4709146F.6020504@yahoo-inc.com> Date: Sun, 07 Oct 2007 10:16:31 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shawn Steele Subject: Re: [Ltru] Extended language tags (long reply) 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: 311e798ce51dbeacf5cdfcc8e9fda21b 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 (warning: this is a long screed, which, now that I've alluded to it on list--and even quoted from the abominable thing-- I may as well share, even though I'll probably think better of it in about an hour when the responses start to arrive) Shawn Steele wrote: > > * We (the bigger software ecosystem we, tools, etc) have encouraged use of zh-HK, etc for labeling both Mandarin and Cantonese. Whatever happens in the future a large number of legacy documents, both Manderin and Cantonese, will be labeled with the existing language tag. Not exactly. "We" have (at least historically) abused the tags "zh-HK" and "zh-TW" to represent Traditional Chinese and ignored the Cantonese/Mandarin split (which is possible if one only means written content, which historically has composed most of the material in our information systems and on the Web). More recently, language tags have allowed for direct tagging of these differences as "zh-Hant" and "zh-Hans" (Traditional vs. Simplified) allowing TW and HK to represent regional differences (there are regional preferential differences, even in written texts, even when ignoring the Cantonese/Mandarin split--we encounter these at Yahoo!, for example). It is unclear how quickly the transition to these subtags is proceeding. Some user-agents don't support these tags yet. With the advent of audio and visual content in particular, tagging all Chinese as 'zh' becomes less useful (at least for those cases), since we suddenly find applications for which we need to describe specific spoken variations not captured by 'zh' and not directly discernible from the region subtag. I note that Chinese *may* be a special case, in comparison to others, in which we have very large document bases in a variety of Sinitic languages tagged with a wide variety of regional subtags representing something other than regional variations. Other macro languages don't exhibit this sort or range of imputed meaning. For example, the Arabic "sub-languages" are mostly regionally based, so one might very well consider 'arz' (Egyptian Arabic) to be a synonym for "ar-EG" (Arabic as used in Egypt). Of course, some of the other Arabic languages don't map so closely to modern nation-states... for the record, I oppose assigning "secret handshake" meaning to region subtags. Explicit subtags seem to work better. [Yes, there really are regional differences, for which region subtags are good, even when the region where the language is spoken leaks over borders a bit.] > > * Whether or not yue or zh-yue was used, it is a change from the current label (in most cases). It seems that in nearly all cases this will require a code change. In particular applications that want to include zh-HK in lists containing zh-cmn-HK or cmn-HK will need extra awareness. It requires tag changes to indicate things with more precision, yes. Nothing says that we might not have continued use of the existing tags; indeed, I would be surprised by a wholesale conversion over to the new scheme (whatever it is). Most people won't "get the message" for awhile. And sometimes the additional specificity doesn't matter ('zh' is perfectly good for many written documents). However, for many applications where content labeling can be controlled, converting over makes life easier. For Chinese in particular, I expect a pretty messy tagging situation to persist for quite some time (since we have overlapping levels of imputed meaning in region subtags and elsewhere). For other languages, a messy situation may not be necessary. Arabic probably doesn't *require* extlangs, although that may be my parochial perspective. While Andrew and Don point out the usefulness of deliberate vagaries in tagging, mightn't we be just as well be served by tagging "generic" Dinka documents (for example) as 'din' and specific Dinka documents as, for example, 'dib' or 'dik'? Again, the question here seems to depend on whether tags or ranges are what matter most. > > * I don't think the Breton example applies. http-accept-lang allows for "br-FR;fr-FR" type fallback, so that is a solution. If an application independently wanted to make this assumption that's fine by me, but this seems orthogonal to the problem we're trying to solve here. I agree that this fallback case is valid as a use-case for language priority lists, but not for language tags. But I think this misses the point. It is quoted without Mark's preamble, in which he posits Breton as a sublanguage of Welsh. Mark is using it more as a parable to illustrate the extlang case, not as an example-in-fact. Let me rephrase Mark's Breton case: when you want Chippewa, any old Ojibwa (its macrolanguage), which might be a language such as Ottawa, will not do. It is unintelligible (maybe: I don't actually know in this case). If it is unintelligible, you're probably better off *not* mapping Chippewa to Ojibwa. You're better off serving some useful default (for Chippewa, this is probably English, but is up to the application, not something RFC 4647 or the LSR do) or even failing. The counter-example would be the ietf-languages adventure in Norwegian tagging. Were we better off when Norwegian was represented by the older registered values (which are quite extlang like, eh?): no-nyn no-bok Than by the codes: nn nb no Things certainly were easier when 'no' meant generic Norwegian (which, it turns out, tends to be 'nb') and Nynorsk could be represented extlang/variant-like. In code that deals with Norwegian language tags today (as well as other odd cases, such as the mistaken 'he'/'iw' pair), you often have this irksome special mapping table of the (what would be) sublanguage codes to its macrolanguage, which is what we "mean". But you can't eat/change the original subtag---other processors might interpret or map the codes differently or be able to serve specific resources tailored to the original request. This is a flaw in the no-extlang case and why Mark and others have insisted that Macrolanguage becomes an important piece of information in the registry. > > * Lots of zh data right now is zh-cmn. Most of "us" seem to agree that we can't narrow the meaning of zh because it does allow Cantonese. However if some application wanted to make an assumption that zh == zh-cmn, then that seems up to the application for fallback. Agreed. More to the point, the "zh" tag encompasses a resource containing *some* (which is to say, exactly ONE) variety of Chinese. It is probably also Simplified Chinese, for example--it certainly can't be both Simplified and Traditional. But you can't make that assumption safely! There are also differences in (for example) the accepted level of English word borrowing between (say) Taiwan and HK, etc. "zh" embodies the least common denominator, which may not be very common in certain circumstances (if you're talking about our HK web site, 'zh' probably means content that could be tagged "zh-yue-Hant-HK", whereas I'm pretty sure other sites or applications would prefer it to be pretty similar to the stuff that could be tagged "zh-cmn-Hans-CN"). Heck, when I started my internationalization career, 'zh' meant Traditional, because many of us did business in Taiwan and hardly anyone in the PRC. Now 'zh' mostly "means" Simplified. > > * Even for the current tags, many of the people in the teleconference seem to extend RFC 4647 in ways that are best for them. Strict use of 4647 behavior seems rare. It seems reasonable to me to expect that in the future people may continue to do so and that RFC 4647 and the registry can only provide guidelines. I don't think that it can solve all problems for all applications, and I'm fine with that. I disagree. RFC 4647 is fine for many purposes. I'm proposing, if we do extlangs, a small modification due to finding a slightly better version of just one algorithm (lookup). I think our ideal goal would be for RFC 4647 matching schemes to work fully for everyone for the scope they are designed for. We might make one or other tweak to the document and possibly the algorithms based on further testing. For now, the existing schemes mostly work. They exhibit varying impact on tag and range choice in either extlang or no-extlang clothes. I disagree that you have to have far more complex matching systems in all cases. Yes, there are use cases that call for more complex systems. But most low-level users have no need of these elaborations. For basic protocols, I think we would prefer the simplest possible algorithms that produce mostly the right results. Locale systems, for example, are based on lookup (well, more like lookup is based on them), and they produce meaningful results for resource lookup pretty reliably. I have a concern that lookup work well, because I have a vested interest in the continued good behavior of systems such as CLDR, which use and depend on these simplest possible matching systems, such as lookup. So we can change the algorithm or "change" the (as yet undefined) tags, which is what is suggested as the other route. > > So from these points, my conclusion is that the zh-cmn form is preferable. > > My reasoning is that either cmn by itself or zh-cmn will require code change in nearly all cases, either to include or exclude existing data or fallback rules. Either was will require a code change, and either way may require knowledge that zh-HK might be interesting if the request is for {Mandarin tag}-HK. Searching may need to include zh files for {Manderin tag} queries and exclude them for {Cantonese tag} queries, but the actual tag doesn't really change this logic. Neither variation is likely to work with existing code when the request is for the new name and the data is tagged with the old tag. > > The deciding factor for me is that to know that cmn is related to zh I'd have to look in the registry, but zh-cmn contains that information. Otherwise I don't really see advantages with either method. The question is: do we want to do this for all time? Or can we help people migrate and just get started on the migration? Yes, retagging with "yue-HK" is a PITA, but so is retagging with "zh-yue-HK". If we have to convince folks to retag their data anyway, what is the best solution/most sensible? The benefit to extlang partially comes from the expectation that the tags will be changed but users won't update their ranges. For that case, you can switch to extended filtering and a slightly modified lookup and use extlangs and go about your business. Of course, you have to explain these fairly complex tags to the Chinese...... (and Arabic, Dinka, Quechua, Zapotec, and etc. speakers) On the other hand, if you go with primary language subtags for everyone, you are expecting that users will change or augment their language priority lists (i.e. "yue-HK; zh-HK") to deal with un-retagged data or provide alternate lookup tables in your implementations. Matching algorithms do not change, but tags eventually have to catch up for the majority of documents or there is (probably quite icky) tagging chaos. So, for me, the main issue is whether we are going to explicitly break the connection between the language and its macrolanguage (at the tag level). In some cases (Norwegian) we already know this can be problematic; in others, it may actually be desirable. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 07 20:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IegIR-0003aY-L4; Sun, 07 Oct 2007 20:16:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IegIQ-0003Yi-NB for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 20:16:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IegIQ-0003VW-Cm for ltru@ietf.org; Sun, 07 Oct 2007 20:16:30 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IegID-0004zD-5e for ltru@ietf.org; Sun, 07 Oct 2007 20:16:23 -0400 Received: by rv-out-0910.google.com with SMTP id l15so568622rvb for ; Sun, 07 Oct 2007 17:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=mkyGO65pa6zgFBHWAFCe9o+6a/NmTg8w2Hr41cmhU6g=; b=g1mpynZcAbIPMnvUL14QYGAKczIr84rzSR/WqZo2XASdaj7/Mr/rMPOvGd6MzmM3UUHth+1Ixw4058yn2Wgvbk2mbIpuY4N1VVWRm8M6+SJvzAoBPhFVBhbLmWa73c5CV1smMeosJKw2Us9kuBxTARbPkvYs56/4tOcLsoTITV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NQLH3vAwnwucrvwIWzNExMPZfF91whBqLRrOZc1E2/fbmNFge3eYPLn+rVm2VSxlMPhcSOF2fNPL7E9TiB5EepBPymY7B0DGOQxzbgPF1XPhf19jEAhwhLLsDpD+L/M9FkEM4y6DecQ6QeW8dRLRzTzqHCz0xpdHZRTWvGQ7hEk= Received: by 10.142.194.1 with SMTP id r1mr2803404wff.1191802557379; Sun, 07 Oct 2007 17:15:57 -0700 (PDT) Received: by 10.142.87.14 with HTTP; Sun, 7 Oct 2007 17:15:57 -0700 (PDT) Message-ID: <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> Date: Mon, 8 Oct 2007 10:15:57 +1000 From: "Andrew Cunningham" To: "Addison Phillips" Subject: Re: [Ltru] Extended language tags (long reply) In-Reply-To: <4709146F.6020504@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4709146F.6020504@yahoo-inc.com> 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 On 08/10/2007, Addison Phillips wrote: > > So, for me, the main issue is whether we are going to explicitly break > the connection between the language and its macrolanguage (at the tag > level). In some cases (Norwegian) we already know this can be > problematic; in others, it may actually be desirable. > It probably comes down to philosophical differences. So, cutting to the chase, which way forward? Andrew _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 07 20:41:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iegg6-0001NH-0h; Sun, 07 Oct 2007 20:40:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iegg5-0001Lt-2e for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 20:40:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iegg4-00017s-Jb for ltru@ietf.org; Sun, 07 Oct 2007 20:40:56 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iegfk-0003vF-0w for ltru@ietf.org; Sun, 07 Oct 2007 20:40:36 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2044584wah for ; Sun, 07 Oct 2007 17:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=14xc1WwT6a3yQfJJrU4fb63cutyVoZlFsSsK5vzhi/o=; b=Cjm+iR9cgXlSuulqEGUga2dA90ZdKLa1RsL24wuNsUWeyvHmHenaokgfEUIJttOuaKrDj165KWGC0SmE/QgaNr+3ZMLMUc8YrMx378Hp4NEeAWa96GBttQXecMJpee4fpwN/2g2cGjBqnGVbtDI1CjHXp+ycHmv6xNhLcKfL5xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=b5Ei7cGN2sTYPZhzUKskVE39Fr4YpRCCGslz4R87HRZTKPyjRGq3eLmkzc6Aeu+LdF8fIANZmdFPqfpX/1v60jUX9ob6NOxrGb3XfYQezNm/CAn8jrBG58/XFzXQSWOt3icAmb70eZLR+j7bPc2caPbLKcp4gI8YIXXvIMRyy68= Received: by 10.114.36.1 with SMTP id j1mr610519waj.1191804033165; Sun, 07 Oct 2007 17:40:33 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Sun, 7 Oct 2007 17:40:33 -0700 (PDT) Message-ID: <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> Date: Sun, 7 Oct 2007 17:40:33 -0700 From: "Mark Davis" To: "Andrew Cunningham" Subject: Re: [Ltru] Extended language tags (long reply) In-Reply-To: <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> MIME-Version: 1.0 References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> X-Google-Sender-Auth: 370817fa5daa7689 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="===============0295028440==" Errors-To: ltru-bounces@ietf.org --===============0295028440== Content-Type: multipart/alternative; boundary="----=_Part_43331_5609204.1191804033162" ------=_Part_43331_5609204.1191804033162 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think what might help is for us to draw up in detail what the matching algorithms (changes to 4747) would be like in either of the two proposals, and look at what happens with different cases 'ar', 'zh', 'no', and others. Mark On 10/7/07, Andrew Cunningham wrote: > > On 08/10/2007, Addison Phillips wrote: > > > > > So, for me, the main issue is whether we are going to explicitly break > > the connection between the language and its macrolanguage (at the tag > > level). In some cases (Norwegian) we already know this can be > > problematic; in others, it may actually be desirable. > > > > It probably comes down to philosophical differences. > > So, cutting to the chase, which way forward? > > Andrew > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_43331_5609204.1191804033162 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think what might help is for us to draw up in detail what the matching algorithms (changes to 4747) would be like in either of the two proposals, and look at what happens with different cases 'ar', 'zh', 'no', and others.

Mark

On 10/7/07, Andrew Cunningham <lang.support@gmail.com> wrote:
On 08/10/2007, Addison Phillips <addison@yahoo-inc.com> wrote:

>
> So, for me, the main issue is whether we are going to explicitly break
> the connection between the language and its macrolanguage (at the tag
> level). In some cases (Norwegian) we already know this can be
> problematic; in others, it may actually be desirable.
>

It probably comes down to philosophical differences.

So, cutting to the chase, which way forward?

Andrew


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



--
Mark ------=_Part_43331_5609204.1191804033162-- --===============0295028440== 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 --===============0295028440==-- From ltru-bounces@ietf.org Sun Oct 07 23:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IejL6-0001YA-Lp; Sun, 07 Oct 2007 23:31:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IejL5-0001Y3-Op for ltru-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 23:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IejL5-0001Ux-FA for ltru@ietf.org; Sun, 07 Oct 2007 23:31:27 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IejKv-0000g4-6S for ltru@ietf.org; Sun, 07 Oct 2007 23:31:23 -0400 Received: from [10.72.77.22] (snvvpn2-10-72-77-c22.corp.yahoo.com [10.72.77.22]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l983TbgW007748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2007 20:29:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=PnOZcm4UA5UbVLlX6pn3Ghi0tcmeSATc3lO71GSlXboe6h12Lo4beNvXGfKsxkVU Message-ID: <4709A420.80508@yahoo-inc.com> Date: Sun, 07 Oct 2007 20:29:36 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Extended language tags (long reply) References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> In-Reply-To: <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 would say: 1. With Extlangs. - change to filtering: none, but you probably want to use extended filtering instead of basic filtering (i.e. "zh-Hant-HK" matches "zh-yue-Hant-HK" and "zh-cmn-Hant-HK") - change to lookup: treat extlang as atomic with the primary language subtag; potentially loop-back through the subtags. That is, given the range "zh-yue-Hant-HK", the fallback pattern is this: zh-yue-Hant-HK zh-yue-Hant zh-yue zh-Hant-HK zh-Hant zh (default) Or this: zh-yue-Hant-HK zh-yue-Hant zh-yue (default) 2. Without extlangs. - change to filtering: none - change to lookup: none BUT... you want to include the macro language in your ranges in some cases. Alternatively, we would have to define new filtering and lookup options that include mapping to macrolanguages. For example, with the range "yue-Hant-HK", you would want the fallback to be: yue-Hant-HK yue-Hant yue zh-Hant-HK zh-Hant zh (default) This can be achieved either by having the language priority list "yue-Hant-HK;zh-Hant-HK" or by inferring it using registry data about macro languages. A similar case can be made for filtering. Addison Mark Davis wrote: > I think what might help is for us to draw up in detail what the matching > algorithms (changes to 4747) would be like in either of the two > proposals, and look at what happens with different cases 'ar', 'zh', > 'no', and others. > > Mark > > On 10/7/07, *Andrew Cunningham* > wrote: > > On 08/10/2007, Addison Phillips > wrote: > > > > > So, for me, the main issue is whether we are going to explicitly > break > > the connection between the language and its macrolanguage (at the > tag > > level). In some cases (Norwegian) we already know this can be > > problematic; in others, it may actually be desirable. > > > > It probably comes down to philosophical differences. > > So, cutting to the chase, which way forward? > > Andrew > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > Mark -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 08 03:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IenHC-0003cW-I2; Mon, 08 Oct 2007 03:43:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IenH7-0003Sy-IX for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 03:43:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IenH1-0002ns-Sw for ltru@ietf.org; Mon, 08 Oct 2007 03:43:31 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IenH1-0004tK-GD for ltru@ietf.org; Mon, 08 Oct 2007 03:43:31 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Mon, 8 Oct 2007 00:43:30 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 8 Oct 2007 00:43:30 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Mon, 8 Oct 2007 00:43:27 -0700 Subject: RE: [Ltru] Extended language tags Thread-Topic: [Ltru] Extended language tags Thread-Index: AcgJBRZ8inmjendOR+G09XbAlg1COAAdZQBw Message-ID: References: <20071005032151.GG27520@mercury.ccil.org> <47091337.705@yahoo-inc.com> In-Reply-To: <47091337.705@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0287011134==" Errors-To: ltru-bounces@ietf.org --===============0287011134== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQWRkaXNvbiBQaGlsbGlwcyBbbWFpbHRvOmFkZGlzb25AeWFob28taW5jLmNvbV0NCg0K PiBMZXQgbWUgcmVwaHJhc2UgTWFyaydzIEJyZXRvbiBjYXNlOiB3aGVuIHlvdSB3YW50IENoaXBw ZXdhLCBhbnkgb2xkDQo+IE9qaWJ3YSAoaXRzIG1hY3JvbGFuZ3VhZ2UpIC0tIHdoaWNoIG1pZ2h0 IGJlIGEgbGFuZ3VhZ2Ugc3VjaCBhcyBPdHRhd2ENCj4gLS0gd2lsbCBub3QgZG8uLi4NCg0KPiBX aGVuIGNvbnNpZGVyZWQgbGlrZSB0aGlzLCB0aGUgQnJldG9uIHZzLiBGcmVuY2ggZXhhbXBsZSBp cyBtb3JlIHVzZWZ1bC4NCj4gT3RoZXJ3aXNlIGl0IGlzIHBvaW50bGVzcy4NCg0KV2VsbCwgd2hh dCB0aGlzIHBvaW50cyBvdXQgaXMgdGhhdCB0aGUgbWFjcm9sYW5ndWFnZSBjYXNlcyBhcmUgbm90 IGFsbCBjb21wYXJhYmxlLg0KDQotIFNvbWUgYXJlIGxpa2UgQ2hpbmVzZSBpbiBoYXZpbmcgb25l IGVuY29tcGFzc2VkIGxhbmd1YWdlIChJJ2xsIGNhbGwgdGhpcyB0aGUgTWFqb3IgTGFuZ3VhZ2Ug VmFyaWV0eSAtIE1MVikgdGhhdCBpcyBxdWl0ZSBkZXZlbG9wZWQgYW5kIHByb2JhYmx5IGludGVs bGlnaWJsZSB0byBhIGNvbnNpZGVyYWJsZSBleHRlbnQgdG8gc3BlYWtlcnMgb2YgYWxsIHRoZSBl bmNvbXBhc3NlZCBsYW5ndWFnZXMuDQoNCi0gU29tZSBhcmUgbGlrZSBPamlid2EgaW4gbm90IGhh dmluZyBvbmUgc3VjaCBNTFYgYW1vbmcgdGhlIGVuY29tcGFzc2VkIGxhbmd1YWdlcy4NCg0KRm9y IHB1cnBvc2VzIG9mIGxvb2t1cCwgdGhlIE1MViBvZiB0aGUgZm9ybWVyIGNhc2VzIG1heSB3ZWxs IGJlIGFuIGFjY2VwdGFibGUgZmFsbGJhY2sgZm9yIHRoZSBvdGhlciBlbmNvbXBhc3NlZCBsYW5n dWFnZXMuIEJ1dCBpbiB0aGUgbGF0dGVyIGNhc2VzLCB0aGVyZSBpcyBubyBNTFYsIGFuZCBub25l IG9mIHRoZSBlbmNvbXBhc3NlZCBsYW5ndWFnZXMgaXMgbGlrZWx5IHRvIGJlIGFuIGFjY2VwdGFi bGUgZmFsbGJhY2sgaW4gZ2VuZXJhbC4NCg0KRm9yIHB1cnBvc2VzIG9mIGZpbHRlcmluZywgaWYg dGhlIHJlY29yZHMgYXJlIGFsbCB0YWdnZWQgc3BlY2lmaWNhbGx5IChNYW5kYXJpbiwgWXVlLCBl dGMuIGluc3RlYWQgb2YganVzdCAiemgiOyAiT3R0YXdhLCBDaGlwcGV3YSwgZXRjLiBpbnN0ZWFk IG9mIGp1c3QgIm9qaSIpLCB0aGVuIGEgdXNlciBjYW4gYWx3YXlzIGdldCB3aGF0IHRoZXkgd2Fu dCAtLSBuYXJyb3cgb3Igc3BlY2lmYy4gQnV0LCBvZiBjb3Vyc2UsIHJlY29yZHMgYXJlbid0IGFs d2F5cyBnb2luZyB0byBiZSB0YWdnZWQgc3BlY2lmaWNhbGx5LCBzbyBsZXQncyBjb25zaWRlciB0 aG9zZSBzY2VuYXJpb3MuIEluIHRoZSBPamlid2EtdHlwZSBjYXNlcywgcmVzdWx0cyB1c2luZyAi b2ppIiBhcyBsYW5ndWFnZS1yYW5nZSB3aWxsIGxpa2VseSBiZSBjb21wYXJhYmx5IGdvb2QgKG9y IGJhZCkgZm9yIENoaXBwZXdhIGFzIGZvciBPdHRhd2EgKG9yIGV0Yy4pLiBJbiB0aGUgQ2hpbmVz ZS10eXBlIGNhc2VzLCByZXN1bHRzIHVzaW5nICJ6aCIgYXMgbGFuZ3VhZ2UtcmFuZ2UgYXJlIGxp a2VseSB0byBiZSB3ZWlnaHRlZCBpbiBmYXZvdXIgb2YgTWFuZGFyaW4gdmVyc3VzIFl1ZSwgZXRj Lg0KDQoNCkkgaGF2ZW4ndCB0aG91Z2h0IHlldCBob3cgdGhpcyBhbGwgcmVsYXRlcyB0byB0aGUg aXNzdWUgb2YgeHh4LXl5eSB2cy4geXl5Lg0KDQoNClBldGVyDQo= --===============0287011134== 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 --===============0287011134==-- From ltru-bounces@ietf.org Mon Oct 08 04:11:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieni1-00022i-61; Mon, 08 Oct 2007 04:11:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ienhx-00020T-C9 for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 04:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ienhx-00020L-2b for ltru@ietf.org; Mon, 08 Oct 2007 04:11: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 1Ienhq-0006X4-Ss for ltru@ietf.org; Mon, 08 Oct 2007 04:11:21 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Mon, 8 Oct 2007 01:10:49 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Mon, 8 Oct 2007 01:10:49 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Mon, 8 Oct 2007 01:10:46 -0700 Subject: RE: [Ltru] Extended language tags (long reply) Thread-Topic: [Ltru] Extended language tags (long reply) Thread-Index: AcgJBd6re/PWL41zRi+R3x6tSDyWugAeolNg Message-ID: References: <4709146F.6020504@yahoo-inc.com> In-Reply-To: <4709146F.6020504@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 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: , Content-Type: multipart/mixed; boundary="===============2013441931==" Errors-To: ltru-bounces@ietf.org --===============2013441931== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQWRkaXNvbiBQaGlsbGlwcyBbbWFpbHRvOmFkZGlzb25AeWFob28taW5jLmNvbV0NCg0K Pj4gICAgICAgICAqIEkgZG9uJ3QgdGhpbmsgdGhlIEJyZXRvbiBleGFtcGxlIGFwcGxpZXMuLi4N Cg0KPiBJIGFncmVlIHRoYXQgdGhpcyBmYWxsYmFjayBjYXNlIGlzIHZhbGlkIGFzIGEgdXNlLWNh c2UgZm9yIGxhbmd1YWdlDQo+IHByaW9yaXR5IGxpc3RzLCBidXQgbm90IGZvciBsYW5ndWFnZSB0 YWdzLiBCdXQgSSB0aGluayB0aGlzIG1pc3NlcyB0aGUNCj4gcG9pbnQuIEl0IGlzIHF1b3RlZCB3 aXRob3V0IE1hcmsncyBwcmVhbWJsZSwgaW4gd2hpY2ggaGUgcG9zaXRzIEJyZXRvbg0KPiBhcyBh IHN1Ymxhbmd1YWdlIG9mIFdlbHNoLiBNYXJrIGlzIHVzaW5nIGl0IG1vcmUgYXMgYSBwYXJhYmxl IHRvDQo+IGlsbHVzdHJhdGUgdGhlIGV4dGxhbmcgY2FzZSwgbm90IGFzIGFuIGV4YW1wbGUtaW4t ZmFjdC4NCj4NCj4gTGV0IG1lIHJlcGhyYXNlIE1hcmsncyBCcmV0b24gY2FzZTogd2hlbiB5b3Ug d2FudCBDaGlwcGV3YSwgYW55IG9sZA0KPiBPamlid2EgKGl0cyBtYWNyb2xhbmd1YWdlKSwgd2hp Y2ggbWlnaHQgYmUgYSBsYW5ndWFnZSBzdWNoIGFzIE90dGF3YSwNCj4gd2lsbCBub3QgZG8uDQoN CkluIHRoYXQgY2FzZSwgeW91ciBsYW5ndWFnZS1yYW5nZSB3b3VsZCBiZSAiKG9qaS0pY2l3Ijsg cmVzb3VyY2VzIG1pZ2h0IGJlIHRhZ2dlZCAib2ppIiBvciAiKG9qaS0pY2l3Ii4gVGhlIHJlcXVl c3Qgc2hvdWxkIG1hdGNoICIob2ppLSljaXciIGlmIGF2YWlsYWxlOyBvdGhlcndpc2UsICJvamki IG1heSBiZSBtYXRjaGVkIC0tIHdoaWNoIG1heSBvciBtYXkgbm90IGJlIGFjY2VwdGFibGUuDQoN CkJ1dCBub3RlOiB5b3UgZ2V0IHRoZSBwb3RlbnRpYWwgb2YgYW4gdW5hY2NlcHRhYmxlIHJlc3Vs dCB3aGV0aGVyICJvamktY2l3IiBpcyB1c2VkIG9yICJjaXciIGlzIHVzZWQgYW5kIHRoZSBhc3Nv Y2lhdGlvbiBiZXR3ZWVuIHRoaXMgYW4gIm9qaSIgaXMgcmVjb3JkZWQgaW4gdGhlIHJlZ2lzdHJ5 LiBFaXRoZXIgd2F5LCBhIGNvbm5lY3Rpb24gaXMgbWFkZSBiZXR3ZWVuIG1hY3JvbGFuZ3VhZ2Ug YW5kIGVuY29tcGFzc2VkIGxhbmd1YWdlIC0tIHdoZXRoZXIgaW4gdGhlIHRhZyBvciBpbiB0aGUg cmVnaXN0cnkuDQoNClRoZSBjbGFpbSBpcyB2YWxpZCB0aGF0IChpKSBzb21lIG1hY3JvbGFuZ3Vh Z2VzIGhhdmUgTUxWcyB3aGlsZSBvdGhlcnMgZG8gbm90LCBhbmQgKGlpKSB0aGF0IGEgbG9va3Vw IG1hdGNoIGluIHRoZSBsYXR0ZXIgY2FzZXMgYSBsb29rdXAgbWF0Y2ggdXNpbmcgdGhlIG1hY3Jv bGFuZ3VhZ2UgY291bGQgcmVzdWx0IGluIGFuIHVuYWNjZXB0YWJsZSAvIHVuaW50ZWxsaWdpYmxl Lg0KDQoqQnV0KiwgdGhlc2UgZmFjdHMgZG8gbm90IGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGUg ZXh0bGFuZyB2cy4gbWFjcm9sYW5ndWFnZSBmaWVsZCBwcm9wb3NhbHMuDQoNCg0KUGV0ZXINCg== --===============2013441931== 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 --===============2013441931==-- From ltru-bounces@ietf.org Mon Oct 08 07:11:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeqVQ-0005Mc-7s; Mon, 08 Oct 2007 07:10:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IeqVO-0005G1-UC for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 07:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeqVO-0005EH-Jh for ltru@lists.ietf.org; Mon, 08 Oct 2007 07:10: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 1IeqVG-0002iz-CS for ltru@lists.ietf.org; Mon, 08 Oct 2007 07:10:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IeqUi-0005Pf-2o for ltru@lists.ietf.org; Mon, 08 Oct 2007 11:09:52 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 11:09:52 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 11:09:52 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Mon, 8 Oct 2007 13:06:55 +0200 Lines: 10 Message-ID: References: <001701c80609$ee5cf180$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: Clarifying Suppress-Script X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: =20 > Thoughts? Wrt 639-2 languages I agree with what Ira, Mark, and Martin wrote. For the new 639-3 languages I see the logistical review problem, but I don't think that your "date-A cutoff" proposal is a good solution. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 08 10:15:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetO1-0002oA-MA; Mon, 08 Oct 2007 10:15:09 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IetO0-0002nS-MX for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 10:15:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetO0-0002nJ-5z for ltru@ietf.org; Mon, 08 Oct 2007 10:15:08 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IetNu-0000Yg-08 for ltru@ietf.org; Mon, 08 Oct 2007 10:15:08 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 839DF1C0120 for ; Mon, 8 Oct 2007 16:14:58 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7FB141C011C for ; Mon, 8 Oct 2007 16:14:58 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7CD1758ECCE for ; Mon, 8 Oct 2007 16:14:58 +0200 (CEST) Date: Mon, 8 Oct 2007 16:14:58 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20071008141458.GA535@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-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: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] Small and embarassing discovery of today X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org There have been many discussions here about the matching of language tags by applications and wether an application asked about 'oc-prv' will find texts tagged with 'prv' if 'prv' is an extlang of the macro-language 'oc'. Several opinions expressed here have assumed that all authors have read the RFC before coding, that all applications are carefully written and well tested. This may be true of big and visible applications like major Web browsers. But there are also a lof of small and hastily written applications that are less important but more numerous. I just discovered a bug into an application I wrote (so I cannot put the blame on a co-worker). Written in Python, a test said: language = string.lower(tree.attrib.get('{http://www.w3.org/XML/1998/namespace}lang')) if language != 'fr': # Specific rules for French texts And the application failed to detect a 'fr-CA' text. [For the record, the correct form should have been: if language[0:1] != 'fr': ] The moral? We should IMHO, stick with very simple rules because most applications will not implement the complicated ones, anyway. A similar case in the IETF is IPv6. My experience with IPv6 deployment is that, yes, big and visible applications like the Linux kernel have a working IPv6 support. But most of the software ecosystem (firewalls generators, log parsers, even Palm Pilot IP address calculators) still do not. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 08 10:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetPI-00041Y-Nj; Mon, 08 Oct 2007 10:16:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IetPH-0003zW-6V for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 10:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetPG-0003zO-TD for ltru@ietf.org; Mon, 08 Oct 2007 10:16:26 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IetPA-0000b6-OB for ltru@ietf.org; Mon, 08 Oct 2007 10:16:26 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IetP1-0001rT-7E; Mon, 08 Oct 2007 10:16:11 -0400 Date: Mon, 8 Oct 2007 10:16:11 -0400 To: Addison Phillips Subject: Re: [Ltru] Extended language tags (long reply) Message-ID: <20071008141611.GA5976@mercury.ccil.org> References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4709A420.80508@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: > zh-yue-Hant-HK > zh-yue-Hant > zh-yue > zh-Hant-HK > zh-Hant > zh > (default) This is equivalent to what I proposed: the matching engine should note that "zh-yue-Hant-HK" has an extlang, and add "zh-Hant-HK" to the list of language ranges immediately after it. > yue-Hant-HK > yue-Hant > yue > zh-Hant-HK > zh-Hant > zh > (default) This likewise is equivalent: if "yue-Hant-HK" is in the list, add "zh-Hant-HK" after it. -- Even the best of friends cannot John Cowan attend each others' funeral. cowan@ccil.org --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 08 11:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieura-0000Os-3d; Mon, 08 Oct 2007 11:49:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IeurZ-0000Om-Df for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 11:49:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeurZ-0000NQ-3U for ltru@ietf.org; Mon, 08 Oct 2007 11:49:45 -0400 Received: from mail14.svc.cra.dublin.eircom.net ([159.134.118.30]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IeurW-0004V4-MC for ltru@ietf.org; Mon, 08 Oct 2007 11:49:42 -0400 Received: (qmail 81855 messnum 6168478 invoked from network[194.125.174.20/ts09-020.dublin.indigo.ie]); 8 Oct 2007 15:49:39 -0000 Received: from ts09-020.dublin.indigo.ie (HELO ?194.125.174.20?) (194.125.174.20) by mail14.svc.cra.dublin.eircom.net (qp 81855) with SMTP; 8 Oct 2007 15:49:39 -0000 In-Reply-To: <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <722C6D2C-2EDD-4EE2-A91E-C5D22F743CD4@egt.ie> Content-Transfer-Encoding: quoted-printable From: Marion Gunn Subject: Re: [Ltru] Extended language tags (long reply) Date: Mon, 8 Oct 2007 16:49:10 +0000 To: Andrew Cunningham X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Short answer to a short question - go for language groups (tag =20 languages in groups which make sense and require little or no =20 explaining), rather than inventing confusing concepts and naming them =20= "extlang", "macrolanguage", which, at least to date, seem to beg more =20= questions than they can answer. mg On 8 Oct 2007, at 00:15, scr=EDobh Andrew Cunningham: > On 08/10/2007, Addison Phillips wrote: >> >> So, for me, the main issue is whether we are going to explicitly =20 >> break >> the connection between the language and its macrolanguage (at the tag >> level). In some cases (Norwegian) we already know this can be >> problematic; in others, it may actually be desirable. >> > > It probably comes down to philosophical differences. > > So, cutting to the chase, which way forward? > > Andrew - - 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 08 11:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieutj-0003d6-TM; Mon, 08 Oct 2007 11:52:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ieutj-0003bh-K7 for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 11:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieutj-0003Zl-9u for ltru@ietf.org; Mon, 08 Oct 2007 11:51:59 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieutd-00032P-VZ for ltru@ietf.org; Mon, 08 Oct 2007 11:51:59 -0400 Received: from [10.72.73.98] (snvvpn1-10-72-73-c98.corp.yahoo.com [10.72.73.98]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l98Fp76C038781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2007 08:51:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=lurE0+ayXW3tUq8RqmPnZWAzw2zgjeeWV6aX0/mJRV7LRI8DIhosARV0pTmqyQEM Message-ID: <470A51EA.9070709@yahoo-inc.com> Date: Mon, 08 Oct 2007 08:51:06 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Extended language tags (long reply) References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> <20071008141611.GA5976@mercury.ccil.org> In-Reply-To: <20071008141611.GA5976@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> zh-yue-Hant-HK >> zh-yue-Hant >> zh-yue >> zh-Hant-HK >> zh-Hant >> zh >> (default) > > This is equivalent to what I proposed: the matching engine should note > that "zh-yue-Hant-HK" has an extlang, and add "zh-Hant-HK" to the list > of language ranges immediately after it. > >> yue-Hant-HK >> yue-Hant >> yue >> zh-Hant-HK >> zh-Hant >> zh >> (default) > > This likewise is equivalent: if "yue-Hant-HK" is in the list, add > "zh-Hant-HK" after it. > They are equivalent *functionally*, but not equivalent in some other important ways. Notably: the first version uses only information embedded in the tags themselves. The second requires the registry. The first version requires code changes in the lookup algorithm. The second requires changes to the user's language priority list. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 08 11:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iev05-0007wG-9Q; Mon, 08 Oct 2007 11:58:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iev03-0007w5-VQ for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 11:58:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iev03-0007vw-LM for ltru@ietf.org; Mon, 08 Oct 2007 11:58:31 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iev03-0004l0-C2 for ltru@ietf.org; Mon, 08 Oct 2007 11:58:31 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ieuzv-0000VX-MB; Mon, 08 Oct 2007 11:58:23 -0400 Date: Mon, 8 Oct 2007 11:58:23 -0400 To: Addison Phillips Subject: Re: [Ltru] Extended language tags (long reply) Message-ID: <20071008155823.GE5976@mercury.ccil.org> References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> <20071008141611.GA5976@mercury.ccil.org> <470A51EA.9070709@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470A51EA.9070709@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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: > They are equivalent *functionally*, but not equivalent in some other > important ways. Notably: the first version uses only information > embedded in the tags themselves. The second requires the registry. The > first version requires code changes in the lookup algorithm. The second > requires changes to the user's language priority list. Sorry, I cut too much context. I was saying that extending the user's priority list is equivalent to making changes to the actual algorithms, and is less intrusive, because if an older implementation does not provide this extension, the user can do so instead. This is so under either the extlang or the no-extlang scheme. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 08 15:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iey1X-00085O-1F; Mon, 08 Oct 2007 15:12:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iey1U-00083F-TE for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 15:12:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iey1T-000835-Cu for ltru@ietf.org; Mon, 08 Oct 2007 15:12:12 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iey1T-0003s8-3C for ltru@ietf.org; Mon, 08 Oct 2007 15:12:11 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EEAAC24080E; Mon, 8 Oct 2007 20:12:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 31F74116F9; Mon, 8 Oct 2007 21:10:50 +0200 (CEST) Date: Mon, 8 Oct 2007 21:10:50 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20071008191049.GA12019@sources.org> References: <20071008141458.GA535@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071008141458.GA535@nic.fr> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] Re: Small and embarassing discovery of today X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 08, 2007 at 04:14:58PM +0200, Stephane Bortzmeyer wrote a message of 40 lines which said: > [For the record, the correct form should have been: > if language[0:1] != 'fr': > ] Ooops, as noted by Addison Phillips, this should be: if language[0:2] != "fr-": Otherwise, language tag 'frr' (northern frisian) would match :-( Shame on me. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 08 20:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If2qu-0002vK-HY; Mon, 08 Oct 2007 20:21:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If2qt-0002q6-AV for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 20:21:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If2qt-0002iv-04 for ltru@ietf.org; Mon, 08 Oct 2007 20:21:35 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If2qn-0003qw-Jk for ltru@ietf.org; Mon, 08 Oct 2007 20:21:29 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20071009002128.DZCJ6229.mta16.adelphia.net@DGBP7M81> for ; Mon, 8 Oct 2007 20:21:28 -0400 Message-ID: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 8 Oct 2007 17:21: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Summary of 2007-10-03 teleconference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 we bake it in, then every simple algorithm will in practice > automatically fall back from Cantonese to Mandarin, fall back from > Dari to Persian, fall back from Khetrani to Lahnda -- and in doing so, > strip the script and country information. As I've said countless times before: If we're going to assume that simple, remove-from-right algorithms are the order of the day, then we are wasting our time and everyone else's by contemplating an update to RFC 4647. -- 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 08 20:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3CR-0001Ya-OR; Mon, 08 Oct 2007 20:43:51 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If3CP-0001Tr-U1 for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 20:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3CP-0001G9-HO for ltru@ietf.org; Mon, 08 Oct 2007 20:43:49 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If3C9-0001Xt-6b for ltru@ietf.org; Mon, 08 Oct 2007 20:43:39 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2586766wah for ; Mon, 08 Oct 2007 17:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=oXVHt3HW9SRzF22/u++m9SX3qHPpO8XSxWu/V+Pou5E=; b=VM3s+h52joRaxvxU7OLCkFdeCVWxyk3XAf9twVqPQPE2WOq37CbVCbFHjpuXxWbTA5J8EiHqGmMQMozCIdBfa68f+Gtl0+/aMVC0XrRsxxOj9pWbZ0VFR6FTnsQ9zm8+nhBHZYfBNPg8vXPCxl5q1gt2ipbg9CCwNpIOWNG3Ii8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=J7KRG8cubnemuLRqXXtILCfbiEvFbWTNzAV7el6Hg1zRnoJDM8Icl+GSJquo4OD/pIRr0I9Oer9a9VOPzwx8/5CNCiAcl7PyRvuwMYyvNdaJVmNVY0Lu1bN+JaaUkg5DfiyOoPzqRQDP3okit5ejogccI3zwaTPKJNKJ3jP+VUQ= Received: by 10.114.196.1 with SMTP id t1mr6300344waf.1191890600355; Mon, 08 Oct 2007 17:43:20 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Mon, 8 Oct 2007 17:43:20 -0700 (PDT) Message-ID: <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> Date: Mon, 8 Oct 2007 17:43:20 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference In-Reply-To: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> MIME-Version: 1.0 References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> X-Google-Sender-Auth: 167fc5ca0cd20016 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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="===============0909035084==" Errors-To: ltru-bounces@ietf.org --===============0909035084== Content-Type: multipart/alternative; boundary="----=_Part_2219_11466670.1191890600350" ------=_Part_2219_11466670.1191890600350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline There is reason to look at how the two different macrolanguage models in affect 4647. If the primary reason cited for the extlang model is compatibility, then we have to see what effects each model has on commonly used matching functions, which is where the rubber hits the road. Mark On 10/8/07, Doug Ewell wrote: > > Mark Davis wrote: > > > If we bake it in, then every simple algorithm will in practice > > automatically fall back from Cantonese to Mandarin, fall back from > > Dari to Persian, fall back from Khetrani to Lahnda -- and in doing so, > > strip the script and country information. > > As I've said countless times before: If we're going to assume that > simple, remove-from-right algorithms are the order of the day, then we > are wasting our time and everyone else's by contemplating an update to > RFC 4647. > > -- > 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 > -- Mark ------=_Part_2219_11466670.1191890600350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline There is reason to look at how the two different macrolanguage models in affect 4647. If the primary reason cited for the extlang model is compatibility, then we have to see what effects each model has on commonly used matching functions, which is where the rubber hits the road.

Mark

On 10/8/07, Doug Ewell <dewell@roadrunner.com> wrote:
Mark Davis <mark dot davis at icu dash project dot org> wrote:

> If we bake it in, then every simple algorithm will in practice
> automatically fall back from Cantonese to Mandarin, fall back from
> Dari to Persian, fall back from Khetrani to Lahnda -- and in doing so,
> strip the script and country information.

As I've said countless times before:  If we're going to assume that
simple, remove-from-right algorithms are the order of the day, then we
are wasting our time and everyone else's by contemplating an update to
RFC 4647.

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



--
Mark ------=_Part_2219_11466670.1191890600350-- --===============0909035084== 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 --===============0909035084==-- From ltru-bounces@ietf.org Mon Oct 08 20:52:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3Ke-0000EF-AX; Mon, 08 Oct 2007 20:52:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If3Kd-0000E7-68 for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 20:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3Kc-0000CM-Sq for ltru@ietf.org; Mon, 08 Oct 2007 20:52:18 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If3KP-0001kH-Be for ltru@ietf.org; Mon, 08 Oct 2007 20:52:14 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20071009005134.GIFA6229.mta16.adelphia.net@DGBP7M81> for ; Mon, 8 Oct 2007 20:51:34 -0400 Message-ID: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 8 Oct 2007 17:51:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Re: Extended 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 Shawn Steele wrote: > * Even for the current tags, many of the people in the teleconference > seem to extend RFC 4647 in ways that are best for them. Strict use of > 4647 behavior seems rare. It seems reasonable to me to expect that in > the future people may continue to do so and that RFC 4647 and the > registry can only provide guidelines. I agree with the part about RFC 4647, but not the Registry, at least not in blanket terms. The Registry contains some fields that are normative and some that are informative. For the informative stuff, say Suppress-Script, it's very reasonable to expect that some people will ignore the warnings and write "en-Latn", and all we can do is tell them they shouldn't. But anyone who uses the normative data in a "non-strict" way is tagging incorrectly. This might include things like using "eng" for English (ISO 639-2 code) or "jp" for Japanese (by false analogy with 'JP" for Japan). Shawn probably did not mean what I took his comment to mean. -- 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 08 20:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3QA-00075H-4p; Mon, 08 Oct 2007 20:58:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If3Q9-000759-OM for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 20:58:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3Q9-000751-E8 for ltru@ietf.org; Mon, 08 Oct 2007 20:58:01 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1If3Q9-0004d4-5t for ltru@ietf.org; Mon, 08 Oct 2007 20:58:01 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071009005800.HZMZ660.mta10.adelphia.net@DGBP7M81> for ; Tue, 9 Oct 2007 00:58:00 +0000 Message-ID: <009b01c80a0f$7035f270$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 8 Oct 2007 17:57:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] Re: Extended 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 Randy Presuhn wrote: > At this moment, the discussion seems to favor (1) Hard to say. I think at this moment there are more contributors who favor (1) than (2), but the two main proponents of (2) are the co-editors of 4646bis, which does tip the balance a bit. -- 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 08 21:11:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3d1-0004DX-N9; Mon, 08 Oct 2007 21:11:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If3cz-0004Bv-CD for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 21:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3cz-00044y-1j for ltru@ietf.org; Mon, 08 Oct 2007 21:11:17 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If3cn-0002gb-Kl for ltru@ietf.org; Mon, 08 Oct 2007 21:11:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eqYYoFAvHMnd54n9ztAvTkXp2JUUjR/DDBTph4hBezpzvd6s9YSKQAaTdhDlKBME; 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.189.8] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1If3cX-0000BB-Ra for ltru@ietf.org; Mon, 08 Oct 2007 21:10:50 -0400 Message-ID: <000d01c80a11$cef5dbc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <009b01c80a0f$7035f270$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Extended language tags Date: Mon, 8 Oct 2007 18:14:57 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a7d43008440b46da657ed016dca5a8be0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, October 08, 2007 5:57 PM > Subject: [Ltru] Re: Extended language tags > > Randy Presuhn wrote: > > > At this moment, the discussion seems to favor (1) > > Hard to say. I think at this moment there are more contributors who > favor (1) than (2), but the two main proponents of (2) are the > co-editors of 4646bis, which does tip the balance a bit. ... No, it does not. Editors do the bidding of the WG, see RFC 2418 clause 6.3. As such they are *not* given special consideration in the determination of working group consensus. Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 08 21:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3gZ-0001UZ-8R; Mon, 08 Oct 2007 21:14:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If3gX-0001QX-MQ for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 21:14:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If3gX-0001QK-Cd for ltru@ietf.org; Mon, 08 Oct 2007 21:14:57 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If3gQ-0002sI-T4 for ltru@ietf.org; Mon, 08 Oct 2007 21:14:57 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20071009011431.EEOJ4148.mta15.adelphia.net@DGBP7M81> for ; Mon, 8 Oct 2007 21:14:31 -0400 Message-ID: <00a701c80a11$bed8a510$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 8 Oct 2007 18:14: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: Extended language tags (long reply) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > The question is: do we want to do this for all time? Or can we help > people migrate and just get started on the migration? Yes, retagging > with "yue-HK" is a PITA, but so is retagging with "zh-yue-HK". But retagging from "zh-HK" to "zh-yue-HK" isn't strictly necessary. It's a matter of providing additional information: "This is not just any old Chinese, this is specifically Cantonese." If the new tag is "yue-HK", then it becomes more necessary to retag the data, because no matching algorithm can match "yue-HK" with "zh" unless it has access to (a copy of) 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 Mon Oct 08 22:34:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If4uO-0005Qs-4z; Mon, 08 Oct 2007 22:33:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1If4uN-0005QQ-Fx for ltru-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 22:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If4uN-0005QI-6J for ltru@ietf.org; Mon, 08 Oct 2007 22:33:19 -0400 Received: from smtp1.wsfo.org ([208.145.81.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If4uG-0005GL-UF for ltru@ietf.org; Mon, 08 Oct 2007 22:33:19 -0400 Received: from mail.link77.net (mail.link77.net [172.22.0.125]) by smtp1.wsfo.org (8.13.1/8.13.1) with ESMTP id l992WtGQ025360 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 8 Oct 2007 22:32:55 -0400 X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.72 (ClamAV engine v0.91.2) Received: from [203.150.139.21] (account martin_hosken@sil.org HELO [192.168.1.101]) by mail.link77.net (CommuniGate Pro SMTP 5.1.12) with ESMTPSA id 159321783; Mon, 08 Oct 2007 22:32:54 -0400 Message-ID: <470AE824.1050203@sil.org> Date: Tue, 09 Oct 2007 09:32:04 +0700 From: Martin Hosken User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Small and embarassing discovery of today References: <20071008141458.GA535@nic.fr> <20071008191049.GA12019@sources.org> In-Reply-To: <20071008191049.GA12019@sources.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.62 on 172.22.0.51 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 Dear Stephane, >> [For the record, the correct form should have been: >> if language[0:1] != 'fr': >> ] >> > > Ooops, as noted by Addison Phillips, this should be: > > if language[0:2] != "fr-": > > Shouldn't that be? if language != 'fr' and language[0:2] != 'fr-' : since a tag can just be 'fr'. It gets harder and harder and that's just a simple comparison. And we can't even decide how to advise people to tag text in a language. Guys if we don't know what hope do we have of teaching others? Yours, Martin Hosken _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 04:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfAsi-0007LI-9x; Tue, 09 Oct 2007 04:56:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfAsg-0007ER-JI for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 04:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfAsg-0007CX-7s for ltru@lists.ietf.org; Tue, 09 Oct 2007 04:55: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 1IfAsY-0006wC-0c for ltru@lists.ietf.org; Tue, 09 Oct 2007 04:55:56 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IfArm-0005RW-Jh for ltru@lists.ietf.org; Tue, 09 Oct 2007 08:55:02 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 08:55:02 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 08:55:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Tue, 9 Oct 2007 10:51:12 +0200 Lines: 18 Message-ID: References: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Informative (was: Extended 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 Doug Ewell wrote: =20 > The Registry contains some fields that are normative and some that are = > informative. For the informative stuff, say Suppress-Script, it's = very=20 > reasonable to expect that some people will ignore the warnings and = write=20 > "en-Latn", and all we can do is tell them they shouldn't. No, Suppress-Script is not only "informative", it got some normative SHOULD rules in BCP 47. These rules aren't mandatory / required MUSTard, but still normative. ITYM that the Suppress-Script field isn't guaranteed to be "stable",=20 but it's not "informative" like say Comment or Added. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 05:34:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBTG-0004Px-E5; Tue, 09 Oct 2007 05:33:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfBTF-0004P5-0L for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 05:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBTE-0004Ox-N5 for ltru@ietf.org; Tue, 09 Oct 2007 05:33:44 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfBT9-0008A9-Eg for ltru@ietf.org; Tue, 09 Oct 2007 05:33:44 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 5EAC024080E; Tue, 9 Oct 2007 10:33:13 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id D6070157D25; Tue, 9 Oct 2007 11:28:12 +0200 (CEST) Date: Tue, 9 Oct 2007 11:28:12 +0200 From: Stephane Bortzmeyer To: Martin Hosken Message-ID: <20071009092812.GA11618@laperouse.bortzmeyer.org> References: <20071008141458.GA535@nic.fr> <20071008191049.GA12019@sources.org> <470AE824.1050203@sil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470AE824.1050203@sil.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org Subject: [Ltru] Re: Small and embarassing discovery of today X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 09, 2007 at 09:32:04AM +0700, Martin Hosken wrote a message of 27 lines which said: > Shouldn't that be? > > if language != 'fr' and language[0:2] != 'fr-' : Yes, I'll stop patching this program, I introduce one more bug each time :-( > And we can't even decide how to advise people to tag text in a language. > Guys if we don't know what hope do we have of teaching others? I'm probably not the best programmer on this list, as everyone can see :-( But that was precisely my point. Many programmers are even worse than me and will make similar mistakes. The odds of complicated matching being properly implemented are low, IMHO. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 09:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFPY-0001nM-Kb; Tue, 09 Oct 2007 09:46:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfFPX-0001nG-FW for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 09:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFPX-0001kr-65 for ltru@ietf.org; Tue, 09 Oct 2007 09:46:11 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfFPM-0000FW-1n for ltru@ietf.org; Tue, 09 Oct 2007 09:46:06 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071009134538.JZKY660.mta10.adelphia.net@DGBP7M81> for ; Tue, 9 Oct 2007 13:45:38 +0000 Message-ID: <00f501c80a7a$aca85520$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 9 Oct 2007 06:45: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: Extended 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 Randy Presuhn wrote: >> Hard to say. I think at this moment there are more contributors who >> favor (1) than (2), but the two main proponents of (2) are the >> co-editors of 4646bis, which does tip the balance a bit. > > No, it does not. Editors do the bidding of the WG, see RFC 2418 > clause 6.3. As such they are *not* given special consideration in the > determination of working group consensus. But they might well be given special consideration by other list members who haven't made up their minds yet. I would guess that with the small number of people solidly on one side or the other, the battle for the "undecided" bloc will be important. -- 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 09 09:59:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFbj-0002p9-Ji; Tue, 09 Oct 2007 09:58:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfFbf-0002lI-I7 for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 09:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFbf-0002l3-8X for ltru@ietf.org; Tue, 09 Oct 2007 09:58:43 -0400 Received: from mta5.adelphia.net ([68.168.78.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfFbW-0000eo-44 for ltru@ietf.org; Tue, 09 Oct 2007 09:58:40 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071009135605.OCZN2495.mta13.adelphia.net@DGBP7M81> for ; Tue, 9 Oct 2007 09:56:05 -0400 Message-ID: <00fb01c80a7c$2313c5e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 9 Oct 2007 06:56:05 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Re: Informative (was: Extended 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 Frank Ellermann wrote: >> The Registry contains some fields that are normative and some that >> are informative. For the informative stuff, say Suppress-Script, >> it's very reasonable to expect that some people will ignore the >> warnings and write "en-Latn", and all we can do is tell them they >> shouldn't. > > No, Suppress-Script is not only "informative", it got some normative > SHOULD rules in BCP 47. These rules aren't mandatory / required > MUSTard, but still normative. > > ITYM that the Suppress-Script field isn't guaranteed to be "stable", > but it's not "informative" like say Comment or Added. I must not be a good enough RFC 2119 language lawyer to understand this. I thought MUST was normative, and SHOULD and MAY were non-normative. It's hard for me to see how "the full implications must be understood and carefully weighed," in the RFC 2119 definition of SHOULD, can be applied in a normative sense. I note that RFC 4646 contains a lot of MUSTard, but almost no direct references to fields or behaviors being "normative" or "informative." -- 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 09 10:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfG2n-0004zo-AW; Tue, 09 Oct 2007 10:26:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfG2l-0004zd-JB for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 10:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfG2l-0004zV-76 for ltru@ietf.org; Tue, 09 Oct 2007 10:26:43 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfG2e-0001RN-NL for ltru@ietf.org; Tue, 09 Oct 2007 10:26:43 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IfG2R-0004fN-Pj; Tue, 09 Oct 2007 10:26:23 -0400 Date: Tue, 9 Oct 2007 10:26:23 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Informative (was: Extended language tags) Message-ID: <20071009142623.GD10816@mercury.ccil.org> References: <00fb01c80a7c$2313c5e0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00fb01c80a7c$2313c5e0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I must not be a good enough RFC 2119 language lawyer to understand this. > I thought MUST was normative, and SHOULD and MAY were non-normative. I think that's a misunderstanding of "normative". MUST, SHOULD, and MAY all represent norms, they are just different kinds of norms, about required, recommended, and optional behavior respectively. A statement in an RFC such as "A client MAY provide a CRC-32 checksum" means that it is conformant either to provide the checksum or to omit it; no server may complain in either case of a violation of the protocol. This is normatively defined behavior (or lack of behavior) on the server's part. Informative content, on the other hand, is historical, exemplary, explanatory, or the like. By this standard, the Type, Subtag, Tag, Prefix, Preferred-Value, and Suppress-Script fields are normative; the Description, Added, Deprecated, Comments, and File-Date fields are informative. -- Where the wombat has walked, John Cowan it will inevitably walk again. http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 14:47:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfK6Q-0002eY-7Z; Tue, 09 Oct 2007 14:46:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfK6P-0002eS-JE for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 14:46:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfK6P-0002b5-8O for ltru@ietf.org; Tue, 09 Oct 2007 14:46:45 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfK68-0002hE-Ip for ltru@ietf.org; Tue, 09 Oct 2007 14:46:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mGb54AgiTroYtAvrMhyiu94QDbefPXOcZkJplzG7eTnE93PzskMrdjtPPPhDjnM+; 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.164.80.37] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IfK67-0004zc-Bf for ltru@ietf.org; Tue, 09 Oct 2007 14:46:27 -0400 Message-ID: <005001c80aa5$463c55e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00f501c80a7a$aca85520$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Extended language tags Date: Tue, 9 Oct 2007 11:50:31 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a6c30e9ccee2695393fbf8219aed569e6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.37 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 Hi - As co-chair... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, October 09, 2007 6:45 AM > Subject: [Ltru] Re: Extended language tags > > Randy Presuhn wrote: > > >> Hard to say. I think at this moment there are more contributors who > >> favor (1) than (2), but the two main proponents of (2) are the > >> co-editors of 4646bis, which does tip the balance a bit. > > > > No, it does not. Editors do the bidding of the WG, see RFC 2418 > > clause 6.3. As such they are *not* given special consideration in the > > determination of working group consensus. > > But they might well be given special consideration by other list members > who haven't made up their minds yet. This would be a bad thing. RFC 2418 is abundantly clear that document editors do not enjoy any special privileges in determining WG consensus. Sometimes editors happen to be experts in the topic, sometimes they are not. But if a WG starts giving their voices more weight merely because they happen to be editors, something is seriously wrong. > I would guess that with the small > number of people solidly on one side or the other, the battle for the > "undecided" bloc will be important. Perhaps, though the undecided have little import for a determination of rough consensus. At some point Martin and I will have to make a determination of consensus. It's clear that none of the options will make everyone happy. It's possible that none of the options will make anyone happy in the long run. Since there has been so little in the way of new information or arguments in this discussion, I think Martin and I will just have to pick one, based on the opinions expressed on this list so far, since few new voices seem to be joining in to express a preference. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 14:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKHh-0002SD-PS; Tue, 09 Oct 2007 14:58:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfKHg-0002S2-4K for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 14:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKHf-0002MU-Qx for ltru@ietf.org; Tue, 09 Oct 2007 14:58:23 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfKHP-0008P7-SQ for ltru@ietf.org; Tue, 09 Oct 2007 14:58:13 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=f0skPuVzc8hKxwIzUih1bm7j0Q8p46tf+X5JE0ccg1kT96U+NKcv0XSAFMrwiE+s; 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.164.80.37] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IfKH1-00015p-TF for ltru@ietf.org; Tue, 09 Oct 2007 14:57:44 -0400 Message-ID: <005501c80aa6$d97791c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00fb01c80a7c$2313c5e0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Informative (was: Extended language tags) Date: Tue, 9 Oct 2007 12:01:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a9f133376a4fc3b3e80310c0a48cd0071350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, October 09, 2007 6:56 AM > Subject: [Ltru] Re: Informative (was: Extended language tags) ... > I must not be a good enough RFC 2119 language lawyer to understand this. > I thought MUST was normative, and SHOULD and MAY were non-normative. No. If language is relevant to determining whether an implementation conforms to a specification, it is normative. Specifying something as an option does NOT make it non-normative. In general, "informative" material is stuff that can be removed from a specification without changing any implementation requirements. "SHOULDs" and "MAYs" obviously do not fall into that category - they are normative language. > It's hard for me to see how "the full implications must be understood > and carefully weighed," in the RFC 2119 definition of SHOULD, can be > applied in a normative sense. The fact that a particular feature is OPTIONAL doesn't make that part of the specification "informative". Think snow tires. They may be optional in some areas, but when you do get them, you want them to fit your car's rims and behave as specified. > I note that RFC 4646 contains a lot of MUSTard, but almost no direct > references to fields or behaviors being "normative" or "informative." "informative" material should be used sparingly in a specification, because folks have an unfortunate tendency to confuse an illustration or example with the specification itself. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 15:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKhu-00056V-J0; Tue, 09 Oct 2007 15:25:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfKht-00056O-IU for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 15:25:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKht-00056G-7h for ltru@ietf.org; Tue, 09 Oct 2007 15:25:29 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfKhs-0003oB-99 for ltru@ietf.org; Tue, 09 Oct 2007 15:25:28 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Tue, 9 Oct 2007 12:25:27 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Tue, 9 Oct 2007 12:25:27 -0700 From: Shawn Steele To: Doug Ewell , LTRU Working Group Date: Tue, 9 Oct 2007 12:25:25 -0700 Subject: RE: [Ltru] Re: Extended language tags Thread-Topic: [Ltru] Re: Extended language tags Thread-Index: AcgKDtABtbHoCNogTkKlXKsVXK54mwAmoFJQ Message-ID: References: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> In-Reply-To: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 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="===============0999034549==" Errors-To: ltru-bounces@ietf.org --===============0999034549== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+ID4gKiBFdmVuIGZvciB0aGUgY3VycmVudCB0YWdzLCBtYW55IG9mIHRoZSBwZW9wbGUgaW4g dGhlIHRlbGVjb25mZXJlbmNlDQo+ID4gc2VlbSB0byBleHRlbmQgUkZDIDQ2NDcgaW4gd2F5cyB0 aGF0IGFyZSBiZXN0IGZvciB0aGVtLiAgU3RyaWN0IHVzZSBvZg0KPiA+IDQ2NDcgYmVoYXZpb3Ig c2VlbXMgcmFyZS4gIEl0IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUgdG8gZXhwZWN0IHRoYXQgaW4N Cj4gPiB0aGUgZnV0dXJlIHBlb3BsZSBtYXkgY29udGludWUgdG8gZG8gc28gYW5kIHRoYXQgUkZD IDQ2NDcgYW5kIHRoZQ0KPiA+IHJlZ2lzdHJ5IGNhbiBvbmx5IHByb3ZpZGUgZ3VpZGVsaW5lcy4N Cg0KPiBJIGFncmVlIHdpdGggdGhlIHBhcnQgYWJvdXQgUkZDIDQ2NDcsIGJ1dCBub3QgdGhlIFJl Z2lzdHJ5LCBhdCBsZWFzdCBub3QNCj4gaW4gYmxhbmtldCB0ZXJtcy4NCg0KPiBUaGUgUmVnaXN0 cnkgY29udGFpbnMgc29tZSBmaWVsZHMgdGhhdCBhcmUgbm9ybWF0aXZlIGFuZCBzb21lIHRoYXQg YXJlDQo+IGluZm9ybWF0aXZlLg0KDQpUYWdnaW5nIGFuZCBsb29rdXAgaG93ZXZlciBhcmUgZGlm ZmVyZW50LiAgTWFueSBvZiB0aGUgdXNlcyBJJ20gaW52b2x2ZWQgd2l0aCBwcmVzdW1lIHRoYXQg dGFncyBhcmUgY29ycmVjdGx5IGRlZmluZWQ6ICBpZTogb25seSBpbnN0YWxsZWQgbG9jYWxlcyBh cmUgYWxsb3dlZCB0byBiZSB1c2VkIGZvciByZXNvdXJjZSBuYW1lcywgb3IgZm9yIG1hcmtpbmcg ZG9jdW1lbnRzLiAgUHJlc3VtYWJseSB0aGUgbG9jYWxlcyB3ZXJlIGNyZWF0ZWQgY29ycmVjdGx5 IHdoZW4gdGhleSB3ZXJlIGluc3RhbGxlZCwgc28gSSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0 ICJlbmciIGJlaW5nIHZhbGlkLg0KDQpNYWtpbmcgYSBtYXRjaGluZyBkZXBlbmRlbmN5IG9uIHRo ZSByZWdpc3RyeSB3b3VsZCByZXF1aXJlIGEgbmV3IGRhdGEgc291cmNlLCB3aGljaCBjb3VsZCBi ZSBwcm9ibGVtYXRpYywgd2hpY2ggaXMgd2h5IEkgcHJlZmVyIHRoZSBpbmZvcm1hdGlvbiBiZSBp biB0aGUgdGFncy4gIElmIHRoZSB0YWdzIGFyZSBpbnZhbGlkIEkgd29uJ3QgbWF0Y2ggY29ycmVj dGx5LCBidXQgSSB3b24ndCBoYXZlIHRvIGxvb2sgdXAgYW4gb24tbGluZSBkZXBlbmRlbmN5LiAg T2J2aW91c2x5IHRoaXMgaXMgbGVzcyBvZiBhIHByb2JsZW0gZm9yIHNvbWUgYXBwbGljYXRpb25z LCBidXQgSSBkb24ndCBzZWUgdGhlcmUgYmVpbmcgYW55IGRvd25zaWRlIGFuZCBpdCBkb2VzIGhl bHAgdG8gaGF2ZSB0aGUgZXh0IGxhbmcgdGFnIGluIHRoaXMgY2FzZS4NCg0KLSBTaGF3bg0KDQo= --===============0999034549== 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 --===============0999034549==-- From ltru-bounces@ietf.org Tue Oct 09 15:33:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKpI-0004Iq-BY; Tue, 09 Oct 2007 15:33:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfKpH-0004I4-RR for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 15:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKpH-0004Hw-Hr for ltru@ietf.org; Tue, 09 Oct 2007 15:33:07 -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 1IfKpF-00010V-6A for ltru@ietf.org; Tue, 09 Oct 2007 15:33:07 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Tue, 9 Oct 2007 12:32:55 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Tue, 9 Oct 2007 12:32:55 -0700 From: Shawn Steele To: Addison Phillips , Mark Davis Date: Tue, 9 Oct 2007 12:32:53 -0700 Subject: RE: [Ltru] Extended language tags (long reply) Thread-Topic: [Ltru] Extended language tags (long reply) Thread-Index: AcgJW8qIgpDxR1XVTniue8ZpTAMeYgBTsP6Q Message-ID: References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> In-Reply-To: <4709A420.80508@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 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: , Content-Type: multipart/mixed; boundary="===============0227170418==" Errors-To: ltru-bounces@ietf.org --===============0227170418== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciAxKSAmIDIpIGRvbid0IGhhdmUgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eS4gIElmIHlvdSBk b24ndCBjaGFuZ2UgdGhlIGxvb2t1cCBmb3IgMiksIHRoZW4geW91IGRvbid0IGdldCB0aGUgYmVo YXZpb3IgdGhhdCB5b3VyIGNoYW5nZWQgbG9va3VwIGluIDEpIHByb3ZpZGVkLg0KDQpDaGFuZ2lu ZyBhIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QgaW4gMikgZG9lcyBjb3VudCBhcyBhIGNoYW5nZS4g IFRoaXMgZG9lc24ndCBoZWxwIGEgIm5ldyIgd2ViIGFwcCB0YWxraW5nIHRvIGFuICJvbGQiIGNs aWVudCB0aGF0IGhhc24ndCBiZWVuIHVwZGF0ZWQsIGZvciBleGFtcGxlLiAgSW4gb3JkZXIgdG8g c29sdmUgdGhhdCB5b3UgaGF2ZSB0byBpbmZlciB0aGUgbWF0Y2hpbmcgc3VnZ2VzdGVkLCB3aGlj aCBJIHRoaW5rIGlzIHNpbXBsZXIgd2l0aCAxKS4NCg0KTm90ZSB0aGF0IHlvdXIgc29sdXRpb24g aW4gMikgY291bGQgYmUgdXNlZCBpZiB5b3UgZmVsdCBpdCB3YXMgc2ltcGxlcjogIHpoLXl1ZS1I YW50LUhLO3poLUhhbnQtSEsgY291bGQgYmUgdXNlZCB0byBzb2x2ZSAxKSBhcyB3ZWxsLCBidXQg d2l0aCAxKSB5b3UgaGF2ZSBtb3JlIG9wdGlvbnMuDQoNCi0gU2hhd24NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEFkZGlzb24gUGhpbGxpcHMgW21haWx0bzphZGRpc29uQHlh aG9vLWluYy5jb21dDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMDcsIDIwMDcgODozMCBQTQ0KVG86 IE1hcmsgRGF2aXMNCkNjOiBsdHJ1QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0x0cnVdIEV4dGVu ZGVkIGxhbmd1YWdlIHRhZ3MgKGxvbmcgcmVwbHkpDQoNCkkgd291bGQgc2F5Og0KDQoxLiBXaXRo IEV4dGxhbmdzLg0KDQotIGNoYW5nZSB0byBmaWx0ZXJpbmc6IG5vbmUsIGJ1dCB5b3UgcHJvYmFi bHkgd2FudCB0byB1c2UgZXh0ZW5kZWQNCmZpbHRlcmluZyBpbnN0ZWFkIG9mIGJhc2ljIGZpbHRl cmluZyAoaS5lLiAiemgtSGFudC1ISyIgbWF0Y2hlcw0KInpoLXl1ZS1IYW50LUhLIiBhbmQgInpo LWNtbi1IYW50LUhLIikNCg0KLSBjaGFuZ2UgdG8gbG9va3VwOiB0cmVhdCBleHRsYW5nIGFzIGF0 b21pYyB3aXRoIHRoZSBwcmltYXJ5IGxhbmd1YWdlDQpzdWJ0YWc7IHBvdGVudGlhbGx5IGxvb3At YmFjayB0aHJvdWdoIHRoZSBzdWJ0YWdzLiBUaGF0IGlzLCBnaXZlbiB0aGUNCnJhbmdlICJ6aC15 dWUtSGFudC1ISyIsIHRoZSBmYWxsYmFjayBwYXR0ZXJuIGlzIHRoaXM6DQoNCiAgemgteXVlLUhh bnQtSEsNCiAgemgteXVlLUhhbnQNCiAgemgteXVlDQogIHpoLUhhbnQtSEsNCiAgemgtSGFudA0K ICB6aA0KICAoZGVmYXVsdCkNCg0KT3IgdGhpczoNCg0KICB6aC15dWUtSGFudC1ISw0KICB6aC15 dWUtSGFudA0KICB6aC15dWUNCiAgKGRlZmF1bHQpDQoNCjIuIFdpdGhvdXQgZXh0bGFuZ3MuDQoN Ci0gY2hhbmdlIHRvIGZpbHRlcmluZzogbm9uZQ0KDQotIGNoYW5nZSB0byBsb29rdXA6IG5vbmUN Cg0KQlVULi4uIHlvdSB3YW50IHRvIGluY2x1ZGUgdGhlIG1hY3JvIGxhbmd1YWdlIGluIHlvdXIg cmFuZ2VzIGluIHNvbWUNCmNhc2VzLiBBbHRlcm5hdGl2ZWx5LCB3ZSB3b3VsZCBoYXZlIHRvIGRl ZmluZSBuZXcgZmlsdGVyaW5nIGFuZCBsb29rdXANCm9wdGlvbnMgdGhhdCBpbmNsdWRlIG1hcHBp bmcgdG8gbWFjcm9sYW5ndWFnZXMuIEZvciBleGFtcGxlLCB3aXRoIHRoZQ0KcmFuZ2UgInl1ZS1I YW50LUhLIiwgeW91IHdvdWxkIHdhbnQgdGhlIGZhbGxiYWNrIHRvIGJlOg0KDQogIHl1ZS1IYW50 LUhLDQogIHl1ZS1IYW50DQogIHl1ZQ0KICB6aC1IYW50LUhLDQogIHpoLUhhbnQNCiAgemgNCiAg KGRlZmF1bHQpDQoNClRoaXMgY2FuIGJlIGFjaGlldmVkIGVpdGhlciBieSBoYXZpbmcgdGhlIGxh bmd1YWdlIHByaW9yaXR5IGxpc3QNCiJ5dWUtSGFudC1ISzt6aC1IYW50LUhLIiBvciBieSBpbmZl cnJpbmcgaXQgdXNpbmcgcmVnaXN0cnkgZGF0YSBhYm91dA0KbWFjcm8gbGFuZ3VhZ2VzLg0KDQpB IHNpbWlsYXIgY2FzZSBjYW4gYmUgbWFkZSBmb3IgZmlsdGVyaW5nLg0KDQpBZGRpc29uDQoNCg== --===============0227170418== 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 --===============0227170418==-- From ltru-bounces@ietf.org Tue Oct 09 15:40:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKwQ-0007t5-HY; Tue, 09 Oct 2007 15:40:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfKwP-0007sq-CV for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 15:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfKwO-0007lm-Ry for ltru@ietf.org; Tue, 09 Oct 2007 15:40:28 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfKwI-0001EF-KE for ltru@ietf.org; Tue, 09 Oct 2007 15:40:28 -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.8/8.13.8/y.rout) with ESMTP id l99Jdn1k068148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 12:39: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=XGI7NOMNtPSrzOi2aaxr1MbDM3wCKAVwVLjTgfmXcKqYuCytezvBbFWGXo3R/DCz Message-ID: <470BD905.2070109@yahoo-inc.com> Date: Tue, 09 Oct 2007 12:39:49 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Informative References: <00fb01c80a7c$2313c5e0$6401a8c0@DGBP7M81> <005501c80aa6$d97791c0$6801a8c0@oemcomputer> In-Reply-To: <005501c80aa6$d97791c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > >> I note that RFC 4646 contains a lot of MUSTard, but almost no direct >> references to fields or behaviors being "normative" or "informative." > > "informative" material should be used sparingly in a specification, > because folks have an unfortunate tendency to confuse an illustration > or example with the specification itself. > More to the point: the normative language associated with Suppress-Script in draft-08 of 4646bis is limited to two cases: 1. Directions for the handling of registrations of Suppress-Script and/or its appearance in the registry. 2. (Repeatedly) indicate that its appearance in the registry means that users SHOULD NOT use the associated script with the associated language. At least one counter-example is given. These normative instructions are always directed at the issue of tag choice. That is, there are no conformance criteria for tag processors because that would be inappropriate. This means that it is a normative field. But this normative information does not apply to (for example) conformance criteria for software implementations of RFC 4646/4646bis. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 09 15:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfL5D-0006aU-0F; Tue, 09 Oct 2007 15:49:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfL5B-0006aP-Vc for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 15:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfL5B-0006UK-M9 for ltru@ietf.org; Tue, 09 Oct 2007 15:49:33 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfL50-0001U8-E0 for ltru@ietf.org; Tue, 09 Oct 2007 15:49:23 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l99Jn2J3068972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 12:49:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=eq1bvzLUiwJRoQfeswp5YKN/GF4YmgjqQcbXTcvJP33Lb9yzxqereJRkzLhFMPl/ Message-ID: <470BDB2D.1030409@yahoo-inc.com> Date: Tue, 09 Oct 2007 12:49:01 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shawn Steele Subject: Re: [Ltru] Extended language tags (long reply) References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.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 Shawn Steele wrote: > Your 1) & 2) don't have the same functionality. If you don't change the lookup for 2), > then you don't get the behavior that your changed lookup > in 1) provided. > > Changing a language priority list in 2) does count as a change. Yes. This is the Norwegian case I cited elsewhere: you have to have "special" or "secret" information in order to perform the complete lookup. Which is a pain. However... we aren't *required* to make a change to the algorithm itself. We could just pretend that everyone is done with their retagging :-). > This doesn't help a "new" web app talking to an "old" client that > hasn't been updated, for example. In order to solve that > you have to infer the matching suggested, which I think is > simpler with 1). Yes. > > Note that your solution in 2) could be used if you felt it was simpler: > zh-yue-Hant-HK;zh-Hant-HK > could be used to solve 1) as well, but with 1) you have more options. No: this is why the modification is necessary. The first fallback, without the change goes: zh-yue-Hant-HK zh-yue-Hant zh-yue zh <-- wrong result, possibly similar to zh-Hans-CN, returned) zh-Hant-HK zh-Hant zh (default) I'm not saying that (1) is a bad option. It works for me. I'm just trying to make the cases clear. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 09 16:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLTu-00061h-GJ; Tue, 09 Oct 2007 16:15:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfLTt-00061S-BP for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 16:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLTt-000616-1a for ltru@ietf.org; Tue, 09 Oct 2007 16:15:05 -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 1IfLTm-0002EX-SL for ltru@ietf.org; Tue, 09 Oct 2007 16:15:05 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Tue, 9 Oct 2007 13:14:30 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Tue, 9 Oct 2007 13:14:30 -0700 From: Shawn Steele To: Andrew Cunningham , Addison Phillips Date: Tue, 9 Oct 2007 13:14:27 -0700 Subject: RE: [Ltru] Extended language tags (long reply) - portuguese Thread-Topic: [Ltru] Extended language tags (long reply) - portuguese Thread-Index: AcgJQGecy0s6HTt6TCyusInd4Hk5PgBb4XoA Message-ID: References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> In-Reply-To: <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.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: , Content-Type: multipart/mixed; boundary="===============0858013993==" Errors-To: ltru-bounces@ietf.org --===============0858013993== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiA+IFNvLCBmb3IgbWUsIHRoZSBtYWluIGlzc3VlIGlzIHdoZXRoZXIgd2UgYXJlIGdvaW5nIHRv IGV4cGxpY2l0bHkgYnJlYWsNCj4gPiB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBsYW5ndWFn ZSBhbmQgaXRzIG1hY3JvbGFuZ3VhZ2UgKGF0IHRoZSB0YWcNCj4gPiBsZXZlbCkuIEluIHNvbWUg Y2FzZXMgKE5vcndlZ2lhbikgd2UgYWxyZWFkeSBrbm93IHRoaXMgY2FuIGJlDQo+ID4gcHJvYmxl bWF0aWM7IGluIG90aGVycywgaXQgbWF5IGFjdHVhbGx5IGJlIGRlc2lyYWJsZS4NCg0KTW9zdGx5 IEkgYWdyZWUgd2l0aCBtb3N0IG9mIHRoZSBwb2ludHMgaW4gQWRkaXNvbidzICJsb25nIHJlcGx5 IiwgSSBqdXN0IGRpc2FncmVlIHdpdGggdGhlIGNvbmNsdXNpb24gOikNCg0KPiBJdCBwcm9iYWJs eSBjb21lcyBkb3duIHRvIHBoaWxvc29waGljYWwgZGlmZmVyZW5jZXMuDQoNCjopDQoNCj4gU28s IGN1dHRpbmcgdG8gdGhlIGNoYXNlLCB3aGljaCB3YXkgZm9yd2FyZD8NCg0KOikNCg0KSSBkbyBo YXZlIG9uZSBvdGhlciBjb25jZXJuIHRoYXQgbmVpdGhlciBzdWdnZXN0IGFkZHJlc3NlcyBkaXJl Y3RseTogTXkgdW5kZXJzdGFuZGluZyAocG9zc2libHkgaW5jb3JyZWN0KSBpcyB0aGF0IEJyYXpp bGlhbiBQb3J0dWd1ZXNlIGFuZCBQb3J0dWd1ZXNlIFBvcnR1Z3Vlc2UgYXJlIGRpZmZlcmVudCBl bm91Z2ggdG8gcmVxdWlyZSBkaWZmZXJlbnQgbG9jYWxpemF0aW9ucy4gIExhYmVsaW5nIHRoZW0g cHQtQlIgYW5kIHB0LVBUIGFyZSBmaW5lLCBleGNlcHQgdGhhdCBpZiBJIGVuZCB1cCB3aXRoIHB0 LU1aIGhvdyBkbyBJIGZpbmQgdGhlIGJlc3QgbWF0Y2g/DQoNCi0gU2hhd24NCg== --===============0858013993== 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 --===============0858013993==-- From ltru-bounces@ietf.org Tue Oct 09 16:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLca-0003pR-Re; Tue, 09 Oct 2007 16:24:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfLca-0003pL-8W for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 16:24:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLcZ-0003p7-Uo for ltru@ietf.org; Tue, 09 Oct 2007 16:24:03 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfLcT-0002UU-Sm for ltru@ietf.org; Tue, 09 Oct 2007 16:24:03 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qsVVXayvUHX8mWBpi4pUGZA+SFxzetNrD3YSonJI7OBYYQ4G+1rJf6OEyQoffp/V; 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.164.80.37] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IfLcE-00024i-RA for ltru@ietf.org; Tue, 09 Oct 2007 16:23:43 -0400 Message-ID: <002701c80ab2$dcba1c20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4709146F.6020504@yahoo-inc.com><9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> Subject: Re: [Ltru] Extended language tags (long reply) - portuguese Date: Tue, 9 Oct 2007 13:27:48 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31aeab150b0c56c754ecf2f11dbaf625546350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Shawn Steele" > To: "Andrew Cunningham" ; "Addison Phillips" > Cc: > Sent: Tuesday, October 09, 2007 1:14 PM > Subject: RE: [Ltru] Extended language tags (long reply) - portuguese ... > I do have one other concern that neither suggest addresses directly: > My understanding (possibly incorrect) is that Brazilian Portuguese > and Portuguese Portuguese are different enough to require different > localizations. Labeling them pt-BR and pt-PT are fine, except that > if I end up with pt-MZ how do I find the best match? ... Not our problem. :-) But seriously, this is exactly the same kind of problem as worries the folks who don't like macrolangauge/extlang constructs; there are cases where the results of remove-from-right heuristics won't always be helpful in all situations. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 09 16:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLsp-0008Hf-GR; Tue, 09 Oct 2007 16:40:51 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfLso-0008G7-25 for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 16:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLsn-0008Fz-OD for ltru@ietf.org; Tue, 09 Oct 2007 16:40:49 -0400 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfLsi-0002v3-Ao for ltru@ietf.org; Tue, 09 Oct 2007 16:40:49 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1085692rvb for ; Tue, 09 Oct 2007 13:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=Vt91WDlBo6o12gEnRNSxSCew64Ra7GCduYB8CslPrlk=; b=YSDhxOZLT1dcxfKY75RAFsEPsL31DW40FGZJMTQ07LOaeenSQgrlWasmyhiFo5UdIaQBwxYf4No8TThisTcIUObkAE3jcO+F2h0ET9cjBDKBIbqgcuX0+cnA3Bcybh8UOISZPXrWOOowwtjAdGLg74/C+wuzkiZsANvM57AYMNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Yq5Yd68MmD5pJQApsKmO0FALecq8QDTjPgnJHYcu3EOIjUfzeIkJYuEOAFTQxurnNSOuxR7EuI1/w408at5Ve+3X1jFIs878VRikiWqh13YuysNZhd4i521wiHbYE7XNM0DINH7Bu6t75RZwmudYLMjRWHXVRtdPFtuoulHugt4= Received: by 10.115.90.1 with SMTP id s1mr3101425wal.1191962418410; Tue, 09 Oct 2007 13:40:18 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Tue, 9 Oct 2007 13:40:18 -0700 (PDT) Message-ID: <30b660a20710091340o50a0bd11taa6b6edaa7945885@mail.gmail.com> Date: Tue, 9 Oct 2007 13:40:18 -0700 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Re: Extended language tags In-Reply-To: <005001c80aa5$463c55e0$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <00f501c80a7a$aca85520$6401a8c0@DGBP7M81> <005001c80aa5$463c55e0$6801a8c0@oemcomputer> X-Google-Sender-Auth: a3b167f628dcf967 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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="===============2107546863==" Errors-To: ltru-bounces@ietf.org --===============2107546863== Content-Type: multipart/alternative; boundary="----=_Part_6308_31239734.1191962418337" ------=_Part_6308_31239734.1191962418337 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline First off, I agree with Andy that the editor's contributions should be judged on technical merit, just like everyone else's. As far as a conclusion goes. Any judgment of consensus at this point is premature. We are increasing the size of the registry by a huge margin, and considering whether to add a significant piece of architecture: it is more important that this revision be correctly designed than that it meet some arbitrary deadline. I think that the telecons have been valuable for bringing out the issues, and we already planned for another this week. As long as we are making progress with that, we should continue. It is useful when the chairs could make that meeting: Randy's been to one of them. Martin, is that time too difficult for you? Mark On 10/9/07, Randy Presuhn wrote: > > Hi - > > As co-chair... > > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Tuesday, October 09, 2007 6:45 AM > > Subject: [Ltru] Re: Extended language tags > > > > Randy Presuhn wrote: > > > > >> Hard to say. I think at this moment there are more contributors who > > >> favor (1) than (2), but the two main proponents of (2) are the > > >> co-editors of 4646bis, which does tip the balance a bit. > > > > > > No, it does not. Editors do the bidding of the WG, see RFC 2418 > > > clause 6.3. As such they are *not* given special consideration in the > > > determination of working group consensus. > > > > But they might well be given special consideration by other list members > > who haven't made up their minds yet. > > This would be a bad thing. RFC 2418 is abundantly clear that document > editors do not enjoy any special privileges in determining WG consensus. > Sometimes editors happen to be experts in the topic, sometimes they are > not. > But if a WG starts giving their voices more weight merely because they > happen to be editors, something is seriously wrong. > > > I would guess that with the small > > number of people solidly on one side or the other, the battle for the > > "undecided" bloc will be important. > > Perhaps, though the undecided have little import for a determination > of rough consensus. At some point Martin and I will have to make > a determination of consensus. It's clear that none of the options > will make everyone happy. It's possible that none of the options > will make anyone happy in the long run. Since there has been so little > in the way of new information or arguments in this discussion, > I think Martin and I will just have to pick one, based on the opinions > expressed on this list so far, since few new voices seem to be joining > in to express a preference. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_6308_31239734.1191962418337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline First off, I agree with Andy that the editor's contributions should be judged on technical merit, just like everyone else's.

As far as a conclusion goes. Any judgment of consensus at this point is premature. We are increasing the size of the registry by a huge margin, and considering whether to add a significant piece of architecture: it is more important that this revision be correctly designed than that it meet some arbitrary deadline. I think that the telecons have been valuable for bringing out the issues, and we already planned for another this week. As long as we are making progress with that, we should continue. It is useful when the chairs could make that meeting: Randy's been to one of them. Martin, is that time too difficult for you?

Mark

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

As co-chair...

> From: "Doug Ewell" <dewell@roadrunner.com>
> To: "LTRU Working Group" <ltru@ietf.org >
> Sent: Tuesday, October 09, 2007 6:45 AM
> Subject: [Ltru] Re: Extended language tags
>
> Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
>
> >> Hard to say.  I think at this moment there are more contributors who
> >> favor (1) than (2), but the two main proponents of (2) are the
> >> co-editors of 4646bis, which does tip the balance a bit.
> >
> > No, it does not.  Editors do the bidding of the WG, see RFC 2418
> > clause 6.3.  As such they are *not* given special consideration in the
> > determination of working group consensus.
>
> But they might well be given special consideration by other list members
> who haven't made up their minds yet.

This would be a bad thing.  RFC 2418 is abundantly clear that document
editors do not enjoy any special privileges in determining WG consensus.
Sometimes editors happen to be experts in the topic, sometimes they are not.
But if a WG starts giving their voices more weight merely because they
happen to be editors, something is seriously wrong.

>  I would guess that with the small
> number of people solidly on one side or the other, the battle for the
> "undecided" bloc will be important.

Perhaps, though the undecided have little import for a determination
of rough consensus.  At some point Martin and I will have to make
a determination of consensus.  It's clear that none of the options
will make everyone happy.  It's possible that none of the options
will make anyone happy in the long run.  Since there has been so little
in the way of new information or arguments in this discussion,
I think Martin and I will just have to pick one, based on the opinions
expressed on this list so far, since few new voices seem to be joining
in to express a preference.

Randy



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



--
Mark ------=_Part_6308_31239734.1191962418337-- --===============2107546863== 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 --===============2107546863==-- From ltru-bounces@ietf.org Tue Oct 09 23:14:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfS14-0001K2-R2; Tue, 09 Oct 2007 23:13:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfS13-0001Jw-Nf for ltru-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 23:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfS13-00016A-EA for ltru@ietf.org; Tue, 09 Oct 2007 23:13:45 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfS0y-00079F-4i for ltru@ietf.org; Tue, 09 Oct 2007 23:13:41 -0400 Received: from [10.72.77.3] (snvvpn2-10-72-77-c3.corp.yahoo.com [10.72.77.3]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9A3CvQt087293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 20:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=NC2i4f67IDJ+01pCiOosPkmwlFR9UAmMCeY3BHmPdLxrTA3MYGC8r0o0nPnE7TTs Message-ID: <470C4339.90901@yahoo-inc.com> Date: Tue, 09 Oct 2007 20:12:57 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Extended language tags References: <00f501c80a7a$aca85520$6401a8c0@DGBP7M81> <005001c80aa5$463c55e0$6801a8c0@oemcomputer> <30b660a20710091340o50a0bd11taa6b6edaa7945885@mail.gmail.com> In-Reply-To: <30b660a20710091340o50a0bd11taa6b6edaa7945885@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) 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: , Errors-To: ltru-bounces@ietf.org Just FYI, tomorrow morning (9 am Pacific) call can be accessed: Dial-In #: +1.888.371.8922 International Dial-In #: +1.617.224.4792 Participant Passcode: 58371972 Addison Mark Davis wrote: > First off, I agree with Andy that the editor's contributions should be > judged on technical merit, just like everyone else's. > > As far as a conclusion goes. Any judgment of consensus at this point is > premature. We are increasing the size of the registry by a huge margin, > and considering whether to add a significant piece of architecture: it > is more important that this revision be correctly designed than that it > meet some arbitrary deadline. I think that the telecons have been > valuable for bringing out the issues, and we already planned for another > this week. As long as we are making progress with that, we should > continue. It is useful when the chairs could make that meeting: Randy's > been to one of them. Martin, is that time too difficult for you? > > Mark > > On 10/9/07, *Randy Presuhn* > wrote: > > Hi - > > As co-chair... > > > From: "Doug Ewell" > > > To: "LTRU Working Group" > > > Sent: Tuesday, October 09, 2007 6:45 AM > > Subject: [Ltru] Re: Extended language tags > > > > Randy Presuhn wrote: > > > > >> Hard to say. I think at this moment there are more > contributors who > > >> favor (1) than (2), but the two main proponents of (2) are the > > >> co-editors of 4646bis, which does tip the balance a bit. > > > > > > No, it does not. Editors do the bidding of the WG, see RFC 2418 > > > clause 6.3. As such they are *not* given special consideration > in the > > > determination of working group consensus. > > > > But they might well be given special consideration by other list > members > > who haven't made up their minds yet. > > This would be a bad thing. RFC 2418 is abundantly clear that document > editors do not enjoy any special privileges in determining WG consensus. > Sometimes editors happen to be experts in the topic, sometimes they > are not. > But if a WG starts giving their voices more weight merely because they > happen to be editors, something is seriously wrong. > > > I would guess that with the small > > number of people solidly on one side or the other, the battle for > the > > "undecided" bloc will be important. > > Perhaps, though the undecided have little import for a determination > of rough consensus. At some point Martin and I will have to make > a determination of consensus. It's clear that none of the options > will make everyone happy. It's possible that none of the options > will make anyone happy in the long run. Since there has been so little > in the way of new information or arguments in this discussion, > I think Martin and I will just have to pick one, based on the opinions > expressed on this list so far, since few new voices seem to be joining > in to express a preference. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 10 05:48:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYA6-0001Py-0h; Wed, 10 Oct 2007 05:47:30 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfYA4-0001Pj-V3 for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 05:47:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfYA4-0001PV-Go for ltru@ietf.org; Wed, 10 Oct 2007 05:47:28 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfYA4-0005su-0n for ltru@ietf.org; Wed, 10 Oct 2007 05:47:28 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007322197.msg for ; Wed, 10 Oct 2007 10:50:55 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 10 Oct 2007 10:47:29 +0100 From: "Debbie Garside" To: , "'Doug Ewell'" , "'LTRU Working Group'" References: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: Extended language tags Date: Wed, 10 Oct 2007 10:46:18 +0100 Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgKDtABtbHoCNogTkKlXKsVXK54mwAmoFJQAB2EeJA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Wed, 10 Oct 2007 10:50:55 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18038546a2=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, 10 Oct 2007 10:50:56 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi I may have missed the answer to this question, apologies if I have, but why not include cwm within the registry and then deprecate in favour of zh-cwm? This way both are in the registry and the fallback, as described by Mark, is facilitated. The same could be done for zh-yue and yue and no-nb etc. Thus if people tag "incorrectly", with, for example, cwm or yue, applications would come up with the correct match anyway. I cannot pretend that I understand the entirety of the current conversations wrt extended language tags but I do think their inclusion would be useful for matching purposes. Best regards Debbie Garside > -----Original Message----- > From: Shawn Steele [mailto:Shawn.Steele@microsoft.com] > Sent: 09 October 2007 20:25 > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Extended language tags > > > > > * Even for the current tags, many of the people in the > > > teleconference seem to extend RFC 4647 in ways that are best for > > > them. Strict use of > > > 4647 behavior seems rare. It seems reasonable to me to > expect that > > > in the future people may continue to do so and that RFC > 4647 and the > > > registry can only provide guidelines. > > > I agree with the part about RFC 4647, but not the Registry, > at least > > not in blanket terms. > > > The Registry contains some fields that are normative and > some that are > > informative. > > Tagging and lookup however are different. Many of the uses > I'm involved with presume that tags are correctly defined: > ie: only installed locales are allowed to be used for > resource names, or for marking documents. Presumably the > locales were created correctly when they were installed, so I > don't have to worry about "eng" being valid. > > Making a matching dependency on the registry would require a > new data source, which could be problematic, which is why I > prefer the information be in the tags. If the tags are > invalid I won't match correctly, but I won't have to look up > an on-line dependency. Obviously this is less of a problem > for some applications, but I don't see there being any > downside and it does help to have the ext lang tag in this case. > > - Shawn > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 12:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife4S-0000Dx-PA; Wed, 10 Oct 2007 12:06:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ife4R-0000Dr-L6 for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:06:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife4R-0000C5-56 for ltru@ietf.org; Wed, 10 Oct 2007 12:06:03 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ife4A-0006wE-RC for ltru@ietf.org; Wed, 10 Oct 2007 12:05:59 -0400 Received: by wa-out-1112.google.com with SMTP id k40so440216wah for ; Wed, 10 Oct 2007 09:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=aUznHmtc6pqMd7XFJDWuJfsCevK2Vi8BfeOF86L2OFo=; b=G6ujQCeUZNEcVYsM7us2RHGgzRUc9KWZ+TZ91/YyiQz2AJW1NAmK5cjcrdaApYgtQgDM0YRAY6WMbpaRh6+hQi/It54DOCIlt/jciyx85FcDntTkbrAzXnVIQyvBJMR7JM7AFlvaC087oeEPG6zViUVVjaKQC/nBErq5V3lQ/cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=rhEB1nf0u4g9/siDr16B/L+39boO+kuzzB82+okrVK/as82uLaw3F4M8UyP3P1QuWhU7da8EdQ7pofkzZmvDPTiOKKZSVfDBjWOQtiqidD6Bjl4XJ7Syix7SRI7zp2H5EcRkPZYQa0ke6KU0hOsr6pmQZZ8dpcxYXGBolqbM2i8= Received: by 10.114.89.1 with SMTP id m1mr955939wab.1192031718337; Wed, 10 Oct 2007 08:55:18 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 10 Oct 2007 08:55:18 -0700 (PDT) Message-ID: <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> Date: Wed, 10 Oct 2007 08:55:18 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Extended language tags (long reply) In-Reply-To: <4709A420.80508@yahoo-inc.com> MIME-Version: 1.0 References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> X-Google-Sender-Auth: 75aefa4d9ef8060b X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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="===============0309345680==" Errors-To: ltru-bounces@ietf.org --===============0309345680== Content-Type: multipart/alternative; boundary="----=_Part_9853_12354135.1192031718331" ------=_Part_9853_12354135.1192031718331 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Some detailed comments on these scenarios. On 10/7/07, Addison Phillips wrote: > > I would say: > > 1. With Extlangs. > > - change to filtering: none, but you probably want to use extended > filtering instead of basic filtering (i.e. "zh-Hant-HK" matches > "zh-yue-Hant-HK" and "zh-cmn-Hant-HK") Actually, I think the change is the reverse; you have to disable extended filtering. In the filtering / search business, it is just as bad (if not worse) to give too many responses as it is to give too few. Otherwise your user is swamped in irrelevant documents. Except in very few cases, notably Arabic and Chinese, according to what I have heard Peter say, we have no reason to believe that a speaker of one microlanguage speaks any other particular macrolanguage. If my user searches for Fulah, and does s/he want to get Maasina Fulfulde, Adamawa Fulfulde, Pulaar, Central-Eastern Niger Fulfulde, and so on, which I have no reason to believe that the original person speaks? And even for Arabic and Chinese, unmodified extended filtering with extlang might make sense only because ar-arb is equivalent to arb and zh-cmn is equivalent to cmn, for all practical purposes, and where all speakers of the microlanguages understand the macrolanguages (which is unclear -- I've asked on the list whether the latter is true -- and it is a crucial fact for extlang -- but get no answer). Better is that if someone really wants both standard Arabic and Tajiki Arabic, than the input be "ar, abh", just like now with Norwegian or Serbo-croation, where someone can just list "nn, nb, no" and "sr, hr, bs, sh", So with extlang we have a backwards compatibility issue with extended filtering; we need to disable macrolanguage lookup in all but a few cases, and even there it is better for the user to just supply the list of items they want. http://www.sil.org/iso639-3/macrolanguages.asp - change to lookup: treat extlang as atomic with the primary language > subtag; potentially loop-back through the subtags. That is, given the > range "zh-yue-Hant-HK", the fallback pattern is this: > > zh-yue-Hant-HK > zh-yue-Hant > zh-yue > zh-Hant-HK > zh-Hant > zh > (default) And again, we disable this for all but a few specific cases. It only makes sense to do this as a heuristic when the speaker of the microlanguage is extremely likely to speak the macrolanguage. If the query is Maasina Fulfulde as used in Ghana (ful-)ffm-GH, we don't want to fall back to some arbitrary Fulah; instead we want to probably fall back to Hausa. And this would need to be handled even more carefully where the input is multiple tags, as in Accept-Language. If the user supplies "zh-yue; en", meaning that they prefer Cantonese, then English -- and may not know Mandarin at all! -- then the stated algorithm, the one that everyone uses now, would give completely incorrect results. (1) Incorrect zh-yue-Hant-HK zh-yue-Hant zh-yue zh en (default) Even the modified version doesn't work (2) Still incorrect zh-yue-Hant-HK zh-yue-Hant zh-yue zh-Hant-HK zh-Hant zh en (default) What we need to do is more complicated: (3) what the user asked for, Cantonese, then English, then maybe something else. zh-yue-Hant-HK zh-yue-Hant zh-yue en zh-Hant-HK zh-Hant zh (default) Number 3 is especially needed whenever the macrolanguage is not overwhelmingly likely to be understood by the macrolanguage users. So with extlang we also have a backwards compatibility issue with lookup; code that used to work fine will fail. Or this: > > zh-yue-Hant-HK > zh-yue-Hant > zh-yue > (default) This would be better, but still requires a change to algorithms, and then simply amounts to adding extlang, but coding around it so that the results were as if there were no extlang -- better to not use the extlang mechanism. 2. Without extlangs. > > - change to filtering: none > > - change to lookup: none Agreed so far, but... BUT... you want to include the macro language in your ranges in some > cases. Alternatively, we would have to define new filtering and lookup > options that include mapping to macrolanguages. For example, with the > range "yue-Hant-HK", you would want the fallback to be: > > yue-Hant-HK > yue-Hant > yue > zh-Hant-HK > zh-Hant > zh > (default) In the case of no extlangs, we really do not want to make any changes to the algorithms. Instead, we want to point out in the text that macro languages *MAY* be a useful resource for having some extended fallback. That is, it *MAY* be reasonable to fall back from the Chinese and Arabic microlanguages to their macrolanguages, but also may not. And the interaction between this additional fallback and multiple tags needs to be taken into consideration. Suppose that the input is "yue-Hant-HK; en"; the current algorithm works. (1) yue-Hant-HK yue-Hant yue en (default) If a particular implementation wants to change the default processing to have an extra step that adds fallback to zh-Hant-HK (and so on) for certain specific languages, such as particular Chinese and Arabic microlanguages, that's a small amount of work. Moreover, it is just what a more enhanced algorithm *currently* would do with any of "nn, nb, no" and "sr, hr, bs, sh", -- in this case they are known to be good, practical fallbacks. Alternatively, if the user just feeds in "yue-Hant-HK, en, zh-Hant-HK" or the reverse "yue-Hant-HK, zh-Hant-HK, en", that will work without any code changes, or any enhancements; the user gets what is asked for. ================ What we don't want to do is make recommendations that if implemented, are harder for people to control and get the right answer. And baking extlang into the tags is even worse -- since it introduces backwards incompatibilities that require old code to be modified to work around. Someone mentioned on this list that they thought that these were only philosophical differences. I don't see it that way at all. The choices we make here will affect the ability of people to work with their own languages for a long time -- it is important to get this right, and pay attention both to backwards compatibility and to future capabilities -- the choice of architecture will make real, practical differences for people, especially for minority language users. My fear is exactly minority language users will be disadvantage with extlang. It isn't the French or German speakers that will end up with problems; it is the Gondi and Grebo speakers. Mark ------=_Part_9853_12354135.1192031718331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Some detailed comments on these scenarios.

On 10/7/07, Addison Phillips <addison@yahoo-inc.com> wrote:
I would say:

1. With Extlangs.

- change to filtering: none, but you probably want to use extended
filtering instead of basic filtering (i.e. "zh-Hant-HK" matches
"zh-yue-Hant-HK" and "zh-cmn-Hant-HK")

Actually, I think the change is the reverse; you have to disable extended filtering. In the filtering / search business, it is just as bad (if not worse) to give too many responses as it is to give too few. Otherwise your user is swamped in irrelevant documents.

Except in very few cases, notably Arabic and Chinese, according to what I have heard Peter say, we have no reason to believe that a speaker of one microlanguage speaks any other particular macrolanguage. If my user searches for Fulah, and does s/he want to get Maasina Fulfulde, Adamawa Fulfulde, Pulaar, Central-Eastern Niger Fulfulde, and so on, which I have no reason to believe that the original person speaks?

And even for Arabic and Chinese, unmodified extended filtering with extlang might make sense only because ar-arb is equivalent to arb and zh-cmn is equivalent to cmn, for all practical purposes, and where all speakers of the microlanguages understand the macrolanguages (which is unclear -- I've asked on the list whether the latter is true -- and it is a crucial fact for extlang -- but get no answer). Better is that if someone really wants both standard Arabic and Tajiki Arabic, than the input be "ar, abh", just like now with Norwegian or Serbo-croation, where someone can just list "nn, nb, no" and "sr, hr, bs, sh",

So with extlang we have a backwards compatibility issue with extended filtering; we need to disable macrolanguage lookup in all but a few cases, and even there it is better for the user to just supply the list of items they want.

http://www.sil.org/iso639-3/macrolanguages.asp

- change to lookup: treat extlang as atomic with the primary language
subtag; potentially loop-back through the subtags. That is, given the
range "zh-yue-Hant-HK", the fallback pattern is this:

  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  zh-Hant-HK
  zh-Hant
  zh
  (default)

And again, we disable this for all but a few specific cases. It only makes sense to do this as a heuristic when the speaker of the microlanguage is extremely likely to speak the macrolanguage.

If the query is Maasina Fulfulde as used in Ghana (ful-)ffm-GH, we don't want to fall back to some arbitrary Fulah; instead we want to probably fall back to Hausa.

And this would need to be handled even more carefully where the input is multiple tags, as in Accept-Language. If the user supplies "zh-yue; en", meaning that they prefer Cantonese, then English -- and may not know Mandarin at all! -- then the stated algorithm, the one that everyone uses now, would give completely incorrect results.

(1) Incorrect
  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  zh
  en
  (default)

Even the modified version doesn't work

(2) Still incorrect
  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  zh-Hant-HK
  zh-Hant
  zh
  en
  (default)

What we need to do is more complicated:

(3) what the user asked for, Cantonese, then English, then maybe something else.
  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  en
  zh-Hant-HK
  zh-Hant
  zh
  (default)

Number 3 is especially needed whenever the macrolanguage is not overwhelmingly likely to be understood by the macrolanguage users.

So with extlang we also have a backwards compatibility issue with lookup; code that used to work fine will fail.

Or this:

  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  (default)

This would be better, but still requires a change to algorithms, and then simply amounts to adding extlang, but coding around it so that the results were as if there were no extlang -- better to not use the extlang mechanism.

2. Without extlangs.

- change to filtering: none

- change to lookup: none

Agreed so far, but...

BUT... you want to include the macro language in your ranges in some
cases. Alternatively, we would have to define new filtering and lookup
options that include mapping to macrolanguages. For example, with the
range "yue-Hant-HK", you would want the fallback to be:

  yue-Hant-HK
  yue-Hant
  yue
  zh-Hant-HK
  zh-Hant
  zh
  (default)


In the case of no extlangs, we really do not want to make any changes to the algorithms. Instead, we want to point out in the text that macro languages *MAY* be a useful resource for having some extended fallback. That is, it *MAY* be reasonable to fall back from the Chinese and Arabic microlanguages to their macrolanguages, but also may not. And the interaction between this additional fallback and multiple tags needs to be taken into consideration.

Suppose that the input is "yue-Hant-HK; en"; the current algorithm works.

(1)
  yue-Hant-HK
  yue-Hant
  yue
  en
  (default)

If a particular implementation wants to change the default processing to have an extra step that adds fallback to zh-Hant-HK (and so on) for certain specific languages, such as particular Chinese and Arabic microlanguages, that's a small amount of work. Moreover, it is just what a more enhanced algorithm *currently* would do with any of "nn, nb, no" and "sr, hr, bs, sh", -- in this case they are known to be good, practical fallbacks.

Alternatively, if the user just feeds in "yue-Hant-HK, en, zh-Hant-HK" or the reverse "yue-Hant-HK, zh-Hant-HK, en", that will work without any code changes, or any enhancements; the user gets what is asked for.

================

What we don't want to do is make recommendations that if implemented, are harder for people to control and get the right answer. And baking extlang into the tags is even worse -- since it introduces backwards incompatibilities that require old code to be modified to work around.

Someone mentioned on this list that they thought that these were only philosophical differences. I don't see it that way at all. The choices we make here will affect the ability of people to work with their own languages for a long time -- it is important to get this right, and pay attention both to backwards compatibility and to future capabilities -- the choice of architecture will make real, practical differences for people, especially for minority language users. My fear is exactly minority language users will be disadvantage with extlang. It isn't the French or German speakers that will end up with problems; it is the Gondi and Grebo speakers.

Mark
------=_Part_9853_12354135.1192031718331-- --===============0309345680== 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 --===============0309345680==-- From ltru-bounces@ietf.org Wed Oct 10 12:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeNH-0002e7-GL; Wed, 10 Oct 2007 12:25:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfeNH-0002e1-0O for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:25:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeNG-0002dW-KG for ltru@ietf.org; Wed, 10 Oct 2007 12:25:30 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfeN7-0001bj-EY for ltru@ietf.org; Wed, 10 Oct 2007 12:25:23 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007324662.msg for ; Wed, 10 Oct 2007 17:28:49 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 10 Oct 2007 17:25:22 +0100 From: "Debbie Garside" To: , "'Addison Phillips'" References: <4709146F.6020504@yahoo-inc.com><9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com><30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com><4709A420.80508@yahoo-inc.com> <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> Subject: RE: [Ltru] Extended language tags (long reply) Date: Wed, 10 Oct 2007 17:24:09 +0100 Message-ID: <059801c80b59$fc7d15b0$0d00a8c0@CPQ86763045110> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> Thread-Index: AcgLV7LOyCsgsFTsREyZMdvpTIYCjQAAQvJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Wed, 10 Oct 2007 17:28:49 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18038546a2=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, 10 Oct 2007 17:28:50 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 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="===============0857091542==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0857091542== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0599_01C80B62.5E417DB0" This is a multi-part message in MIME format. ------=_NextPart_000_0599_01C80B62.5E417DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark I haven't time at the moment to put together the fallback for this (as it would take me ages) but I think fas-prs and fas-pes are good cases for macrolanguages to be included as extended language tags. These languages are mutually intelligible and to be able to choose prs and have a system create a fallback based on fas would be a huge bonus. Implementations should have the extended language tags option and end users should be presented with a question asking if they want macrolanguage related languages matched IMHO. It is not just about whether they understand the macrolanguage it is whether a user wants to return the related languages within the macrolanguage; I do understand that the end user would not want this in many cases but where is the harm in the provision? If I was querying using prs I would certainly want to have pes and fas tagged items returned as a secondary match. Best regards Debbie _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 10 October 2007 16:55 To: Addison Phillips Cc: ltru@ietf.org Subject: Re: [Ltru] Extended language tags (long reply) Some detailed comments on these scenarios. On 10/7/07, Addison Phillips wrote: I would say: 1. With Extlangs. - change to filtering: none, but you probably want to use extended filtering instead of basic filtering (i.e. "zh-Hant-HK" matches "zh-yue-Hant-HK" and "zh-cmn-Hant-HK") Actually, I think the change is the reverse; you have to disable extended filtering. In the filtering / search business, it is just as bad (if not worse) to give too many responses as it is to give too few. Otherwise your user is swamped in irrelevant documents. Except in very few cases, notably Arabic and Chinese, according to what I have heard Peter say, we have no reason to believe that a speaker of one microlanguage speaks any other particular macrolanguage. If my user searches for Fulah, and does s/he want to get Maasina Fulfulde, Adamawa Fulfulde, Pulaar, Central-Eastern Niger Fulfulde, and so on, which I have no reason to believe that the original person speaks? And even for Arabic and Chinese, unmodified extended filtering with extlang might make sense only because ar-arb is equivalent to arb and zh-cmn is equivalent to cmn, for all practical purposes, and where all speakers of the microlanguages understand the macrolanguages (which is unclear -- I've asked on the list whether the latter is true -- and it is a crucial fact for extlang -- but get no answer). Better is that if someone really wants both standard Arabic and Tajiki Arabic, than the input be "ar, abh", just like now with Norwegian or Serbo-croation, where someone can just list "nn, nb, no" and "sr, hr, bs, sh", So with extlang we have a backwards compatibility issue with extended filtering; we need to disable macrolanguage lookup in all but a few cases, and even there it is better for the user to just supply the list of items they want. http://www.sil.org/iso639-3/macrolanguages.asp - change to lookup: treat extlang as atomic with the primary language subtag; potentially loop-back through the subtags. That is, given the range "zh-yue-Hant-HK", the fallback pattern is this: zh-yue-Hant-HK zh-yue-Hant zh-yue zh-Hant-HK zh-Hant zh (default) And again, we disable this for all but a few specific cases. It only makes sense to do this as a heuristic when the speaker of the microlanguage is extremely likely to speak the macrolanguage. If the query is Maasina Fulfulde as used in Ghana (ful-)ffm-GH, we don't want to fall back to some arbitrary Fulah; instead we want to probably fall back to Hausa. And this would need to be handled even more carefully where the input is multiple tags, as in Accept-Language. If the user supplies "zh-yue; en", meaning that they prefer Cantonese, then English -- and may not know Mandarin at all! -- then the stated algorithm, the one that everyone uses now, would give completely incorrect results. (1) Incorrect zh-yue-Hant-HK zh-yue-Hant zh-yue zh en (default) Even the modified version doesn't work (2) Still incorrect zh-yue-Hant-HK zh-yue-Hant zh-yue zh-Hant-HK zh-Hant zh en (default) What we need to do is more complicated: (3) what the user asked for, Cantonese, then English, then maybe something else. zh-yue-Hant-HK zh-yue-Hant zh-yue en zh-Hant-HK zh-Hant zh (default) Number 3 is especially needed whenever the macrolanguage is not overwhelmingly likely to be understood by the macrolanguage users. So with extlang we also have a backwards compatibility issue with lookup; code that used to work fine will fail. Or this: zh-yue-Hant-HK zh-yue-Hant zh-yue (default) This would be better, but still requires a change to algorithms, and then simply amounts to adding extlang, but coding around it so that the results were as if there were no extlang -- better to not use the extlang mechanism. 2. Without extlangs. - change to filtering: none - change to lookup: none Agreed so far, but... BUT... you want to include the macro language in your ranges in some cases. Alternatively, we would have to define new filtering and lookup options that include mapping to macrolanguages. For example, with the range "yue-Hant-HK", you would want the fallback to be: yue-Hant-HK yue-Hant yue zh-Hant-HK zh-Hant zh (default) In the case of no extlangs, we really do not want to make any changes to the algorithms. Instead, we want to point out in the text that macro languages *MAY* be a useful resource for having some extended fallback. That is, it *MAY* be reasonable to fall back from the Chinese and Arabic microlanguages to their macrolanguages, but also may not. And the interaction between this additional fallback and multiple tags needs to be taken into consideration. Suppose that the input is "yue-Hant-HK; en"; the current algorithm works. (1) yue-Hant-HK yue-Hant yue en (default) If a particular implementation wants to change the default processing to have an extra step that adds fallback to zh-Hant-HK (and so on) for certain specific languages, such as particular Chinese and Arabic microlanguages, that's a small amount of work. Moreover, it is just what a more enhanced algorithm *currently* would do with any of "nn, nb, no" and "sr, hr, bs, sh", -- in this case they are known to be good, practical fallbacks. Alternatively, if the user just feeds in "yue-Hant-HK, en, zh-Hant-HK" or the reverse "yue-Hant-HK, zh-Hant-HK, en", that will work without any code changes, or any enhancements; the user gets what is asked for. ================ What we don't want to do is make recommendations that if implemented, are harder for people to control and get the right answer. And baking extlang into the tags is even worse -- since it introduces backwards incompatibilities that require old code to be modified to work around. Someone mentioned on this list that they thought that these were only philosophical differences. I don't see it that way at all. The choices we make here will affect the ability of people to work with their own languages for a long time -- it is important to get this right, and pay attention both to backwards compatibility and to future capabilities -- the choice of architecture will make real, practical differences for people, especially for minority language users. My fear is exactly minority language users will be disadvantage with extlang. It isn't the French or German speakers that will end up with problems; it is the Gondi and Grebo speakers. Mark ------=_NextPart_000_0599_01C80B62.5E417DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mark
 
I=20 haven't time at the moment to put together the fallback for this (as it = would=20 take me ages) but I think fas-prs and fas-pes are good cases for=20 macrolanguages to be included as extended language tags.  These = languages=20 are mutually intelligible and to be able to choose prs and have a system = create=20 a fallback based on fas would be a huge bonus.  Implementations = should have=20 the extended language tags option and end users should be presented with = a=20 question asking if they want macrolanguage related languages matched=20 IMHO. It is not just about whether they understand the = macrolanguage it is=20 whether a user wants to return the related languages within the = macrolanguage; I=20 do understand that the end user would not want this in many cases = but where=20 is the harm in the provision?  If I was querying using prs I would=20 certainly want to have pes and fas tagged items returned as a secondary=20 match. 
 
Best regards
 
Debbie 

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 10 October 2007=20 16:55
To: Addison Phillips
Cc:=20 ltru@ietf.org
Subject: Re: [Ltru] Extended language tags = (long=20 reply)

Some detailed comments on these scenarios.

On 10/7/07, Addison=20 Phillips <addison@yahoo-inc.com>=20 wrote:=20
I=20 would say:

1. With Extlangs.

- change to filtering: = none, but=20 you probably want to use extended
filtering instead of basic = filtering=20 (i.e. "zh-Hant-HK" matches
"zh-yue-Hant-HK" and=20 "zh-cmn-Hant-HK")

Actually, I think the change is the reverse; you have to = disable=20 extended filtering. In the filtering / search business, it is just as = bad (if=20 not worse) to give too many responses as it is to give too few. = Otherwise your=20 user is swamped in irrelevant documents.

Except in very few = cases,=20 notably Arabic and Chinese, according to what I have heard Peter say, = we have=20 no reason to believe that a speaker of one microlanguage speaks any = other=20 particular macrolanguage. If my user searches for Fulah, and does s/he = want to=20 get Maasina Fulfulde, Adamawa Fulfulde, Pulaar, Central-Eastern Niger=20 Fulfulde, and so on, which I have no reason to believe that the = original=20 person speaks?

And even for Arabic and Chinese, unmodified = extended=20 filtering with extlang might make sense only because ar-arb is = equivalent to=20 arb and zh-cmn is equivalent to cmn, for all practical purposes, and = where all=20 speakers of the microlanguages understand the macrolanguages (which is = unclear=20 -- I've asked on the list whether the latter is true -- and it is a = crucial=20 fact for extlang -- but get no answer). Better is that if someone = really wants=20 both standard Arabic and Tajiki Arabic, than the input be "ar, abh", = just like=20 now with Norwegian or Serbo-croation, where someone can just list "nn, = nb, no"=20 and "sr, hr, bs, sh",

So with extlang we have a backwards=20 compatibility issue with extended filtering; we need to disable = macrolanguage=20 lookup in all but a few cases, and even there it is better for the = user to=20 just supply the list of items they want.

http://www.sil.or= g/iso639-3/macrolanguages.asp

-=20 change to lookup: treat extlang as atomic with the primary=20 language
subtag; potentially loop-back through the subtags. That = is,=20 given the
range "zh-yue-Hant-HK", the fallback pattern is=20 this:

  zh-yue-Hant-HK=20 =
  zh-yue-Hant
  zh-yue
  zh-Hant-= HK
  zh-Hant
  zh
  (default)

And again, we disable this for all but a few specific cases. = It only=20 makes sense to do this as a heuristic when the speaker of the = microlanguage is=20 extremely likely to speak the macrolanguage.

If the query is = Maasina=20 Fulfulde as used in Ghana (ful-)ffm-GH, we don't want to fall back to = some=20 arbitrary Fulah; instead we want to probably fall back to = Hausa.

And=20 this would need to be handled even more carefully where the input is = multiple=20 tags, as in Accept-Language. If the user supplies "zh-yue; en", = meaning that=20 they prefer Cantonese, then English -- and may not know Mandarin at = all! --=20 then the stated algorithm, the one that everyone uses now, would give=20 completely incorrect results.

(1) Incorrect
 =20 = zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
 =  zh
 =20 en
  (default)

Even the modified version doesn't=20 work

(2) Still incorrect
 =20 zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue=20 =
  zh-Hant-HK
  zh-Hant
  zh
&n= bsp;=20 en
  (default)

What we need to do is more=20 complicated:

(3) what the user asked for, Cantonese, then = English, then=20 maybe something else.
  = zh-yue-Hant-HK
  zh-yue-Hant=20
  zh-yue
  en
 =20 = zh-Hant-HK
  zh-Hant
  zh
  (defau= lt)

Number=20 3 is especially needed whenever the macrolanguage is not = overwhelmingly likely=20 to be understood by the macrolanguage users.

So with extlang we = also=20 have a backwards compatibility issue with lookup; code that used to = work fine=20 will fail.

Or=20 = this:

  zh-yue-Hant-HK
  zh-yue-Hant
&nb= sp; zh-yue
  (default)

This would be better, but still requires a change to = algorithms, and=20 then simply amounts to adding extlang, but coding around it so that = the=20 results were as if there were no extlang -- better to not use the = extlang=20 mechanism.

2.=20 Without extlangs.

- change to filtering: none

- change = to=20 lookup: none

Agreed so far, but...

BUT...=20 you want to include the macro language in your ranges in some =
cases.=20 Alternatively, we would have to define new filtering and = lookup
options=20 that include mapping to macrolanguages. For example, with = the
range=20 "yue-Hant-HK", you would want the fallback to=20 = be:

  yue-Hant-HK
  yue-Hant
  = ;yue
  zh-Hant-HK
  zh-Hant
  zh  (default)


In the case of no extlangs, we really do not want to make = any=20 changes to the algorithms. Instead, we want to point out in the text = that=20 macro languages *MAY* be a useful resource for having some extended = fallback.=20 That is, it *MAY* be reasonable to fall back from the Chinese and = Arabic=20 microlanguages to their macrolanguages, but also may not. And the = interaction=20 between this additional fallback and multiple tags needs to be taken = into=20 consideration.

Suppose that the input is "yue-Hant-HK; en"; = the=20 current algorithm works.

(1)
 =20 yue-Hant-HK
  yue-Hant
  yue
  = en
 =20 (default)

If a particular implementation wants to change the = default=20 processing to have an extra step that adds fallback to zh-Hant-HK (and = so on)=20 for certain specific languages, such as particular Chinese and Arabic=20 microlanguages, that's a small amount of work. Moreover, it is just = what a=20 more enhanced algorithm *currently* would do with any of "nn, nb, no" = and "sr,=20 hr, bs, sh", -- in this case they are known to be good, practical = fallbacks.=20

Alternatively, if the user just feeds in "yue-Hant-HK, en, = zh-Hant-HK"=20 or the reverse "yue-Hant-HK, zh-Hant-HK, en", that will work without = any code=20 changes, or any enhancements; the user gets what is asked for.=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

What = we don't want to do is make=20 recommendations that if implemented, are harder for people to control = and get=20 the right answer. And baking extlang into the tags is even worse -- = since it=20 introduces backwards incompatibilities that require old code to be = modified to=20 work around.

Someone mentioned on this list that they thought = that=20 these were only philosophical differences. I don't see it that way at = all. The=20 choices we make here will affect the ability of people to work with = their own=20 languages for a long time -- it is important to get this right, and = pay=20 attention both to backwards compatibility and to future capabilities = -- the=20 choice of architecture will make real, practical differences for = people,=20 especially for minority language users. My fear is exactly minority = language=20 users will be disadvantage with extlang. It isn't the French or German = speakers that will end up with problems; it is the Gondi and Grebo = speakers.=20

Mark
------=_NextPart_000_0599_01C80B62.5E417DB0-- --===============0857091542== 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 --===============0857091542==-- From ltru-bounces@ietf.org Wed Oct 10 13:44:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffb9-0007Tc-3B; Wed, 10 Oct 2007 13:43:55 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iffb7-0007TW-Kj for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 13:43:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffb7-0007SE-0j for ltru@ietf.org; Wed, 10 Oct 2007 13:43:53 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iffb6-0004SF-LE for ltru@ietf.org; Wed, 10 Oct 2007 13:43:52 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 10:43:51 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Wed, 10 Oct 2007 10:43:46 -0700 From: Shawn Steele To: "ltru@ietf.org" Date: Wed, 10 Oct 2007 10:43:43 -0700 Thread-Topic: duel(ing) tags Thread-Index: AcgLVq4EvlAcVpuwT4igtNbF/odZhwADhTng Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ltru] RE: duel(ing) 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 I was sort of wondering the same thing. I was thinking that to support mistakes, legacy tags & other randomness it = might be best if any matching stuff I wrote recognized that cmn & zh-cmn we= re interchangeable. It is unclear to me if data is currently tagged as cmn= though, although I know some is tagged as zh-cmn. - Shawn ------------------------------ Date: Wed, 10 Oct 2007 10:46:18 +0100 From: "Debbie Garside" Subject: RE: [Ltru] Re: Extended language tags To: , "'Doug Ewell'" , "'LTRU Working Group'" Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> Hi I may have missed the answer to this question, apologies if I have, but why not include cwm within the registry and then deprecate in favour of zh-cwm? This way both are in the registry and the fallback, as described by Mark, i= s facilitated. The same could be done for zh-yue and yue and no-nb etc. Thus if people tag "incorrectly", with, for example, cwm or yue, applications would come up with the correct match anyway. I cannot pretend that I understand the entirety of the current conversation= s wrt extended language tags but I do think their inclusion would be useful for matching purposes. Best regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 13:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffhC-000369-Ic; Wed, 10 Oct 2007 13:50:10 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IffhB-00035w-P6 for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 13:50:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffhB-00035i-DQ for ltru@ietf.org; Wed, 10 Oct 2007 13:50:09 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IffhA-0004jZ-NN for ltru@ietf.org; Wed, 10 Oct 2007 13:50:09 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 10:50:08 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Wed, 10 Oct 2007 10:50:07 -0700 From: Peter Constable To: LTRU Working Group Date: Wed, 10 Oct 2007 10:50:04 -0700 Subject: RE: [Ltru] Re: Extended language tags Thread-Topic: [Ltru] Re: Extended language tags Thread-Index: AcgK6/Vwsa2LXu2VQk2G0cUc2neoYAAeegaQ Message-ID: References: <00f501c80a7a$aca85520$6401a8c0@DGBP7M81> <005001c80aa5$463c55e0$6801a8c0@oemcomputer> <30b660a20710091340o50a0bd11taa6b6edaa7945885@mail.gmail.com> <470C4339.90901@yahoo-inc.com> In-Reply-To: <470C4339.90901@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1800845366==" Errors-To: ltru-bounces@ietf.org --===============1800845366== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgSSB3YXNuJ3QgYWJsZSB0byBjYWxsIGluIHRoaXMgbW9ybmluZy4gSGFkIGEgaGlnaCBw cmkvaGlnaCB1cmdlbmN5IHRhc2sgdG8gdGFrZSBjYXJlIG9mLg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWRkaXNvbiBQaGlsbGlwcyBbbWFpbHRvOmFkZGlzb25A eWFob28taW5jLmNvbV0NCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAwOSwgMjAwNyA4OjEzIFBN DQo+IFRvOiBNYXJrIERhdmlzDQo+IENjOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDog UmU6IFtMdHJ1XSBSZTogRXh0ZW5kZWQgbGFuZ3VhZ2UgdGFncw0KPg0KPiBKdXN0IEZZSSwgdG9t b3Jyb3cgbW9ybmluZyAoOSBhbSBQYWNpZmljKSBjYWxsIGNhbiBiZSBhY2Nlc3NlZDoNCj4NCj4g RGlhbC1JbiAjOiArMS44ODguMzcxLjg5MjINCj4NCj4gSW50ZXJuYXRpb25hbCBEaWFsLUluICM6 ICsxLjYxNy4yMjQuNDc5Mg0KPg0KPiBQYXJ0aWNpcGFudCBQYXNzY29kZTogNTgzNzE5NzINCj4N Cj4gQWRkaXNvbg0KPg0KPiBNYXJrIERhdmlzIHdyb3RlOg0KPiA+IEZpcnN0IG9mZiwgSSBhZ3Jl ZSB3aXRoIEFuZHkgdGhhdCB0aGUgZWRpdG9yJ3MgY29udHJpYnV0aW9ucyBzaG91bGQNCj4gYmUN Cj4gPiBqdWRnZWQgb24gdGVjaG5pY2FsIG1lcml0LCBqdXN0IGxpa2UgZXZlcnlvbmUgZWxzZSdz Lg0KPiA+DQo+ID4gQXMgZmFyIGFzIGEgY29uY2x1c2lvbiBnb2VzLiBBbnkganVkZ21lbnQgb2Yg Y29uc2Vuc3VzIGF0IHRoaXMgcG9pbnQNCj4gaXMNCj4gPiBwcmVtYXR1cmUuIFdlIGFyZSBpbmNy ZWFzaW5nIHRoZSBzaXplIG9mIHRoZSByZWdpc3RyeSBieSBhIGh1Z2UNCj4gbWFyZ2luLA0KPiA+ IGFuZCBjb25zaWRlcmluZyB3aGV0aGVyIHRvIGFkZCBhIHNpZ25pZmljYW50IHBpZWNlIG9mIGFy Y2hpdGVjdHVyZToNCj4gaXQNCj4gPiBpcyBtb3JlIGltcG9ydGFudCB0aGF0IHRoaXMgcmV2aXNp b24gYmUgY29ycmVjdGx5IGRlc2lnbmVkIHRoYW4gdGhhdA0KPiBpdA0KPiA+IG1lZXQgc29tZSBh cmJpdHJhcnkgZGVhZGxpbmUuIEkgdGhpbmsgdGhhdCB0aGUgdGVsZWNvbnMgaGF2ZSBiZWVuDQo+ ID4gdmFsdWFibGUgZm9yIGJyaW5naW5nIG91dCB0aGUgaXNzdWVzLCBhbmQgd2UgYWxyZWFkeSBw bGFubmVkIGZvcg0KPiBhbm90aGVyDQo+ID4gdGhpcyB3ZWVrLiBBcyBsb25nIGFzIHdlIGFyZSBt YWtpbmcgcHJvZ3Jlc3Mgd2l0aCB0aGF0LCB3ZSBzaG91bGQNCj4gPiBjb250aW51ZS4gSXQgaXMg dXNlZnVsIHdoZW4gdGhlIGNoYWlycyBjb3VsZCBtYWtlIHRoYXQgbWVldGluZzoNCj4gUmFuZHkn cw0KPiA+IGJlZW4gdG8gb25lIG9mIHRoZW0uIE1hcnRpbiwgaXMgdGhhdCB0aW1lIHRvbyBkaWZm aWN1bHQgZm9yIHlvdT8NCj4gPg0KPiA+IE1hcmsNCj4gPg0KPiA+IE9uIDEwLzkvMDcsICpSYW5k eSBQcmVzdWhuKiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbQ0KPiA+IDxtYWlsdG86cmFu ZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gICAgIEhpIC0NCj4g Pg0KPiA+ICAgICBBcyBjby1jaGFpci4uLg0KPiA+DQo+ID4gICAgICA+IEZyb206ICJEb3VnIEV3 ZWxsIiA8ZGV3ZWxsQHJvYWRydW5uZXIuY29tDQo+ID4gICAgIDxtYWlsdG86ZGV3ZWxsQHJvYWRy dW5uZXIuY29tPj4NCj4gPiAgICAgID4gVG86ICJMVFJVIFdvcmtpbmcgR3JvdXAiIDxsdHJ1QGll dGYub3JnDQo+IDxtYWlsdG86bHRydUBpZXRmLm9yZz4+DQo+ID4gICAgICA+IFNlbnQ6IFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMDcgNjo0NSBBTQ0KPiA+ICAgICAgPiBTdWJqZWN0OiBbTHRydV0g UmU6IEV4dGVuZGVkIGxhbmd1YWdlIHRhZ3MNCj4gPiAgICAgID4NCj4gPiAgICAgID4gUmFuZHkg UHJlc3VobiA8cmFuZHkgdW5kZXJzY29yZSBwcmVzdWhuIGF0IG1pbmRzcHJpbmcgZG90IGNvbT4N Cj4gd3JvdGU6DQo+ID4gICAgICA+DQo+ID4gICAgICA+ID4+IEhhcmQgdG8gc2F5LiAgSSB0aGlu ayBhdCB0aGlzIG1vbWVudCB0aGVyZSBhcmUgbW9yZQ0KPiA+ICAgICBjb250cmlidXRvcnMgd2hv DQo+ID4gICAgICA+ID4+IGZhdm9yICgxKSB0aGFuICgyKSwgYnV0IHRoZSB0d28gbWFpbiBwcm9w b25lbnRzIG9mICgyKSBhcmUNCj4gdGhlDQo+ID4gICAgICA+ID4+IGNvLWVkaXRvcnMgb2YgNDY0 NmJpcywgd2hpY2ggZG9lcyB0aXAgdGhlIGJhbGFuY2UgYSBiaXQuDQo+ID4gICAgICA+ID4NCj4g PiAgICAgID4gPiBObywgaXQgZG9lcyBub3QuICBFZGl0b3JzIGRvIHRoZSBiaWRkaW5nIG9mIHRo ZSBXRywgc2VlIFJGQw0KPiAyNDE4DQo+ID4gICAgICA+ID4gY2xhdXNlIDYuMy4gIEFzIHN1Y2gg dGhleSBhcmUgKm5vdCogZ2l2ZW4gc3BlY2lhbA0KPiBjb25zaWRlcmF0aW9uDQo+ID4gICAgIGlu IHRoZQ0KPiA+ICAgICAgPiA+IGRldGVybWluYXRpb24gb2Ygd29ya2luZyBncm91cCBjb25zZW5z dXMuDQo+ID4gICAgICA+DQo+ID4gICAgICA+IEJ1dCB0aGV5IG1pZ2h0IHdlbGwgYmUgZ2l2ZW4g c3BlY2lhbCBjb25zaWRlcmF0aW9uIGJ5IG90aGVyDQo+IGxpc3QNCj4gPiAgICAgbWVtYmVycw0K PiA+ICAgICAgPiB3aG8gaGF2ZW4ndCBtYWRlIHVwIHRoZWlyIG1pbmRzIHlldC4NCj4gPg0KPiA+ ICAgICBUaGlzIHdvdWxkIGJlIGEgYmFkIHRoaW5nLiAgUkZDIDI0MTggaXMgYWJ1bmRhbnRseSBj bGVhciB0aGF0DQo+IGRvY3VtZW50DQo+ID4gICAgIGVkaXRvcnMgZG8gbm90IGVuam95IGFueSBz cGVjaWFsIHByaXZpbGVnZXMgaW4gZGV0ZXJtaW5pbmcgV0cNCj4gY29uc2Vuc3VzLg0KPiA+ICAg ICBTb21ldGltZXMgZWRpdG9ycyBoYXBwZW4gdG8gYmUgZXhwZXJ0cyBpbiB0aGUgdG9waWMsIHNv bWV0aW1lcw0KPiB0aGV5DQo+ID4gICAgIGFyZSBub3QuDQo+ID4gICAgIEJ1dCBpZiBhIFdHIHN0 YXJ0cyBnaXZpbmcgdGhlaXIgdm9pY2VzIG1vcmUgd2VpZ2h0IG1lcmVseSBiZWNhdXNlDQo+IHRo ZXkNCj4gPiAgICAgaGFwcGVuIHRvIGJlIGVkaXRvcnMsIHNvbWV0aGluZyBpcyBzZXJpb3VzbHkg d3JvbmcuDQo+ID4NCj4gPiAgICAgID4gIEkgd291bGQgZ3Vlc3MgdGhhdCB3aXRoIHRoZSBzbWFs bA0KPiA+ICAgICAgPiBudW1iZXIgb2YgcGVvcGxlIHNvbGlkbHkgb24gb25lIHNpZGUgb3IgdGhl IG90aGVyLCB0aGUgYmF0dGxlDQo+IGZvcg0KPiA+ICAgICB0aGUNCj4gPiAgICAgID4gInVuZGVj aWRlZCIgYmxvYyB3aWxsIGJlIGltcG9ydGFudC4NCj4gPg0KPiA+ICAgICBQZXJoYXBzLCB0aG91 Z2ggdGhlIHVuZGVjaWRlZCBoYXZlIGxpdHRsZSBpbXBvcnQgZm9yIGENCj4gZGV0ZXJtaW5hdGlv bg0KPiA+ICAgICBvZiByb3VnaCBjb25zZW5zdXMuICBBdCBzb21lIHBvaW50IE1hcnRpbiBhbmQg SSB3aWxsIGhhdmUgdG8gbWFrZQ0KPiA+ICAgICBhIGRldGVybWluYXRpb24gb2YgY29uc2Vuc3Vz LiAgSXQncyBjbGVhciB0aGF0IG5vbmUgb2YgdGhlDQo+IG9wdGlvbnMNCj4gPiAgICAgd2lsbCBt YWtlIGV2ZXJ5b25lIGhhcHB5LiAgSXQncyBwb3NzaWJsZSB0aGF0IG5vbmUgb2YgdGhlIG9wdGlv bnMNCj4gPiAgICAgd2lsbCBtYWtlIGFueW9uZSBoYXBweSBpbiB0aGUgbG9uZyBydW4uICBTaW5j ZSB0aGVyZSBoYXMgYmVlbiBzbw0KPiBsaXR0bGUNCj4gPiAgICAgaW4gdGhlIHdheSBvZiBuZXcg aW5mb3JtYXRpb24gb3IgYXJndW1lbnRzIGluIHRoaXMgZGlzY3Vzc2lvbiwNCj4gPiAgICAgSSB0 aGluayBNYXJ0aW4gYW5kIEkgd2lsbCBqdXN0IGhhdmUgdG8gcGljayBvbmUsIGJhc2VkIG9uIHRo ZQ0KPiBvcGluaW9ucw0KPiA+ICAgICBleHByZXNzZWQgb24gdGhpcyBsaXN0IHNvIGZhciwgc2lu Y2UgZmV3IG5ldyB2b2ljZXMgc2VlbSB0byBiZQ0KPiBqb2luaW5nDQo+ID4gICAgIGluIHRvIGV4 cHJlc3MgYSBwcmVmZXJlbmNlLg0KPiA+DQo+ID4gICAgIFJhbmR5DQo+ID4NCj4gPg0KPiA+DQo+ ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gICAgIEx0cnUgbWFpbGluZyBsaXN0DQo+ID4gICAgIEx0cnVAaWV0Zi5vcmcgPG1haWx0bzpM dHJ1QGlldGYub3JnPg0KPiA+ICAgICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sdHJ1DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+IE1hcmsNCj4gPg0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+IEx0 cnVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1DQo+DQo+IC0tDQo+IEFkZGlzb24gUGhpbGxpcHMNCj4gR2xvYmFsaXphdGlvbiBBcmNoaXRl Y3QgLS0gWWFob28hIEluYy4NCj4gQ2hhaXIgLS0gVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENv cmUgV0cNCj4NCj4gSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgYW4gYXJjaGl0ZWN0dXJlLg0KPiBJ dCBpcyBub3QgYSBmZWF0dXJlLg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============1800845366== 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 --===============1800845366==-- From ltru-bounces@ietf.org Wed Oct 10 13:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffp8-0006R0-Sp; Wed, 10 Oct 2007 13:58:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iffp7-0006Qm-I1 for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 13:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffp7-0006ON-8D for ltru@ietf.org; Wed, 10 Oct 2007 13:58:21 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound3-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iffov-0002i2-V6 for ltru@ietf.org; Wed, 10 Oct 2007 13:58:16 -0400 Received: from outbound3-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-cpk-R.bigfish.com (Postfix) with ESMTP id 8BC269956DC; Wed, 10 Oct 2007 17:57:50 +0000 (UTC) Received: from mail21-cpk-R.bigfish.com (unknown [10.2.40.3]) by outbound3-cpk.bigfish.com (Postfix) with ESMTP id 1148E800054; Wed, 10 Oct 2007 17:57:50 +0000 (UTC) Received: from mail21-cpk (localhost.localdomain [127.0.0.1]) by mail21-cpk-R.bigfish.com (Postfix) with ESMTP id F1F55AF0401; Wed, 10 Oct 2007 17:57:49 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail21-cpk (MessageSwitch) id 1192039069906492_21404; Wed, 10 Oct 2007 17:57:49 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail21-cpk.bigfish.com (Postfix) with ESMTP id CC7551B007C; Wed, 10 Oct 2007 17:57:49 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007101010574771-264925 ; Wed, 10 Oct 2007 10:57:47 -0700 In-Reply-To: <470C4339.90901@yahoo-inc.com> To: Addison Phillips Subject: Re: [Ltru] Re: Extended language tags MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 10 Oct 2007 10:55:21 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/10/2007 10:55:22, Serialize complete at 10/10/2007 10:55:22, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 10:57:47 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 10:57:49 AM, Serialize complete at 10/10/2007 10:57:49 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -4.0 (----) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 This e-mail went out too late for me to participate. Please try to send notice before the close of business the day before the call. Karen Broome Addison Phillips 10/09/2007 08:12 PM To Mark Davis cc LTRU Working Group Subject Re: [Ltru] Re: Extended language tags Just FYI, tomorrow morning (9 am Pacific) call can be accessed: Dial-In #: +1.888.371.8922 International Dial-In #: +1.617.224.4792 Participant Passcode: 58371972 Addison Mark Davis wrote: > First off, I agree with Andy that the editor's contributions should be > judged on technical merit, just like everyone else's. > > As far as a conclusion goes. Any judgment of consensus at this point is > premature. We are increasing the size of the registry by a huge margin, > and considering whether to add a significant piece of architecture: it > is more important that this revision be correctly designed than that it > meet some arbitrary deadline. I think that the telecons have been > valuable for bringing out the issues, and we already planned for another > this week. As long as we are making progress with that, we should > continue. It is useful when the chairs could make that meeting: Randy's > been to one of them. Martin, is that time too difficult for you? > > Mark > > On 10/9/07, *Randy Presuhn* > wrote: > > Hi - > > As co-chair... > > > From: "Doug Ewell" > > > To: "LTRU Working Group" > > > Sent: Tuesday, October 09, 2007 6:45 AM > > Subject: [Ltru] Re: Extended language tags > > > > Randy Presuhn wrote: > > > > >> Hard to say. I think at this moment there are more > contributors who > > >> favor (1) than (2), but the two main proponents of (2) are the > > >> co-editors of 4646bis, which does tip the balance a bit. > > > > > > No, it does not. Editors do the bidding of the WG, see RFC 2418 > > > clause 6.3. As such they are *not* given special consideration > in the > > > determination of working group consensus. > > > > But they might well be given special consideration by other list > members > > who haven't made up their minds yet. > > This would be a bad thing. RFC 2418 is abundantly clear that document > editors do not enjoy any special privileges in determining WG consensus. > Sometimes editors happen to be experts in the topic, sometimes they > are not. > But if a WG starts giving their voices more weight merely because they > happen to be editors, something is seriously wrong. > > > I would guess that with the small > > number of people solidly on one side or the other, the battle for > the > > "undecided" bloc will be important. > > Perhaps, though the undecided have little import for a determination > of rough consensus. At some point Martin and I will have to make > a determination of consensus. It's clear that none of the options > will make everyone happy. It's possible that none of the options > will make anyone happy in the long run. Since there has been so little > in the way of new information or arguments in this discussion, > I think Martin and I will just have to pick one, based on the opinions > expressed on this list so far, since few new voices seem to be joining > in to express a preference. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 14:02:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffsl-0002E6-EB; Wed, 10 Oct 2007 14:02:07 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iffsk-000242-2A for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:02:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffsj-00021w-LU for ltru@ietf.org; Wed, 10 Oct 2007 14:02:05 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iffsi-00057Z-Uh for ltru@ietf.org; Wed, 10 Oct 2007 14:02:05 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 11:02:03 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Wed, 10 Oct 2007 11:02:03 -0700 From: Shawn Steele To: Mark Davis , Addison Phillips Date: Wed, 10 Oct 2007 11:02:01 -0700 Subject: RE: [Ltru] Extended language tags (long reply) Thread-Topic: [Ltru] Extended language tags (long reply) Thread-Index: AcgLV9bSZPjEpSv6Q221PL+RneS7+AADmQkQ Message-ID: References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> In-Reply-To: <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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="===============1795232004==" Errors-To: ltru-bounces@ietf.org --===============1795232004== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C9BF0238EED3634BA1866AEF14C7A9E55A598803B7NAEXMSGC116re_" --_000_C9BF0238EED3634BA1866AEF14C7A9E55A598803B7NAEXMSGC116re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PQ0KDQpXaGF0IHdlIGRvbid0IHdhbnQgdG8gZG8gaXMgbWFrZSByZWNv bW1lbmRhdGlvbnMgdGhhdCBpZiBpbXBsZW1lbnRlZCwgYXJlIGhhcmRlciBmb3IgcGVvcGxlIHRv IGNvbnRyb2wgYW5kIGdldCB0aGUgcmlnaHQgYW5zd2VyLiBBbmQgYmFraW5nIGV4dGxhbmcgaW50 byB0aGUgdGFncyBpcyBldmVuIHdvcnNlIC0tIHNpbmNlIGl0IGludHJvZHVjZXMgYmFja3dhcmRz IGluY29tcGF0aWJpbGl0aWVzIHRoYXQgcmVxdWlyZSBvbGQgY29kZSB0byBiZSBtb2RpZmllZCB0 byB3b3JrIGFyb3VuZC4NCg0KPT09PT09PT09PT09PT09PQ0KDQpjbW4gaXMgY29tcGxldGVseSBp bmNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBwcmFjdGljZSBhbnl3YXksIHNvIHlvdSBjYW7igJl0 IGNsYWltIHRoYXQgaXQgc29sdmVzIHRoZSBwcm9ibGVtLiAgRXhpc3RpbmcgY2xpZW50cyBhc2sg Zm9yIHpoLUhLIChvciB3aGF0ZXZlcikgYW5kIGNvZGUgaXMgdGFnZ2VkIGFzIHpoLUhLIChvciB3 aGF0ZXZlcikuICBUaG9zZSB3b27igJl0IG1hdGNoIGNtbiB1c2luZyBSRkMgNDY0Ny4NCg0KU28g Zm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHpoLWNtbiBpcyBubyB3b3JzZSB0aGFuIGNtbi4g IEFuZCBpZiB5b3UgZG9u4oCZdCBsaWtlIHRoZSBpbmZlcmVuY2Ugb2YgdGhlIHpoLCB0aGVuIHlv dSBjYW4gaWdub3JlIHRoYXQgcGFydCwgYnV0IGF0IGxlYXN0IHRoZSBkYXRh4oCZcyB0aGVyZSBp ZiBwZW9wbGUgZG8gd2FudCBpdC4NCg0KRm9yIHNvbWUgbWFjcm8gbGFuZ3VhZ2VzIHRoZSBzdHJp Y3QgZmFsbGJhY2sgaXMgcHJvYmFibHkgaW5hcHByb3ByaWF0ZSwgaG93ZXZlciBJIGRvbuKAmXQg ZXhwZWN0IHRvIGZpbmQgbWF0Y2hlcyBpbiB0aGF0IGNhc2UgKGJlY2F1c2UgSSBkb27igJl0IGV4 cGVjdCBjb3JyZWN0bHkgdGFnZ2VkIGRhdGEgdG8gYmUg4oCcemjigJ0pLiAgSWYgdGhpcyBpcyBh IGNvbmNlcm4sIHRob3NlIGFyZSBlYXNpbHkgZmlsdGVyZWQgb3V0Lg0KDQpGcm9tIHRoZSBkaXNj dXNzaW9uIEkgZG9u4oCZdCB0aGluayB0aGUgYmlnZ2VyIHByb2JsZW0gaXMgd2hldGhlciBvciBu b3Qgd2UgZ28gd2l0aCB6aC1jbW4gb3IganVzdCBjbW4uICBUaGUgYmlnZ2VyIGlzc3VlIHNlZW1z IHRvIGJlIGhvdyB0byBtb2RpZnkgUkZDIDQ2NDcgdG8gcHJvdmlkZSBtZWFuaW5nZnVsIGZhbGxi YWNrIHdpdGggd2hpY2hldmVyIG1vZGUgaXMgdXNlZC4gIFNpbmNlIHNvbWUgYXBwbGljYXRpb25z IG1heSAob3IgbWF5IG5vdCkgd2FudCB0byBjb25zaWRlciB6aC1ISyBvciBvdGhlciBsZWdhY3kg YmVoYXZpb3JzLCBzdWNoIHJlY29tbWVuZGF0aW9ucyBhcmVu4oCZdCB0cml2aWFsLiAgR2l2ZW4g dGhlIGRpZmZlcmluZyByZXF1aXJlbWVudHMgYW1vbmdzdCB1cywgSSBzdXNwZWN0IGEgY2VydGFp biBmbGV4aWJpbGl0eSBvZiB0aGUgYXBwbGljYXRpb25zIHdpbGwgYmUgbmVjZXNzYXJ5LCBwZXJo YXBzIHNldmVyYWwgc3VnZ2VzdGlvbnMgcmF0aGVyIHRoYW4gdGhlIHN0cmljdCBiZWhhdmlvciBv ZiBSRkMgNDY0NyAod2hpY2ggZXZlcnlvbmUgc2VlbXMgdG8gbW9kaWZ5IGZvciB0aGVpciBwdXJw b3NlcyBhbnl3YXkpDQoNCi0gU2hhd24NCg== --_000_C9BF0238EED3634BA1866AEF14C7A9E55A598803B7NAEXMSGC116re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1hbmdh bDsNCglwYW5vc2UtMToyIDQgNSAzIDUgMiAzIDMgMiAyO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5nbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmdtYWls X3F1b3RlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxl Pg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxk aXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD49PT09PT09PT09PT09PT09PGJyPg0KPGJyPg0KV2hhdCB3ZSBkb24ndCB3YW50IHRvIGRvIGlz IG1ha2UgcmVjb21tZW5kYXRpb25zIHRoYXQgaWYgaW1wbGVtZW50ZWQsIGFyZQ0KaGFyZGVyIGZv ciBwZW9wbGUgdG8gY29udHJvbCBhbmQgZ2V0IHRoZSByaWdodCBhbnN3ZXIuIEFuZCBiYWtpbmcg ZXh0bGFuZyBpbnRvDQp0aGUgdGFncyBpcyBldmVuIHdvcnNlIC0tIHNpbmNlIGl0IGludHJvZHVj ZXMgYmFja3dhcmRzIGluY29tcGF0aWJpbGl0aWVzIHRoYXQNCnJlcXVpcmUgb2xkIGNvZGUgdG8g YmUgbW9kaWZpZWQgdG8gd29yayBhcm91bmQuIDxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD49 PT09PT09PT09PT09PT09PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xv cjojMUY0OTdEJz5jbW4gaXMgY29tcGxldGVseSBpbmNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBw cmFjdGljZSBhbnl3YXksIHNvDQp5b3UgY2Fu4oCZdCBjbGFpbSB0aGF0IGl0IHNvbHZlcyB0aGUg cHJvYmxlbS7CoCBFeGlzdGluZyBjbGllbnRzIGFzayBmb3IgemgtSEsgKG9yDQp3aGF0ZXZlcikg YW5kIGNvZGUgaXMgdGFnZ2VkIGFzIHpoLUhLIChvciB3aGF0ZXZlcikuwqAgVGhvc2Ugd29u4oCZ dCBtYXRjaCBjbW4NCnVzaW5nIFJGQyA0NjQ3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+U28gZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHpoLWNtbiBpcyBubyB3b3JzZSB0aGFu IGNtbi7CoCBBbmQNCmlmIHlvdSBkb27igJl0IGxpa2UgdGhlIGluZmVyZW5jZSBvZiB0aGUgemgs IHRoZW4geW91IGNhbiBpZ25vcmUgdGhhdCBwYXJ0LCBidXQNCmF0IGxlYXN0IHRoZSBkYXRh4oCZ cyB0aGVyZSBpZiBwZW9wbGUgZG8gd2FudCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPkZvciBzb21lIG1hY3JvIGxhbmd1YWdlcyB0aGUgc3RyaWN0IGZhbGxiYWNrIGlzIHByb2Jh Ymx5DQppbmFwcHJvcHJpYXRlLCBob3dldmVyIEkgZG9u4oCZdCBleHBlY3QgdG8gZmluZCBtYXRj aGVzIGluIHRoYXQgY2FzZSAoYmVjYXVzZSBJDQpkb27igJl0IGV4cGVjdCBjb3JyZWN0bHkgdGFn Z2VkIGRhdGEgdG8gYmUg4oCcemjigJ0pLsKgIElmIHRoaXMgaXMgYSBjb25jZXJuLCB0aG9zZQ0K YXJlIGVhc2lseSBmaWx0ZXJlZCBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5G cm9tIHRoZSBkaXNjdXNzaW9uIEkgZG9u4oCZdCB0aGluayB0aGUgYmlnZ2VyIHByb2JsZW0gaXMg d2hldGhlcg0Kb3Igbm90IHdlIGdvIHdpdGggemgtY21uIG9yIGp1c3QgY21uLsKgIFRoZSBiaWdn ZXIgaXNzdWUgc2VlbXMgdG8gYmUgaG93IHRvDQptb2RpZnkgUkZDIDQ2NDcgdG8gcHJvdmlkZSBt ZWFuaW5nZnVsIGZhbGxiYWNrIHdpdGggd2hpY2hldmVyIG1vZGUgaXMgdXNlZC7CoA0KU2luY2Ug c29tZSBhcHBsaWNhdGlvbnMgbWF5IChvciBtYXkgbm90KSB3YW50IHRvIGNvbnNpZGVyIHpoLUhL IG9yIG90aGVyIGxlZ2FjeQ0KYmVoYXZpb3JzLCBzdWNoIHJlY29tbWVuZGF0aW9ucyBhcmVu4oCZ dCB0cml2aWFsLsKgIEdpdmVuIHRoZSBkaWZmZXJpbmcNCnJlcXVpcmVtZW50cyBhbW9uZ3N0IHVz LCBJIHN1c3BlY3QgYSBjZXJ0YWluIGZsZXhpYmlsaXR5IG9mIHRoZSBhcHBsaWNhdGlvbnMNCndp bGwgYmUgbmVjZXNzYXJ5LCBwZXJoYXBzIHNldmVyYWwgc3VnZ2VzdGlvbnMgcmF0aGVyIHRoYW4g dGhlIHN0cmljdCBiZWhhdmlvcg0Kb2YgUkZDIDQ2NDcgKHdoaWNoIGV2ZXJ5b25lIHNlZW1zIHRv IG1vZGlmeSBmb3IgdGhlaXIgcHVycG9zZXMgYW55d2F5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+LSBTaGF3bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_C9BF0238EED3634BA1866AEF14C7A9E55A598803B7NAEXMSGC116re_-- --===============1795232004== 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 --===============1795232004==-- From ltru-bounces@ietf.org Wed Oct 10 14:24:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgE8-0001mq-6d; Wed, 10 Oct 2007 14:24:12 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfgE7-0001ml-9h for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgE7-0001md-02 for ltru@ietf.org; Wed, 10 Oct 2007 14:24:11 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfgE0-0003Xs-Lk for ltru@ietf.org; Wed, 10 Oct 2007 14:24:10 -0400 Received: by wa-out-1112.google.com with SMTP id k40so494680wah for ; Wed, 10 Oct 2007 11:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=FmTtAEkuGBDOgWD2SIsjEow+joCc1FNLvSc8R41A6Mo=; b=oOL0goMCXCg57bujmk4Mn/Lk2VArDNjPS9IZB2sZcS5RUmVUG65PjcHgv2fFq4QFUcI4nM6WymYDvOAdii41auM1996ph7uR3KBpef5jljJreh44DHHCsXNhD/cUPpN1P3WjBcpsx/ZUa5oi2bcQi0CQZfLY7Ro+DGTxo9FrynA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=DfJ3KDVK/dPn4wcgodL+Q+IuXCkmMgOyJKLZx2ItkhvKJ5yFihN71G1SVlroBRM7YkYO10GGZ3fBHddiVWtkdhLDRGFiiOE7yZca10RFGFdGDEXqGpj8yKxUBIkIyTQ9gNtanScNuSgRCIvfR6AAOLqk884jJpPA1BFZP080uFQ= Received: by 10.114.149.2 with SMTP id w2mr1128801wad.1192040628864; Wed, 10 Oct 2007 11:23:48 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 10 Oct 2007 11:23:48 -0700 (PDT) Message-ID: <30b660a20710101123i709d06eeqbbb9bdc8c117da5e@mail.gmail.com> Date: Wed, 10 Oct 2007 11:23:48 -0700 From: "Mark Davis" To: "Shawn Steele" Subject: Re: [Ltru] RE: duel(ing) tags In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 6a114e7e3e73bf92 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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="===============1115062053==" Errors-To: ltru-bounces@ietf.org --===============1115062053== Content-Type: multipart/alternative; boundary="----=_Part_10734_21934470.1192040628857" ------=_Part_10734_21934470.1192040628857 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Even if we have extlang, I have no doubt that in practice we'll need to treat "yue" and "zh-yue" as equivalent, and so forth. In addition, in practice, you'll need to treat "cmn"/"zh-cmn" and "zh" as equivalent. Mark On 10/10/07, Shawn Steele wrote: > > I was sort of wondering the same thing. > > I was thinking that to support mistakes, legacy tags & other randomness it > might be best if any matching stuff I wrote recognized that cmn & zh-cmn > were interchangeable. It is unclear to me if data is currently tagged as > cmn though, although I know some is tagged as zh-cmn. > > - Shawn > > ------------------------------ > > Date: Wed, 10 Oct 2007 10:46:18 +0100 > From: "Debbie Garside" > Subject: RE: [Ltru] Re: Extended language tags > To: , "'Doug Ewell'" > , "'LTRU Working Group'" < > ltru@ietf.org> > Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> > > Hi > > I may have missed the answer to this question, apologies if I have, but > why > not include cwm within the registry and then deprecate in favour of > zh-cwm? > This way both are in the registry and the fallback, as described by Mark, > is > facilitated. The same could be done for zh-yue and yue and no-nb > etc. Thus > if people tag "incorrectly", with, for example, cwm or yue, applications > would come up with the correct match anyway. > > I cannot pretend that I understand the entirety of the current > conversations > wrt extended language tags but I do think their inclusion would be useful > for matching purposes. > > Best regards > > Debbie Garside > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_10734_21934470.1192040628857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Even if we have extlang, I have no doubt that in practice we'll need to treat "yue" and "zh-yue" as equivalent, and so forth. In addition, in practice, you'll need to treat "cmn"/"zh-cmn" and "zh" as equivalent.

Mark

On 10/10/07, Shawn Steele <Shawn.Steele@microsoft.com> wrote:
I was sort of wondering the same thing.

I was thinking that to support mistakes, legacy tags & other randomness it might be best if any matching stuff I wrote recognized that cmn & zh-cmn were interchangeable.  It is unclear to me if data is currently tagged as cmn though, although I know some is tagged as zh-cmn.

- Shawn

------------------------------

Date: Wed, 10 Oct 2007 10:46:18 +0100
From: "Debbie Garside" <debbie@ictmarketing.co.uk>
Subject: RE: [Ltru] Re: Extended language tags
To: <Shawn.Steele@microsoft.com>, "'Doug Ewell'"
        <dewell@roadrunner.com>,        "'LTRU Working Group'" < ltru@ietf.org>
Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110>

Hi

I may have missed the answer to this question, apologies if I have, but why
not include cwm within the registry and then deprecate in favour of zh-cwm?
This way both are in the registry and the fallback, as described by Mark, is
facilitated. The same could be done for zh-yue and yue and no-nb etc.  Thus
if people tag "incorrectly", with, for example, cwm or yue, applications
would come up with the correct match anyway.

I cannot pretend that I understand the entirety of the current conversations
wrt extended language tags but I do think their inclusion would be useful
for matching purposes.

Best regards

Debbie Garside



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



--
Mark ------=_Part_10734_21934470.1192040628857-- --===============1115062053== 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 --===============1115062053==-- From ltru-bounces@ietf.org Wed Oct 10 14:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgIJ-0004SJ-Gd; Wed, 10 Oct 2007 14:28:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfgII-0004SC-1K for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:28:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgIH-0004PM-Md for ltru@ietf.org; Wed, 10 Oct 2007 14:28:29 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound4-cpk-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfgID-0005vZ-0y for ltru@ietf.org; Wed, 10 Oct 2007 14:28:25 -0400 Received: from outbound4-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-cpk-R.bigfish.com (Postfix) with ESMTP id 909FA908432; Wed, 10 Oct 2007 18:28:24 +0000 (UTC) Received: from mail66-cpk-R.bigfish.com (unknown [10.2.40.3]) by outbound4-cpk.bigfish.com (Postfix) with ESMTP id 8EB8BAC0002; Wed, 10 Oct 2007 18:28:24 +0000 (UTC) Received: from mail66-cpk (localhost.localdomain [127.0.0.1]) by mail66-cpk-R.bigfish.com (Postfix) with ESMTP id 8287A1F80C4; Wed, 10 Oct 2007 18:28:24 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail66-cpk (MessageSwitch) id 1192040904468345_31880; Wed, 10 Oct 2007 18:28:24 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail66-cpk.bigfish.com (Postfix) with ESMTP id 674B4708069; Wed, 10 Oct 2007 18:28:23 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007101011281818-267116 ; Wed, 10 Oct 2007 11:28:18 -0700 In-Reply-To: To: Shawn Steele Subject: RE: [Ltru] Extended language tags (long reply) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 10 Oct 2007 11:25:53 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/10/2007 11:25:52, Serialize complete at 10/10/2007 11:25:52, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 11:28:18 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 11:28:23 AM, Serialize complete at 10/10/2007 11:28:23 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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="===============0996362177==" Errors-To: ltru-bounces@ietf.org --===============0996362177== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" SSB0aGluayBpZiBtZWFuaW5nZnVsIGZhbGxiYWNrIGlzIHRoZSBnb2FsLCB5b3UgbmVlZCB0byBj b25zaWRlciBib3RoIA0KYXVkaW8gYW5kIHRleHR1YWwgZm9ybXMgb2YgbGFuZ3VhZ2VzIGFuZCB0 aGVpciByZXNwZWN0aXZlIGZhbGxiYWNrIA0KbWVjaGFuaXNtcy4gV2hpbGUgYSBmYWxsYmFjayB0 byAiemgiIChmcm9tICJ6aC1jbW4iIG9yICJ6aC1ISyIsIGV0Yy4pIA0Kd291bGQgbGlrZWx5IGJl IHVzZWZ1bCBpbiB3cml0dGVuIGNvbnRleHRzLCBmYWxsaW5nIGJhY2sgdG8gc3Bva2VuICJ6aCIg DQpmcm9tIHNwb2tlbiAiY21uIiBtYXkgcHJvdmlkZSBzb21ldGhpbmcgdW5pbnRlbGxpZ2libGUu IA0KDQpJbiB0aGUgY29udGV4dCBvZiBteSBpbmR1c3RyeSwgaXQgd291bGQgbGlrZWx5IGJlIHVz ZWZ1bCBmb3IgYSBDYW50b25lc2UgDQpzcGVha2VyIHRvIGJlIGFibGUgdG8gZmluZCBzdWJ0aXRs ZWQgZmlsbXMgaW4gInpoIiBpZiAiemgteXVlIiBpcyBub3QgDQphdmFpbGFibGUuIE9idmlvdXNs eSB0aGVyZSBhcmUgcXVlc3Rpb25zIG9mIHNpbXBsaWZpZWQgdnMuIHRyYWRpdGlvbmFsIA0Kb3J0 aG9ncmFwaHksIGJ1dCB0aGUgInpoIiB0YWcgYWxvbmUgZW5jb21wYXNzZXMgYm90aCBvcnRob2dy YXBoaWVzLiBCdXQgaWYgDQp0aGUgQ2FudG9uZXNlIHNwZWFrZXIgaXMgbG9va2luZyBhdCBkdWJi ZWQgZmlsbXMsIGEgZmFsbGJhY2sgdG8gc3Bva2VuIA0KInpoLWNtbiIgaXMgbm90IGFzIGxpa2Vs eSB0byBiZSB1c2VmdWwuDQoNCkZyb20gd2hhdCBJIHVuZGVyc3RhbmQgdGhlIHNhbWUgaXMgdHJ1 ZSBpbiB3cml0dGVuIER1dGNoIHZzLiBzcG9rZW4gDQpGbGVtaXNoIC0tIGEgRmxlbWlzaCBzcGVh a2VyIG1heSBiZSBhYmxlIHRvIGVhc2lseSByZWFkIHN0YW5kYXJkIER1dGNoLCANCmJ1dCB0aGUg c3Bva2VuIGZvcm1zIGNhbiBjcmVhdGUgcHJvYmxlbXMgb2YgdW5kZXJzdGFuZGluZyB0byB0aGUg cG9pbnQgDQp3aGVyZSBEdXRjaCBpcyBzdWJ0aXRsZWQgaW4gQmVsZ2l1bS4gKEkgc3RpbGwgZG9u J3Qga25vdyB3aGV0aGVyICJ2bHMiIA0KKDYzOS0zKSBmYWxscyBiYWNrIHRvICJubGQvZHV0IiBp biA2MzktMiwgdGhvdWdoIEZsZW1pc2ggaXMgY2l0ZWQgYXMgYSANCnN5bm9ueW0gZm9yIFZsYWFt cyBpbiA2MzktMy4pDQoNClBsZWFzZSBjb25zaWRlciB0aGUgbmF0dXJlIG9mIGJvdGggYXVkaW8g YW5kIHdyaXR0ZW4gbGFuZ3VhZ2Ugd2l0aCByZXNwZWN0IA0KdG8gZXh0IGxhbmdzLiBJIHRoaW5r IHlvdSdsbCBmaW5kIHdoYXQgbWFrZXMgc2Vuc2UgZm9yIGZhbGxiYWNrIGRlcGVuZHMgb24gDQp0 aGVzZSBkaXN0aW5jdGlvbnMgaW4gbWFueSBvdGhlciBjYXNlcyB0aGFuIHRob3NlIEkndmUgbWVu dGlvbmVkLiANCg0KUmVnYXJkcywNCg0KS2FyZW4gQnJvb21lDQpNZXRhZGF0YSBTeXN0ZW1zIERl c2lnbmVyDQpTb255IFBpY3R1cmVzIEVudGVydGFpbm1lbnQNCjMxMC4yNDQuNDM4NA0KDQoNCg0K U2hhd24gU3RlZWxlIDxTaGF3bi5TdGVlbGVAbWljcm9zb2Z0LmNvbT4gDQoxMC8xMC8yMDA3IDEx OjAyIEFNDQoNClRvDQpNYXJrIERhdmlzIDxtYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz4sIEFk ZGlzb24gUGhpbGxpcHMgDQo8YWRkaXNvbkB5YWhvby1pbmMuY29tPg0KY2MNCiJsdHJ1QGlldGYu b3JnIiA8bHRydUBpZXRmLm9yZz4NClN1YmplY3QNClJFOiBbTHRydV0gRXh0ZW5kZWQgbGFuZ3Vh Z2UgdGFncyAobG9uZyByZXBseSkNCg0KDQoNCg0KDQoNCj09PT09PT09PT09PT09PT0NCg0KV2hh dCB3ZSBkb24ndCB3YW50IHRvIGRvIGlzIG1ha2UgcmVjb21tZW5kYXRpb25zIHRoYXQgaWYgaW1w bGVtZW50ZWQsIGFyZSANCmhhcmRlciBmb3IgcGVvcGxlIHRvIGNvbnRyb2wgYW5kIGdldCB0aGUg cmlnaHQgYW5zd2VyLiBBbmQgYmFraW5nIGV4dGxhbmcgDQppbnRvIHRoZSB0YWdzIGlzIGV2ZW4g d29yc2UgLS0gc2luY2UgaXQgaW50cm9kdWNlcyBiYWNrd2FyZHMgDQppbmNvbXBhdGliaWxpdGll cyB0aGF0IHJlcXVpcmUgb2xkIGNvZGUgdG8gYmUgbW9kaWZpZWQgdG8gd29yayBhcm91bmQuIA0K DQo9PT09PT09PT09PT09PT09DQoNCmNtbiBpcyBjb21wbGV0ZWx5IGluY29tcGF0aWJsZSB3aXRo IGV4aXN0aW5nIHByYWN0aWNlIGFueXdheSwgc28geW91IGNhbuKAmXQgDQpjbGFpbSB0aGF0IGl0 IHNvbHZlcyB0aGUgcHJvYmxlbS4gIEV4aXN0aW5nIGNsaWVudHMgYXNrIGZvciB6aC1ISyAob3Ig DQp3aGF0ZXZlcikgYW5kIGNvZGUgaXMgdGFnZ2VkIGFzIHpoLUhLIChvciB3aGF0ZXZlcikuICBU aG9zZSB3b27igJl0IG1hdGNoIA0KY21uIHVzaW5nIFJGQyA0NjQ3Lg0KIA0KU28gZm9yIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IHpoLWNtbiBpcyBubyB3b3JzZSB0aGFuIGNtbi4gIEFuZCBpZiB5 b3UgDQpkb27igJl0IGxpa2UgdGhlIGluZmVyZW5jZSBvZiB0aGUgemgsIHRoZW4geW91IGNhbiBp Z25vcmUgdGhhdCBwYXJ0LCBidXQgYXQgDQpsZWFzdCB0aGUgZGF0YeKAmXMgdGhlcmUgaWYgcGVv cGxlIGRvIHdhbnQgaXQuDQogDQpGb3Igc29tZSBtYWNybyBsYW5ndWFnZXMgdGhlIHN0cmljdCBm YWxsYmFjayBpcyBwcm9iYWJseSBpbmFwcHJvcHJpYXRlLCANCmhvd2V2ZXIgSSBkb27igJl0IGV4 cGVjdCB0byBmaW5kIG1hdGNoZXMgaW4gdGhhdCBjYXNlIChiZWNhdXNlIEkgZG9u4oCZdCANCmV4 cGVjdCBjb3JyZWN0bHkgdGFnZ2VkIGRhdGEgdG8gYmUg4oCcemjigJ0pLiAgSWYgdGhpcyBpcyBh IGNvbmNlcm4sIHRob3NlIGFyZSANCmVhc2lseSBmaWx0ZXJlZCBvdXQuDQogDQpGcm9tIHRoZSBk aXNjdXNzaW9uIEkgZG9u4oCZdCB0aGluayB0aGUgYmlnZ2VyIHByb2JsZW0gaXMgd2hldGhlciBv ciBub3Qgd2UgDQpnbyB3aXRoIHpoLWNtbiBvciBqdXN0IGNtbi4gIFRoZSBiaWdnZXIgaXNzdWUg c2VlbXMgdG8gYmUgaG93IHRvIG1vZGlmeSANClJGQyA0NjQ3IHRvIHByb3ZpZGUgbWVhbmluZ2Z1 bCBmYWxsYmFjayB3aXRoIHdoaWNoZXZlciBtb2RlIGlzIHVzZWQuICANClNpbmNlIHNvbWUgYXBw bGljYXRpb25zIG1heSAob3IgbWF5IG5vdCkgd2FudCB0byBjb25zaWRlciB6aC1ISyBvciBvdGhl ciANCmxlZ2FjeSBiZWhhdmlvcnMsIHN1Y2ggcmVjb21tZW5kYXRpb25zIGFyZW7igJl0IHRyaXZp YWwuICBHaXZlbiB0aGUgDQpkaWZmZXJpbmcgcmVxdWlyZW1lbnRzIGFtb25nc3QgdXMsIEkgc3Vz cGVjdCBhIGNlcnRhaW4gZmxleGliaWxpdHkgb2YgdGhlIA0KYXBwbGljYXRpb25zIHdpbGwgYmUg bmVjZXNzYXJ5LCBwZXJoYXBzIHNldmVyYWwgc3VnZ2VzdGlvbnMgcmF0aGVyIHRoYW4gDQp0aGUg c3RyaWN0IGJlaGF2aW9yIG9mIFJGQyA0NjQ3ICh3aGljaCBldmVyeW9uZSBzZWVtcyB0byBtb2Rp ZnkgZm9yIHRoZWlyIA0KcHVycG9zZXMgYW55d2F5KQ0KIA0KLSBTaGF3bl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMdHJ1IG1haWxpbmcgbGlzdA0KTHRy dUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K DQoNCg== --===============0996362177== 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 --===============0996362177==-- From ltru-bounces@ietf.org Wed Oct 10 14:36:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgQ1-0002DO-DG; Wed, 10 Oct 2007 14:36:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfgQ0-0002CQ-5o for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgPz-0002C9-S1 for ltru@ietf.org; Wed, 10 Oct 2007 14:36:27 -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 1IfgPu-00040B-Ji for ltru@ietf.org; Wed, 10 Oct 2007 14:36:27 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 11:36:03 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Wed, 10 Oct 2007 11:36:02 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Wed, 10 Oct 2007 11:36:01 -0700 Subject: RE: [Ltru] Extended language tags (long reply) Thread-Topic: [Ltru] Extended language tags (long reply) Thread-Index: AcgLV95ssMTPR5w8T8iB/uBPRioYtwAFD41g Message-ID: References: <4709146F.6020504@yahoo-inc.com> <9d70cb000710071715p398a669fhd06326843d9d9390@mail.gmail.com> <30b660a20710071740ma6d39a3u61c8543c70125847@mail.gmail.com> <4709A420.80508@yahoo-inc.com> <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> In-Reply-To: <30b660a20710100855g5130486awf10f33d3d31fb891@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.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="===============0973560542==" Errors-To: ltru-bounces@ietf.org --===============0973560542== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KDQo+ IElmIG15IHVzZXIgc2VhcmNoZXMgZm9yIEZ1bGFoLCBhbmQgZG9lcyBzL2hlIHdhbnQgdG8gZ2V0 DQo+IE1hYXNpbmEgRnVsZnVsZGUsIEFkYW1hd2EgRnVsZnVsZGUsIFB1bGFhciwgQ2VudHJhbC1F YXN0ZXJuDQo+IE5pZ2VyIEZ1bGZ1bGRlLCBhbmQgc28gb24sIHdoaWNoIEkgaGF2ZSBubyByZWFz b24gdG8NCj4gYmVsaWV2ZSB0aGF0IHRoZSBvcmlnaW5hbCBwZXJzb24gc3BlYWtzPw0KDQpUaGUg dXNlciBwcm9iYWJseSBkb2Vzbid0IHdhbnQgYWxsIHRoYXQuIEJ1dCBob3cgZG8geW91IGtub3cg KndoYXQqIHRoZXkgd2FudD8gSWYgdGhleSB1c2UgYSBnZW5lcmljIHF1YWxpZmllciBpbiB0aGVp ciBxdWVyeSwgSSBkb24ndCBrbm93IGhvdyB5b3UgZG8gYmV0dGVyIHRoYW4gcmV0dXJuIGdlbmVy aWMgcmVzdWx0cywgaW4gdGhlIGFic2VuY2Ugb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4NCg0K DQpQZXRlcg0K --===============0973560542== 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 --===============0973560542==-- From ltru-bounces@ietf.org Wed Oct 10 14:40:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgTk-0002tn-76; Wed, 10 Oct 2007 14:40:20 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfgTi-0002r8-VK for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:40:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgTi-0002lT-KD for ltru@ietf.org; Wed, 10 Oct 2007 14:40:18 -0400 Received: from mail-dub.bigfish.com ([213.199.154.10] helo=mail134-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfgTe-0006Ov-SN for ltru@ietf.org; Wed, 10 Oct 2007 14:40:15 -0400 Received: from mail134-dub (localhost.localdomain [127.0.0.1]) by mail134-dub-R.bigfish.com (Postfix) with ESMTP id A1D3E160875E for ; Wed, 10 Oct 2007 18:39:53 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail134-dub (MessageSwitch) id 1192041593572158_9879; Wed, 10 Oct 2007 18:39:53 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail134-dub.bigfish.com (Postfix) with ESMTP id 14D4E1A38078 for ; Wed, 10 Oct 2007 18:39:53 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007101011394982-267808 ; Wed, 10 Oct 2007 11:39:49 -0700 In-Reply-To: To: "ltru@ietf.org" Subject: RE: [Ltru] Extended language tags (long reply) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 10 Oct 2007 11:37:24 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/10/2007 11:37:24, Serialize complete at 10/10/2007 11:37:24, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 11:39:50 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 11:39:53 AM, Serialize complete at 10/10/2007 11:39:53 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I wrote: (I still don't know whether "vls" (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a synonym for Vlaams in 639-3.) Sorry, I meant to say that "Flemish" is cited as a synonym on Ethnologue.com. Karen Broome Karen_Broome@spe.sony.com 10/10/2007 11:25 AM To Shawn Steele cc "ltru@ietf.org" Subject RE: [Ltru] Extended language tags (long reply) I think if meaningful fallback is the goal, you need to consider both audio and textual forms of languages and their respective fallback mechanisms. While a fallback to "zh" (from "zh-cmn" or "zh-HK", etc.) would likely be useful in written contexts, falling back to spoken "zh" from spoken "cmn" may provide something unintelligible. In the context of my industry, it would likely be useful for a Cantonese speaker to be able to find subtitled films in "zh" if "zh-yue" is not available. Obviously there are questions of simplified vs. traditional orthography, but the "zh" tag alone encompasses both orthographies. But if the Cantonese speaker is looking at dubbed films, a fallback to spoken "zh-cmn" is not as likely to be useful. >From what I understand the same is true in written Dutch vs. spoken Flemish -- a Flemish speaker may be able to easily read standard Dutch, but the spoken forms can create problems of understanding to the point where Dutch is subtitled in Belgium. (I still don't know whether "vls" (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a synonym for Vlaams in 639-3.) Please consider the nature of both audio and written language with respect to ext langs. I think you'll find what makes sense for fallback depends on these distinctions in many other cases than those I've mentioned. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Shawn Steele 10/10/2007 11:02 AM To Mark Davis , Addison Phillips cc "ltru@ietf.org" Subject RE: [Ltru] Extended language tags (long reply) ================ What we don't want to do is make recommendations that if implemented, are harder for people to control and get the right answer. And baking extlang into the tags is even worse -- since it introduces backwards incompatibilities that require old code to be modified to work around. ================ cmn is completely incompatible with existing practice anyway, so you can?t claim that it solves the problem. Existing clients ask for zh-HK (or whatever) and code is tagged as zh-HK (or whatever). Those won?t match cmn using RFC 4647. So for backwards compatibility zh-cmn is no worse than cmn. And if you don?t like the inference of the zh, then you can ignore that part, but at least the data?s there if people do want it. For some macro languages the strict fallback is probably inappropriate, however I don?t expect to find matches in that case (because I don?t expect correctly tagged data to be ?zh?). If this is a concern, those are easily filtered out. >From the discussion I don?t think the bigger problem is whether or not we go with zh-cmn or just cmn. The bigger issue seems to be how to modify RFC 4647 to provide meaningful fallback with whichever mode is used. Since some applications may (or may not) want to consider zh-HK or other legacy behaviors, such recommendations aren?t trivial. Given the differing requirements amongst us, I suspect a certain flexibility of the applications will be necessary, perhaps several suggestions rather than the strict behavior of RFC 4647 (which everyone seems to modify for their purposes anyway) - Shawn_______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 14:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgaA-0001Ud-2Q; Wed, 10 Oct 2007 14:46:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifga8-0001RJ-UE for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifga8-0001RB-Kh for ltru@ietf.org; Wed, 10 Oct 2007 14:46:56 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifga6-0004SE-UU for ltru@ietf.org; Wed, 10 Oct 2007 14:46:56 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 11:46:34 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Wed, 10 Oct 2007 11:46:35 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Wed, 10 Oct 2007 11:46:33 -0700 Subject: RE: [Ltru] Extended language tags (long reply) Thread-Topic: [Ltru] Extended language tags (long reply) Thread-Index: AcgLbRSvXSFkUbb/RkOqwv630YXDPAAAI+TA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Where do you see "Flemish" cited as synonymous with "Vlaams"? The closest I see is a statement that Dutch is "[c]alled 'Vlaams' in Belgiu= m, even though it is different from the (West) Vlaams spoken there." Peter > -----Original Message----- > From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > Sent: Wednesday, October 10, 2007 11:37 AM > To: ltru@ietf.org > Subject: RE: [Ltru] Extended language tags (long reply) > > I wrote: > > (I still don't know whether "vls" > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a > synonym for Vlaams in 639-3.) > > Sorry, I meant to say that "Flemish" is cited as a synonym on > Ethnologue.com. > > Karen Broome > > > > > Karen_Broome@spe.sony.com > 10/10/2007 11:25 AM > > To > Shawn Steele > cc > "ltru@ietf.org" > Subject > RE: [Ltru] Extended language tags (long reply) > > > > > > > I think if meaningful fallback is the goal, you need to consider both > audio and textual forms of languages and their respective fallback > mechanisms. While a fallback to "zh" (from "zh-cmn" or "zh-HK", etc.) > would likely be useful in written contexts, falling back to spoken "zh" > from spoken "cmn" may provide something unintelligible. > > In the context of my industry, it would likely be useful for a > Cantonese > speaker to be able to find subtitled films in "zh" if "zh-yue" is not > available. Obviously there are questions of simplified vs. traditional > orthography, but the "zh" tag alone encompasses both orthographies. But > if > > the Cantonese speaker is looking at dubbed films, a fallback to spoken > "zh-cmn" is not as likely to be useful. > > >From what I understand the same is true in written Dutch vs. spoken > Flemish -- a Flemish speaker may be able to easily read standard Dutch, > but the spoken forms can create problems of understanding to the point > where Dutch is subtitled in Belgium. (I still don't know whether "vls" > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a > synonym for Vlaams in 639-3.) > > Please consider the nature of both audio and written language with > respect > > to ext langs. I think you'll find what makes sense for fallback depends > on > > these distinctions in many other cases than those I've mentioned. > > Regards, > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > 310.244.4384 > > > > Shawn Steele > 10/10/2007 11:02 AM > > To > Mark Davis , Addison Phillips > > cc > "ltru@ietf.org" > Subject > RE: [Ltru] Extended language tags (long reply) > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What we don't want to do is make recommendations that if implemented, > are > harder for people to control and get the right answer. And baking > extlang > into the tags is even worse -- since it introduces backwards > incompatibilities that require old code to be modified to work around. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > cmn is completely incompatible with existing practice anyway, so you > can?t > > claim that it solves the problem. Existing clients ask for zh-HK (or > whatever) and code is tagged as zh-HK (or whatever). Those won?t match > cmn using RFC 4647. > > So for backwards compatibility zh-cmn is no worse than cmn. And if you > don?t like the inference of the zh, then you can ignore that part, but > at > least the data?s there if people do want it. > > For some macro languages the strict fallback is probably inappropriate, > however I don?t expect to find matches in that case (because I don?t > expect correctly tagged data to be ?zh?). If this is a concern, those > are > > easily filtered out. > > >From the discussion I don?t think the bigger problem is whether or not > we > go with zh-cmn or just cmn. The bigger issue seems to be how to modify > RFC 4647 to provide meaningful fallback with whichever mode is used. > Since some applications may (or may not) want to consider zh-HK or > other > legacy behaviors, such recommendations aren?t trivial. Given the > differing requirements amongst us, I suspect a certain flexibility of > the > applications will be necessary, perhaps several suggestions rather than > the strict behavior of RFC 4647 (which everyone seems to modify for > their > purposes anyway) > > - Shawn_______________________________________________ > 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 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 14:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfghZ-0001Jf-Cc; Wed, 10 Oct 2007 14:54:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfghY-0001FI-Jj for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:54:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfghY-0001Em-8C for ltru@ietf.org; Wed, 10 Oct 2007 14:54:36 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfghX-0006tn-HL for ltru@ietf.org; Wed, 10 Oct 2007 14:54:36 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 11:54:34 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Wed, 10 Oct 2007 11:54:33 -0700 From: Shawn Steele To: "Karen_Broome@spe.sony.com" , Addison Phillips Date: Wed, 10 Oct 2007 11:54:31 -0700 Thread-Topic: Teleconference Thread-Index: AcgLZ1EZSV9qLqDQQSCWs9B/h1qpRgAB5bTA Message-ID: References: <470C4339.90901@yahoo-inc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: LTRU Working Group Subject: [Ltru] Teleconference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org And a warning before then'd be nice too :) Is there a plan for another teleconference? - Shawn -----Original Message----- From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] Sent: Wednesday, October 10, 2007 10:55 AM To: Addison Phillips Cc: LTRU Working Group Subject: Re: [Ltru] Re: Extended language tags This e-mail went out too late for me to participate. Please try to send notice before the close of business the day before the call. Karen Broome Addison Phillips 10/09/2007 08:12 PM To Mark Davis cc LTRU Working Group Subject Re: [Ltru] Re: Extended language tags Just FYI, tomorrow morning (9 am Pacific) call can be accessed: Dial-In #: +1.888.371.8922 International Dial-In #: +1.617.224.4792 Participant Passcode: 58371972 Addison Mark Davis wrote: > First off, I agree with Andy that the editor's contributions should be > judged on technical merit, just like everyone else's. > > As far as a conclusion goes. Any judgment of consensus at this point is > premature. We are increasing the size of the registry by a huge margin, > and considering whether to add a significant piece of architecture: it > is more important that this revision be correctly designed than that it > meet some arbitrary deadline. I think that the telecons have been > valuable for bringing out the issues, and we already planned for another > this week. As long as we are making progress with that, we should > continue. It is useful when the chairs could make that meeting: Randy's > been to one of them. Martin, is that time too difficult for you? > > Mark > > On 10/9/07, *Randy Presuhn* > wrote: > > Hi - > > As co-chair... > > > From: "Doug Ewell" > > > To: "LTRU Working Group" > > > Sent: Tuesday, October 09, 2007 6:45 AM > > Subject: [Ltru] Re: Extended language tags > > > > Randy Presuhn wrote: > > > > >> Hard to say. I think at this moment there are more > contributors who > > >> favor (1) than (2), but the two main proponents of (2) are the > > >> co-editors of 4646bis, which does tip the balance a bit. > > > > > > No, it does not. Editors do the bidding of the WG, see RFC 2418 > > > clause 6.3. As such they are *not* given special consideration > in the > > > determination of working group consensus. > > > > But they might well be given special consideration by other list > members > > who haven't made up their minds yet. > > This would be a bad thing. RFC 2418 is abundantly clear that document > editors do not enjoy any special privileges in determining WG consensus. > Sometimes editors happen to be experts in the topic, sometimes they > are not. > But if a WG starts giving their voices more weight merely because they > happen to be editors, something is seriously wrong. > > > I would guess that with the small > > number of people solidly on one side or the other, the battle for > the > > "undecided" bloc will be important. > > Perhaps, though the undecided have little import for a determination > of rough consensus. At some point Martin and I will have to make > a determination of consensus. It's clear that none of the options > will make everyone happy. It's possible that none of the options > will make anyone happy in the long run. Since there has been so little > in the way of new information or arguments in this discussion, > I think Martin and I will just have to pick one, based on the opinions > expressed on this list so far, since few new voices seem to be joining > in to express a preference. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 15:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgoQ-0002Zd-0T; Wed, 10 Oct 2007 15:01:42 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfgoO-0002ZU-TA for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgoO-0002ZM-Jf for ltru@ietf.org; Wed, 10 Oct 2007 15:01:40 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfgoG-0004xX-Sj for ltru@ietf.org; Wed, 10 Oct 2007 15:01:40 -0400 Received: by rv-out-0910.google.com with SMTP id l15so243534rvb for ; Wed, 10 Oct 2007 12:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=CiIFdaWKDdPwkqYHsBPiAeFzZnVCHinXo3/l1R1Nj7Q=; b=Fsxz6ONthFMzcktjnnL1N5GGdzOkGF8VkRTC0WQ8+Q0u3AytAt35ikM8cITNRjSy9oNwpc/GD7McIJ7MW5uDYeNvucROC7JCb2KuAfnQhKi9SIxRxrqRKK8bXUZWzhWN55xb7/leXBr9kqD33RIvxLhggYs2qkU6oUmoOzPFHTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=fb0mTyA0g1fk1Z6ETUUr5NZ8wkkf2raSi4+fFMTwc1rJsGmBPKhIuVISRPl34FFSWN5XP8HupqdKNl8KQrrBrJp0JG55fUpvVFYNnPzlbXhy4KlfwtAR0kERAkDEbrQAgDNCX+ia9dwqwS705XYTzDcLub8yYRY4TZ5bgdrL8g0= Received: by 10.114.161.11 with SMTP id j11mr1132985wae.1192042860672; Wed, 10 Oct 2007 12:01:00 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 10 Oct 2007 12:01:00 -0700 (PDT) Message-ID: <30b660a20710101201t7e7f34d8jcaf9fba091c91db3@mail.gmail.com> Date: Wed, 10 Oct 2007 12:01:00 -0700 From: "Mark Davis" To: "Shawn Steele" Subject: Re: [Ltru] Teleconference In-Reply-To: MIME-Version: 1.0 References: <470C4339.90901@yahoo-inc.com> X-Google-Sender-Auth: 6ce861f5fd7b4296 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Karen_Broome@spe.sony.com" , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0652951002==" Errors-To: ltru-bounces@ietf.org --===============0652951002== Content-Type: multipart/alternative; boundary="----=_Part_10971_18236799.1192042860669" ------=_Part_10971_18236799.1192042860669 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, we're planning to have them each Wednesday, same time, as long as we are making progress. (Except we're going to skip next week, because of the Unicode conference.) On 10/10/07, Shawn Steele wrote: > > And a warning before then'd be nice too :) > > Is there a plan for another teleconference? > > - Shawn ------=_Part_10971_18236799.1192042860669 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, we're planning to have them each Wednesday, same time, as long as we are making progress. (Except we're going to skip next week, because of the Unicode conference.)

On 10/10/07, Shawn Steele <Shawn.Steele@microsoft.com> wrote:
And a warning before then'd be nice too :)

Is there a plan for another teleconference?

- Shawn
------=_Part_10971_18236799.1192042860669-- --===============0652951002== 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 --===============0652951002==-- From ltru-bounces@ietf.org Wed Oct 10 15:02:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifgp4-0002qm-AP; Wed, 10 Oct 2007 15:02:22 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifgp3-0002qV-EU for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:02:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifgp3-0002q2-32 for ltru@ietf.org; Wed, 10 Oct 2007 15:02:21 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound2-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifgp1-00079X-Ho for ltru@ietf.org; Wed, 10 Oct 2007 15:02:21 -0400 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id 5CF9E13F9A39 for ; Wed, 10 Oct 2007 18:59:52 +0000 (UTC) Received: from mail148-sin-R.bigfish.com (unknown [10.3.252.3]) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 45C9A528069 for ; Wed, 10 Oct 2007 18:59:52 +0000 (UTC) Received: from mail148-sin (localhost.localdomain [127.0.0.1]) by mail148-sin-R.bigfish.com (Postfix) with ESMTP id A63DB1740147 for ; Wed, 10 Oct 2007 18:59:49 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail148-sin (MessageSwitch) id 1192042789404876_6332; Wed, 10 Oct 2007 18:59:49 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail148-sin.bigfish.com (Postfix) with ESMTP id 0C383F88068 for ; Wed, 10 Oct 2007 18:59:49 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007101011594130-269283 ; Wed, 10 Oct 2007 11:59:41 -0700 In-Reply-To: To: "ltru@ietf.org" Subject: RE: [Ltru] Extended language tags (long reply) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 10 Oct 2007 11:57:15 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/10/2007 11:57:15, Serialize complete at 10/10/2007 11:57:15, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 11:59:41 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 11:59:56 AM, Serialize complete at 10/10/2007 11:59:56 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org http://www.ethnologue.com/show_language.asp?code=vls "Flemish" is listed as an alternate name in Netherlands and France. Karen Broome Peter Constable wrote on 10/10/2007 11:46:33 AM: > Where do you see "Flemish" cited as synonymous with "Vlaams"? > > The closest I see is a statement that Dutch is "[c]alled 'Vlaams' in > Belgium, even though it is different from the (West) Vlaams spoken there." > > > Peter > > > -----Original Message----- > > From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > > Sent: Wednesday, October 10, 2007 11:37 AM > > To: ltru@ietf.org > > Subject: RE: [Ltru] Extended language tags (long reply) > > > > I wrote: > > > > (I still don't know whether "vls" > > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a > > synonym for Vlaams in 639-3.) > > > > Sorry, I meant to say that "Flemish" is cited as a synonym on > > Ethnologue.com. > > > > Karen Broome > > > > > > > > > > Karen_Broome@spe.sony.com > > 10/10/2007 11:25 AM > > > > To > > Shawn Steele > > cc > > "ltru@ietf.org" > > Subject > > RE: [Ltru] Extended language tags (long reply) > > > > > > > > > > > > > > I think if meaningful fallback is the goal, you need to consider both > > audio and textual forms of languages and their respective fallback > > mechanisms. While a fallback to "zh" (from "zh-cmn" or "zh-HK", etc.) > > would likely be useful in written contexts, falling back to spoken "zh" > > from spoken "cmn" may provide something unintelligible. > > > > In the context of my industry, it would likely be useful for a > > Cantonese > > speaker to be able to find subtitled films in "zh" if "zh-yue" is not > > available. Obviously there are questions of simplified vs. traditional > > orthography, but the "zh" tag alone encompasses both orthographies. But > > if > > > > the Cantonese speaker is looking at dubbed films, a fallback to spoken > > "zh-cmn" is not as likely to be useful. > > > > >From what I understand the same is true in written Dutch vs. spoken > > Flemish -- a Flemish speaker may be able to easily read standard Dutch, > > but the spoken forms can create problems of understanding to the point > > where Dutch is subtitled in Belgium. (I still don't know whether "vls" > > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a > > synonym for Vlaams in 639-3.) > > > > Please consider the nature of both audio and written language with > > respect > > > > to ext langs. I think you'll find what makes sense for fallback depends > > on > > > > these distinctions in many other cases than those I've mentioned. > > > > Regards, > > > > Karen Broome > > Metadata Systems Designer > > Sony Pictures Entertainment > > 310.244.4384 > > > > > > > > Shawn Steele > > 10/10/2007 11:02 AM > > > > To > > Mark Davis , Addison Phillips > > > > cc > > "ltru@ietf.org" > > Subject > > RE: [Ltru] Extended language tags (long reply) > > > > > > > > > > > > > > ================ > > > > What we don't want to do is make recommendations that if implemented, > > are > > harder for people to control and get the right answer. And baking > > extlang > > into the tags is even worse -- since it introduces backwards > > incompatibilities that require old code to be modified to work around. > > > > ================ > > > > cmn is completely incompatible with existing practice anyway, so you > > can?t > > > > claim that it solves the problem. Existing clients ask for zh-HK (or > > whatever) and code is tagged as zh-HK (or whatever). Those won?t match > > cmn using RFC 4647. > > > > So for backwards compatibility zh-cmn is no worse than cmn. And if you > > don?t like the inference of the zh, then you can ignore that part, but > > at > > least the data?s there if people do want it. > > > > For some macro languages the strict fallback is probably inappropriate, > > however I don?t expect to find matches in that case (because I don?t > > expect correctly tagged data to be ?zh?). If this is a concern, those > > are > > > > easily filtered out. > > > > >From the discussion I don?t think the bigger problem is whether or not > > we > > go with zh-cmn or just cmn. The bigger issue seems to be how to modify > > RFC 4647 to provide meaningful fallback with whichever mode is used. > > Since some applications may (or may not) want to consider zh-HK or > > other > > legacy behaviors, such recommendations aren?t trivial. Given the > > differing requirements amongst us, I suspect a certain flexibility of > > the > > applications will be necessary, perhaps several suggestions rather than > > the strict behavior of RFC 4647 (which everyone seems to modify for > > their > > purposes anyway) > > > > - Shawn_______________________________________________ > > 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 > > > _______________________________________________ > 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 10 15:06:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifgst-0005X9-5g; Wed, 10 Oct 2007 15:06:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifgsr-0005UC-T0 for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:06:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifgsr-0005Cm-EZ for ltru@ietf.org; Wed, 10 Oct 2007 15:06:17 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifgsk-0007Fq-U4 for ltru@ietf.org; Wed, 10 Oct 2007 15:06:11 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ghTIoFCt5XKFbXK8BLAKhaocQP8+uFtdjvz3VGj28HtKU2FfWGZxDwdmAF0o7VhX; 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 [64.105.34.47] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ifgsh-0008Mj-PS for ltru@ietf.org; Wed, 10 Oct 2007 15:06:08 -0400 Message-ID: <007001c80b71$31dc72c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <470C4339.90901@yahoo-inc.com> Subject: Re: [Ltru] Teleconference Date: Wed, 10 Oct 2007 12:10:16 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31aa2bddea3eb6f62bc0b2f57c2b169547e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.47 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Shawn Steele" > To: ; "Addison Phillips" > Cc: "LTRU Working Group" > Sent: Wednesday, October 10, 2007 11:54 AM > Subject: [Ltru] Teleconference ... > Is there a plan for another teleconference? ... There was talk of holding another one on October 24. While these discussions have been helpful, I'm concerned that rather few people have been actually participating in them. But what is most important is that that progress translates into progress in the discussion on the WG mailing list, and progress towards consensus on what our deliverables should say. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 15:31:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhHM-0005l0-51; Wed, 10 Oct 2007 15:31:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfhHK-0005V2-Gv for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:31:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhHJ-0005SZ-T7 for ltru@ietf.org; Wed, 10 Oct 2007 15:31:34 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfhHD-0005zx-5p for ltru@ietf.org; Wed, 10 Oct 2007 15:31:33 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IfhH2-0005G5-C7; Wed, 10 Oct 2007 15:31:16 -0400 Date: Wed, 10 Oct 2007 15:31:16 -0400 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] Extended language tags (long reply) Message-ID: <20071010193116.GC15438@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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 Karen_Broome@spe.sony.com scripsit: > I wrote: > > (I still don't know whether "vls" > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a > synonym for Vlaams in 639-3.) It does not. > Sorry, I meant to say that "Flemish" is cited as a synonym on > Ethnologue.com. That is to say, the name "Flemish" has been used for both vls and the Belgian version of nl. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall cowan@ccil.org buy a piece of the rope for a keepsake. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 15:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhLF-000572-Vw; Wed, 10 Oct 2007 15:35:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfhLE-0004yw-9v for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhLE-0004xt-08 for ltru@ietf.org; Wed, 10 Oct 2007 15:35:36 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfhL0-00067z-VO for ltru@ietf.org; Wed, 10 Oct 2007 15:35:29 -0400 Received: from [172.21.232.206] (wlanvpn-abc-232-206.corp.yahoo.com [172.21.232.206]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9AJYqLd060549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 12:34: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=bfe4Myef8xyQgUNhunT/iCsf+1d7xwm62SuTMTUQRM9MkfGy5H+kzTD+av9ROG3M Message-ID: <470D295B.2040800@yahoo-inc.com> Date: Wed, 10 Oct 2007 12:34:51 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Teleconference References: <470C4339.90901@yahoo-inc.com> <007001c80b71$31dc72c0$6801a8c0@oemcomputer> In-Reply-To: <007001c80b71$31dc72c0$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) 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 Randy, Perhaps a poll for day/time options? Addison Randy Presuhn wrote: > Hi - > >> From: "Shawn Steele" >> To: ; "Addison Phillips" >> Cc: "LTRU Working Group" >> Sent: Wednesday, October 10, 2007 11:54 AM >> Subject: [Ltru] Teleconference > ... >> Is there a plan for another teleconference? > ... > > There was talk of holding another one on October 24. > > While these discussions have been helpful, I'm concerned that > rather few people have been actually participating in them. But > what is most important is that that progress translates into progress > in the discussion on the WG mailing list, and progress towards > consensus on what our deliverables should say. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 10 15:42:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhRU-0004Cp-7X; Wed, 10 Oct 2007 15:42:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfhRS-0004B5-QF for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 15:42:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhRS-0004Aw-Gn for ltru@ietf.org; Wed, 10 Oct 2007 15:42:02 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfhRR-0006Jo-B6 for ltru@ietf.org; Wed, 10 Oct 2007 15:42:02 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IfhRQ-0005qH-Ld; Wed, 10 Oct 2007 15:42:00 -0400 Date: Wed, 10 Oct 2007 15:42:00 -0400 To: Randy Presuhn Subject: Re: [Ltru] Teleconference Message-ID: <20071010194200.GD15438@mercury.ccil.org> References: <007001c80b71$31dc72c0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007001c80b71$31dc72c0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > > Is there a plan for another teleconference? > ... > > There was talk of holding another one on October 24. That's unnecessarily vague. There *will* be another one on October 24, and (I think) every week thereafter until we are deadlocked or there is consensus. All are invited and urged to show up. The dialup information is always the same: Time: 9:00-10:00 Pacific Time USA Dial-In #:+1.888.371.8922 International Dial-In #:+1.617.224.4792 Participant Passcode: 5837197 (Currently, Pacific Time is UTC-7, so that's 1200 Eastern, 1600 UTC, 1700 WET, 1800 CET. As of Oct 30, the European time will be an hour earlier; as of Nov 7 the American times will be an hour earlier relative to UTC.) -- John Cowan cowan@ccil.org http://ccil.org/~cowan Big as a house, much bigger than a house, it looked to [Sam], a grey-clad moving hill. Fear and wonder, maybe, enlarged him in the hobbit's eyes, but the Mumak of Harad was indeed a beast of vast bulk, and the like of him does not walk now in Middle-earth; his kin that live still in latter days are but memories of his girth and his majesty. --"Of Herbs and Stewed Rabbit" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 16:01:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhkG-0003JT-2t; Wed, 10 Oct 2007 16:01:28 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfhkE-00039d-4X for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 16:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhkD-0002Sq-QX for ltru@ietf.org; Wed, 10 Oct 2007 16:01:25 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifhk0-0006og-IG for ltru@ietf.org; Wed, 10 Oct 2007 16:01:18 -0400 Received: from [172.21.232.206] (wlanvpn-abc-232-206.corp.yahoo.com [172.21.232.206]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9AK0dBP062711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 13:00: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=wvHyQUwVNKa30+xsLp0ghveuJLNHUIUCrTGzWgyaNmuXXPa4ZIFj0RioeTaSK8d2 Message-ID: <470D2F66.2010202@yahoo-inc.com> Date: Wed, 10 Oct 2007 13:00:38 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shawn Steele Subject: Re: [Ltru] RE: duel(ing) tags 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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org 'cmn' is not a valid subtag at present. It is part of the 7000+ additional subtags in ISO 639-3 that are being added. Presumably nothing is tagged with 'cmn' today. I definitely am against providing both tagging options. Addison Shawn Steele wrote: > I was sort of wondering the same thing. > > I was thinking that to support mistakes, legacy tags & other randomness it might be best if any matching stuff I wrote recognized that cmn & zh-cmn were interchangeable. It is unclear to me if data is currently tagged as cmn though, although I know some is tagged as zh-cmn. > > - Shawn > > ------------------------------ > > Date: Wed, 10 Oct 2007 10:46:18 +0100 > From: "Debbie Garside" > Subject: RE: [Ltru] Re: Extended language tags > To: , "'Doug Ewell'" > , "'LTRU Working Group'" > Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> > > Hi > > I may have missed the answer to this question, apologies if I have, but why > not include cwm within the registry and then deprecate in favour of zh-cwm? > This way both are in the registry and the fallback, as described by Mark, is > facilitated. The same could be done for zh-yue and yue and no-nb etc. Thus > if people tag "incorrectly", with, for example, cwm or yue, applications > would come up with the correct match anyway. > > I cannot pretend that I understand the entirety of the current conversations > wrt extended language tags but I do think their inclusion would be useful > for matching purposes. > > Best regards > > Debbie Garside > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 10 16:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhqJ-00070w-T8; Wed, 10 Oct 2007 16:07:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfhqH-00070n-VR for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 16:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfhqH-00070f-Lv for ltru@ietf.org; Wed, 10 Oct 2007 16:07:41 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifhq6-00074x-Cd for ltru@ietf.org; Wed, 10 Oct 2007 16:07:41 -0400 Received: by rv-out-0910.google.com with SMTP id l15so258215rvb for ; Wed, 10 Oct 2007 13:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=v1e1ccbegb3IyhYiXBH51kDpuCUsjqYPRzD9v3AKwzg=; b=He8N3XtLdPS132JdlDupPSkPAJN5xcf8IVWfOcqXyu/oJHXS/Jmp5kUUbGFq3/tZX/grWisFuwiYB5RSwf2iJWrAY1D+3Yfi9cT9w2dBqJCi94mDqXBAVfOHQw2qt+5yw0hb+iJMCQXzf/WZGAbzAZG2gfD5P6Ct7rR1/n8aQ08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=svLnv62nghv7NT5uHIzeIpGED8s+wx1tc62I+gwvLoV8HjUcHTf4PDgmHzf7MjXDz4HhNvQPXh1L8epQv4wCZWuvZbXog9zjvUNpNXiJaWaEYBRPl+5juj7MMAKMK9O/5hNvyyzwTsnvPP3Tpy0p0JjWHLIhypGnqAYNpZ4+LNw= Received: by 10.114.194.1 with SMTP id r1mr1225119waf.1192046818561; Wed, 10 Oct 2007 13:06:58 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 10 Oct 2007 13:06:58 -0700 (PDT) Message-ID: <30b660a20710101306w4ac5099wea8b342dee1d5110@mail.gmail.com> Date: Wed, 10 Oct 2007 13:06:58 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] RE: duel(ing) tags In-Reply-To: <470D2F66.2010202@yahoo-inc.com> MIME-Version: 1.0 References: <470D2F66.2010202@yahoo-inc.com> X-Google-Sender-Auth: 056ff12039b59f7b X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0038586581==" Errors-To: ltru-bounces@ietf.org --===============0038586581== Content-Type: multipart/alternative; boundary="----=_Part_11453_18049978.1192046818553" ------=_Part_11453_18049978.1192046818553 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am definitely against providing both options in the specification as well -- we should settle on either "ar-arb" or "arb". However, we also must recognize that, even if we require "ar-arb", in practice we would see a lot of simple "arb" as input, and implementations would need to deal with it, typically by equating it to "ar-arb". Mark On 10/10/07, Addison Phillips wrote: > > 'cmn' is not a valid subtag at present. It is part of the 7000+ > additional subtags in ISO 639-3 that are being added. Presumably nothing > is tagged with 'cmn' today. > > I definitely am against providing both tagging options. > > Addison > > Shawn Steele wrote: > > I was sort of wondering the same thing. > > > > I was thinking that to support mistakes, legacy tags & other randomness > it might be best if any matching stuff I wrote recognized that cmn & zh-cmn > were interchangeable. It is unclear to me if data is currently tagged as > cmn though, although I know some is tagged as zh-cmn. > > > > - Shawn > > > > ------------------------------ > > > > Date: Wed, 10 Oct 2007 10:46:18 +0100 > > From: "Debbie Garside" > > Subject: RE: [Ltru] Re: Extended language tags > > To: , "'Doug Ewell'" > > , "'LTRU Working Group'" < > ltru@ietf.org> > > Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> > > > > Hi > > > > I may have missed the answer to this question, apologies if I have, but > why > > not include cwm within the registry and then deprecate in favour of > zh-cwm? > > This way both are in the registry and the fallback, as described by > Mark, is > > facilitated. The same could be done for zh-yue and yue and no-nb > etc. Thus > > if people tag "incorrectly", with, for example, cwm or yue, applications > > would come up with the correct match anyway. > > > > I cannot pretend that I understand the entirety of the current > conversations > > wrt extended language tags but I do think their inclusion would be > useful > > for matching purposes. > > > > Best regards > > > > Debbie Garside > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_11453_18049978.1192046818553 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am definitely against providing both options in the specification as well -- we should settle on either "ar-arb" or "arb". However, we also must recognize that, even if we require "ar-arb" , in practice we would see a lot of simple "arb" as input, and implementations would need to deal with it, typically by equating it to "ar-arb".

Mark

On 10/10/07, Addison Phillips <addison@yahoo-inc.com> wrote:
'cmn' is not a valid subtag at present. It is part of the 7000+
additional subtags in ISO 639-3 that are being added. Presumably nothing
is tagged with 'cmn' today.

I definitely am against providing both tagging options.

Addison

Shawn Steele wrote:
> I was sort of wondering the same thing.
>
> I was thinking that to support mistakes, legacy tags & other randomness it might be best if any matching stuff I wrote recognized that cmn & zh-cmn were interchangeable.  It is unclear to me if data is currently tagged as cmn though, although I know some is tagged as zh-cmn.
>
> - Shawn
>
> ------------------------------
>
> Date: Wed, 10 Oct 2007 10:46:18 +0100
> From: "Debbie Garside" <debbie@ictmarketing.co.uk >
> Subject: RE: [Ltru] Re: Extended language tags
> To: <Shawn.Steele@microsoft.com>, "'Doug Ewell'"
>         < dewell@roadrunner.com>,        "'LTRU Working Group'" <ltru@ietf.org>
> Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110>
>
> Hi
>
> I may have missed the answer to this question, apologies if I have, but why
> not include cwm within the registry and then deprecate in favour of zh-cwm?
> This way both are in the registry and the fallback, as described by Mark, is
> facilitated. The same could be done for zh-yue and yue and no-nb etc.  Thus
> if people tag "incorrectly", with, for example, cwm or yue, applications
> would come up with the correct match anyway.
>
> I cannot pretend that I understand the entirety of the current conversations
> wrt extended language tags but I do think their inclusion would be useful
> for matching purposes.
>
> Best regards
>
> Debbie Garside
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

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

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_11453_18049978.1192046818553-- --===============0038586581== 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 --===============0038586581==-- From ltru-bounces@ietf.org Wed Oct 10 16:11:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifhu6-0002Of-Hr; Wed, 10 Oct 2007 16:11:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifhu5-0002Jt-JA for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 16:11:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifhu5-0002Jl-8S for ltru@ietf.org; Wed, 10 Oct 2007 16:11:37 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifhu4-0000nT-ML for ltru@ietf.org; Wed, 10 Oct 2007 16:11:37 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007325375.msg for ; Wed, 10 Oct 2007 21:15:06 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 10 Oct 2007 21:11:42 +0100 From: "Debbie Garside" To: , "'Shawn Steele'" References: <470D2F66.2010202@yahoo-inc.com> Subject: RE: [Ltru] RE: duel(ing) tags Date: Wed, 10 Oct 2007 21:10:28 +0100 Message-ID: <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <470D2F66.2010202@yahoo-inc.com> Thread-Index: AcgLeKwEnoA0O6lJSC+xA/wWE7++agAAIQiA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Wed, 10 Oct 2007 21:15:06 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18038546a2=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, 10 Oct 2007 21:15:06 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: ltru-bounces@ietf.org Addison wrote: > I definitely am against providing both tagging options. But where is the harm in including cmn in the registry and then deprecating in favour of zh-cmn? As stated previously, this would catch those who unwittingly tag with any 639-3 code and are unaware of macrolanguages and 4646bis. Best regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 10 October 2007 21:01 > To: Shawn Steele > Cc: ltru@ietf.org > Subject: Re: [Ltru] RE: duel(ing) tags > > 'cmn' is not a valid subtag at present. It is part of the > 7000+ additional subtags in ISO 639-3 that are being added. > Presumably nothing is tagged with 'cmn' today. > > I definitely am against providing both tagging options. > > Addison > > Shawn Steele wrote: > > I was sort of wondering the same thing. > > > > I was thinking that to support mistakes, legacy tags & > other randomness it might be best if any matching stuff I > wrote recognized that cmn & zh-cmn were interchangeable. It > is unclear to me if data is currently tagged as cmn though, > although I know some is tagged as zh-cmn. > > > > - Shawn > > > > ------------------------------ > > > > Date: Wed, 10 Oct 2007 10:46:18 +0100 > > From: "Debbie Garside" > > Subject: RE: [Ltru] Re: Extended language tags > > To: , "'Doug Ewell'" > > , "'LTRU Working > Group'" > > Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> > > > > Hi > > > > I may have missed the answer to this question, apologies if I have, > > but why not include cwm within the registry and then > deprecate in favour of zh-cwm? > > This way both are in the registry and the fallback, as described by > > Mark, is facilitated. The same could be done for zh-yue and yue and > > no-nb etc. Thus if people tag "incorrectly", with, for > example, cwm > > or yue, applications would come up with the correct match anyway. > > > > I cannot pretend that I understand the entirety of the current > > conversations wrt extended language tags but I do think their > > inclusion would be useful for matching purposes. > > > > Best regards > > > > Debbie Garside > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 16:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiCP-0006GQ-Ep; Wed, 10 Oct 2007 16:30:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfiCN-0006G0-9C for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 16:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiCM-0006Fo-ST for ltru@ietf.org; Wed, 10 Oct 2007 16:30:30 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfiCG-0007sS-Mk for ltru@ietf.org; Wed, 10 Oct 2007 16:30:30 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 13:29:53 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed, 10 Oct 2007 13:29:53 -0700 From: Shawn Steele To: "debbie@ictmarketing.co.uk" , "addison@yahoo-inc.com" Date: Wed, 10 Oct 2007 13:29:52 -0700 Subject: RE: [Ltru] RE: duel(ing) tags Thread-Topic: [Ltru] RE: duel(ing) tags Thread-Index: AcgLeKwEnoA0O6lJSC+xA/wWE7++agAAIQiAAAC3ncA= Message-ID: References: <470D2F66.2010202@yahoo-inc.com> <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> In-Reply-To: <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.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 > > I definitely am against providing both tagging options. > But where is the harm in including cmn in the registry and then deprecati= ng > in favour of zh-cmn? As stated previously, this would catch those who > unwittingly tag with any 639-3 code and are unaware of macrolanguages and > 4646bis. I wasn't suggesting registering both. Its just my experience that people d= on't really always pay that much attention, so they might use both. I was = merely suggesting that robust applications might want to recognize both for= ms, even if one was "illegal". - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 16:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiHT-0000J8-5j; Wed, 10 Oct 2007 16:35:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfiHS-0000Iy-1L for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 16:35:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiHR-0000Iq-O8 for ltru@ietf.org; Wed, 10 Oct 2007 16:35:45 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfiHL-00084D-I1 for ltru@ietf.org; Wed, 10 Oct 2007 16:35:45 -0400 Received: by nz-out-0506.google.com with SMTP id n1so255095nzf for ; Wed, 10 Oct 2007 13:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=AfVU7l5b+iIb3h6v1LNwlIyfIE65zWlT/wbcS+eTdBI=; b=hcUmgJGF0KcE/fg8Xg8J9p+ZAxdD56b178QSl5Eqb4Z6pnkQD+g4ms5iOl1upWfWOaiLHuS6JGb9tscvquy5sJiAH29UJa5UKhHrbW8jboG3q/SKNSMvbmMBueuvWiKc6lLHdEcDNTQe2K3PjNOwvdA/bybPE0BXC64Ie62aabw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=GrMCMXDqcnzuNcp1TYCidr5nTbhtvYqJwrZTfCh0zTlVQJC3GTJHAOj+dF8EP2qgvRXMDdVnmllmYktvmXnPiXu5km5pAdap1e+KqQpDrb8NX8B0nwnIe8EANDtY2bgQn4DwoQ84QeeiVSW8eMj32u3UwIwhOMbLvrLmSiO8970= Received: by 10.115.91.2 with SMTP id t2mr1220688wal.1192048521254; Wed, 10 Oct 2007 13:35:21 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 10 Oct 2007 13:35:21 -0700 (PDT) Message-ID: <30b660a20710101335m686196a5xaac4329dca87090a@mail.gmail.com> Date: Wed, 10 Oct 2007 13:35:21 -0700 From: "Mark Davis" To: "Shawn Steele" Subject: Re: [Ltru] RE: duel(ing) tags In-Reply-To: MIME-Version: 1.0 References: <470D2F66.2010202@yahoo-inc.com> <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> X-Google-Sender-Auth: 5f90ffb7f2bebc2d 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="===============0620311474==" Errors-To: ltru-bounces@ietf.org --===============0620311474== Content-Type: multipart/alternative; boundary="----=_Part_11716_16082589.1192048521280" ------=_Part_11716_16082589.1192048521280 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Right. On 10/10/07, Shawn Steele wrote: > > > > I definitely am against providing both tagging options. > > > But where is the harm in including cmn in the registry and then > deprecating > > in favour of zh-cmn? As stated previously, this would catch those who > > unwittingly tag with any 639-3 code and are unaware of macrolanguages > and > > 4646bis. > > I wasn't suggesting registering both. Its just my experience that people > don't really always pay that much attention, so they might use both. I was > merely suggesting that robust applications might want to recognize both > forms, even if one was "illegal". > > - Shawn > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_11716_16082589.1192048521280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Right.

On 10/10/07, Shawn Steele <Shawn.Steele@microsoft.com> wrote:
> > I definitely am against providing both tagging options.

> But where is the harm in including cmn in the registry and then deprecating
> in favour of zh-cmn?  As stated previously, this would catch those who
> unwittingly tag with any 639-3 code and are unaware of macrolanguages and
> 4646bis.

I wasn't suggesting registering both.  Its just my experience that people don't really always pay that much attention, so they might use both.  I was merely suggesting that robust applications might want to recognize both forms, even if one was "illegal".

- Shawn


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



--
Mark ------=_Part_11716_16082589.1192048521280-- --===============0620311474== 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 --===============0620311474==-- From ltru-bounces@ietf.org Wed Oct 10 16:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiL6-00053G-AF; Wed, 10 Oct 2007 16:39:32 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfiL5-000534-6x for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 16:39:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfiL4-00052v-SM for ltru@ietf.org; Wed, 10 Oct 2007 16:39:30 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfiL4-0001Zn-Ff for ltru@ietf.org; Wed, 10 Oct 2007 16:39:30 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007325460.msg for ; Wed, 10 Oct 2007 21:42:58 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 10 Oct 2007 21:39:33 +0100 From: "Debbie Garside" To: , References: <470D2F66.2010202@yahoo-inc.com> <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] RE: duel(ing) tags Date: Wed, 10 Oct 2007 21:38:15 +0100 Message-ID: <060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgLeKwEnoA0O6lJSC+xA/wWE7++agAAIQiAAAC3ncAAACfKUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Wed, 10 Oct 2007 21:42:58 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18038546a2=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, 10 Oct 2007 21:43:00 +0100 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 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 Shawn wrote: Its just my experience > that people don't really always pay that much attention, so > they might use both. I was merely suggesting that robust > applications might want to recognize both forms, even if one > was "illegal". But if we already know that is what people will do (which is the case) and if we are to use extended language subtags with the inclusion of 639-3 within the registry why not include a way to catch the "illegal" tags that is easy for applications to implement? I see more use than harm in using extended language subtags and deprecating the individual 639-3 codes to facilitate matching. This can be documented within 4646bis. Best regards Debbie > -----Original Message----- > From: Shawn Steele [mailto:Shawn.Steele@microsoft.com] > Sent: 10 October 2007 21:30 > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > Cc: ltru@ietf.org > Subject: RE: [Ltru] RE: duel(ing) tags > > > > I definitely am against providing both tagging options. > > > But where is the harm in including cmn in the registry and then > > deprecating in favour of zh-cmn? As stated previously, this would > > catch those who unwittingly tag with any 639-3 code and are > unaware of > > macrolanguages and 4646bis. > > I wasn't suggesting registering both. Its just my experience > that people don't really always pay that much attention, so > they might use both. I was merely suggesting that robust > applications might want to recognize both forms, even if one > was "illegal". > > - Shawn > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 17:02:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifigj-00010t-EP; Wed, 10 Oct 2007 17:01:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifigh-00010V-P8 for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 17:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifigh-0000vD-FB for ltru@ietf.org; Wed, 10 Oct 2007 17:01:51 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound5-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfigW-0000ZE-LK for ltru@ietf.org; Wed, 10 Oct 2007 17:01:47 -0400 Received: from outbound5-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-blu-R.bigfish.com (Postfix) with ESMTP id 691D011087DA; Wed, 10 Oct 2007 21:01:23 +0000 (UTC) Received: from mail31-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound5-blu.bigfish.com (Postfix) with ESMTP id 196B6B30052; Wed, 10 Oct 2007 21:01:23 +0000 (UTC) Received: from mail31-blu (localhost.localdomain [127.0.0.1]) by mail31-blu-R.bigfish.com (Postfix) with ESMTP id 366DA1B881EF; Wed, 10 Oct 2007 21:01:22 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail31-blu (MessageSwitch) id 1192050081853132_1078; Wed, 10 Oct 2007 21:01:21 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail31-blu.bigfish.com (Postfix) with ESMTP id 1729B14C006E; Wed, 10 Oct 2007 21:01:20 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007101014011863-275738 ; Wed, 10 Oct 2007 14:01:18 -0700 In-Reply-To: <20071010193116.GC15438@mercury.ccil.org> To: John Cowan Subject: Re: [Ltru] Extended language tags (long reply) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 10 Oct 2007 13:58:53 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/10/2007 13:58:53, Serialize complete at 10/10/2007 13:58:53, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 02:01:18 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 02:01:21 PM, Serialize complete at 10/10/2007 02:01:21 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "ltru@ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Without additional disambiguation, this is very confusing to just about anyone with a language list that includes Flemish. It is especially confusing to me as the editor of ISO 639-3 previously indicated to me and the MPAA that this was indeed the tag for the Flemish dialect of Dutch. Granted, 639-3 was in DIS status at that point. After ISO 639-3 was published, I recommended the "vls" tag for a non-RFC-4646 usage than spanned efforts of several studios. Could we make a request for just a bit more disambiguation in the Ethnologue entry? This is text I received in a private e-mail about the tag when I presented a list of film languages a couple years back and asked for equivalents in ISO 639-3. I specifically noted the need to distinguish the Flemish dialect of Dutch from the Netherlands variant: "ISO 639-3 does have an entry for "Flemish", though it happens to use the autonym "Vlaams" for the reference name. That is, on the one hand, a documentation problem and, on the other, a UI problem: a developer needs to be able to discover that the entry "vls, 'Vlaams'" is for Flemish, and then they need to determine the UI string they should present to users that will allow *them* to find the correct item in a list. Regards, Karen Broome John Cowan 10/10/2007 12:31 PM To Karen_Broome@spe.sony.com cc "ltru@ietf.org" Subject Re: [Ltru] Extended language tags (long reply) Karen_Broome@spe.sony.com scripsit: > I wrote: > > (I still don't know whether "vls" > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a > synonym for Vlaams in 639-3.) It does not. > Sorry, I meant to say that "Flemish" is cited as a synonym on > Ethnologue.com. That is to say, the name "Flemish" has been used for both vls and the Belgian version of nl. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall cowan@ccil.org buy a piece of the rope for a keepsake. _______________________________________________ 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 10 18:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfkJn-00022d-Vm; Wed, 10 Oct 2007 18:46:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfkJm-00022N-Bd for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 18:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfkJm-00021X-1s for ltru@ietf.org; Wed, 10 Oct 2007 18:46:18 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfkJg-0003qa-Nt for ltru@ietf.org; Wed, 10 Oct 2007 18:46:18 -0400 Received: from [10.72.72.156] (snvvpn1-10-72-72-c156.corp.yahoo.com [10.72.72.156]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9AMjIFu077568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 15:45:21 -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=1drLrUGDHczFRkQvN5k5XBAhZ6CLLlRL+rCQ3QhIB7re/s01UTxBaCKN8JTiOe6q Message-ID: <470D55FE.6040203@yahoo-inc.com> Date: Wed, 10 Oct 2007 15:45:18 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: [Ltru] RE: duel(ing) tags References: <470D2F66.2010202@yahoo-inc.com> <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> In-Reply-To: <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Read the spec. Items are not permitted to exist in both language and extlang. Furthermore, 'deprecated' does not mean illegal. In fact, you'd be required to support it as a valid tagging option. Whether my software chooses to deal with bad tags by equating them to something else is up to me (and how it does so), is my problem. Making such mappings obligatory (which, as I'll point out, requires registry access, something we have historically tried hard to avoid as an implementation requirement), I oppose. Addison Debbie Garside wrote: > Addison wrote: > >> I definitely am against providing both tagging options. > > But where is the harm in including cmn in the registry and then deprecating > in favour of zh-cmn? As stated previously, this would catch those who > unwittingly tag with any 639-3 code and are unaware of macrolanguages and > 4646bis. > > Best regards > > Debbie > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 10 October 2007 21:01 >> To: Shawn Steele >> Cc: ltru@ietf.org >> Subject: Re: [Ltru] RE: duel(ing) tags >> >> 'cmn' is not a valid subtag at present. It is part of the >> 7000+ additional subtags in ISO 639-3 that are being added. >> Presumably nothing is tagged with 'cmn' today. >> >> I definitely am against providing both tagging options. >> >> Addison >> >> Shawn Steele wrote: >>> I was sort of wondering the same thing. >>> >>> I was thinking that to support mistakes, legacy tags & >> other randomness it might be best if any matching stuff I >> wrote recognized that cmn & zh-cmn were interchangeable. It >> is unclear to me if data is currently tagged as cmn though, >> although I know some is tagged as zh-cmn. >>> - Shawn >>> >>> ------------------------------ >>> >>> Date: Wed, 10 Oct 2007 10:46:18 +0100 >>> From: "Debbie Garside" >>> Subject: RE: [Ltru] Re: Extended language tags >>> To: , "'Doug Ewell'" >>> , "'LTRU Working >> Group'" >>> Message-ID: <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> >>> >>> Hi >>> >>> I may have missed the answer to this question, apologies if I have, >>> but why not include cwm within the registry and then >> deprecate in favour of zh-cwm? >>> This way both are in the registry and the fallback, as described by >>> Mark, is facilitated. The same could be done for zh-yue and yue and >>> no-nb etc. Thus if people tag "incorrectly", with, for >> example, cwm >>> or yue, applications would come up with the correct match anyway. >>> >>> I cannot pretend that I understand the entirety of the current >>> conversations wrt extended language tags but I do think their >>> inclusion would be useful for matching purposes. >>> >>> Best regards >>> >>> Debbie Garside >>> >>> >>> >>> _______________________________________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ltru >> -- >> Addison Phillips >> Globalization Architect -- Yahoo! Inc. >> Chair -- W3C Internationalization Core WG >> >> Internationalization is an architecture. >> It is not a feature. >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> > > > > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 10 19:07:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifkdg-0000aJ-Po; Wed, 10 Oct 2007 19:06:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifkde-0000Yy-Vd for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 19:06:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifkde-00007t-Kn for ltru@ietf.org; Wed, 10 Oct 2007 19:06:50 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfkdK-0005tn-Q1 for ltru@ietf.org; Wed, 10 Oct 2007 19:06:31 -0400 Received: from [10.72.72.156] (snvvpn1-10-72-72-c156.corp.yahoo.com [10.72.72.156]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9AN6HE7064755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 16:06:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=d3GzUdoRAYS2FSLo55adlmq29BRA6rUkS9itlkkL6gNUS+4EZLofq/xRcEbXb/Tt Message-ID: <470D5AE9.6020304@yahoo-inc.com> Date: Wed, 10 Oct 2007 16:06:17 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: [Ltru] RE: duel(ing) tags References: <470D2F66.2010202@yahoo-inc.com> <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> <060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> In-Reply-To: <060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 > why not include a way to catch the "illegal" tags that > is easy for applications to implement? Ur... that's what the registry does. I can catch the fact that "cmn-HK" is not valid and it's really easy to implement. What you mean is that I should be able to infer that the user really means "zh-cmn-HK", which I might be able to do in my software (but which I am free *not* to do at present). After all, plenty of content is labeled with the language tag "english". Implementations are free to infer that this really means "en". However, they are not obliged to do so. > I see more use than harm in using > extended language subtags and deprecating the individual > 639-3 codes to > facilitate matching. This can be documented within 4646bis. I sense perhaps some confusion here? We are not talking about deprecated any ISO 639-3 codes. We are talking about how ISO 639-3 codes are incorporated into the registry. 'cmn' is a perfectly valid ISO 639-3 code. We have several choices for how to include it in the registry: - as a primary language subtag (making tags like "cmn-Hant-HK" valid) - as an extlang of 'zh' (making tags like "zh-cmn-Hant-HK" valid) // note: notice that I chose an un-grandfathered tag there - as a primary language subtag that is deprecated (making tags like "cmn-Hant-HK" valid, but deprecated) - not at all (none of the tags in this example would be valid then) Let me note that "special case" handling and mapping in matching algorithms is incredibly painful to build and maintain. If you choose to canonicalize tags and ranges before processing, this isn't so bad. But if you are a "good citizen" and preserve the original form of the tags/ranges for later consumption, one must implement quite complex logic for doing what's supposed to be quite simple matching. Furthermore, this requires, absolutely, access to information above and beyond that embodied in the tags/ranges themselves. That is a wholesale departure from current practice in matching. While my own implementations might very well use such information (and more) to "do the right thing", that is *my* application and you might not care for my particular implementation choices (they may not be right for your application). To the extent that we can describe behaviors that do not require registry access, I am content with either primary language subtags or extlangs (but NOT both for the same language). Remember: a deprecated subtag is still a valid subtag. Addison PS> Note that the word "valid" in the foregoing refers explicitly to the terminology defined in Section 2.2.9 "Classes of Conformance" in the current draft of RFC 4646bis (and by intention to the same section in RFC 4646). Debbie Garside wrote: > Shawn wrote: > > Its just my experience >> that people don't really always pay that much attention, so >> they might use both. I was merely suggesting that robust >> applications might want to recognize both forms, even if one >> was "illegal". > > But if we already know that is what people will do (which is the case) and > if we are to use extended language subtags with the inclusion of 639-3 > within the registry why not include a way to catch the "illegal" tags that > is easy for applications to implement? I see more use than harm in using > extended language subtags and deprecating the individual 639-3 codes to > facilitate matching. This can be documented within 4646bis. > > Best regards > > Debbie > > >> -----Original Message----- >> From: Shawn Steele [mailto:Shawn.Steele@microsoft.com] >> Sent: 10 October 2007 21:30 >> To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com >> Cc: ltru@ietf.org >> Subject: RE: [Ltru] RE: duel(ing) tags >> >>>> I definitely am against providing both tagging options. >>> But where is the harm in including cmn in the registry and then >>> deprecating in favour of zh-cmn? As stated previously, this would >>> catch those who unwittingly tag with any 639-3 code and are >> unaware of >>> macrolanguages and 4646bis. >> I wasn't suggesting registering both. Its just my experience >> that people don't really always pay that much attention, so >> they might use both. I was merely suggesting that robust >> applications might want to recognize both forms, even if one >> was "illegal". >> >> - Shawn >> >> >> > > > > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 10 19:45:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IflEq-0002sE-Rv; Wed, 10 Oct 2007 19:45:16 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IflEq-0002oG-1L for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 19:45:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IflEp-0002o2-Lt for ltru@ietf.org; Wed, 10 Oct 2007 19:45:15 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IflEo-0006p5-KV for ltru@ietf.org; Wed, 10 Oct 2007 19:45:15 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007325896.msg for ; Thu, 11 Oct 2007 00:48:43 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 11 Oct 2007 00:45:17 +0100 From: "Debbie Garside" To: References: <470D2F66.2010202@yahoo-inc.com> <060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> <060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> <470D5AE9.6020304@yahoo-inc.com> Subject: RE: [Ltru] RE: duel(ing) tags Date: Thu, 11 Oct 2007 00:44:03 +0100 Message-ID: <062401c80b97$706d2ef0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <470D5AE9.6020304@yahoo-inc.com> Thread-Index: AcgLkpHX4oQPe2ZBQFqIqMl1dmUCVwAAdc2A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Thu, 11 Oct 2007 00:48:43 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18038546a2=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, 11 Oct 2007 00:48:44 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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: , Errors-To: ltru-bounces@ietf.org Hi Addison Comments in line... > > why not include a way to catch the "illegal" tags that > > is easy for applications to implement? > > Ur... that's what the registry does. I can catch the fact > that "cmn-HK" > is not valid and it's really easy to implement. What you mean > is that I should be able to infer that the user really means > "zh-cmn-HK", which I might be able to do in my software (but > which I am free *not* to do at present). That is exactly what I mean. > > After all, plenty of content is labeled with the language tag > "english". > Implementations are free to infer that this really means > "en". However, they are not obliged to do so. > > > I see more use than harm in using > > extended language subtags and deprecating the individual > > 639-3 codes to > facilitate matching. This can be > documented within 4646bis. > > I sense perhaps some confusion here? I don't think I am confused at all... Having read your email :-) > We are not talking about deprecated any ISO 639-3 codes. We > are talking about how ISO 639-3 codes are incorporated into > the registry. That is exactly what I am talking about. >'cmn' is a perfectly valid ISO 639-3 code. Agreed > We > have several choices for how to include it in the registry: > > - as a primary language subtag (making tags like "cmn-Hant-HK" valid) > - as an extlang of 'zh' (making tags like "zh-cmn-Hant-HK" valid) > // note: notice that I chose an un-grandfathered tag there > - as a primary language subtag that is deprecated (making > tags like "cmn-Hant-HK" valid, but deprecated) > - not at all (none of the tags in this example would be valid then) Indeed. I understood this perfectly well. I was attempting to show how cmn could be incorporated within the registry as an extlang of 'zh' whilst also covering the back door by registering 'cmn' and then immediately deprecating 'cmn' in favour of 'zh-cmn'. You already have several deprecated subtags what is the problem with a few more to deal with the macrolanguage scenario? > Let me note that "special case" handling and mapping in > matching algorithms is incredibly painful to build and > maintain. If you choose to canonicalize tags and ranges > before processing, this isn't so bad. But if you are a "good > citizen" and preserve the original form of the tags/ranges > for later consumption, one must implement quite complex logic > for doing what's supposed to be quite simple matching. What I have proposed is fairly simple logic for matching purposes. > Furthermore, this requires, absolutely, access to information > above and beyond that embodied in the tags/ranges themselves. > That is a wholesale departure from current practice in > matching. While my own implementations might very well use > such information (and more) to "do the right thing", that is > *my* application and you might not care for my particular > implementation choices (they may not be right for your > application). To the extent that we can describe behaviors > that do not require registry access, I am content with either > primary language subtags or extlangs (but NOT both for the > same language). I am not proposing both for the same language as such. I am proposing to deprecate one in favour of the other. > > Remember: a deprecated subtag is still a valid subtag. Yes, I know. Perhaps you would like to call it something else? Retired as part of macrolanguage? Replaced by? The whole point is to have both within the registry; one current, one not current but both valid for matching. By deprecating cmn to zh-cmn matching is facilitated. Text within RFC4646bis can be quite simply written to explain this. Now I am going to shut up about it as I am obviously banging my head against a brick wall. But I really cannot see what the problem is; other than people will tag with both zh-cmn and cmn whether we like it or not and I think it is far better to deal with that scenario within the registry rather than leave it to application designers who may not be as conversant with RFC4646bis as you (and maybe) me :-) Best regards Debbie > Addison > > PS> Note that the word "valid" in the foregoing refers > explicitly to the > terminology defined in Section 2.2.9 "Classes of Conformance" > in the current draft of RFC 4646bis (and by intention to the > same section in RFC 4646). > > Debbie Garside wrote: > > Shawn wrote: > > > > Its just my experience > >> that people don't really always pay that much attention, so they > >> might use both. I was merely suggesting that robust applications > >> might want to recognize both forms, even if one was "illegal". > > > > But if we already know that is what people will do (which > is the case) > > and if we are to use extended language subtags with the > inclusion of > > 639-3 within the registry why not include a way to catch > the "illegal" tags that > > is easy for applications to implement? I see more use > than harm in using > > extended language subtags and deprecating the individual > 639-3 codes > > to facilitate matching. This can be documented within 4646bis. > > > > Best regards > > > > Debbie > > > > > >> -----Original Message----- > >> From: Shawn Steele [mailto:Shawn.Steele@microsoft.com] > >> Sent: 10 October 2007 21:30 > >> To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > >> Cc: ltru@ietf.org > >> Subject: RE: [Ltru] RE: duel(ing) tags > >> > >>>> I definitely am against providing both tagging options. > >>> But where is the harm in including cmn in the registry and then > >>> deprecating in favour of zh-cmn? As stated previously, > this would > >>> catch those who unwittingly tag with any 639-3 code and are > >> unaware of > >>> macrolanguages and 4646bis. > >> I wasn't suggesting registering both. Its just my experience that > >> people don't really always pay that much attention, so > they might use > >> both. I was merely suggesting that robust applications > might want to > >> recognize both forms, even if one was "illegal". > >> > >> - Shawn > >> > >> > >> > > > > > > > > > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > 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 10 20:46:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfmBW-0004dE-6X; Wed, 10 Oct 2007 20:45:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfmBU-0004cW-GU for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 20:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfmBU-0004cO-6t for ltru@ietf.org; Wed, 10 Oct 2007 20:45:52 -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 1IfmBO-00077F-0I for ltru@ietf.org; Wed, 10 Oct 2007 20:45:52 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 10 Oct 2007 17:45:15 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Wed, 10 Oct 2007 17:45:15 -0700 From: Peter Constable To: "ltru@ietf.org" Date: Wed, 10 Oct 2007 17:45:12 -0700 Subject: RE: [Ltru] Extended language tags (long reply) Thread-Topic: [Ltru] Extended language tags (long reply) Thread-Index: AcgLgO8NBpjArryaTt+zejNQ5AxW9wAF96KQ Message-ID: References: <20071010193116.GC15438@mercury.ccil.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: 'ISO 639 Joint Advisory Committee' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [cc to JAC] The documentation problem is something that ISO 639 RAs potentially can and= probably should address so that it's clear to implementers that "vls" is i= ndeed the identifier for the language variety typically meant by the appell= ation "Flemish". Note, though, that there's no way to escape the issue Ethnologue is calling= out: that "Flemish" and "Vlaams" are sometimes used to refer to the variet= y usually called (in English) Dutch. If someone wants to find the ID for "F= lemish", they must first make sure they know what language variety it is th= ey are really dealing with. That is not a problem that ISO 639 can deal wit= h. Also, ISO 639 cannot really deal with the UI issue. Languages can have many= names. Some names may go in or out of vogue; some names may be strongly pr= eferred in some places and simultaneously strongly disparaged in other plac= es. It is not the role of the ISO 639 JAC or the RAs to give out recommenda= tions as to what names should be exposed to users in products. Finally, wrt our email exchange in 2005, I think I may have expressed thing= s in a way that was misunderstood. I believe this is the bit in question: E.g. Karen mentioned "nld-BE" (3066 would use require nd-BE) for Flemish, t= hough 639-3 will provide "vls". I expect a successor to RFC 3066 will consi= der both valid, though we can't force people to use "vls" if they happen to= come up with "nd-BE". I'm pretty sure I did not mean to imply by these comments that I considered= "vls" appropriate for Dutch spoken in the Flemish region. I believe I thou= ght we were discussing Flemish aka Vlaams. Peter > -----Original Message----- > From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > Sent: Wednesday, October 10, 2007 1:59 PM > To: John Cowan > Cc: ltru@ietf.org > Subject: Re: [Ltru] Extended language tags (long reply) > > Without additional disambiguation, this is very confusing to just about > anyone with a language list that includes Flemish. It is especially > confusing to me as the editor of ISO 639-3 previously indicated to me > and > the MPAA that this was indeed the tag for the Flemish dialect of Dutch. > Granted, 639-3 was in DIS status at that point. After ISO 639-3 was > published, I recommended the "vls" tag for a non-RFC-4646 usage than > spanned efforts of several studios. > > Could we make a request for just a bit more disambiguation in the > Ethnologue entry? > > This is text I received in a private e-mail about the tag when I > presented > a list of film languages a couple years back and asked for equivalents > in > ISO 639-3. I specifically noted the need to distinguish the Flemish > dialect of Dutch from the Netherlands variant: > > "ISO 639-3 does have an entry for "Flemish", though it happens to use > the > autonym "Vlaams" for the reference name. That is, on the one hand, a > documentation problem and, on the other, a UI problem: a developer > needs > to be able to discover that the entry "vls, 'Vlaams'" is for Flemish, > and > then they need to determine the UI string they should present to users > that will allow *them* to find the correct item in a list. > > Regards, > > Karen Broome > > > > > > John Cowan > 10/10/2007 12:31 PM > > To > Karen_Broome@spe.sony.com > cc > "ltru@ietf.org" > Subject > Re: [Ltru] Extended language tags (long reply) > > > > > > > Karen_Broome@spe.sony.com scripsit: > > I wrote: > > > > (I still don't know whether "vls" > > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as > a > > synonym for Vlaams in 639-3.) > > It does not. > > > Sorry, I meant to say that "Flemish" is cited as a synonym on > > Ethnologue.com. > > That is to say, the name "Flemish" has been used for both vls and > the Belgian version of nl. > > -- > Mark Twain on Cecil Rhodes: John Cowan > I admire him, I freely admit it, > http://www.ccil.org/~cowan > and when his time comes I shall cowan@ccil.org > buy a piece of the rope for a keepsake. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 10 21:04:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfmTJ-0000pQ-4y; Wed, 10 Oct 2007 21:04:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfmTI-0000pD-0K for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 21:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfmTH-0000p5-N1 for ltru@ietf.org; Wed, 10 Oct 2007 21:04:15 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfmTB-0007ch-GU for ltru@ietf.org; Wed, 10 Oct 2007 21:04:15 -0400 Received: by wa-out-1112.google.com with SMTP id k40so625611wah for ; Wed, 10 Oct 2007 18:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=M9jSgVcAtW/iPa4+6UnzkeCs3lnEZNKDWUyh3cab5dw=; b=nmozEF6+guzwpM63O+idsVmrYJ2pL2amGnLH0C9vSUQX148eiJacwCny0Z1nB4zwt1uMQySXuNB+O/rjcFqVBwGY6bPMJwcXmLdKPEZW0HCwyImdSxnTf8O+Juf0bDaZl4Dtpkxx23mIiUeOwkhAnUvvYWHpRil+SaqdADO1GgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=CHNwjtCkW6YXDCNOOreDHap8Zqe2UcT9O7eFRZ6J4mPr5ehHW7UXLCDzPBww7Jbn/iIr3uenFdA47a5h2ejnTco54wqnrXR6CiGwiQaI3QjVNKbIVEd65GjtXfOESHzIF3gk+LXqjLLtsPrAoP0ZjiU+uzKTKve5Svt5nCRxcqc= Received: by 10.114.134.1 with SMTP id h1mr1513112wad.1192064616767; Wed, 10 Oct 2007 18:03:36 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 10 Oct 2007 18:03:36 -0700 (PDT) Message-ID: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> Date: Wed, 10 Oct 2007 18:03:36 -0700 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 33335d976bcbdf00 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1945605944==" Errors-To: ltru-bounces@ietf.org --===============1945605944== Content-Type: multipart/alternative; boundary="----=_Part_13013_23045562.1192064616768" ------=_Part_13013_23045562.1192064616768 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We've been talking about two different models for dealing with macrolanguages: extlang and no-extlang. In our telephone conversations, a third has come up: partial-extlang. The partial-extlang model is where we only make X a secondary language for Y when it can reliably be assumed that someone who understands X will also understand Y. That would be the case if all of the microlanguages of Y are mutually intelligible, or if Y is generally identified with a "prestige" variant. With this model we wouldn't make all the microlanguages be secondary, just certain ones like those having ar and zh as macrolanguages. An example might be zh-yue. To assess these options, I suggest that the right way to do it is to look at the textual changes that we would need to make to RFC 4747 in order to have each of these work -- AND describes the implications for implementers. That way we can assess actual text that reflects the impact of the models on the operations that use their structure. Mark ------=_Part_13013_23045562.1192064616768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We've been talking about two different models for dealing with macrolanguages: extlang and no-extlang. In our telephone conversations, a third has come up: partial-extlang.

The partial-extlang model is where we only make X a secondary language for Y when it can reliably be assumed that someone who understands X will also understand Y. That would be the case if all of the microlanguages of Y are mutually intelligible, or if Y is generally identified with a "prestige" variant. With this model we wouldn't make all the microlanguages be secondary, just certain ones like those having ar and zh as macrolanguages. An example might be zh-yue.

To assess these options, I suggest that the right way to do it is to look at the textual changes that we would need to make to RFC 4747 in order to have each of these work -- AND describes the implications for implementers. That way we can assess actual text that reflects the impact of the models on the operations that use their structure.

Mark
------=_Part_13013_23045562.1192064616768-- --===============1945605944== 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 --===============1945605944==-- From ltru-bounces@ietf.org Wed Oct 10 21:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifn47-0002k6-5G; Wed, 10 Oct 2007 21:42:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifn46-0002ip-2i for ltru-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 21:42:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifn45-0002if-M9 for ltru@ietf.org; Wed, 10 Oct 2007 21:42:17 -0400 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound8-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifn3z-0001X5-5J for ltru@ietf.org; Wed, 10 Oct 2007 21:42:12 -0400 Received: from outbound8-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound8-sin-R.bigfish.com (Postfix) with ESMTP id 9F2AA1539C54; Thu, 11 Oct 2007 01:42:03 +0000 (UTC) Received: from mail57-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound8-sin.bigfish.com (Postfix) with ESMTP id 9311815D8058; Thu, 11 Oct 2007 01:42:03 +0000 (UTC) Received: from mail57-sin (localhost.localdomain [127.0.0.1]) by mail57-sin-R.bigfish.com (Postfix) with ESMTP id E64A9E201A9; Thu, 11 Oct 2007 01:42:01 +0000 (UTC) X-BigFish: VP X-FB-SS: 0, X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail57-sin (MessageSwitch) id 1192066921888417_6106; Thu, 11 Oct 2007 01:42:01 +0000 (UCT) Received: from USCCIMTA02.spe.sony.com (unknown [64.14.251.196]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail57-sin.bigfish.com (Postfix) with ESMTP id 9020E19D805C; Thu, 11 Oct 2007 01:42:01 +0000 (UTC) Received: from usmail02.spe.sony.com ([43.130.148.26]) by USCCIMTA02.spe.sony.com (Lotus Domino Release 6.5.5) with ESMTP id 2007101018420606-290423 ; Wed, 10 Oct 2007 18:42:06 -0700 In-Reply-To: To: Peter Constable Subject: RE: [Ltru] Extended language tags (long reply) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 Message-ID: From: Karen_Broome@spe.sony.com Date: Wed, 10 Oct 2007 18:39:41 -0700 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 10/10/2007 18:39:40, Serialize complete at 10/10/2007 18:39:40, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 06:42:06 PM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 10/10/2007 06:42:08 PM, Serialize complete at 10/10/2007 06:42:08 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: "ltru@ietf.org" , 'ISO 639 Joint Advisory Committee' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 comment I quoted was in reply to this comment from me. I think it was pretty clear that I was talking about dialects of Dutch. The context for this comment was not RFC 4646, it was ISO 639-6 and some of the interesting things I saw in its hierarchical structure and spoken/written distinctions: Dialects represented here are critical to us even if we only use a small subset of these codes. The difference between Dutch and Flemish is important in our world. I understand that Dutch productions are often subtitled in Flanders because the accent is so different. In written form, there is very little to distinguish the two dialects. Even 639-3 doesn't recognize Flemish. The people tasked with classifying content and developing linguistic classifications are usually not people who can tell the difference between Flemish and Vlaams given a piece of data that merely says "Flemish." For this reason, I request clarification on both the Dutch and Vlaams pages on the Ethnologue site. This would help. This is now probably off-topic for the IETF list, but serves as a reminder of the confusion that can result from the combination of such different language standards in BCP 47 and the need for adequate documentation and disambiguation at the Ethnologue site. I think ISO 639-3 may prove to be too complex for the average classifier of linguistic content. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 Peter Constable 10/10/2007 05:45 PM To "ltru@ietf.org" cc 'ISO 639 Joint Advisory Committee' Subject RE: [Ltru] Extended language tags (long reply) [cc to JAC] The documentation problem is something that ISO 639 RAs potentially can and probably should address so that it's clear to implementers that "vls" is indeed the identifier for the language variety typically meant by the appellation "Flemish". Note, though, that there's no way to escape the issue Ethnologue is calling out: that "Flemish" and "Vlaams" are sometimes used to refer to the variety usually called (in English) Dutch. If someone wants to find the ID for "Flemish", they must first make sure they know what language variety it is they are really dealing with. That is not a problem that ISO 639 can deal with. Also, ISO 639 cannot really deal with the UI issue. Languages can have many names. Some names may go in or out of vogue; some names may be strongly preferred in some places and simultaneously strongly disparaged in other places. It is not the role of the ISO 639 JAC or the RAs to give out recommendations as to what names should be exposed to users in products. Finally, wrt our email exchange in 2005, I think I may have expressed things in a way that was misunderstood. I believe this is the bit in question: E.g. Karen mentioned "nld-BE" (3066 would use require nd-BE) for Flemish, though 639-3 will provide "vls". I expect a successor to RFC 3066 will consider both valid, though we can't force people to use "vls" if they happen to come up with "nd-BE". I'm pretty sure I did not mean to imply by these comments that I considered "vls" appropriate for Dutch spoken in the Flemish region. I believe I thought we were discussing Flemish aka Vlaams. Peter > -----Original Message----- > From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > Sent: Wednesday, October 10, 2007 1:59 PM > To: John Cowan > Cc: ltru@ietf.org > Subject: Re: [Ltru] Extended language tags (long reply) > > Without additional disambiguation, this is very confusing to just about > anyone with a language list that includes Flemish. It is especially > confusing to me as the editor of ISO 639-3 previously indicated to me > and > the MPAA that this was indeed the tag for the Flemish dialect of Dutch. > Granted, 639-3 was in DIS status at that point. After ISO 639-3 was > published, I recommended the "vls" tag for a non-RFC-4646 usage than > spanned efforts of several studios. > > Could we make a request for just a bit more disambiguation in the > Ethnologue entry? > > This is text I received in a private e-mail about the tag when I > presented > a list of film languages a couple years back and asked for equivalents > in > ISO 639-3. I specifically noted the need to distinguish the Flemish > dialect of Dutch from the Netherlands variant: > > "ISO 639-3 does have an entry for "Flemish", though it happens to use > the > autonym "Vlaams" for the reference name. That is, on the one hand, a > documentation problem and, on the other, a UI problem: a developer > needs > to be able to discover that the entry "vls, 'Vlaams'" is for Flemish, > and > then they need to determine the UI string they should present to users > that will allow *them* to find the correct item in a list. > > Regards, > > Karen Broome > > > > > > John Cowan > 10/10/2007 12:31 PM > > To > Karen_Broome@spe.sony.com > cc > "ltru@ietf.org" > Subject > Re: [Ltru] Extended language tags (long reply) > > > > > > > Karen_Broome@spe.sony.com scripsit: > > I wrote: > > > > (I still don't know whether "vls" > > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as > a > > synonym for Vlaams in 639-3.) > > It does not. > > > Sorry, I meant to say that "Flemish" is cited as a synonym on > > Ethnologue.com. > > That is to say, the name "Flemish" has been used for both vls and > the Belgian version of nl. > > -- > Mark Twain on Cecil Rhodes: John Cowan > I admire him, I freely admit it, > http://www.ccil.org/~cowan > and when his time comes I shall cowan@ccil.org > buy a piece of the rope for a keepsake. > > > _______________________________________________ > 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 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 02:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfrGE-0007lp-6L; Thu, 11 Oct 2007 02:11:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfrGC-0007aN-Ac for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 02:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfrGB-0007QT-Jw for ltru@lists.ietf.org; Thu, 11 Oct 2007 02:11: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 1IfrG0-000115-CG for ltru@lists.ietf.org; Thu, 11 Oct 2007 02:10:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfrF8-0002jU-Ez for ltru@lists.ietf.org; Thu, 11 Oct 2007 06:09:58 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 06:09:58 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 06:09:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 11 Oct 2007 08:07:05 +0200 Lines: 15 Message-ID: References: <470D2F66.2010202@yahoo-inc.com><060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110> <060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> 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: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: RE: duel(ing) 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 Debbie Garside wrote: > if we already know that is what people will do (which is the case) and > if we are to use extended language subtags with the inclusion of 639-3 > within the registry why not include a way to catch the "illegal" tags > that is easy for applications to implement? Your proposal is a cute hack. =20 If we're *_not_* using the extlang-construct we'd deprecate zh-cmn with preferred value cmn. In both cases we'd end up with about 200 = deprecated aliases, don't we ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 02:38:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrgh-0000rJ-VQ; Thu, 11 Oct 2007 02:38:27 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifrgg-0000pt-M8 for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 02:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrgg-0000pl-88 for ltru@lists.ietf.org; Thu, 11 Oct 2007 02:38:26 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifrgb-0001zb-Vw for ltru@lists.ietf.org; Thu, 11 Oct 2007 02:38:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfrgR-0005Ll-Jr for ltru@lists.ietf.org; Thu, 11 Oct 2007 06:38:11 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 06:38:11 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 06:38:11 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 11 Oct 2007 08:35:39 +0200 Lines: 24 Message-ID: References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > The partial-extlang model is where we only make X a secondary language = for > Y when it can reliably be assumed that someone who understands X will = also > understand Y. Hard to judge. One of the sources I used for the Suppress-Script = modification requests claims that folks talking "mt" understand "ar-015" but can't = read it.=20 > That would be the case if all of the microlanguages of Y are mutually = intelligible, > or if Y is generally identified with a "prestige" variant. What's a "prestige variant", is that a weasel word for "zh" ? I also = don't like the term "microlanguage" as long as it's undefined. Are say "mt", "lb", = "nds",=20 or "gsw" microlanguages ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 02:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrxy-0007pr-Fq; Thu, 11 Oct 2007 02:56:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifrxx-0007mk-EE for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 02:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrxt-0007iI-5J for ltru@lists.ietf.org; Thu, 11 Oct 2007 02:56: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 1Ifrxn-0002Xm-R3 for ltru@lists.ietf.org; Thu, 11 Oct 2007 02:56:13 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007326947.msg for ; Thu, 11 Oct 2007 07:59:19 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 11 Oct 2007 07:55:51 +0100 From: "Debbie Garside" To: , References: <470D2F66.2010202@yahoo-inc.com><060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110><060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] Re: RE: duel(ing) tags Date: Thu, 11 Oct 2007 07:54:33 +0100 Message-ID: <068c01c80bd3$95e09eb0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgLzgG31ZCVpzGgSO+6nxTlEppH6wABXMxA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Thu, 11 Oct 2007 07:59:19 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18043d9518=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, 11 Oct 2007 07:59:20 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: > If we're *_not_* using the extlang-construct we'd deprecate > zh-cmn with preferred value cmn. In both cases we'd end up > with about 200 deprecated aliases, don't we ? Exactly :-) Debbie > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: 11 October 2007 07:07 > To: ltru@lists.ietf.org > Subject: [Ltru] Re: RE: duel(ing) tags > > Debbie Garside wrote: > > > if we already know that is what people will do (which is > the case) and > > if we are to use extended language subtags with the > inclusion of 639-3 > > within the registry why not include a way to catch the > "illegal" tags > > that is easy for applications to implement? > > Your proposal is a cute hack. > > If we're *_not_* using the extlang-construct we'd deprecate > zh-cmn with preferred value cmn. In both cases we'd end up > with about 200 deprecated aliases, don't we ? > > 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 Thu Oct 11 04:50:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iftk1-0002iS-4d; Thu, 11 Oct 2007 04:50:01 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iftjz-0002hX-RK for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 04:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iftjz-0002hB-Cs for ltru@lists.ietf.org; Thu, 11 Oct 2007 04:49: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 1Iftjy-00070e-5O for ltru@lists.ietf.org; Thu, 11 Oct 2007 04:49:59 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007327596.msg for ; Thu, 11 Oct 2007 09:53:24 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 11 Oct 2007 09:49:59 +0100 From: "Debbie Garside" To: , References: <470D2F66.2010202@yahoo-inc.com><060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110><060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] Re: RE: duel(ing) tags Date: Thu, 11 Oct 2007 09:48:41 +0100 Message-ID: <069801c80be3$86a8a4a0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgLzgG31ZCVpzGgSO+6nxTlEppH6wAFKeZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Thu, 11 Oct 2007 09:53:24 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18043d9518=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, 11 Oct 2007 09:53:24 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: > If we're *_not_* using the extlang-construct we'd deprecate > zh-cmn with preferred value cmn. In both cases we'd end up > with about 200 deprecated aliases, don't we ? In fact, it is more preferable to deprecate zh-cmn in favour of cmn. This way application designers need not include matching for extlang if they don't want to; they can purely match to primary language subtags. Best regards Debbie > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: 11 October 2007 07:07 > To: ltru@lists.ietf.org > Subject: [Ltru] Re: RE: duel(ing) tags > > Debbie Garside wrote: > > > if we already know that is what people will do (which is > the case) and > > if we are to use extended language subtags with the > inclusion of 639-3 > > within the registry why not include a way to catch the > "illegal" tags > > that is easy for applications to implement? > > Your proposal is a cute hack. > > If we're *_not_* using the extlang-construct we'd deprecate > zh-cmn with preferred value cmn. In both cases we'd end up > with about 200 deprecated aliases, don't we ? > > 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 Thu Oct 11 07:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifw7D-0002kP-QO; Thu, 11 Oct 2007 07:22:07 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifw7A-0002dG-HO for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 07:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifw79-0002b5-OO for ltru@ietf.org; Thu, 11 Oct 2007 07:22:03 -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 1Ifw72-000409-Do for ltru@ietf.org; Thu, 11 Oct 2007 07:22:03 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007328732.msg for ; Thu, 11 Oct 2007 12:25:22 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 11 Oct 2007 12:21:49 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> Subject: RE: [Ltru] Matching Text Date: Thu, 11 Oct 2007 12:20:32 +0100 Message-ID: <06e601c80bf8$bc8d4930$0d00a8c0@CPQ86763045110> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> Thread-Index: AcgLo1hb4fTfYAkcRKuriqoOPnrsIwAVJUlw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Thu, 11 Oct 2007 12:25:22 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=18043d9518=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, 11 Oct 2007 12:25:22 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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="===============0585886429==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0585886429== Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E7_01C80C01.1E51B130" This is a multi-part message in MIME format. ------=_NextPart_000_06E7_01C80C01.1E51B130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If I was designing a UI for a matching application I would expect the user to enter the 639-3 code or the language name. I would then wish to inform the user that this code forms part of a macrolanguage that encompasses a number of other languages and offer the user an option to include, via some check box facility, any or all or none of the related codes as secondary matches. This puts the decision on the end user and negates the need for us to make any decisions as to intelligibility. Just my limited application :-) Best regards Debbie _____ From: Mark Davis [mailto:mark.davis@icu-project.org] Sent: 11 October 2007 02:04 To: LTRU Working Group Subject: [Ltru] Matching Text We've been talking about two different models for dealing with macrolanguages: extlang and no-extlang. In our telephone conversations, a third has come up: partial-extlang. The partial-extlang model is where we only make X a secondary language for Y when it can reliably be assumed that someone who understands X will also understand Y. That would be the case if all of the microlanguages of Y are mutually intelligible, or if Y is generally identified with a "prestige" variant. With this model we wouldn't make all the microlanguages be secondary, just certain ones like those having ar and zh as macrolanguages. An example might be zh-yue. To assess these options, I suggest that the right way to do it is to look at the textual changes that we would need to make to RFC 4747 in order to have each of these work -- AND describes the implications for implementers. That way we can assess actual text that reflects the impact of the models on the operations that use their structure. Mark ------=_NextPart_000_06E7_01C80C01.1E51B130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If I was designing a UI for a matching = application I would=20 expect the user to enter the 639-3 code or the language name.  I = would then=20 wish to inform the user that this code forms part of a macrolanguage = that=20 encompasses a number of other languages and offer the user an option to = include,=20 via some check box facility,  any or all or none of the related = codes as=20 secondary matches.  This puts the decision on the end user and = negates the=20 need for us to make any decisions as to intelligibility. Just my limited = application :-)
 
Best regards
 
Debbie

From: Mark Davis=20 [mailto:mark.davis@icu-project.org]
Sent: 11 October 2007=20 02:04
To: LTRU Working Group
Subject: [Ltru] = Matching=20 Text

We've been talking about two different models for dealing = with=20 macrolanguages: extlang and no-extlang. In our telephone = conversations, a=20 third has come up: partial-extlang.

The partial-extlang model = is where=20 we only make X a secondary language for Y when it can reliably be = assumed that=20 someone who understands X will also understand Y. That would be the = case if=20 all of the microlanguages of Y are mutually intelligible, or if Y is = generally=20 identified with a "prestige" variant. With this model we wouldn't make = all the=20 microlanguages be secondary, just certain ones like those having ar = and zh as=20 macrolanguages. An example might be zh-yue.

To assess these = options, I=20 suggest that the right way to do it is to look at the textual changes = that we=20 would need to make to RFC 4747 in order to have each of these work -- = AND=20 describes the implications for implementers. That way we can assess = actual=20 text that reflects the impact of the models on the operations that use = their=20 structure.

Mark
------=_NextPart_000_06E7_01C80C01.1E51B130-- --===============0585886429== 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 --===============0585886429==-- From ltru-bounces@ietf.org Thu Oct 11 07:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwPh-0004ox-JT; Thu, 11 Oct 2007 07:41:13 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfwPf-0004mv-PZ for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 07:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwPf-0004jY-AE for ltru@lists.ietf.org; Thu, 11 Oct 2007 07:41:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfwPZ-0004Zg-2f for ltru@lists.ietf.org; Thu, 11 Oct 2007 07:41:11 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfwO6-00058K-OX for ltru@lists.ietf.org; Thu, 11 Oct 2007 11:39:34 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 11:39:34 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Oct 2007 11:39:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 11 Oct 2007 13:35:43 +0200 Lines: 19 Message-ID: References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <06e601c80bf8$bc8d4930$0d00a8c0@CPQ86763045110> 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: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 I was designing a UI for a matching application I would expect the > user to enter the 639-3 code or the language name. I would then wish > to inform the user that this code forms part of a macrolanguage that > encompasses a number of other languages and offer the user an option > to include, via some check box facility, any or all or none of the > related codes as secondary matches. This puts the decision on the end > user and negates the need for us to make any decisions as to > intelligibility. Just my limited application :-) Sounds fine for a user configuring Accept-Languages for his browser, at least for languages with a Suppress-Script. But that's only one side of it. =20 My limited application is tagging Web pages, and I wasn't too thrilled when Google searches for English pages missed my en-GB-oed pages. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 08:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxHx-00060r-Go; Thu, 11 Oct 2007 08:37:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfxHv-0005vG-Lv for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:37:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxHv-0005uX-Am for ltru@ietf.org; Thu, 11 Oct 2007 08:37:15 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfxHu-0000Bi-Vy for ltru@ietf.org; Thu, 11 Oct 2007 08:37:15 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8DA64240826; Thu, 11 Oct 2007 13:37:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id B48A712E71; Thu, 11 Oct 2007 14:35:16 +0200 (CEST) Date: Thu, 11 Oct 2007 14:35:16 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20071011123516.GA27828@sources.org> References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LTRU Working Group Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 10, 2007 at 06:03:36PM -0700, Mark Davis wrote a message of 54 lines which said: > The partial-extlang model is where we only make X a secondary > language for Y when it can reliably be assumed that someone who > understands X will also understand Y. Won't it be a problem similar to the Suppress-Script issue? ietf-languages will have to evaluate languages and assess wether they are or not compatible, since the information is not in ISO-639. Unlike the other two proposals, this one is apparently not implementable by using only the ISO 639 standard. > To assess these options, I suggest that the right way to do it is to > look at the textual changes that we would need to make to RFC 4747 > in order to have each of these work -- AND describes the > implications for implementers. IMHO, the first thing to do would be to try to classify every macrolanguage in 639-3 according to this plan. We will probably discover it is complicated and flame-generating. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 09:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifxkm-00029S-Us; Thu, 11 Oct 2007 09:07:04 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifxkm-00029N-D7 for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 09:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifxkm-00029F-3S for ltru@lists.ietf.org; Thu, 11 Oct 2007 09:07:04 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifxkf-0008JH-9H for ltru@lists.ietf.org; Thu, 11 Oct 2007 09:07:04 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ifxke-0007nq-Rz; Thu, 11 Oct 2007 09:06:56 -0400 Date: Thu, 11 Oct 2007 09:06:56 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Matching Text Message-ID: <20071011130656.GD2710@mercury.ccil.org> References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan 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 Frank Ellermann scripsit: > One of the sources I used for the Suppress-Script modification requests > claims that folks talking "mt" understand "ar-015" but can't read it. Reasonable. Of course, they are going to lack vocabulary items that have been replaced in Maltese by English and Italian borrowings. > What's a "prestige variant", is that a weasel word for "zh" ? Macrolanguages come in two basic types. In the first type, there is a single encompassed language (Mandarin for Chinese, Standard Arabic for Arabic, Eastern Yiddish for Yiddish, Swahili (individual language) for Swahili (macrolanguage), e.g.) which has much higher numbers and status than the others. In the other type, there is no such dominance among the group of encompassed languages (Sardinian, Quechua, Romany, e.g.). Sometimes the answer is unclear: Tosk Albanian is the basis of Standard Albanian, but is spoken by only about 48% of all Albanian-speakers. > I also don't like the term "microlanguage" as long as it's undefined. It's the slang of this list for "language encompassed, according to ISO 639-3, by a macrolanguage". It will never be an official term. > Are say "mt", "lb", "nds", or "gsw" microlanguages ? Since none of them appear at http://www.sil.org/iso639-3/macrolanguages.asp , the answer is "no" by definition. All of them are part of the German dialect continuum, but then so is "nl". Sociolinguistically they all function as separate languages. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 10:33:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifz6B-00076q-TF; Thu, 11 Oct 2007 10:33:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifz6A-00075c-Kd for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:33:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifz6A-00075U-AX for ltru@ietf.org; Thu, 11 Oct 2007 10:33:14 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifz69-0007CQ-WA for ltru@ietf.org; Thu, 11 Oct 2007 10:33:14 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ifz67-0005Hi-62; Thu, 11 Oct 2007 10:33:11 -0400 Date: Thu, 11 Oct 2007 10:33:11 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Matching Text Message-ID: <20071011143311.GF2710@mercury.ccil.org> References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011123516.GA27828@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011123516.GA27828@sources.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > IMHO, the first thing to do would be to try to classify every > macrolanguage in 639-3 according to this plan. We will probably > discover it is complicated and flame-generating. Indeed. I've already mentioned the case of Albanian, and Azerbaijani is even more contentious: North Azerbaijani is the basis for the official language of Azerbaijan, but only about 22% of Azerbaijani speakers use it. What's more, as Ethnologue delicately says: North and South Azerbaijani are spoken by one ethnic group. Each language group is reluctant to accept the written form of the other. That is, North Azerbaijani is written in the Latin and Cyrillic scripts, South Azerbaijani in the Arabic script. Ethnologue says there are "significant differences" between the two, but provides no estimates of shared lexicon; other sources claim that mutual intelligibility is easily attained, and even with eastern Turkish and with Turkmen. -- There is no real going back. Though I John Cowan may come to the Shire, it will not seem cowan@ccil.org the same; for I shall not be the same. http://www.ccil.org/~cowan I am wounded with knife, sting, and tooth, and a long burden. Where shall I find rest? --Frodo _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 11:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzqg-0006r4-Cf; Thu, 11 Oct 2007 11:21:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ifzqf-0006qC-A4 for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzqe-0006q4-Vm for ltru@lists.ietf.org; Thu, 11 Oct 2007 11:21:16 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfzqY-0006Ok-Kk for ltru@lists.ietf.org; Thu, 11 Oct 2007 11:21:16 -0400 Received: by wa-out-1112.google.com with SMTP id j4so719921wah for ; Thu, 11 Oct 2007 08:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=SuQAeXIq+99hbCUTFigVIwTx14XKM77aGq2oP1hcGIo=; b=qTjoBlAl83dU+U+kDOMvyNcd6UEpUvrDuBtm4pp45yx6NT1TpsWWu2v281MBzfRjU9asHGDIGs/dOoxnfXy9X74hQMUMct94d0sNy088SNSXDVpXIVQVyentC1369WXKCNWAnoTKN+8ol1Gz/pkB+5SWhopZ+1umOvRosE2fTSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CCHw6F21wpPzA8804lSMvqx0p8abBHOI0MZ2Dr4t21mr5yo+YjpLxpsjgtQVJTVfqgKK4Ucy9Ha8sHPV83wftmCfaUu4Iopgvn7d5FX13BCVQ67SoXpTWwHVhOJjpjAvzlwfas+yoqqaSlGnyJBvC+u9SumUsTv7/27CvygpYmI= Received: by 10.114.134.1 with SMTP id h1mr2325447wad.1192116038513; Thu, 11 Oct 2007 08:20:38 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 11 Oct 2007 08:20:38 -0700 (PDT) Message-ID: <30b660a20710110820n776d797bvd4d58bf8cafb09fa@mail.gmail.com> Date: Thu, 11 Oct 2007 08:20:38 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Matching Text In-Reply-To: MIME-Version: 1.0 References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <06e601c80bf8$bc8d4930$0d00a8c0@CPQ86763045110> X-Google-Sender-Auth: 46a46174b30ef809 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080432788==" Errors-To: ltru-bounces@ietf.org --===============2080432788== Content-Type: multipart/alternative; boundary="----=_Part_15916_2879030.1192116038506" ------=_Part_15916_2879030.1192116038506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline At Google we end up having to only regard the tags on Web pages as (weak) hints, because so many pages are so badly tagged. Instead, we have to do automated detection. I believe the other search engines do this as well. Detection cannot effectively distinguish between relatively small variants of a language, as typically expressed by variant subtags, or even significant ones like most country variants. So for those cases, those features are not distinguished when pages are indexed. The situation is far worst for charsets, since a bad tag there has a much more serious impact than just getting the language wrong. The situation is very different for localization, rather than search. There we can support country variants, such as en vs en-GB, more effectively. Mark BTW. For those of you coming to the Unicode conference next week, I'll be giving a paper on how Google handles Unicode, charsets, and languages; I think there will be discussions of those issues by other companies as well. On 10/11/07, Frank Ellermann wrote: > > Debbie Garside wrote: > > > If I was designing a UI for a matching application I would expect the > > user to enter the 639-3 code or the language name. I would then wish > > to inform the user that this code forms part of a macrolanguage that > > encompasses a number of other languages and offer the user an option > > to include, via some check box facility, any or all or none of the > > related codes as secondary matches. This puts the decision on the end > > user and negates the need for us to make any decisions as to > > intelligibility. Just my limited application :-) > > Sounds fine for a user configuring Accept-Languages for his browser, > at least for languages with a Suppress-Script. But that's only one > side of it. > > My limited application is tagging Web pages, and I wasn't too thrilled > when Google searches for English pages missed my en-GB-oed pages. > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_15916_2879030.1192116038506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline At Google we end up having to only regard the tags on Web pages as (weak) hints, because so many pages are so badly tagged. Instead, we have to do automated detection. I believe the other search engines do this as well. Detection cannot effectively distinguish between relatively small variants of a language, as typically expressed by variant subtags, or even significant ones like most country variants. So for those cases, those features are not distinguished when pages are indexed.

The situation is far worst for charsets, since a bad tag there has a much more serious impact than just getting the language wrong.

The situation is very different for localization, rather than search. There we can support country variants, such as en vs en-GB, more effectively.

Mark

BTW. For those of you coming to the Unicode conference next week, I'll be giving a paper on how Google handles Unicode, charsets, and languages; I think there will be discussions of those issues by other companies as well.

On 10/11/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Debbie Garside wrote:

> If I was designing a UI for a matching application I would expect the
> user to enter the 639-3 code or the language name.  I would then wish
> to inform the user that this code forms part of a macrolanguage that
> encompasses a number of other languages and offer the user an option
> to include, via some check box facility,  any or all or none of the
> related codes as secondary matches.  This puts the decision on the end
> user and negates the need for us to make any decisions as to
> intelligibility. Just my limited application :-)

Sounds fine for a user configuring Accept-Languages for his browser,
at least for languages with a Suppress-Script.  But that's only one
side of it.

My limited application is tagging Web pages, and I wasn't too thrilled
when Google searches for English pages missed my en-GB-oed pages.

Frank



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



--
Mark ------=_Part_15916_2879030.1192116038506-- --===============2080432788== 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 --===============2080432788==-- From ltru-bounces@ietf.org Thu Oct 11 11:23:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzsb-00015b-1z; Thu, 11 Oct 2007 11:23:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IfzsZ-000151-2l for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzsY-00014t-PX for ltru@ietf.org; Thu, 11 Oct 2007 11:23:14 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfzsX-0006VS-Ey for ltru@ietf.org; Thu, 11 Oct 2007 11:23:14 -0400 Received: by wa-out-1112.google.com with SMTP id k40so962938wah for ; Thu, 11 Oct 2007 08:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=KmyJz/O0UjNRmUQDn3DbFnUP11m8gD/Y0RT2i57wv2c=; b=BwXvtJogQImhoI0PzQp4bvaKB6cuzK/maaVsdMQAxsvXIYIP4jh3n2jQqTeLyOOFG1YgvfpktTT4vP67r6jdsbs7wua2Xjoxa0a+kBMQcZ28dsKTGs3scVPJVz/jpGY9j7UDKMMkmsrgSmabyCHjbduj++Lv3D4a7Mom95rzeOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=h+hUD3EYsWhQY+mojvBue0gkkZcBZXk32gln2OOEe0bmavrrPS/NQ3shm5KMzePWJNtcHMReL3CpQjDNyjxu2qW8rwvYcemo/eQwAPon6+t83bBynZgZ08PoKzRIEZklmid53Nu8u1NbSXlpznmSfroKUI1uxSmJT9EEr/PgVhY= Received: by 10.114.151.13 with SMTP id y13mr2307070wad.1192116180387; Thu, 11 Oct 2007 08:23:00 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 11 Oct 2007 08:23:00 -0700 (PDT) Message-ID: <30b660a20710110823h1090e01dv376a6eb49c002b25@mail.gmail.com> Date: Thu, 11 Oct 2007 08:23:00 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" In-Reply-To: <20071011123516.GA27828@sources.org> MIME-Version: 1.0 References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011123516.GA27828@sources.org> X-Google-Sender-Auth: d39e74f6c3882b87 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: LTRU Working Group Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1693279006==" Errors-To: ltru-bounces@ietf.org --===============1693279006== Content-Type: multipart/alternative; boundary="----=_Part_15928_19703542.1192116180382" ------=_Part_15928_19703542.1192116180382 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I should have mentioned the other part of it. The extlang mechanism is only for backwards compatibility in the first place, so for the partial-extlang model we'd only need to look at cases where there has been a lot of tagging data with the macrolanguage tag because the microlanguage tags were not available. On 10/11/07, Stephane Bortzmeyer wrote: > > On Wed, Oct 10, 2007 at 06:03:36PM -0700, > Mark Davis wrote > a message of 54 lines which said: > > > The partial-extlang model is where we only make X a secondary > > language for Y when it can reliably be assumed that someone who > > understands X will also understand Y. > > Won't it be a problem similar to the Suppress-Script issue? > ietf-languages will have to evaluate languages and assess wether they > are or not compatible, since the information is not in ISO-639. > > Unlike the other two proposals, this one is apparently not > implementable by using only the ISO 639 standard. > > > To assess these options, I suggest that the right way to do it is to > > look at the textual changes that we would need to make to RFC 4747 > > in order to have each of these work -- AND describes the > > implications for implementers. > > IMHO, the first thing to do would be to try to classify every > macrolanguage in 639-3 according to this plan. We will probably > discover it is complicated and flame-generating. > > -- Mark ------=_Part_15928_19703542.1192116180382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I should have mentioned the other part of it. The extlang mechanism is only for backwards compatibility in the first place, so for the partial-extlang model we'd only need to look at cases where there has been a lot of tagging data with the macrolanguage tag because the microlanguage tags were not available.

On 10/11/07, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Wed, Oct 10, 2007 at 06:03:36PM -0700,
Mark Davis <mark.davis@icu-project.org> wrote
a message of 54 lines which said:

> The partial-extlang model is where we only make X a secondary
> language for Y when it can reliably be assumed that someone who
> understands X will also understand Y.

Won't it be a problem similar to the Suppress-Script issue?
ietf-languages will have to evaluate languages and assess wether they
are or not compatible, since the information is not in ISO-639.

Unlike the other two proposals, this one is apparently not
implementable by using only the ISO 639 standard.

> To assess these options, I suggest that the right way to do it is to
> look at the textual changes that we would need to make to RFC 4747
> in order to have each of these work -- AND describes the
> implications for implementers.

IMHO, the first thing to do would be to try to classify every
macrolanguage in 639-3 according to this plan. We will probably
discover it is complicated and flame-generating.




--
Mark ------=_Part_15928_19703542.1192116180382-- --===============1693279006== 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 --===============1693279006==-- From ltru-bounces@ietf.org Thu Oct 11 13:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1wm-0006a6-JX; Thu, 11 Oct 2007 13:35:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ig1wl-0006a0-OW for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 13:35:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1wl-0006Zs-DL for ltru@ietf.org; Thu, 11 Oct 2007 13:35:43 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig1wk-0007YM-W0 for ltru@ietf.org; Thu, 11 Oct 2007 13:35:43 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bXWjp9icod4L0cMsFyQciWMuaG6Ee1EEeWFTS58WczUc20YFcWJEbSNddfwPhjB7; 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 [64.105.34.184] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ig1wi-0004Y6-5p for ltru@ietf.org; Thu, 11 Oct 2007 13:35:40 -0400 Message-ID: <006801c80c2d$bb378a20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011130656.GD2710@mercury.ccil.org> Subject: Re: [Ltru] Re: Matching Text Date: Thu, 11 Oct 2007 10:39:51 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31aa3a5056446fde5fdf1d54e9e3df8b554350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.184 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: "Frank Ellermann" > Cc: > Sent: Thursday, October 11, 2007 6:06 AM > Subject: Re: [Ltru] Re: Matching Text > > Frank Ellermann scripsit: ... > > What's a "prestige variant", is that a weasel word for "zh" ? It's a term from the field of sociolinguistics, used to describe a variant that is favored in such ways as being taught in schools, used by TV and radio announcers, etc. > Macrolanguages come in two basic types. In the first type, there is a > single encompassed language (Mandarin for Chinese, Standard Arabic for > Arabic, Eastern Yiddish for Yiddish, Swahili (individual language) for > Swahili (macrolanguage), e.g.) which has much higher numbers and status > than the others. In the other type, there is no such dominance among > the group of encompassed languages (Sardinian, Quechua, Romany, e.g.). > Sometimes the answer is unclear: Tosk Albanian is the basis of Standard > Albanian, but is spoken by only about 48% of all Albanian-speakers. I think this perspective can help clearly illustrate the difference in how different people in this WG understand the problem. Here's how I would have put it: Macrolanguages come in two basic types. In the first type, the string which forms the macrolanguage subtag has historically been used as a tag for a particular language. As a consequence of the dominance of a particular variety of that language, common usage has resulted in a situation where, in the field, the macrolanguage subtag is effectively equivalent to the tag for the dominant variety. In the second type, there is no such history of usage, or no significant body of data tagged in that way exists. In this case, the macrolanguage subtag by itself merely has the semantic "undifferentiated Foo", meaning the content could be from any member of that macrolanguage family. More succinctly: some view "macrolanguage" as being effectively equivalent to some dominant or (likely) mutually intelligible member of the group, while others view "macrolanguage" as being simply an abstraction, not corresponding to any specific member of the group. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 11 13:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23U-0005fJ-KS; Thu, 11 Oct 2007 13:42:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ig23T-0005f5-EN for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23T-0005a5-1K for ltru@lists.ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig23E-0004lJ-3v for ltru@lists.ietf.org; Thu, 11 Oct 2007 13:42:30 -0400 Received: from [10.72.72.156] (snvvpn1-10-72-72-c156.corp.yahoo.com [10.72.72.156]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9BHg8Vp036039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 10:42:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=EAZktR6h2LPjaUQOIpDkFqxkM8QTlrkaP+z3a5DjAtFvx3PVCGITPcbFb8C5GMoG Message-ID: <470E606F.2080507@yahoo-inc.com> Date: Thu, 11 Oct 2007 10:42:07 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: [Ltru] Re: RE: duel(ing) tags References: <470D2F66.2010202@yahoo-inc.com><060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110><060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> <068c01c80bd3$95e09eb0$0d00a8c0@CPQ86763045110> In-Reply-To: <068c01c80bd3$95e09eb0$0d00a8c0@CPQ86763045110> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nobody@xyzzy.claranet.de, 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 Debbie Garside wrote: > >> If we're *_not_* using the extlang-construct we'd deprecate >> zh-cmn with preferred value cmn. In both cases we'd end up >> with about 200 deprecated aliases, don't we ? > > Exactly :-) > In the former case (deprecating "zh-cmn" and associates), we would be deprecating *existing* grandfathered tags. In the latter case (deprecating "cmn" and friends), we would be *adding* items into the registry in a deprecated state. This is, in part, what bothers me. There is no need to make these codes valid as primary language tags if they serve no purpose there. Making it legal for people to create undesirable codes "just because they will anyway" will contribute to poor tagging practice and a proliferation of tags synonymous in meaning but not in form. We already know this is bad: why encourage it? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 11 13:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23U-0005fJ-KS; Thu, 11 Oct 2007 13:42:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ig23T-0005f5-EN for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23T-0005a5-1K for ltru@lists.ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig23E-0004lJ-3v for ltru@lists.ietf.org; Thu, 11 Oct 2007 13:42:30 -0400 Received: from [10.72.72.156] (snvvpn1-10-72-72-c156.corp.yahoo.com [10.72.72.156]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9BHg8Vp036039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 10:42:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=EAZktR6h2LPjaUQOIpDkFqxkM8QTlrkaP+z3a5DjAtFvx3PVCGITPcbFb8C5GMoG Message-ID: <470E606F.2080507@yahoo-inc.com> Date: Thu, 11 Oct 2007 10:42:07 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: [Ltru] Re: RE: duel(ing) tags References: <470D2F66.2010202@yahoo-inc.com><060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110><060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> <068c01c80bd3$95e09eb0$0d00a8c0@CPQ86763045110> In-Reply-To: <068c01c80bd3$95e09eb0$0d00a8c0@CPQ86763045110> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nobody@xyzzy.claranet.de, 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 Debbie Garside wrote: > >> If we're *_not_* using the extlang-construct we'd deprecate >> zh-cmn with preferred value cmn. In both cases we'd end up >> with about 200 deprecated aliases, don't we ? > > Exactly :-) > In the former case (deprecating "zh-cmn" and associates), we would be deprecating *existing* grandfathered tags. In the latter case (deprecating "cmn" and friends), we would be *adding* items into the registry in a deprecated state. This is, in part, what bothers me. There is no need to make these codes valid as primary language tags if they serve no purpose there. Making it legal for people to create undesirable codes "just because they will anyway" will contribute to poor tagging practice and a proliferation of tags synonymous in meaning but not in form. We already know this is bad: why encourage it? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 11 13:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23U-0005fF-Hl; Thu, 11 Oct 2007 13:42:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ig23T-0005f6-EN for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23T-0005a6-1H for ltru@ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig23D-0004k3-0H for ltru@ietf.org; Thu, 11 Oct 2007 13:42:30 -0400 Received: from [10.72.72.156] (snvvpn1-10-72-72-c156.corp.yahoo.com [10.72.72.156]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9BHfWeI035970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 10:41:44 -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=X63JCFlC+LadI+W6/tAnQybr90WzFMXD7HNdPBq0kApObE+Xv67KQQBpNIE12AUE Message-ID: <470E6049.2050004@yahoo-inc.com> Date: Thu, 11 Oct 2007 10:41:29 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Matching Text References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011130656.GD2710@mercury.ccil.org> <006801c80c2d$bb378a20$6801a8c0@oemcomputer> In-Reply-To: <006801c80c2d$bb378a20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 wrote: > > More succinctly: some view "macrolanguage" as being effectively equivalent > to some dominant or (likely) mutually intelligible member of the group, while > others view "macrolanguage" as being simply an abstraction, not corresponding > to any specific member of the group. > I would put a slight twist on that. I would say that "some view some of the macrolanguages as being effectively equivalent to some dominant (etc.) member of the group while viewing other macrolanguages of being simply an abstraction". That is, I think both cases exist simultaneously. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru .org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23U-0005fF-Hl; Thu, 11 Oct 2007 13:42:40 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ig23T-0005f6-EN for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig23T-0005a6-1H for ltru@ietf.org; Thu, 11 Oct 2007 13:42:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig23D-0004k3-0H for ltru@ietf.org; Thu, 11 Oct 2007 13:42:30 -0400 Received: from [10.72.72.156] (snvvpn1-10-72-72-c156.corp.yahoo.com [10.72.72.156]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9BHfWeI035970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 10:41:44 -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=X63JCFlC+LadI+W6/tAnQybr90WzFMXD7HNdPBq0kApObE+Xv67KQQBpNIE12AUE Message-ID: <470E6049.2050004@yahoo-inc.com> Date: Thu, 11 Oct 2007 10:41:29 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Matching Text References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011130656.GD2710@mercury.ccil.org> <006801c80c2d$bb378a20$6801a8c0@oemcomputer> In-Reply-To: <006801c80c2d$bb378a20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 wrote: > > More succinctly: some view "macrolanguage" as being effectively equivalent > to some dominant or (likely) mutually intelligible member of the group, while > others view "macrolanguage" as being simply an abstraction, not corresponding > to any specific member of the group. > I would put a slight twist on that. I would say that "some view some of the macrolanguages as being effectively equivalent to some dominant (etc.) member of the group while viewing other macrolanguages of being simply an abstraction". That is, I think both cases exist simultaneously. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 11 15:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3M8-0002zH-8S; Thu, 11 Oct 2007 15:06:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ig3M7-0002z2-5Q for ltru-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 15:05:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig3M6-0002yt-RH for ltru@lists.ietf.org; Thu, 11 Oct 2007 15:05:58 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig3M6-0004Nx-IQ for ltru@lists.ietf.org; Thu, 11 Oct 2007 15:05:58 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Thu, 11 Oct 2007 12:05:57 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Thu, 11 Oct 2007 12:05:56 -0700 From: Shawn Steele To: Frank Ellermann , "ltru@lists.ietf.org" Date: Thu, 11 Oct 2007 12:05:55 -0700 Subject: RE: [Ltru] Re: Matching Text Thread-Topic: [Ltru] Re: Matching Text Thread-Index: AcgL+94DNN5iokW9SY2m/K2tvZVpOwAPYByA Message-ID: References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <06e601c80bf8$bc8d4930$0d00a8c0@CPQ86763045110> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 > My limited application is tagging Web pages, and I wasn't too thrilled > when Google searches for English pages missed my en-GB-oed pages. Google doesn't like my tlh-US user locale either :-) - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 03:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEVP-0004oC-6g; Fri, 12 Oct 2007 03:00:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgEVO-0004nX-OO for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:00:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEVM-0004Ye-To for ltru@ietf.org; Fri, 12 Oct 2007 03:00:16 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgEVJ-0007LX-KK for ltru@ietf.org; Fri, 12 Oct 2007 03:00:13 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071012070012.GEIW26917.mta9.adelphia.net@DGBP7M81> for ; Fri, 12 Oct 2007 03:00:12 -0400 Message-ID: <008a01c80c9d$8909f8b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 12 Oct 2007 00:00:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Informative (was: Extended 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 John Cowan wrote: > By this standard, the Type, Subtag, Tag, Prefix, Preferred-Value, and > Suppress-Script fields are normative; the Description, Added, > Deprecated, Comments, and File-Date fields are informative. Thanks to all for setting me straight on this point. It started as just an example, but I apologize for the confusion. As I predicted, I think I misunderstood what Shawn Steele said about the Registry only providing guidelines, so my whole response is moot anyway. -- 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 12 03:06:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEb0-000188-AO; Fri, 12 Oct 2007 03:06:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgEay-00012i-Uf for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:06:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEay-00012a-Kh for ltru@ietf.org; Fri, 12 Oct 2007 03:06:04 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgEay-0007Wr-7w for ltru@ietf.org; Fri, 12 Oct 2007 03:06:04 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071012070603.XIPC2495.mta13.adelphia.net@DGBP7M81>; Fri, 12 Oct 2007 03:06:03 -0400 Message-ID: <008c01c80c9e$5a098ac0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> Subject: Re: [Ltru] Re: Extended language tags Date: Fri, 12 Oct 2007 00:06: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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 Debbie Garside wrote: > I may have missed the answer to this question, apologies if I have, > but why not include cwm within the registry and then deprecate in > favour of zh-cwm? This way both are in the registry and the fallback, > as described by Mark, is facilitated. The same could be done for > zh-yue and yue and no-nb etc. Thus if people tag "incorrectly", with, > for example, cwm or yue, applications would come up with the correct > match anyway. > > I cannot pretend that I understand the entirety of the current > conversations wrt extended language tags but I do think their > inclusion would be useful for matching purposes. I would not be in favor of creating 482 new deprecated-at-birth subtags. I think "deprecated" is a necessary evil that is needed when an ISO code element is withdrawn or a mistake is found. It should not be a mechanism for implementing fallback. -- 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 12 03:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEp1-0004EZ-MZ; Fri, 12 Oct 2007 03:20:35 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgEp0-0004ES-Du for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEp0-0004B9-4V for ltru@ietf.org; Fri, 12 Oct 2007 03:20:34 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgEor-0007pU-0U for ltru@ietf.org; Fri, 12 Oct 2007 03:20:31 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071012072008.SZUC2217.mta10.adelphia.net@DGBP7M81> for ; Fri, 12 Oct 2007 03:20:08 -0400 Message-ID: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 12 Oct 2007 00:20: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: Extended language tags (long reply) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > It only makes sense to do this as a heuristic when the speaker of the > microlanguage is extremely likely to speak the macrolanguage. And so once again, the concept of "macrolanguage" is represented not as ISO 639-3 intended it, as a family of languages that are sometimes considered a single language for some purposes, but rather as a specific, dominant language within that family. If this is the definition we apply to the term "macrolanguage," and if we understand "zh-yue" as a signal to fall back from Cantonese to Mandarin, then the no-extlang proponents are certain to win this battle. -- 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 12 03:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgExB-0002P1-2r; Fri, 12 Oct 2007 03:29:01 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgExA-0002OZ-7C for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:29:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEx9-0002OQ-TQ for ltru@ietf.org; Fri, 12 Oct 2007 03:28:59 -0400 Received: from mta15.mail.adelphia.net ([68.168.78.77] helo=mta15.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgEx9-00081w-IP for ltru@ietf.org; Fri, 12 Oct 2007 03:28:59 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20071012072858.UOL4148.mta15.adelphia.net@DGBP7M81> for ; Fri, 12 Oct 2007 03:28:58 -0400 Message-ID: <00a601c80ca1$8dd31cb0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 12 Oct 2007 00:28:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ltru] Re: Teleconference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Perhaps a poll for day/time options? I'm not going to be able to make another 9:00 weekday time slot for the foreseeable future. I used up all my zorch making the first one. Believe it or not, 6:00 Pacific time (currently 13:00 UTC) would fit my schedule much better, though I understand it would be murder on others, and I'm not holding my breath that it will be changed. -- 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 12 03:38:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgF6a-0001H8-Dv; Fri, 12 Oct 2007 03:38:44 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgF6Y-0001F8-HO for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:38:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgF6Y-00018o-7N for ltru@ietf.org; Fri, 12 Oct 2007 03:38:42 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgF6S-0008Gv-Te for ltru@ietf.org; Fri, 12 Oct 2007 03:38:37 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071012073836.WMN20060.mta11.adelphia.net@DGBP7M81> for ; Fri, 12 Oct 2007 03:38:36 -0400 Message-ID: <00b201c80ca2$e6082d70$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 12 Oct 2007 00:38: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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've been talking about two different models for dealing with > macrolanguages: extlang and no-extlang. In our telephone > conversations, a third has come up: partial-extlang. > > The partial-extlang model is where we only make X a secondary language > for Y when it can reliably be assumed that someone who understands X > will also understand Y. That would be the case if all of the > microlanguages of Y are mutually intelligible, or if Y is generally > identified with a "prestige" variant. With this model we wouldn't make > all the microlanguages be secondary, just certain ones like those > having ar and zh as macrolanguages. An example might be zh-yue. Would we have to make this decision on a case-by-case basis for each of several hundred encompassed 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 Fri Oct 12 03:48:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgFFt-0008RW-3u; Fri, 12 Oct 2007 03:48:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgFFr-0008RQ-DB for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 03:48:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgFFr-0008RH-3B for ltru@ietf.org; Fri, 12 Oct 2007 03:48:19 -0400 Received: from mta16.adelphia.net ([68.168.78.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgFFq-0008VP-O9 for ltru@ietf.org; Fri, 12 Oct 2007 03:48:19 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta16.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20071012074817.JNVW4814.mta16.adelphia.net@DGBP7M81> for ; Fri, 12 Oct 2007 03:48:17 -0400 Message-ID: <00b801c80ca4$40b9d6f0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 12 Oct 2007 00:48:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > The extlang mechanism is only for backwards compatibility in the first > place, I thought John Cowan had said repeatedly -- including at the beginning of the first teleconference -- that this was not true, that language-extlang was also intended as a shim between the ISO 639-2 and 639-3 worlds, neither of which is "wrong." Not all tagging scenarios call for maximum specificity; sometimes it really is just "Chinese" and not "Mandarin or Cantonese or Wu or Hakka or Gan or Min-Nan or...." -- 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 12 06:08:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHQc-0006GT-75; Fri, 12 Oct 2007 06:07:34 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgHQa-0006Ei-ET for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:07:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHQa-0006Ea-4G for ltru@ietf.org; Fri, 12 Oct 2007 06:07:32 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgHQZ-0006Tq-Pm for ltru@ietf.org; Fri, 12 Oct 2007 06:07:32 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007334326.msg for ; Fri, 12 Oct 2007 11:11:00 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 12 Oct 2007 11:07:29 +0100 From: "Debbie Garside" To: , "'LTRU Working Group'" References: <009301c80a0e$8a4b9c10$6401a8c0@DGBP7M81> <04f501c80b22$68debac0$0d00a8c0@CPQ86763045110> <008c01c80c9e$5a098ac0$6401a8c0@DGBP7M81> Subject: RE: [Ltru] Re: Extended language tags Date: Fri, 12 Oct 2007 11:06:15 +0100 Message-ID: <08be01c80cb7$86cd7760$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <008c01c80c9e$5a098ac0$6401a8c0@DGBP7M81> Thread-Index: AcgMnpoce1bV9PUlS/WFOWl7zbWwmQAF0hbA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Fri, 12 Oct 2007 11:11:00 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=180595bbdf=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, 12 Oct 2007 11:11:01 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Doug > I would not be in favor of creating 482 new > deprecated-at-birth subtags. > I think "deprecated" is a necessary evil that is needed when > an ISO code element is withdrawn or a mistake is found. It > should not be a mechanism for implementing fallback. To be honest, the whole macrolanguage scenario has been developed to deal with historical coding errors and the great extlang debate is the result. I really cannot see the harm in this proposal. I know it is not what this function was originally designed for but it would be using the RFC to its optimum. I would imagine that good application designers will incorporate something like this anyway so to standardize such a hack (as Frank calls it) is sensible. It is what standardization is all about. Best regards Debbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 06:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2k-0000dX-3i; Fri, 12 Oct 2007 06:46:58 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgI2i-0000dH-FX for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2i-0000by-58 for ltru@lists.ietf.org; Fri, 12 Oct 2007 06:46: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 1IgI2Z-0006vc-Bh for ltru@lists.ietf.org; Fri, 12 Oct 2007 06:46:56 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007334531.msg for ; Fri, 12 Oct 2007 11:50:00 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 12 Oct 2007 11:46:33 +0100 From: "Debbie Garside" To: References: <470D2F66.2010202@yahoo-inc.com><060201c80b79$9a7079f0$0d00a8c0@CPQ86763045110><060801c80b7d$7e0d7d90$0d00a8c0@CPQ86763045110> <068c01c80bd3$95e09eb0$0d00a8c0@CPQ86763045110> <470E606F.2080507@yahoo-inc.com> Subject: RE: [Ltru] Re: RE: duel(ing) tags Date: Fri, 12 Oct 2007 11:45:15 +0100 Message-ID: <08dc01c80cbc$fb8dac50$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <470E606F.2080507@yahoo-inc.com> Thread-Index: AcgMLjLHu/X4l67hQaq29dCg51HHgwAjWYCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Processed: mx1.nexbyte.net, Fri, 12 Oct 2007 11:50:00 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=180595bbdf=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, Fri, 12 Oct 2007 11:50:01 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nobody@xyzzy.claranet.de, ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Addison >Making it legal > for people to create undesirable codes "just because they > will anyway" will contribute to poor tagging practice and a > proliferation of tags synonymous in meaning but not in form. > We already know this is bad: why encourage it? I don't think we would be encouraging it. Users of the RFC or BCP who have good knowledge of the system will still tag correctly but users who have little or no knowledge will, for sure, tag incorrectly anyway. I think prevention is better than cure. If we do not do this it will result in application designers having to incorporate it within their systems in an ad hoc way (cure). Will this facilitate interchange with other systems? Not unless it is standardized (prevention) IMHO. Maybe I am wrong, but I can see good use for extlang (probably because ISO 639-6 is hierarchical and works in the same way :-)). Best regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 11 October 2007 18:42 > To: debbie@ictmarketing.co.uk > Cc: nobody@xyzzy.claranet.de; ltru@lists.ietf.org > Subject: Re: [Ltru] Re: RE: duel(ing) tags > > Debbie Garside wrote: > > > >> If we're *_not_* using the extlang-construct we'd deprecate zh-cmn > >> with preferred value cmn. In both cases we'd end up with > about 200 > >> deprecated aliases, don't we ? > > > > Exactly :-) > > > > In the former case (deprecating "zh-cmn" and associates), we > would be deprecating *existing* grandfathered tags. > > In the latter case (deprecating "cmn" and friends), we would > be *adding* items into the registry in a deprecated state. > This is, in part, what bothers me. > > There is no need to make these codes valid as primary > language tags if they serve no purpose there. Making it legal > for people to create undesirable codes "just because they > will anyway" will contribute to poor tagging practice and a > proliferation of tags synonymous in meaning but not in form. > We already know this is bad: why encourage it? > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > 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 12 10:15:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLH2-0003d8-6u; Fri, 12 Oct 2007 10:13:56 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgLH1-0003cx-7m for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 10:13:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLH0-0003ZS-Tx for ltru@ietf.org; Fri, 12 Oct 2007 10:13:54 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLGt-00083X-Bd for ltru@ietf.org; Fri, 12 Oct 2007 10:13:47 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IgLGs-0001Kt-Ai; Fri, 12 Oct 2007 10:13:46 -0400 Date: Fri, 12 Oct 2007 10:13:46 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Matching Text Message-ID: <20071012141346.GL2710@mercury.ccil.org> References: <00b201c80ca2$e6082d70$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201c80ca2$e6082d70$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Would we have to make this decision on a case-by-case basis for each of > several hundred encompassed languages? No, just for the macrolanguages. But I agree that it's contentious. -- The man that wanders far cowan@ccil.org from the walking tree http://www.ccil.org/~cowan --first line of a non-existent poem by: John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 10:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLIP-0005GJ-D0; Fri, 12 Oct 2007 10:15:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgLIO-0005Eo-00 for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 10:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLIN-0005Ef-Mf for ltru@ietf.org; Fri, 12 Oct 2007 10:15:19 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgLIF-0006cz-UK for ltru@ietf.org; Fri, 12 Oct 2007 10:15:19 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IgLI6-0001PI-G6; Fri, 12 Oct 2007 10:15:02 -0400 Date: Fri, 12 Oct 2007 10:15:02 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Extended language tags (long reply) Message-ID: <20071012141502.GM2710@mercury.ccil.org> References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) 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: > And so once again, the concept of "macrolanguage" is represented not as > ISO 639-3 intended it, as a family of languages that are sometimes > considered a single language for some purposes, but rather as a > specific, dominant language within that family. Even if you don't take that view (and I don't), it's idle to deny that almost everything textual tagged "zh" or "ar" is Mandarin Chinese or Standard Arabic respectively, as an uncontroversial consequence of the fact that almost all written documents in Chinese or Arabic *are* Mandarin or Standard respectively. -- I now introduce Professor Smullyan, John Cowan who will prove to you that either cowan@ccil.org he doesn't exist or you don't exist, http://www.ccil.org/~cowan but you won't know which. --Melvin Fitting _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 10:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLls-0004Ex-JY; Fri, 12 Oct 2007 10:45:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgLlr-0004EN-DR for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 10:45:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLlr-0004Aj-0R for ltru@ietf.org; Fri, 12 Oct 2007 10:45:47 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLlq-0003Gc-Kt for ltru@ietf.org; Fri, 12 Oct 2007 10:45:46 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 12 Oct 2007 07:45:45 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Fri, 12 Oct 2007 07:45:45 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 12 Oct 2007 07:45:40 -0700 Subject: RE: [Ltru] Re: Extended language tags (long reply) Thread-Topic: [Ltru] Re: Extended language tags (long reply) Thread-Index: AcgMoI7aEZVxmqRTSp6qEdwKz4oZzQAPLqPg Message-ID: References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> In-Reply-To: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 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: , Content-Type: multipart/mixed; boundary="===============1778489498==" Errors-To: ltru-bounces@ietf.org --===============1778489498== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG91ZyBFd2VsbCBbbWFpbHRvOmRld2VsbEByb2FkcnVubmVyLmNvbV0NCg0KPj4gSXQg b25seSBtYWtlcyBzZW5zZSB0byBkbyB0aGlzIGFzIGEgaGV1cmlzdGljIHdoZW4gdGhlIHNwZWFr ZXIgb2YgdGhlDQo+PiBtaWNyb2xhbmd1YWdlIGlzIGV4dHJlbWVseSBsaWtlbHkgdG8gc3BlYWsg dGhlIG1hY3JvbGFuZ3VhZ2UuDQo+DQo+IEFuZCBzbyBvbmNlIGFnYWluLCB0aGUgY29uY2VwdCBv ZiAibWFjcm9sYW5ndWFnZSIgaXMgcmVwcmVzZW50ZWQgbm90IGFzDQo+IElTTyA2MzktMyBpbnRl bmRlZCBpdCwgYXMgYSBmYW1pbHkgb2YgbGFuZ3VhZ2VzIHRoYXQgYXJlIHNvbWV0aW1lcw0KPiBj b25zaWRlcmVkIGEgc2luZ2xlIGxhbmd1YWdlIGZvciBzb21lIHB1cnBvc2VzLCBidXQgcmF0aGVy IGFzIGENCj4gc3BlY2lmaWMsIGRvbWluYW50IGxhbmd1YWdlIHdpdGhpbiB0aGF0IGZhbWlseS4N Cg0KRG91ZydzIGNvbW1lbnQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBpbnRlbnQgb2YgSVNPIDYz OSwgYW5kIEkgc3VwcG9ydCBpdC4NCg0KSSBhbHNvIGNvbmNlZGUsIHRob3VnaCwgdGhhdCBNYXJr J3MgY29tbWVudCB3YXNuJ3QgZW50aXJlbHkgd2l0aG91dCBiYXNpczogdGhlIHJlYWxpdHkgaXMg dGhhdCBmb3IgYSBzbWFsbCBzZXQgb2YgbWFjcm9sYW5ndWFnZXMgdGhlcmUgaXMgYSBkb21pbmFu dCB2YXJpZXR5IHRoYXQgd291bGQgaGF2ZSBiZWVuIG1lYW50IGluIGEgaGlnaCBwcm9wb3J0aW9u IG9mIGluc3RhbmNlcyBvZiB1c2FnZSBvZiB0aGUgaWRlbnRpZmllciBmb3IgdGhhdCBtYWNyb2xh bmd1YWdlLiBUaGF0J3MgdGhlIGNvbmZ1c2lvbiBjcmVhdGVkIGJ5IGxlZ2FjeSBsYW5ndWFnZS1p ZGVudGlmaWVyIGltcGxlbWVudGF0aW9ucyBhbmQgdGhlIG5vdC1zby1zaW1wbGUgc29jaW9saW5n dWlzdGljcyB0aGV5IHdlcmUgZmFjZWQgd2l0aC4NCg0KDQo+IElmIHRoaXMgaXMgdGhlIGRlZmlu aXRpb24gd2UgYXBwbHkgdG8gdGhlIHRlcm0gIm1hY3JvbGFuZ3VhZ2UsIiBhbmQgaWYNCj4gd2Ug dW5kZXJzdGFuZCAiemgteXVlIiBhcyBhIHNpZ25hbCB0byBmYWxsIGJhY2sgZnJvbSBDYW50b25l c2UgdG8NCj4gTWFuZGFyaW4sIHRoZW4gdGhlIG5vLWV4dGxhbmcgcHJvcG9uZW50cyBhcmUgY2Vy dGFpbiB0byB3aW4gdGhpcyBiYXR0bGUuDQoNCiJ6aC15dWUiLCBpZiB3ZSBzdGljayB3aXRoIGl0 LCBzaG91bGQgbm90IGJlIGEgc2lnbmFsIHRvIGZhbGwgYmFjayB0byBNYW5kYXJpbi4gSXQgc2hv dWxkIGJlIGEgc2lnbmFsIHRoYXQsIHdoZW4gInpoLXl1ZSIgaXMgcmVxdWVzdGVkLCByZXR1cm5p bmcgYSByZWNvcmQgdGFnZ2VkICJ6aCIgbWF5IGdpdmUgYWNjZXB0YWJsZSByZXN1bHRzLg0KDQoN Cg0KUGV0ZXINCg== --===============1778489498== 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 --===============1778489498==-- From ltru-bounces@ietf.org Fri Oct 12 11:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMPr-0007qv-HN; Fri, 12 Oct 2007 11:27:07 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgMPr-0007ql-32 for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 11:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMPq-0007qb-PT for ltru@ietf.org; Fri, 12 Oct 2007 11:27:06 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgMPk-0001cf-HL for ltru@ietf.org; Fri, 12 Oct 2007 11:27:06 -0400 Received: from [10.72.76.75] (snvvpn2-10-72-76-c75.corp.yahoo.com [10.72.76.75]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9CFQUrR099374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2007 08:26:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=SqKqjrxZGNqtPNeZf729tYGS0LjDq3VF4DbJCkz1I0fh+LDzWUUDn/jQSYqnn10Y Message-ID: <470F9225.6030108@yahoo-inc.com> Date: Fri, 12 Oct 2007 08:26:29 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: Extended language tags (long reply) References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> In-Reply-To: <20071012141502.GM2710@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 John Cowan wrote: > > Even if you don't take that view (and I don't), it's idle to deny > that almost everything textual tagged "zh" or "ar" is Mandarin Chinese > or Standard Arabic respectively, as an uncontroversial consequence > of the fact that almost all written documents in Chinese or Arabic > *are* Mandarin or Standard respectively. > Actually, I don't know that I would say that, at least in the case of Chinese. In fact, for most Chinese written documents, I would tend to say that it isn't possible to discern which specific Chinese language they are in. You could represent that as being "in Mandarin", since that is the source of the written form, but in practical terms there is little enough difference between Cantonese and Mandarin at the written level to really know. In fact, it is a very useful fiction that these languages are "the same". This is one reason that I prefer my workaround for the lookup algorithm using extlangs to Mark's recent suggestion on list: it recognizes that, for written resources, "generic" Chinese plus subtags is a better fallback than the second language in your language priority list. [[As a reminder Mark's suggestion was to make fallback for the LPL "zh-yue-Hant-HK;en" to be: zh-yue-Hant-HK zh-yue-Hant zh-yue en zh-Hant-HK zh-Hant zh (default) And mine was: zh-yue-Hant-HK zh-yue-Hant zh-yue zh-Hant-HK zh-Hant zh en (default) ]] Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 12 13:00:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNre-0002He-OR; Fri, 12 Oct 2007 12:59:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgNrc-0002H4-PN for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 12:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgNrc-0002Gv-Fh for ltru@ietf.org; Fri, 12 Oct 2007 12:59:52 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgNrW-0005FX-6I for ltru@ietf.org; Fri, 12 Oct 2007 12:59:52 -0400 Received: by nz-out-0506.google.com with SMTP id n1so708833nzf for ; Fri, 12 Oct 2007 09:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=OYBCHRLl2HDlLdrE3D4vM7dISk0SM5I3jmou1xV45H0=; b=DpOg/GAAbJv9TGycYa/YRkRnDWEsy/sBZjQccDAV8160lNKmgHVjIHCnCa/maxDjS9DnMtfghiYzj4Es1N2H3nXGRmartF8j3xSTgMzDNyr02tYKGUMUtPwQwIGEpIm/Q8tQ1A4Vyy1WdNPVEMpiqilpjL5W3++N+Jqtp1dTzE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=lX8trRNX/iBdV28eh/k1atDluLwX1Y0PVl3Rfg4gRLcdWQtMvIyhSQpNy4axbrpAD+OZw23hWqhajAuR97PYKsylT0BGGyGmztYa2kt+hsuqY1DDOlANPqvihxicq7prl8RKxKFKD2bJG++avf4B0KCd+AUHNScaBfiNECAHjnU= Received: by 10.114.59.1 with SMTP id h1mr3736844waa.1192208363346; Fri, 12 Oct 2007 09:59:23 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Fri, 12 Oct 2007 09:59:23 -0700 (PDT) Message-ID: <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> Date: Fri, 12 Oct 2007 09:59:23 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Extended language tags (long reply) In-Reply-To: <470F9225.6030108@yahoo-inc.com> MIME-Version: 1.0 References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> X-Google-Sender-Auth: 0ebc0bad80621df8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004733592==" Errors-To: ltru-bounces@ietf.org --===============1004733592== Content-Type: multipart/alternative; boundary="----=_Part_21915_32001762.1192208363335" ------=_Part_21915_32001762.1192208363335 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is precisely why I think this should not be baked into extlang. For some applications it might be better off to fallback "yue, en" as 1. yue-Hant-HK 2. yue-Hant 3. yue 4. zh-Hant-HK 5. zh-Hant 6. zh 7. en But there is a big maybe here. According to Lee Collins, who is well versed in this area, there are two cases: 1. Standard written Chinese read as Cantonese. 2. Written Cantonese. 1. Can't be distinguished at the script level from Mandarin, 2. can be as easily discerned as easily as any other language. It's as different, say, as dutch is from English. Some words look the same, but a mandarin speaker couldn't read it. So the situation is not that clear. And certainly in other circumstances (like audio), it is much better to actually honor the user's request, and fall back like 1. yue-Hant-HK 2. yue-Hant 3. yue 4. en 5. (default, which could expand to) 1. zh-Hant-HK 2. zh-Hant 3. zh That's why if we leave this up to the application, which knows what domain it is working in, we're better off than if we hard code a relationship that sometimes works, but requires code changes anyway, and I think more often fails. This situation is very similar to another case that we have already. We could have used extlang with gsw (Swiss German). We could have said: Hmm, there was no way to tag Swiss German before, so we might have ended up with such content tagged as "de" instead. And, hmmm, when the Swiss write German, they typically use High German, so the written form is essentially the same (with the exception of sharp-s). So let's make the tag be "de-gsw" instead. But we didn't bake this relationship into the codes; instead we leave this to the application, to handle appropriate to the domain. Mark On 10/12/07, Addison Phillips wrote: > > John Cowan wrote: > > > > Even if you don't take that view (and I don't), it's idle to deny > > that almost everything textual tagged "zh" or "ar" is Mandarin Chinese > > or Standard Arabic respectively, as an uncontroversial consequence > > of the fact that almost all written documents in Chinese or Arabic > > *are* Mandarin or Standard respectively. > > > > Actually, I don't know that I would say that, at least in the case of > Chinese. > > In fact, for most Chinese written documents, I would tend to say that it > isn't possible to discern which specific Chinese language they are in. > You could represent that as being "in Mandarin", since that is the > source of the written form, but in practical terms there is little > enough difference between Cantonese and Mandarin at the written level to > really know. In fact, it is a very useful fiction that these languages > are "the same". > > This is one reason that I prefer my workaround for the lookup algorithm > using extlangs to Mark's recent suggestion on list: it recognizes that, > for written resources, "generic" Chinese plus subtags is a better > fallback than the second language in your language priority list. > > [[As a reminder Mark's suggestion was to make fallback for the LPL > "zh-yue-Hant-HK;en" to be: > > zh-yue-Hant-HK > zh-yue-Hant > zh-yue > en > zh-Hant-HK > zh-Hant > zh > (default) > > And mine was: > > zh-yue-Hant-HK > zh-yue-Hant > zh-yue > zh-Hant-HK > zh-Hant > zh > en > (default) > > ]] > > Addison > > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG > > Internationalization is an architecture. > It is not a feature. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_21915_32001762.1192208363335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is precisely why I think this should not be baked into extlang. For some applications it might be better off to fallback "yue, en" as

  1. yue-Hant-HK
  2. yue-Hant
  3. yue
  4. zh-Hant-HK
  5. zh-Hant
  6. zh
  7. en

But there is a big maybe here. According to Lee Collins, who is well versed in this area, there are two cases:

1. Standard written Chinese read as Cantonese. 
2. Written Cantonese. 

1. Can't be distinguished at the script level from Mandarin,
2. can be as easily discerned as easily as any other language. It's as different, say, as dutch is from English. Some words look the same, but a mandarin speaker couldn't read it.

So the situation is not that clear. And certainly in other circumstances (like audio), it is much better to actually honor the user's request, and fall back like

  1. yue-Hant-HK
  2. yue-Hant
  3. yue
  4. en
  5. (default, which could expand to)
    1. zh-Hant-HK
    2. zh-Hant
    3. zh

That's why if we leave this up to the application, which knows what domain it is working in, we're better off than if we hard code a relationship that sometimes works, but requires code changes anyway, and I think more often fails.

This situation is very similar to another case that we have already. We could have used extlang with gsw (Swiss German). We could have said: Hmm, there was no way to tag Swiss German before, so we might have ended up with such content tagged as "de" instead. And, hmmm, when the Swiss write German, they typically use High German, so the written form is essentially the same (with the exception of sharp-s). So let's make the tag be "de-gsw" instead.

But we didn't bake this relationship into the codes; instead we leave this to the application, to handle appropriate to the domain.
Mark

On 10/12/07, Addison Phillips < addison@yahoo-inc.com> wrote:
John Cowan wrote:
>
> Even if you don't take that view (and I don't), it's idle to deny
> that almost everything textual tagged "zh" or "ar" is Mandarin Chinese
> or Standard Arabic respectively, as an uncontroversial consequence
> of the fact that almost all written documents in Chinese or Arabic
> *are* Mandarin or Standard respectively.
>

Actually, I don't know that I would say that, at least in the case of
Chinese.

In fact, for most Chinese written documents, I would tend to say that it
isn't possible to discern which specific Chinese language they are in.
You could represent that as being "in Mandarin", since that is the
source of the written form, but in practical terms there is little
enough difference between Cantonese and Mandarin at the written level to
really know. In fact, it is a very useful fiction that these languages
are "the same".

This is one reason that I prefer my workaround for the lookup algorithm
using extlangs to Mark's recent suggestion on list: it recognizes that,
for written resources, "generic" Chinese plus subtags is a better
fallback than the second language in your language priority list.

[[As a reminder Mark's suggestion was to make fallback for the LPL
"zh-yue-Hant-HK;en" to be:

  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  en
  zh-Hant-HK
  zh-Hant
  zh
  (default)

And mine was:

  zh-yue-Hant-HK
  zh-yue-Hant
  zh-yue
  zh-Hant-HK
  zh-Hant
  zh
  en
  (default)

]]

Addison

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

Internationalization is an architecture.
It is not a feature.


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



--
Mark ------=_Part_21915_32001762.1192208363335-- --===============1004733592== 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 --===============1004733592==-- From ltru-bounces@ietf.org Fri Oct 12 13:24:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOFU-0005pa-VU; Fri, 12 Oct 2007 13:24:32 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgOFT-0005oz-Nn for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:24:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOFT-0005oh-Cy for ltru@ietf.org; Fri, 12 Oct 2007 13:24:31 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgOFS-000100-Tb for ltru@ietf.org; Fri, 12 Oct 2007 13:24:31 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=H0maP3JOpR0/vuCw/KqEXc1kvH3ma73PrBUUL9n2tqmLgPiVMcG/pYnFaATG/Eay; 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 [66.167.77.122] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IgOFR-0004IE-Ud for ltru@ietf.org; Fri, 12 Oct 2007 13:24:30 -0400 Message-ID: <002601c80cf5$55364540$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 12 Oct 2007 10:28:40 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a5fc190b75c2013a84b8c95d626969c69350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.77.122 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Ltru] Fw: REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 - Forwarded for your information. Randy ----- Original Message ----- > From: "IETF Secretariat" > To: "IETF Announcement list" > Sent: Friday, October 12, 2007 8:45 AM > Subject: REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada > > There are two (2) Internet-Draft cutoff dates for the 70th IETF > Meeting in Vancouver, BC, Canada: > > November 12th: Cutoff Date for Initial (i.e., version -00) Internet-Draft > Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > November 12th at 9:00 AM ET (14:00 UTC/GMT). The only exception is for > version -00 WG drafts that replace existing non-WG drafts. Such drafts > may be submitted until the cutoff date for version -01 and higher drafts. > 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, November 5th at 9:00 AM ET (14:00 UTC/GMT). > > November 19th: 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, November 19th at 9:00 AM ET (14:00 UTC/GMT). > > Initial and revised Internet-Drafts submitted after their respective > cutoff dates will not be made available in the Internet-Drafts directory > or announced until on or after Monday, December 3rd at 9:00 AM ET (14:00 > UTC/GMT), when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > The Secretariat encourages you to submit your Internet-Drafts via the > Internet-Draft Submission Tool (IDST) > https://datatracker.ietf.org/idst/upload.cgi. If you are unable to do so, > then you may still submit your Internet-Drafts manually by sending them to > internet-drafts@ietf.org. If you are submitting a version -00 WG draft > that replaces non-WG draft, then you must submit it manually as the > current IDST cannot handle replacements. Please be sure to state that one > draft replaces another in the cover note that accompanies your > submission. Also, please note that the IDST will not accept drafts > submitted after their respective cutoff dates. > > 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 70th IETF Meeting can be found at > http://www3.ietf.org/meetings/70-cutoff_dates.html. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 13:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOaG-0004Kq-ST; Fri, 12 Oct 2007 13:46:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgOaF-0004KY-Vl for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOaF-0004K0-Lu for ltru@ietf.org; Fri, 12 Oct 2007 13:45:59 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOa2-0006jw-C0 for ltru@ietf.org; Fri, 12 Oct 2007 13:45:57 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GyJO68xFQ6LgZeccFujg5ykLR71lWby6VzxpVPiG0HL/mKKw8EOV6uyuvfZ6Zhig; 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 [66.167.77.122] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IgOZi-00066N-N4 for ltru@ietf.org; Fri, 12 Oct 2007 13:45:27 -0400 Message-ID: <005001c80cf8$425be300$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00a601c80ca1$8dd31cb0$6401a8c0@DGBP7M81> Subject: Re: [Ltru] Re: Teleconference Date: Fri, 12 Oct 2007 10:49:37 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31ae51337e075f461dbe865059ed3739561350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.77.122 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, October 12, 2007 12:28 AM > Subject: [Ltru] Re: Teleconference ... > Believe it or not, 6:00 Pacific time (currently 13:00 UTC) would fit my > schedule much better, though I understand it would be murder on others, > and I'm not holding my breath that it will be changed. ... This time would also work for me. Not pleasant, but definitely doable. It would make participation from eastern Asia less onerous. Would moving it from the end to the middle of the European workday garner any participation from there? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 14:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP0Q-0005gh-JJ; Fri, 12 Oct 2007 14:13:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgP0P-0005fP-8L for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP0O-0005ci-RF for ltru@ietf.org; Fri, 12 Oct 2007 14:13:00 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgP0I-0007ST-Ix for ltru@ietf.org; Fri, 12 Oct 2007 14:13:00 -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.8/8.13.8/y.rout) with ESMTP id l9CICB08012982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2007 11:12:11 -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=UJ2G5IPePwKg/38frfmKIu2kf3Ykh65Y2qINOEhzZKJIdeew0S5XP2X4kg1uMPPy Message-ID: <470FB8FA.6040004@yahoo-inc.com> Date: Fri, 12 Oct 2007 11:12:10 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Ltru] Re: Teleconference References: <00a601c80ca1$8dd31cb0$6401a8c0@DGBP7M81> <005001c80cf8$425be300$6801a8c0@oemcomputer> In-Reply-To: <005001c80cf8$425be300$6801a8c0@oemcomputer> 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 It would also work for me. Addison Randy Presuhn wrote: > Hi - > >> From: "Doug Ewell" >> To: "LTRU Working Group" >> Sent: Friday, October 12, 2007 12:28 AM >> Subject: [Ltru] Re: Teleconference > ... >> Believe it or not, 6:00 Pacific time (currently 13:00 UTC) would fit my >> schedule much better, though I understand it would be murder on others, >> and I'm not holding my breath that it will be changed. > ... > > This time would also work for me. Not pleasant, but definitely doable. > It would make participation from eastern Asia less onerous. Would moving > it from the end to the middle of the European workday garner any > participation from there? > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 12 14:13:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP19-0006MG-Sf; Fri, 12 Oct 2007 14:13:47 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgP18-0006M9-OU for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:13:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP18-0006L5-4C for ltru@ietf.org; Fri, 12 Oct 2007 14:13:46 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgP17-00026U-HJ for ltru@ietf.org; Fri, 12 Oct 2007 14:13:46 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 12 Oct 2007 11:13:44 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Fri, 12 Oct 2007 11:13:44 -0700 From: Shawn Steele To: Mark Davis , Addison Phillips Date: Fri, 12 Oct 2007 11:13:42 -0700 Subject: RE: [Ltru] Re: Extended language tags (long reply) Thread-Topic: [Ltru] Re: Extended language tags (long reply) Thread-Index: AcgM8Yj1VDh0tC/JSgOBoLKpSmoj6AACcl6w Message-ID: References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> In-Reply-To: <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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="===============1141256946==" Errors-To: ltru-bounces@ietf.org --===============1141256946== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C9BF0238EED3634BA1866AEF14C7A9E55A5995568FNAEXMSGC116re_" --_000_C9BF0238EED3634BA1866AEF14C7A9E55A5995568FNAEXMSGC116re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCsOYICBUaGlzIGlzIHByZWNpc2VseSB3aHkgSSB0aGluayB0aGlzIHNob3VsZCBub3QgYmUg YmFrZWQgaW50byBleHRsYW5nLiBGb3Igc29tZSBhcHBsaWNhdGlvbnMgaXQgbWlnaHQgYmUgYmV0 dGVyIG9mZiB0byBmYWxsYmFjayAieXVlLCBlbiIgYXMNCg0KIDEuICB5dWUtSGFudC1ISw0KIDIu ICB5dWUtSGFudA0KIDMuICB5dWUNCiA0LiAgemgtSGFudC1ISw0KIDUuICB6aC1IYW50DQogNi4g IHpoDQogNy4gIGVuDQpNeSBpbnRlcnByZXRhdGlvbiBvZiBodHRwLWFjY2VwdC1sYW5nIGFuZCBy ZmM0NjQ3IGlzIHRoYXQgaWYgdGhleSBhc2sgZm9yIHl1ZTtlbiwgdGhlbiB5b3UgbG9vayBmb3IN Cg0KDQoxLiAgICAgICDigJx5dWXigJ0NCg0KMi4gICAgICDigJxlbuKAnQ0KDQpJIGRvbuKAmXQg a25vdyB3aGVyZSB5b3XigJlyZSBnZXR0aW5nIHRoZSByZXN0IG9mIHRoZXNlIGZyb20sIHBhcnRp Y3VsYXJseSB0aGUgSEsgdmFyaWF0aW9ucy4gIElmIHlvdSB3YW50IHRvIGRvIHNvbWV0aGluZyBh cHAgc3BlY2lmaWMsIHRoYXTigJlzIGNvb2wsIGJ1dCB0aGF04oCZcyBhcHAgc3BlY2lmaWMuDQoN Cg0KLSAgICAgICAgICBTaGF3bg0K --_000_C9BF0238EED3634BA1866AEF14C7A9E55A5995568FNAEXMSGC116re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6TWFuZ2FsOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSAyIDMgMyAyIDI7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUg NCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut MToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmdtYWlscXVvdGUNCgl7bXNvLXN0 eWxlLW5hbWU6Z21haWxfcXVvdGU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9 DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI2MDM4 MTEzMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE4MjkzOTc4NDt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDo1NjEyMDg5NDI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MzM1MTg5Njt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMDc3NzUxNDk1Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ0NjIxNzMxNiAyMzQ1MjYwNzIgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6 MTQ5OTY4NTU5NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTExOTQ2Njc1NDYgMTE5NTc2MzI4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwzOmxldmVs MQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KQGxpc3QgbDQN Cgl7bXNvLWxpc3QtaWQ6MTU1NTMxMTQxNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTg5OTQwNTY4MCAtNzA1OTIyMDAyIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWluZGVudDotLjI1aW47DQptc28t bGlzdDpsNCBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCc+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+w5g8c3Bhbg0Kc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhp cw0KaXMgcHJlY2lzZWx5IHdoeSBJIHRoaW5rIHRoaXMgc2hvdWxkIG5vdCBiZSBiYWtlZCBpbnRv IGV4dGxhbmcuIEZvciBzb21lDQphcHBsaWNhdGlvbnMgaXQgbWlnaHQgYmUgYmV0dGVyIG9mZiB0 byBmYWxsYmFjayAmcXVvdDt5dWUsIGVuJnF1b3Q7IGE8c3Bhbg0Kc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPnM8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPG9sIHN0YXJ0PTEgdHlwZT0xPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KICAgICBt c28tbGlzdDpsMSBsZXZlbDEgbGZvMSc+eXVlLUhhbnQtSEs8bzpwPjwvbzpwPjwvbGk+DQogPGxp IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwxIGxldmVsMSBsZm8xJz55dWUtSGFu dDxvOnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzEnPnl1ZTxvOnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCiAgICAgbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEnPnpoLUhhbnQtSEs8bzpwPjwvbzpwPjwv bGk+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwxIGxldmVsMSBsZm8x Jz56aC1IYW50PG86cD48L286cD48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KICAgICBt c28tbGlzdDpsMSBsZXZlbDEgbGZvMSc+emg8bzpwPjwvbzpwPjwvbGk+DQogPGxpIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQogICAgIG1zby1saXN0OmwxIGxldmVsMSBsZm8xJz5lbjxvOnA+PC9vOnA+PC9s aT4NCjwvb2w+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+TXkgaW50ZXJwcmV0YXRpb24gb2YNCmh0dHAtYWNjZXB0LWxhbmcgYW5kIHJmYzQ2NDcgaXMg dGhhdCBpZiB0aGV5IGFzayBmb3IgeXVlO2VuLCB0aGVuIHlvdSBsb29rIGZvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCc+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4NCnN0eWxlPSdjb2xvcjojMUY0OTdEJz48c3BhbiBz dHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+wqDigJx5dWXigJ08 L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9 J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCc+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4NCnN0eWxlPSdjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz4yLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+4oCcZW7igJ08L3NwYW4+PG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCBrbm93IHdoZXJlIHlvdeKAmXJlDQpnZXR0 aW5nIHRoZSByZXN0IG9mIHRoZXNlIGZyb20sIHBhcnRpY3VsYXJseSB0aGUgSEsgdmFyaWF0aW9u cy7CoCBJZiB5b3Ugd2FudCB0bw0KZG8gc29tZXRoaW5nIGFwcCBzcGVjaWZpYywgdGhhdOKAmXMg Y29vbCwgYnV0IHRoYXTigJlzIGFwcCBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzUnPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuDQpzdHlsZT0nY29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0 Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2hh d248L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+ DQo= --_000_C9BF0238EED3634BA1866AEF14C7A9E55A5995568FNAEXMSGC116re_-- --===============1141256946== 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 --===============1141256946==-- From ltru-bounces@ietf.org Fri Oct 12 14:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP5x-0002ko-Gl; Fri, 12 Oct 2007 14:18:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgP5w-0002jm-4z for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP5v-0002je-RQ for ltru@ietf.org; Fri, 12 Oct 2007 14:18:43 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgP5p-0007ev-GK for ltru@ietf.org; Fri, 12 Oct 2007 14:18:43 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 12 Oct 2007 11:18:07 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Fri, 12 Oct 2007 11:18:06 -0700 From: Shawn Steele To: Mark Davis , Addison Phillips Date: Fri, 12 Oct 2007 11:18:06 -0700 Subject: RE: [Ltru] Re: Extended language tags (long reply) Thread-Topic: [Ltru] Re: Extended language tags (long reply) Thread-Index: AcgM8Yj1VDh0tC/JSgOBoLKpSmoj6AAChh3w Message-ID: References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> In-Reply-To: <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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="===============0674014508==" Errors-To: ltru-bounces@ietf.org --===============0674014508== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C9BF0238EED3634BA1866AEF14C7A9E55A59955695NAEXMSGC116re_" --_000_C9BF0238EED3634BA1866AEF14C7A9E55A59955695NAEXMSGC116re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlmZmVyZW50IGlkZWEgKHNvIEkgbWFkZSBpdCBhIGRpZmZlcmVudCBtYWlsKQ0KDQoNCsOYICBU aGlzIGlzIHByZWNpc2VseSB3aHkgSSB0aGluayB0aGlzIHNob3VsZCBub3QgYmUgYmFrZWQgaW50 byBleHRsYW5nLiBGb3Igc29tZSBhcHBsaWNhdGlvbnMgaXQgbWlnaHQgYmUgYmV0dGVyIG9mZiB0 byBmYWxsYmFjayAieXVlLCBlbiIgYXMNCk5vdGUg4oCcc29tZSBhcHBsaWNhdGlvbnPigJ0uICBJ ZiBJIGhhdmUg4oCcemgteXVl4oCdIG9uIHRoZSB3aXJlIGFuZCBJ4oCZbSBhbiBhcHBsaWNhdGlv biB0aGF0IHByZWZlcnMgdG8gdGhpbmsgb2YgdGhhdCBpbiBhIOKAnHl1ZeKAnSBtYW5uZXIsIHRo ZW4gdGhlIGNvbnZlcnNpb24gZnJvbSB6aC15dWUgdG8geXVlIGlzIGZhaXJseSB0cml2aWFsLiAg KHBDaGFyKz0zKQ0KSWYsIGhvd2V2ZXIgd2UgaGF2ZSDigJx5dWXigJ0gYW5kIEnigJltIGFuIGFw cGxpY2F0aW9uIHRoYXQgcHJlZmVycyB0byB0aGluayBvZiB0aGF0IGFzIOKAnHpoLXl1ZeKAnSwg dGhlbiBJIGp1c3QgZ290IGEgbXVjaCBiaWdnZXIgcHJvYmxlbS4NClNvIGluIG15IHZpZXcsIHRo ZSBwcm9ibGVtIGlzbuKAmXQgaWYgNDY0NmJpcyBzYXlzIHVzZSDigJx6aC15dWXigJ0sIHRoZSBw cm9ibGVtIGlzIGhvdyA0NjQ3YmlzIHNheXMgdG8gZmFsbGJhY2sgeXVlLCBubyBtYXR0ZXIgaG93 IGl0cyBsYWJlbGVkLiAgSSBhbHNvIGRvbuKAmXQgdGhpbmsgdGhhdCA0NjQ3YmlzIHNob3VsZCBz YXkg4oCcTVVTVOKAnSAob3IgZXZlbiDigJxTSE9VTETigJ0pIGluIHRoaXMgY29udGV4dCBiZWNh dXNlIGl0IGlzIHF1aXRlIGFwcGFyZW50IHRoYXQgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBoYXZl IGRpZmZlcmVudCBuZWVkcyBmb3IgZmFsbGluZyBiYWNrIOKAnHN1Ymxhbmdz4oCdLiAgSSBkbyB0 aGluayBpdCBzaG91bGQgcHJvdmlkZSBndWlkZWxpbmVzIG9uIHRoYXQgYmVoYXZpb3IuDQpBbnl3 YXksIElNTyB0aGlzIGlzbuKAmXQgYSA0NjQ2IHRhZ2dpbmcgcHJvYmxlbSwgaXTigJlzIGEgNDY0 NyBmYWxsYmFjayBwcm9ibGVtLg0KLSBTaGF3bg0KDQo= --_000_C9BF0238EED3634BA1866AEF14C7A9E55A59955695NAEXMSGC116re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6TWFuZ2FsOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSAyIDMgMyAyIDI7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUg NCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut MToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmdtYWlscXVvdGUNCgl7bXNvLXN0 eWxlLW5hbWU6Z21haWxfcXVvdGU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9 DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU4ODI3 NzM0MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTIz NTM2NTAwOCAyMzY5ODYwOTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 Ok1hbmdhbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2Mjc1ODY4NjU7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjI3ODk0MTk5Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxODM5NDY2NDE1Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotODA4Njk1OTI2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxODc0MTQ2MTM4Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUyNDIzMDY2NCAxNzc4Mzg1OTI2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5EaWZmZXJlbnQgaWRlYSAoc28gSSBtYWRl IGl0IGENCmRpZmZlcmVudCBtYWlsKTwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDt0 ZXh0LWluZGVudDotLjI1aW47DQptc28tbGlzdDpsMyBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCmNvbG9yOiMxRjQ5 N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsOYPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4w cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPlRoaXMgaXMgcHJlY2lzZWx5IHdoeSBJIHRoaW5rIHRoaXMgc2hvdWxkIG5vdCBiZQ0KYmFr ZWQgaW50byBleHRsYW5nLiBGb3Igc29tZSBhcHBsaWNhdGlvbnMgaXQgbWlnaHQgYmUgYmV0dGVy IG9mZiB0byBmYWxsYmFjaw0KJnF1b3Q7eXVlLCBlbiZxdW90OyBhczxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+Tm90ZSDigJxzb21lIGFwcGxpY2F0aW9uc+KAnS7CoCBJZg0KSSBo YXZlIOKAnHpoLXl1ZeKAnSBvbiB0aGUgd2lyZSBhbmQgSeKAmW0gYW4gYXBwbGljYXRpb24gdGhh dCBwcmVmZXJzIHRvIHRoaW5rIG9mDQp0aGF0IGluIGEg4oCceXVl4oCdIG1hbm5lciwgdGhlbiB0 aGUgY29udmVyc2lvbiBmcm9tIHpoLXl1ZSB0byB5dWUgaXMgZmFpcmx5DQp0cml2aWFsLsKgIChw Q2hhcis9Myk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0K Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JZiwgaG93 ZXZlciB3ZSBoYXZlIOKAnHl1ZeKAnSBhbmQNCknigJltIGFuIGFwcGxpY2F0aW9uIHRoYXQgcHJl ZmVycyB0byB0aGluayBvZiB0aGF0IGFzIOKAnHpoLXl1ZeKAnSwgdGhlbiBJIGp1c3QgZ290IGEN Cm11Y2ggYmlnZ2VyIHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+U28gaW4gbXkgdmlldywgdGhlIHByb2JsZW0NCmlzbuKAmXQgaWYgNDY0NmJpcyBzYXlz IHVzZSDigJx6aC15dWXigJ0sIHRoZSBwcm9ibGVtIGlzIGhvdyA0NjQ3YmlzIHNheXMgdG8gZmFs bGJhY2sNCnl1ZSwgbm8gbWF0dGVyIGhvdyBpdHMgbGFiZWxlZC7CoCBJIGFsc28gZG9u4oCZdCB0 aGluayB0aGF0IDQ2NDdiaXMgc2hvdWxkIHNheSDigJxNVVNU4oCdDQoob3IgZXZlbiDigJxTSE9V TETigJ0pIGluIHRoaXMgY29udGV4dCBiZWNhdXNlIGl0IGlzIHF1aXRlIGFwcGFyZW50IHRoYXQg ZGlmZmVyZW50DQphcHBsaWNhdGlvbnMgaGF2ZSBkaWZmZXJlbnQgbmVlZHMgZm9yIGZhbGxpbmcg YmFjayDigJxzdWJsYW5nc+KAnS7CoCBJIGRvIHRoaW5rIGl0DQpzaG91bGQgcHJvdmlkZSBndWlk ZWxpbmVzIG9uIHRoYXQgYmVoYXZpb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+QW55d2F5LCBJTU8gdGhpcyBpc27igJl0IGEgNDY0Ng0KdGFnZ2luZyBwcm9ibGVt LCBpdOKAmXMgYSA0NjQ3IGZhbGxiYWNrIHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+LSBTaGF3bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPsKgPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwv aHRtbD4NCg== --_000_C9BF0238EED3634BA1866AEF14C7A9E55A59955695NAEXMSGC116re_-- --===============0674014508== 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 --===============0674014508==-- From ltru-bounces@ietf.org Fri Oct 12 14:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP82-0005tr-Qx; Fri, 12 Oct 2007 14:20:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgP81-0005tl-LJ for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgP81-0005sF-Am for ltru@ietf.org; Fri, 12 Oct 2007 14:20:53 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgP80-0007jA-1H for ltru@ietf.org; Fri, 12 Oct 2007 14:20:53 -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.8/8.13.8/y.rout) with ESMTP id l9CIKSfh013707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2007 11:20: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=HlyhkSSRV0DtvN/S/UfyWKReoh8NJ/exA0FCUWCII4HwckN++1umRzhv/q1BaAmG Message-ID: <470FBAEC.7050500@yahoo-inc.com> Date: Fri, 12 Oct 2007 11:20:28 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Shawn Steele Subject: Re: [Ltru] Re: Extended language tags (long reply) References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@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 rsmtp1.corp.yahoo.com id l9CIKSfh013707 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Shawn Steele wrote: > =20 >=20 > =C3=98 This is precisely why I think this should not be baked into ext= lang.=20 > For some applications it might be better off to fallback "yue, en" as This was a misquote of the original example?? The LPL would be=20 "yue-Hant-HK;en" for this example: >=20 > 1. yue-Hant-HK > 2. yue-Hant > 3. yue > 4. zh-Hant-HK > 5. zh-Hant > 6. zh > 7. en >=20 > My interpretation of http-accept-lang and rfc4647 is that if they ask=20 > for yue;en, then you look for >=20 > =20 >=20 > 1. =E2=80=9Cyue=E2=80=9D >=20 > 2. =E2=80=9Cen=E2=80=9D >=20 > =20 >=20 > I don=E2=80=99t know where you=E2=80=99re getting the rest of these fro= m, particularly=20 > the HK variations. If you want to do something app specific, that=E2=80= =99s=20 > cool, but that=E2=80=99s app specific. You're referring to the filtering algorithm. I'm referring to the lookup=20 algorithm, which is in RFC 4647. For filtering, if you ask for "yue;en", that matches "yue" or "en", but=20 also "yue-HK", "en-Brai-GB", etc. Addison --=20 Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 12 14:24:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPBX-0000Pg-1Z; Fri, 12 Oct 2007 14:24:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgPBV-0000MK-Uh for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPBV-0000M1-Kw for ltru@ietf.org; Fri, 12 Oct 2007 14:24:29 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPBS-0007ot-Iv for ltru@ietf.org; Fri, 12 Oct 2007 14:24:29 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 12 Oct 2007 11:24:14 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Fri, 12 Oct 2007 11:24:14 -0700 From: Shawn Steele To: Addison Phillips Date: Fri, 12 Oct 2007 11:24:14 -0700 Subject: RE: [Ltru] Re: Extended language tags (long reply) Thread-Topic: [Ltru] Re: Extended language tags (long reply) Thread-Index: AcgM/KE22tOfpcxXRMWM0DmYiOFR6wAAFvUg Message-ID: References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> <470FBAEC.7050500@yahoo-inc.com> In-Reply-To: <470FBAEC.7050500@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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="===============0936596686==" Errors-To: ltru-bounces@ietf.org --===============0936596686== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBZb3UncmUgcmVmZXJyaW5nIHRvIHRoZSBmaWx0ZXJpbmcgYWxnb3JpdGhtLiBJJ20gcmVmZXJy aW5nIHRvIHRoZSBsb29rdXANCj4gYWxnb3JpdGhtLCB3aGljaCBpcyBpbiBSRkMgNDY0Ny4NCg0K PiBGb3IgZmlsdGVyaW5nLCBpZiB5b3UgYXNrIGZvciAieXVlO2VuIiwgdGhhdCBtYXRjaGVzICJ5 dWUiIG9yICJlbiIsIGJ1dA0KPiBhbHNvICJ5dWUtSEsiLCAiZW4tQnJhaS1HQiIsIGV0Yy4NCg0K WW91J3JlIHJpZ2h0LCB0aGF0J3MgbXkgYmlhcywgc29ycnkgOikNCg0KLSBTaGF3bg0K --===============0936596686== 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 --===============0936596686==-- From ltru-bounces@ietf.org Fri Oct 12 16:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQwz-0002La-I8; Fri, 12 Oct 2007 16:17:37 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgQwy-0002Fm-4M for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQwx-00026q-El for ltru@ietf.org; Fri, 12 Oct 2007 16:17:35 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQwq-00038q-KN for ltru@ietf.org; Fri, 12 Oct 2007 16:17:35 -0400 Received: by wa-out-1112.google.com with SMTP id k40so1616341wah for ; Fri, 12 Oct 2007 13:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=4o7DAAZiczwuMZ8H5B1zMC/UQqEvu5Az2haNC0r/xD4=; b=FX2LVt6SxYu94EPD5Myk+GYYxHKjYWqECfwgBEOTt6CpIl+jDqmJNiCoL/9bwP8zQPHBMU5xBJq8hhqD9lSbLAGbhDhtISTUzT/jqr9+X7zyH7G/zP2HlpHh74DHEc+whc3lHR300RJTSxK6Vgr5SuTzGgkFJxAWpJPNClCLrDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=OsX4bDwzqKiDPaSG0CczH9pGx8t9F5U/Ypa6vx4urh0l1J25AwzmqSYA7IBI8M9k7IgIwkRZZUPaa/1cq0lVsFIXpZSY21igdkYxUGUK+fHmEa2zBeouf7Bwt99AJMK5vhDZxuYDMs2rWGdiCfzWugnfyvjgz3thQQXGgxIZz1w= Received: by 10.115.108.1 with SMTP id k1mr3892493wam.1192220224308; Fri, 12 Oct 2007 13:17:04 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Fri, 12 Oct 2007 13:17:04 -0700 (PDT) Message-ID: <30b660a20710121317t3799c8e4xb4e974237483c44@mail.gmail.com> Date: Fri, 12 Oct 2007 13:17:04 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: Extended language tags (long reply) In-Reply-To: <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> MIME-Version: 1.0 References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> X-Google-Sender-Auth: b189565910ea2ab4 X-Spam-Score: 0.6 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: LTRU Working Group , Doug Ewell X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1505151505==" Errors-To: ltru-bounces@ietf.org --===============1505151505== Content-Type: multipart/alternative; boundary="----=_Part_22759_29487460.1192220224295" ------=_Part_22759_29487460.1192220224295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U29ycnkgZm9yIHRoZSBjb25mdXNpb24sIEkgZGlkIG1lYW4gdGhlIHF1ZXJ5J3MgYmVpbmcgInl1 ZS1IYW50LUhLLCBlbiIuCgpBbHNvLCBnb3QgYSBub3RlIGZyb20gSm9obiBKZW5raW5zIGFib3V0 IENhbnRvbmVzZToKCgpUaGUgZm9ybWVyIGlzIGxpa2UgaGF2aW5nIFNwYW5pYXJkcyByZWFkIGFu ZCB3cml0ZSBGcmVuY2ggYnV0IHByb25vdW5jZSBpdAphcyBpZiBpdCB3ZXJlIFNwYW5pc2guICBB IEZyZW5jaG1hbiB3b3VsZG4ndCB1bmRlcnN0YW5kIGl0IGlmIGl0IHRoZXkgaGVhcmQKaXQgZXZl biB0aG91Z2ggaXQncyB0aGUgc2FtZSB3b3JkcyBhbmQgZ3JhbW1hci4KClRoZSBsYXR0ZXIgaXMg dmVyeSBkaWZmZXJlbnQgYW5kLCBhcyBMZWUgc2F5cywgbGFyZ2VseSBpbmNvbXByZWhlbnNpYmxl IHRvIGEKTWFuZGFyaW4gc3BlYWtlci4gIE5vdCBlbnRpcmVseSwgYXMgdGhlcmUncyBhIGxvdCBv ZiBvdmVybGFwIGJldHdlZW4gdGhlIHR3bwpsZXhpY2FsbHksIGJ1dCBlbm91Z2ggY29tbW9uIHdv cmRzIGFyZSBkaWZmZXJlbnQgYXMgdG8gdGhyb3cgdGhlIHJlYWRlciBvZmYuCiBJJ3ZlIGJlZW4g Y2F1Z2h0IGEgY291cGxlIG9mIHRpbWVzIG5vdCBiZWluZyBhYmxlIHRvIG1ha2Ugb3V0IGFkcyBp biB0aGUKSG9uZyBLb25nIHVuZGVyZ3JvdW5kIHVudGlsIEkgcmVhbGl6ZWQgdGhhdCB0aGV5IHdl cmUgaW4gQ2FudG9uZXNlLCBub3QKc3RhbmRhcmQgd3JpdHRlbiBDaGluZXNlLgoKVGhlIGV4YW1w bGUgb2YgRW5nbGlzaCBhbmQgRHV0Y2ggaXMgZ29vZCwgaW4gdGhhdCBlbm91Z2ggd29yZHMgYXJl IGNsb3NlCmVub3VnaCB5b3UgY2FuIGdldCBhIHZhZ3VlIHNlbnNlIG9mIHdoYXQncyBiZWluZyBz YWlkLCBidXQgeW91IGNhbid0IHJlYWxseQpyZWFkIGl0LgoKRS5nLiwgdGhlIEVuZ2xpc2ggc2Vu dGVuY2UsICJUaGFuayB5b3U7IHRoYXQncyBhIGdvb2QgYm9vay4iIGlzOgoK6Kyd6KydOyDpgqPm nKzmm7jlvojlpb3jgIIKCnN0YW5kYXJkIHdyaXR0ZW4gQ2hpbmVzZSwgYnV0OgoK5ZSU6KmyOyDl l7DmnKzmm7jlpb3lpb3lmrnjgIIKCmluIENhbnRvbmVzZS4gVGhlIE1hbmRhcmluIHNwZWFrZXIg Y291bGQgZmlndXJlIG91dCB0aGF0IGl0J3Mgc29tZXRoaW5nCmFib3V0IGdvb2QgYm9va3MsIGJ1 dCB0aGF0J3MgaXQuIFRoZXkgd291bGRuJ3QgaGF2ZSBhIGNsdWUgYXMgdG8gdGhlIG1lYW5pbmcK b2Yg5ZSULCDll7AsIG9yIOWauSwgYW5kIHRoZSB3YXkgdGhlIGZhbWlsaWFyIGNoYXJhY3RlcnMg 6KmyIGFuZCDlpb0gYXJlIGJlaW5nIHVzZWQKd291bGQgc2VlbSBvZGQgYXQgYmVzdC4KCkFuZCwg RldJVywgd3JpdHRlbiBDYW50b25lc2UgaXMgc3RpbGwgc29tZXRoaW5nIG9mIGEgYXZpcyByYXJh LCBidXQgdGhlcmUncwpiZWVuIGEgbWluaS1ib29tIGluIGl0IHNpbmNlIEhLIHdlbnQgYmFjayB0 byB0aGUgbWFpbmxhbmQuICBXaGVuIEkgbGl2ZWQKdGhlcmUgdHdlbnR5LWZpdmUgeWVhcnMgYWdv LCBpdCB3YXMgdW5oZWFyZCBvZiBleGNlcHQKaW4gcGVkYWdvZ2ljYWwgbWF0ZXJpYWxzLCBtb3Zp ZSBzY3JpcHRzLCBhbmQgZ3JhZmZpdGkuCgpNYXJrCgpPbiAxMC8xMi8wNywgTWFyayBEYXZpcyA8 bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc+IHdyb3RlOgo+Cj4gVGhpcyBpcyBwcmVjaXNlbHkg d2h5IEkgdGhpbmsgdGhpcyBzaG91bGQgbm90IGJlIGJha2VkIGludG8gZXh0bGFuZy4gRm9yCj4g c29tZSBhcHBsaWNhdGlvbnMgaXQgbWlnaHQgYmUgYmV0dGVyIG9mZiB0byBmYWxsYmFjayAieXVl LCBlbiIgYXMKPgo+Cj4gICAgMS4geXVlLUhhbnQtSEsKPiAgICAyLiB5dWUtSGFudAo+ICAgIDMu IHl1ZQo+ICAgIDQuIHpoLUhhbnQtSEsKPiAgICA1LiB6aC1IYW50Cj4gICAgNi4gemgKPiAgICA3 LiBlbgo+Cj4KPiBCdXQgdGhlcmUgaXMgYSBiaWcgbWF5YmUgaGVyZS4gQWNjb3JkaW5nIHRvIExl ZSBDb2xsaW5zLCB3aG8gaXMgd2VsbAo+IHZlcnNlZCBpbiB0aGlzIGFyZWEsIHRoZXJlIGFyZSB0 d28gY2FzZXM6Cj4gMS4gU3RhbmRhcmQgd3JpdHRlbiBDaGluZXNlIHJlYWQgYXMgQ2FudG9uZXNl Lgo+IDIuIFdyaXR0ZW4gQ2FudG9uZXNlLgo+Cj4gMS4gQ2FuJ3QgYmUgZGlzdGluZ3Vpc2hlZCBh dCB0aGUgc2NyaXB0IGxldmVsIGZyb20gTWFuZGFyaW4sCj4gMi4gY2FuIGJlIGFzIGVhc2lseSBk aXNjZXJuZWQgYXMgZWFzaWx5IGFzIGFueSBvdGhlciBsYW5ndWFnZS4gSXQncyBhcwo+IGRpZmZl cmVudCwgc2F5LCBhcyBkdXRjaCBpcyBmcm9tIEVuZ2xpc2guIFNvbWUgd29yZHMgbG9vayB0aGUg c2FtZSwgYnV0IGEKPiBtYW5kYXJpbiBzcGVha2VyIGNvdWxkbid0IHJlYWQgaXQuCj4KPiBTbyB0 aGUgc2l0dWF0aW9uIGlzIG5vdCB0aGF0IGNsZWFyLiBBbmQgY2VydGFpbmx5IGluIG90aGVyIGNp cmN1bXN0YW5jZXMKPiAobGlrZSBhdWRpbyksIGl0IGlzIG11Y2ggYmV0dGVyIHRvIGFjdHVhbGx5 IGhvbm9yIHRoZSB1c2VyJ3MgcmVxdWVzdCwgYW5kCj4gZmFsbCBiYWNrIGxpa2UKPgo+Cj4gICAg MS4geXVlLUhhbnQtSEsKPiAgICAyLiB5dWUtSGFudAo+ICAgIDMuIHl1ZQo+ICAgIDQuIGVuCj4g ICAgNS4gKGRlZmF1bHQsIHdoaWNoIGNvdWxkIGV4cGFuZCB0bykKPiAgICAgICAxLiB6aC1IYW50 LUhLCj4gICAgICAgMi4gemgtSGFudAo+ICAgICAgIDMuIHpoCj4KPgo+IFRoYXQncyB3aHkgaWYg d2UgbGVhdmUgdGhpcyB1cCB0byB0aGUgYXBwbGljYXRpb24sIHdoaWNoIGtub3dzIHdoYXQgZG9t YWluCj4gaXQgaXMgd29ya2luZyBpbiwgd2UncmUgYmV0dGVyIG9mZiB0aGFuIGlmIHdlIGhhcmQg Y29kZSBhIHJlbGF0aW9uc2hpcCB0aGF0Cj4gc29tZXRpbWVzIHdvcmtzLCBidXQgcmVxdWlyZXMg Y29kZSBjaGFuZ2VzIGFueXdheSwgYW5kIEkgdGhpbmsgbW9yZSBvZnRlbgo+IGZhaWxzLgo+Cj4g VGhpcyBzaXR1YXRpb24gaXMgdmVyeSBzaW1pbGFyIHRvIGFub3RoZXIgY2FzZSB0aGF0IHdlIGhh dmUgYWxyZWFkeS4gV2UKPiBjb3VsZCBoYXZlIHVzZWQgZXh0bGFuZyB3aXRoIGdzdyAoU3dpc3Mg R2VybWFuKS4gV2UgY291bGQgaGF2ZSBzYWlkOiBIbW0sCj4gdGhlcmUgd2FzIG5vIHdheSB0byB0 YWcgU3dpc3MgR2VybWFuIGJlZm9yZSwgc28gd2UgbWlnaHQgaGF2ZSBlbmRlZCB1cCB3aXRoCj4g c3VjaCBjb250ZW50IHRhZ2dlZCBhcyAiZGUiIGluc3RlYWQuIEFuZCwgaG1tbSwgd2hlbiB0aGUg U3dpc3Mgd3JpdGUgR2VybWFuLAo+IHRoZXkgdHlwaWNhbGx5IHVzZSBIaWdoIEdlcm1hbiwgc28g dGhlIHdyaXR0ZW4gZm9ybSBpcyBlc3NlbnRpYWxseSB0aGUgc2FtZQo+ICh3aXRoIHRoZSBleGNl cHRpb24gb2Ygc2hhcnAtcykuIFNvIGxldCdzIG1ha2UgdGhlIHRhZyBiZSAiZGUtZ3N3Igo+IGlu c3RlYWQuCj4KPiBCdXQgd2UgZGlkbid0IGJha2UgdGhpcyByZWxhdGlvbnNoaXAgaW50byB0aGUg Y29kZXM7IGluc3RlYWQgd2UgbGVhdmUgdGhpcwo+IHRvIHRoZSBhcHBsaWNhdGlvbiwgdG8gaGFu ZGxlIGFwcHJvcHJpYXRlIHRvIHRoZSBkb21haW4uCj4KPiBNYXJrCj4KPiBPbiAxMC8xMi8wNywg QWRkaXNvbiBQaGlsbGlwcyA8IGFkZGlzb25AeWFob28taW5jLmNvbT4gd3JvdGU6Cj4gPgo+ID4g Sm9obiBDb3dhbiB3cm90ZToKPiA+ID4KPiA+ID4gRXZlbiBpZiB5b3UgZG9uJ3QgdGFrZSB0aGF0 IHZpZXcgKGFuZCBJIGRvbid0KSwgaXQncyBpZGxlIHRvIGRlbnkKPiA+ID4gdGhhdCBhbG1vc3Qg ZXZlcnl0aGluZyB0ZXh0dWFsIHRhZ2dlZCAiemgiIG9yICJhciIgaXMgTWFuZGFyaW4gQ2hpbmVz ZQo+ID4gPiBvciBTdGFuZGFyZCBBcmFiaWMgcmVzcGVjdGl2ZWx5LCBhcyBhbiB1bmNvbnRyb3Zl cnNpYWwgY29uc2VxdWVuY2UKPiA+ID4gb2YgdGhlIGZhY3QgdGhhdCBhbG1vc3QgYWxsIHdyaXR0 ZW4gZG9jdW1lbnRzIGluIENoaW5lc2Ugb3IgQXJhYmljCj4gPiA+ICphcmUqIE1hbmRhcmluIG9y IFN0YW5kYXJkIHJlc3BlY3RpdmVseS4KPiA+ID4KPiA+Cj4gPiBBY3R1YWxseSwgSSBkb24ndCBr bm93IHRoYXQgSSB3b3VsZCBzYXkgdGhhdCwgYXQgbGVhc3QgaW4gdGhlIGNhc2Ugb2YKPiA+IENo aW5lc2UuCj4gPgo+ID4gSW4gZmFjdCwgZm9yIG1vc3QgQ2hpbmVzZSB3cml0dGVuIGRvY3VtZW50 cywgSSB3b3VsZCB0ZW5kIHRvIHNheSB0aGF0IGl0Cj4gPiBpc24ndCBwb3NzaWJsZSB0byBkaXNj ZXJuIHdoaWNoIHNwZWNpZmljIENoaW5lc2UgbGFuZ3VhZ2UgdGhleSBhcmUgaW4uCj4gPiBZb3Ug Y291bGQgcmVwcmVzZW50IHRoYXQgYXMgYmVpbmcgImluIE1hbmRhcmluIiwgc2luY2UgdGhhdCBp cyB0aGUKPiA+IHNvdXJjZSBvZiB0aGUgd3JpdHRlbiBmb3JtLCBidXQgaW4gcHJhY3RpY2FsIHRl cm1zIHRoZXJlIGlzIGxpdHRsZQo+ID4gZW5vdWdoIGRpZmZlcmVuY2UgYmV0d2VlbiBDYW50b25l c2UgYW5kIE1hbmRhcmluIGF0IHRoZSB3cml0dGVuIGxldmVsIHRvCj4gPiByZWFsbHkga25vdy4g SW4gZmFjdCwgaXQgaXMgYSB2ZXJ5IHVzZWZ1bCBmaWN0aW9uIHRoYXQgdGhlc2UgbGFuZ3VhZ2Vz Cj4gPiBhcmUgInRoZSBzYW1lIi4KPiA+Cj4gPiBUaGlzIGlzIG9uZSByZWFzb24gdGhhdCBJIHBy ZWZlciBteSB3b3JrYXJvdW5kIGZvciB0aGUgbG9va3VwIGFsZ29yaXRobQo+ID4gdXNpbmcgZXh0 bGFuZ3MgdG8gTWFyaydzIHJlY2VudCBzdWdnZXN0aW9uIG9uIGxpc3Q6IGl0IHJlY29nbml6ZXMg dGhhdCwKPiA+IGZvciB3cml0dGVuIHJlc291cmNlcywgImdlbmVyaWMiIENoaW5lc2UgcGx1cyBz dWJ0YWdzIGlzIGEgYmV0dGVyCj4gPiBmYWxsYmFjayB0aGFuIHRoZSBzZWNvbmQgbGFuZ3VhZ2Ug aW4geW91ciBsYW5ndWFnZSBwcmlvcml0eSBsaXN0Lgo+ID4KPiA+IFtbQXMgYSByZW1pbmRlciBN YXJrJ3Mgc3VnZ2VzdGlvbiB3YXMgdG8gbWFrZSBmYWxsYmFjayBmb3IgdGhlIExQTAo+ID4gInpo LXl1ZS1IYW50LUhLO2VuIiB0byBiZToKPiA+Cj4gPiAgIHpoLXl1ZS1IYW50LUhLCj4gPiAgIHpo LXl1ZS1IYW50Cj4gPiAgIHpoLXl1ZQo+ID4gICBlbgo+ID4gICB6aC1IYW50LUhLCj4gPiAgIHpo LUhhbnQKPiA+ICAgemgKPiA+ICAgKGRlZmF1bHQpCj4gPgo+ID4gQW5kIG1pbmUgd2FzOgo+ID4K PiA+ICAgemgteXVlLUhhbnQtSEsKPiA+ICAgemgteXVlLUhhbnQKPiA+ICAgemgteXVlCj4gPiAg IHpoLUhhbnQtSEsKPiA+ICAgemgtSGFudAo+ID4gICB6aAo+ID4gICBlbgo+ID4gICAoZGVmYXVs dCkKPiA+Cj4gPiBdXQo+ID4KPiA+IEFkZGlzb24KPiA+Cj4gPiAtLQo+ID4gQWRkaXNvbiBQaGls bGlwcwo+ID4gR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gWWFob28hIEluYy4KPiA+IENoYWly IC0tIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdHCj4gPgo+ID4gSW50ZXJuYXRpb25h bGl6YXRpb24gaXMgYW4gYXJjaGl0ZWN0dXJlLgo+ID4gSXQgaXMgbm90IGEgZmVhdHVyZS4KPiA+ Cj4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PiA+IEx0cnUgbWFpbGluZyBsaXN0Cj4gPiBMdHJ1QGlldGYub3JnCj4gPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4gPgo+Cj4KPgo+IC0tCj4gTWFyawoKCgoK LS0gCk1hcmsK ------=_Part_22759_29487460.1192220224295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U29ycnkgZm9yIHRoZSBjb25mdXNpb24sIEkgZGlkIG1lYW4gdGhlIHF1ZXJ5JiMzOTtzIGJlaW5n ICZxdW90O3l1ZS1IYW50LUhLLCBlbiZxdW90Oy48YnI+PGJyPkFsc28sIGdvdCBhIG5vdGUgZnJv bSBKb2huIEplbmtpbnMgYWJvdXQgQ2FudG9uZXNlOjxicj48YnI+PGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6IDQwcHg7Ij48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPlRoZSBmb3Jt ZXIgaXMgbGlrZSBoYXZpbmcgU3BhbmlhcmRzIHJlYWQgYW5kIHdyaXRlCkZyZW5jaCBidXQgcHJv bm91bmNlIGl0IGFzIGlmIGl0IHdlcmUgU3BhbmlzaC4gJm5ic3A7QSBGcmVuY2htYW4gd291bGRu JiMzOTt0CnVuZGVyc3RhbmQgaXQgaWYgaXQgdGhleSBoZWFyZCBpdCBldmVuIHRob3VnaCBpdCYj Mzk7cyB0aGUgc2FtZSB3b3JkcyBhbmQKZ3JhbW1hci4gJm5ic3A7PC9mb250PjwvZGl2PjxkaXY+ PGZvbnQgc2l6ZT0iMiI+PGJyPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPlRoZSBs YXR0ZXIgaXMgdmVyeSBkaWZmZXJlbnQgYW5kLAphcyBMZWUgc2F5cywgbGFyZ2VseSBpbmNvbXBy ZWhlbnNpYmxlIHRvIGEgTWFuZGFyaW4gc3BlYWtlci4gJm5ic3A7Tm90CmVudGlyZWx5LCBhcyB0 aGVyZSYjMzk7cyBhIGxvdCBvZiBvdmVybGFwIGJldHdlZW4gdGhlIHR3byBsZXhpY2FsbHksIGJ1 dAplbm91Z2ggY29tbW9uIHdvcmRzIGFyZSBkaWZmZXJlbnQgYXMgdG8gdGhyb3cgdGhlIHJlYWRl ciBvZmYuICZuYnNwO0kmIzM5O3ZlCmJlZW4gY2F1Z2h0IGEgY291cGxlIG9mIHRpbWVzIG5vdCBi ZWluZyBhYmxlIHRvIG1ha2Ugb3V0IGFkcyBpbiB0aGUKSG9uZyBLb25nIHVuZGVyZ3JvdW5kIHVu dGlsIEkgcmVhbGl6ZWQgdGhhdCB0aGV5IHdlcmUgaW4gQ2FudG9uZXNlLCBub3QKc3RhbmRhcmQg d3JpdHRlbiBDaGluZXNlLiAmbmJzcDs8L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj48 YnI+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiI+VGhlIGV4YW1wbGUgb2YKRW5nbGlz aCBhbmQgRHV0Y2ggaXMgZ29vZCwgaW4gdGhhdCBlbm91Z2ggd29yZHMgYXJlIGNsb3NlIGVub3Vn aCB5b3UKY2FuIGdldCBhIHZhZ3VlIHNlbnNlIG9mIHdoYXQmIzM5O3MgYmVpbmcgc2FpZCwgYnV0 IHlvdSBjYW4mIzM5O3QgcmVhbGx5IHJlYWQKaXQuICZuYnNwOzwvZm9udD48L2Rpdj48ZGl2Pjxm b250IHNpemU9IjIiPjxicj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj5FLmcuLCB0 aGUgRW5nbGlzaCBzZW50ZW5jZSwgJnF1b3Q7VGhhbmsgeW91OyB0aGF0JiMzOTtzIGEgZ29vZCBi b29rLiZxdW90OyBpczo8L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj48YnI+PC9mb250 PjwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiI+CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7 Ij7orJ3orJ07IOmCozxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVGFsaWdlbnRNb25vOyBmb250 LXNpemU6IDE0cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij7mnKzmm7jlvojlpb08L3NwYW4+44CC PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGZhY2U9IiYjMzk7TGlIZWkgUHJvJiMzOTsi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7Ij4KPGJyPjwvc3Bhbj48L2Zv bnQ+PC9kaXY+PGRpdj48Zm9udCBmYWNlPSImIzM5O0xpSGVpIFBybyYjMzk7IiBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4OyI+c3RhbmRhcmQgd3JpdHRlbiBDaGluZXNlLCBi dXQ6PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPjxicj48L2ZvbnQ+PC9k aXY+PGRpdj48Zm9udCBzaXplPSIyIj7llJToqbI8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNXB4 OyI+CjsgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWxpZ2VudE1vbm87IGZvbnQtc2l6ZTog MTRweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPuWXsOacrOabuOWlveWlveWauTxzcGFuIHN0eWxl PSJmb250LXNpemU6IDE1cHg7Ij7jgII8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+ PGRpdj48Zm9udCBmYWNlPSImIzM5O0xpSGVpIFBybyYjMzk7IiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxNXB4OyI+Cjxicj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQg ZmFjZT0iJiMzOTtMaUhlaSBQcm8mIzM5OyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTVweDsiPmluCkNhbnRvbmVzZS4gVGhlIE1hbmRhcmluIHNwZWFrZXIgY291bGQgZmlndXJl IG91dCB0aGF0IGl0JiMzOTtzIHNvbWV0aGluZwphYm91dCBnb29kIGJvb2tzLCBidXQgdGhhdCYj Mzk7cyBpdC4gVGhleSB3b3VsZG4mIzM5O3QgaGF2ZSBhIGNsdWUgYXMgdG8gdGhlCm1lYW5pbmcg b2YgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWxpZ2VudE1vbm87IGZvbnQtc2l6ZTogMTRw eDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPuWUlCwmbmJzcDvll7AsIG9yJm5ic3A75Zq5LCBhbmQg dGhlIHdheSB0aGUgZmFtaWxpYXIgY2hhcmFjdGVycyZuYnNwO+ipsiBhbmQmbmJzcDvlpb0gYXJl IGJlaW5nIHVzZWQgd291bGQgc2VlbSBvZGQgYXQgYmVzdC48L3NwYW4+PC9zcGFuPjwvZm9udD48 L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPgo8YnI+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgc2l6 ZT0iMiI+QW5kLApGV0lXLCB3cml0dGVuIENhbnRvbmVzZSBpcyBzdGlsbCBzb21ldGhpbmcgb2Yg YSBhdmlzIHJhcmEsIGJ1dCB0aGVyZSYjMzk7cwpiZWVuIGEgbWluaS1ib29tIGluIGl0IHNpbmNl IEhLIHdlbnQgYmFjayB0byB0aGUgbWFpbmxhbmQuICZuYnNwO1doZW4gSQpsaXZlZCB0aGVyZSB0 d2VudHktZml2ZSB5ZWFycyBhZ28sIGl0IHdhcyB1bmhlYXJkIG9mIGV4Y2VwdAppbiZuYnNwO3Bl ZGFnb2dpY2FsJm5ic3A7bWF0ZXJpYWxzLCBtb3ZpZSBzY3JpcHRzLCBhbmQgZ3JhZmZpdGkuPGJy Pjxicj48L2ZvbnQ+PC9kaXY+PC9kaXY+TWFyazxkaXY+PGJyPjwvZGl2Pjxicj48ZGl2PjxzcGFu IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTAvMTIvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJu YW1lIj5NYXJrIERhdmlzPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmsuZGF2aXNAaWN1LXBy b2plY3Qub3JnIj4KbWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+Jmd0OyB3cm90ZTo8L3Nw YW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFw eCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBh ZGRpbmctbGVmdDogMWV4OyI+VGhpcyBpcyBwcmVjaXNlbHkgd2h5IEkgdGhpbmsgdGhpcyBzaG91 bGQgbm90IGJlIGJha2VkIGludG8gZXh0bGFuZy4gRm9yIHNvbWUgYXBwbGljYXRpb25zIGl0IG1p Z2h0IGJlIGJldHRlciBvZmYgdG8gZmFsbGJhY2sgJnF1b3Q7eXVlLCBlbiZxdW90OyBhcwo8YnI+ PGJyPjxvbD48c3BhbiBjbGFzcz0icSI+PGxpPjxzcGFuPnl1ZS1IYW50LUhLPC9zcGFuPjwvbGk+ PGxpPjxzcGFuPnl1ZS1IYW50PC9zcGFuPjwvbGk+PC9zcGFuPjxzcGFuIGNsYXNzPSJxIj4KPGxp PjxzcGFuPnl1ZTwvc3Bhbj48L2xpPjxsaT48c3Bhbj56aC1IYW50LUhLPC9zcGFuPjwvbGk+PGxp PjxzcGFuPgp6aC1IYW50PC9zcGFuPjwvbGk+PGxpPjxzcGFuPnpoPC9zcGFuPjwvbGk+PGxpPjxz cGFuPmVuPC9zcGFuPjwvbGk+PC9zcGFuPjwvb2w+PHNwYW4+PGJyPkJ1dCB0aGVyZSBpcyBhIGJp ZyBtYXliZSBoZXJlLiBBY2NvcmRpbmcgdG8gTGVlIENvbGxpbnMsIHdobyBpcyB3ZWxsIHZlcnNl ZCBpbiB0aGlzIGFyZWEsPC9zcGFuPiB0aGVyZSBhcmUgdHdvIGNhc2VzOjxzcGFuIGNsYXNzPSJx Ij4KPGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6IDQwcHg7Ij4KMS4gU3Rh bmRhcmQgd3JpdHRlbiBDaGluZXNlIHJlYWQgYXMgQ2FudG9uZXNlLiZuYnNwOzwvZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OiA0MHB4OyI+Mi4gV3JpdHRlbiBDYW50b25lc2UuJm5ic3A7PC9k aXY+PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6IDQwcHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6IDQwcHg7Ij4xLgpDYW4mIzM5O3QgYmUgZGlzdGluZ3Vpc2hlZCBhdCB0aGUg c2NyaXB0IGxldmVsIGZyb20gTWFuZGFyaW4sIDxicj4yLiBjYW4gYmUgYXMKZWFzaWx5IGRpc2Nl cm5lZCBhcyBlYXNpbHkgYXMgYW55IG90aGVyIGxhbmd1YWdlLiBJdCYjMzk7cyBhcyBkaWZmZXJl bnQsCnNheSwgYXMgZHV0Y2ggaXMgZnJvbSBFbmdsaXNoLiBTb21lIHdvcmRzIGxvb2sgdGhlIHNh bWUsIGJ1dCBhIG1hbmRhcmluCnNwZWFrZXIgY291bGRuJiMzOTt0IHJlYWQgaXQuIDxicj48L2Rp dj48L3NwYW4+PHNwYW4+PGJyPlNvIHRoZSBzaXR1YXRpb24gaXMgbm90IHRoYXQgY2xlYXIuIEFu ZCBjZXJ0YWlubHkgaW4gb3RoZXIgY2lyY3Vtc3RhbmNlcyAobGlrZSBhdWRpbyksIGl0IGlzIG11 Y2ggYmV0dGVyIHRvIGFjdHVhbGx5IGhvbm9yIHRoZSB1c2VyJiMzOTtzIHJlcXVlc3QsIGFuZCBm YWxsIGJhY2sgbGlrZQo8YnI+PGJyPgo8L3NwYW4+PG9sPjxzcGFuIGNsYXNzPSJxIj48bGk+PHNw YW4+eXVlLUhhbnQtSEs8L3NwYW4+PC9saT48bGk+PHNwYW4+eXVlLUhhbnQ8L3NwYW4+PC9saT48 bGk+PHNwYW4+Cnl1ZTwvc3Bhbj48L2xpPjxsaT48c3Bhbj5lbjwvc3Bhbj48L2xpPjwvc3Bhbj48 bGk+PHNwYW4+KGRlZmF1bHQsIHdoaWNoIGNvdWxkIGV4cGFuZCB0byk8L3NwYW4+PC9saT48c3Bh biBjbGFzcz0icSI+PG9sPjxsaT48c3Bhbj56aC1IYW50LUhLPC9zcGFuPjwvbGk+PGxpPjxzcGFu PnpoLUhhbnQ8L3NwYW4+PC9saT48bGk+PHNwYW4+emg8L3NwYW4+PC9saT48L29sPjwvc3Bhbj48 L29sPgo8c3Bhbj48YnI+VGhhdCYjMzk7cyB3aHkgaWYgd2UgbGVhdmUgdGhpcyB1cCB0byB0aGUg YXBwbGljYXRpb24sIHdoaWNoIGtub3dzIHdoYXQgZG9tYWluIGl0IGlzIHdvcmtpbmcgaW4sIHdl JiMzOTtyZSBiZXR0ZXIgb2ZmIHRoYW4gaWYgd2UgaGFyZCBjb2RlIGEgcmVsYXRpb25zaGlwIHRo YXQgc29tZXRpbWVzIHdvcmtzLCBidXQgcmVxdWlyZXMgY29kZSBjaGFuZ2VzIGFueXdheSwgYW5k IEkgdGhpbmsgbW9yZSBvZnRlbiBmYWlscy4KPGJyPjxicj5UaGlzIHNpdHVhdGlvbiBpcyB2ZXJ5 IHNpbWlsYXIgdG8gYW5vdGhlciBjYXNlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5LiBXZSBjb3VsZCBo YXZlIHVzZWQgZXh0bGFuZyB3aXRoIGdzdyAoU3dpc3MgR2VybWFuKS4gV2UgY291bGQgaGF2ZSBz YWlkOiBIbW0sIHRoZXJlIHdhcyBubyB3YXkgdG8gdGFnIFN3aXNzIEdlcm1hbiBiZWZvcmUsIHNv IHdlIG1pZ2h0IGhhdmUgZW5kZWQgdXAgd2l0aCBzdWNoIGNvbnRlbnQgdGFnZ2VkIGFzICZxdW90 O2RlJnF1b3Q7IGluc3RlYWQuIEFuZCwgaG1tbSwgd2hlbiB0aGUgU3dpc3Mgd3JpdGUgR2VybWFu LCB0aGV5IHR5cGljYWxseSB1c2UgSGlnaCBHZXJtYW4sIHNvIHRoZSB3cml0dGVuIGZvcm0gaXMg ZXNzZW50aWFsbHkgdGhlIHNhbWUgKHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBzaGFycC1zKS4KPC9z cGFuPjxzcGFuPlNvIGxldCYjMzk7cyBtYWtlIHRoZSB0YWcgYmUgJnF1b3Q7ZGUtZ3N3JnF1b3Q7 IGluc3RlYWQuIDxicj48YnI+QnV0IHdlIGRpZG4mIzM5O3QgYmFrZSB0aGlzIHJlbGF0aW9uc2hp cCBpbnRvIHRoZSBjb2RlczsgaW5zdGVhZCB3ZSBsZWF2ZSB0aGlzIHRvIHRoZSBhcHBsaWNhdGlv biwgdG8gaGFuZGxlIGFwcHJvcHJpYXRlIHRvIHRoZSBkb21haW4uPGJyPjwvc3Bhbj4KCjxzcGFu Pjxicj5NYXJrPC9zcGFuPjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExNTk1MjdlZTY5OTZm ODRfMTAiPjxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDEwLzEyLzA3 LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+QWRkaXNvbiBQaGlsbGlwczwvYj4gJmx0Ozxh IGhyZWY9Im1haWx0bzphZGRpc29uQHlhaG9vLWluYy5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNs aWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CgphZGRp c29uQHlhaG9vLWluYy5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQs IDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+Ckpv aG4gQ293YW4gd3JvdGU6PGJyPiZndDs8YnI+Jmd0OyBFdmVuIGlmIHlvdSBkb24mIzM5O3QgdGFr ZSB0aGF0IHZpZXcgKGFuZCBJIGRvbiYjMzk7dCksIGl0JiMzOTtzIGlkbGUgdG8gZGVueTxicj4m Z3Q7IHRoYXQgYWxtb3N0IGV2ZXJ5dGhpbmcgdGV4dHVhbCB0YWdnZWQgJnF1b3Q7emgmcXVvdDsg b3IgJnF1b3Q7YXImcXVvdDsgaXMgTWFuZGFyaW4gQ2hpbmVzZTxicj4mZ3Q7IG9yIFN0YW5kYXJk IEFyYWJpYyByZXNwZWN0aXZlbHksIGFzIGFuIHVuY29udHJvdmVyc2lhbCBjb25zZXF1ZW5jZQo8 YnI+Jmd0OyBvZiB0aGUgZmFjdCB0aGF0IGFsbW9zdCBhbGwgd3JpdHRlbiBkb2N1bWVudHMgaW4g Q2hpbmVzZSBvciBBcmFiaWM8YnI+Jmd0OyAqYXJlKiBNYW5kYXJpbiBvciBTdGFuZGFyZCByZXNw ZWN0aXZlbHkuPGJyPiZndDs8YnI+PGJyPkFjdHVhbGx5LCBJIGRvbiYjMzk7dCBrbm93IHRoYXQg SSB3b3VsZCBzYXkgdGhhdCwgYXQgbGVhc3QgaW4gdGhlIGNhc2Ugb2Y8YnI+Q2hpbmVzZS4KPGJy Pjxicj5JbiBmYWN0LCBmb3IgbW9zdCBDaGluZXNlIHdyaXR0ZW4gZG9jdW1lbnRzLCBJIHdvdWxk IHRlbmQgdG8gc2F5IHRoYXQgaXQ8YnI+aXNuJiMzOTt0IHBvc3NpYmxlIHRvIGRpc2Nlcm4gd2hp Y2ggc3BlY2lmaWMgQ2hpbmVzZSBsYW5ndWFnZSB0aGV5IGFyZSBpbi48YnI+WW91IGNvdWxkIHJl cHJlc2VudCB0aGF0IGFzIGJlaW5nICZxdW90O2luIE1hbmRhcmluJnF1b3Q7LCBzaW5jZSB0aGF0 IGlzIHRoZQo8YnI+c291cmNlIG9mIHRoZSB3cml0dGVuIGZvcm0sIGJ1dCBpbiBwcmFjdGljYWwg dGVybXMgdGhlcmUgaXMgbGl0dGxlPGJyPmVub3VnaCBkaWZmZXJlbmNlIGJldHdlZW4gQ2FudG9u ZXNlIGFuZCBNYW5kYXJpbiBhdCB0aGUgd3JpdHRlbiBsZXZlbCB0bzxicj5yZWFsbHkga25vdy4g SW4gZmFjdCwgaXQgaXMgYSB2ZXJ5IHVzZWZ1bCBmaWN0aW9uIHRoYXQgdGhlc2UgbGFuZ3VhZ2Vz Cjxicj4KYXJlICZxdW90O3RoZSBzYW1lJnF1b3Q7Ljxicj48YnI+VGhpcyBpcyBvbmUgcmVhc29u IHRoYXQgSSBwcmVmZXIgbXkgd29ya2Fyb3VuZCBmb3IgdGhlIGxvb2t1cCBhbGdvcml0aG08YnI+ dXNpbmcgZXh0bGFuZ3MgdG8gTWFyayYjMzk7cyByZWNlbnQgc3VnZ2VzdGlvbiBvbiBsaXN0OiBp dCByZWNvZ25pemVzIHRoYXQsPGJyPmZvciB3cml0dGVuIHJlc291cmNlcywgJnF1b3Q7Z2VuZXJp YyZxdW90OyBDaGluZXNlIHBsdXMgc3VidGFncyBpcyBhIGJldHRlcgo8YnI+ZmFsbGJhY2sgdGhh biB0aGUgc2Vjb25kIGxhbmd1YWdlIGluIHlvdXIgbGFuZ3VhZ2UgcHJpb3JpdHkgbGlzdC48YnI+ PGJyPltbQXMgYSByZW1pbmRlciBNYXJrJiMzOTtzIHN1Z2dlc3Rpb24gd2FzIHRvIG1ha2UgZmFs bGJhY2sgZm9yIHRoZSBMUEw8YnI+JnF1b3Q7emgteXVlLUhhbnQtSEs7ZW4mcXVvdDsgdG8gYmU6 PGJyPjxicj4mbmJzcDsmbmJzcDt6aC15dWUtSGFudC1ISzxicj4mbmJzcDsmbmJzcDt6aC15dWUt SGFudAo8YnI+Jm5ic3A7Jm5ic3A7emgteXVlPGJyPiZuYnNwOyZuYnNwO2VuPGJyPiZuYnNwOyZu YnNwO3poLUhhbnQtSEs8YnI+Jm5ic3A7Jm5ic3A7emgtSGFudDxicj4mbmJzcDsmbmJzcDt6aDxi cj4mbmJzcDsmbmJzcDsoZGVmYXVsdCk8YnI+PGJyPkFuZCBtaW5lIHdhczo8YnI+PGJyPiZuYnNw OyZuYnNwO3poLXl1ZS1IYW50LUhLPGJyPiZuYnNwOyZuYnNwO3poLXl1ZS1IYW50PGJyPiZuYnNw OyZuYnNwO3poLXl1ZTxicj4mbmJzcDsmbmJzcDt6aC1IYW50LUhLPGJyPiZuYnNwOyZuYnNwO3po LUhhbnQ8YnI+Jm5ic3A7Jm5ic3A7emg8YnI+Jm5ic3A7Jm5ic3A7ZW48YnI+Jm5ic3A7Jm5ic3A7 KGRlZmF1bHQpPGJyPjxicj5dXTxicj4KCjxicj4KQWRkaXNvbjxicj48YnI+LS08YnI+QWRkaXNv biBQaGlsbGlwczxicj5HbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBZYWhvbyEgSW5jLjxicj5D aGFpciAtLSBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXRzxicj48YnI+SW50ZXJuYXRp b25hbGl6YXRpb24gaXMgYW4gYXJjaGl0ZWN0dXJlLjxicj5JdCBpcyBub3QgYSBmZWF0dXJlLjxi cj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cjxicj5MdHJ1IG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0i cmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgoKaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48YnI+PC9ibG9ja3F1b3RlPjwv ZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+Cjxicj48L3NwYW4+PC9kaXY+LS0gPGJyPjxzcGFuIGNs YXNzPSJzZyI+TWFyawo8L3NwYW4+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFs bCI+PGJyPi0tIDxicj5NYXJrCg== ------=_Part_22759_29487460.1192220224295-- --===============1505151505== 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 --===============1505151505==-- From ltru-bounces@ietf.org Fri Oct 12 18:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgT8H-0000Fs-RB; Fri, 12 Oct 2007 18:37:25 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgT8G-0000Fn-K3 for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 18:37:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgT8G-0000FQ-AH for ltru@ietf.org; Fri, 12 Oct 2007 18:37:24 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgT85-0007GG-Pa for ltru@ietf.org; Fri, 12 Oct 2007 18:37:21 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 12 Oct 2007 15:36:33 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Fri, 12 Oct 2007 15:36:33 -0700 From: Peter Constable To: LTRU Working Group Date: Fri, 12 Oct 2007 15:36:32 -0700 Subject: RE: [Ltru] Re: Extended language tags (long reply) Thread-Topic: [Ltru] Re: Extended language tags (long reply) Thread-Index: AcgNDQ53dqSwL9vRT52OmS+Tw+sQVAAEtnIQ Message-ID: References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> <30b660a20710121317t3799c8e4xb4e974237483c44@mail.gmail.com> In-Reply-To: <30b660a20710121317t3799c8e4xb4e974237483c44@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0047960568==" Errors-To: ltru-bounces@ietf.org --===============0047960568== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AC6CD8ABNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AC6CD8ABNAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBkZWJhdGUgdGhhdCB3cml0dGVuIENhbnRvbmVzZSBh bmQgd3JpdHRlbiBNYW5kYXJpbiBtYXkgYmUgcXVpdGUgdW5pbnRlbGxpZ2libGU7IEkgZGlkbuKA mXQga25vdyB0aGlzIG11Y2ggZGV0YWlsLCBidXQgSSBjZXJ0YWlubHkgZG9u4oCZdCBmaW5kIGl0 IHN1cnByaXNpbmcuIFRoZSBwcm9ibGVtIGlzIHRoYXQg4oCcemjigJ0gY2FuIGxlZ2l0aW1hdGVs eSBiZSBhcHBsaWVkIHRvIGVpdGhlci4gU28sIGl04oCZcyBub3QgYSBtYXR0ZXIgb2Ygc2F5aW5n IHRoYXQgaXTigJlzIE9LIHRvIGZhbGxiYWNrIGZyb20gYSByZXF1ZXN0IHRvIHpoLXl1ZSB0byBN YW5kYXJpbiByZXNvdXJjZXMuIEl04oCZcyBhIG1hdHRlciBvZiBob3cgdG8gZGVhbCB3aXRoIHRo ZSB2YWd1YXJpZXMgb2Yg4oCcemjigJ0uDQoNClBldGVyDQoNCkZyb206IE1hcmsgRGF2aXMgW21h aWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAx MiwgMjAwNyAxOjE3IFBNDQpUbzogQWRkaXNvbiBQaGlsbGlwcw0KQ2M6IExUUlUgV29ya2luZyBH cm91cDsgRG91ZyBFd2VsbA0KU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogRXh0ZW5kZWQgbGFuZ3Vh Z2UgdGFncyAobG9uZyByZXBseSkNCg0KU29ycnkgZm9yIHRoZSBjb25mdXNpb24sIEkgZGlkIG1l YW4gdGhlIHF1ZXJ5J3MgYmVpbmcgInl1ZS1IYW50LUhLLCBlbiIuDQoNCkFsc28sIGdvdCBhIG5v dGUgZnJvbSBKb2huIEplbmtpbnMgYWJvdXQgQ2FudG9uZXNlOg0KDQpUaGUgZm9ybWVyIGlzIGxp a2UgaGF2aW5nIFNwYW5pYXJkcyByZWFkIGFuZCB3cml0ZSBGcmVuY2ggYnV0IHByb25vdW5jZSBp dCBhcyBpZiBpdCB3ZXJlIFNwYW5pc2guICBBIEZyZW5jaG1hbiB3b3VsZG4ndCB1bmRlcnN0YW5k IGl0IGlmIGl0IHRoZXkgaGVhcmQgaXQgZXZlbiB0aG91Z2ggaXQncyB0aGUgc2FtZSB3b3JkcyBh bmQgZ3JhbW1hci4NCg0KVGhlIGxhdHRlciBpcyB2ZXJ5IGRpZmZlcmVudCBhbmQsIGFzIExlZSBz YXlzLCBsYXJnZWx5IGluY29tcHJlaGVuc2libGUgdG8gYSBNYW5kYXJpbiBzcGVha2VyLiAgTm90 IGVudGlyZWx5LCBhcyB0aGVyZSdzIGEgbG90IG9mIG92ZXJsYXAgYmV0d2VlbiB0aGUgdHdvIGxl eGljYWxseSwgYnV0IGVub3VnaCBjb21tb24gd29yZHMgYXJlIGRpZmZlcmVudCBhcyB0byB0aHJv dyB0aGUgcmVhZGVyIG9mZi4gIEkndmUgYmVlbiBjYXVnaHQgYSBjb3VwbGUgb2YgdGltZXMgbm90 IGJlaW5nIGFibGUgdG8gbWFrZSBvdXQgYWRzIGluIHRoZSBIb25nIEtvbmcgdW5kZXJncm91bmQg dW50aWwgSSByZWFsaXplZCB0aGF0IHRoZXkgd2VyZSBpbiBDYW50b25lc2UsIG5vdCBzdGFuZGFy ZCB3cml0dGVuIENoaW5lc2UuDQoNClRoZSBleGFtcGxlIG9mIEVuZ2xpc2ggYW5kIER1dGNoIGlz IGdvb2QsIGluIHRoYXQgZW5vdWdoIHdvcmRzIGFyZSBjbG9zZSBlbm91Z2ggeW91IGNhbiBnZXQg YSB2YWd1ZSBzZW5zZSBvZiB3aGF0J3MgYmVpbmcgc2FpZCwgYnV0IHlvdSBjYW4ndCByZWFsbHkg cmVhZCBpdC4NCg0KRS5nLiwgdGhlIEVuZ2xpc2ggc2VudGVuY2UsICJUaGFuayB5b3U7IHRoYXQn cyBhIGdvb2QgYm9vay4iIGlzOg0KDQrorJ3orJ07IOmCo+acrOabuOW+iOWlveOAgg0KDQpzdGFu ZGFyZCB3cml0dGVuIENoaW5lc2UsIGJ1dDoNCg0K5ZSU6KmyIDsg5Zew5pys5pu45aW95aW95Zq5 44CCDQoNCmluIENhbnRvbmVzZS4gVGhlIE1hbmRhcmluIHNwZWFrZXIgY291bGQgZmlndXJlIG91 dCB0aGF0IGl0J3Mgc29tZXRoaW5nIGFib3V0IGdvb2QgYm9va3MsIGJ1dCB0aGF0J3MgaXQuIFRo ZXkgd291bGRuJ3QgaGF2ZSBhIGNsdWUgYXMgdG8gdGhlIG1lYW5pbmcgb2Yg5ZSULCDll7AsIG9y IOWauSwgYW5kIHRoZSB3YXkgdGhlIGZhbWlsaWFyIGNoYXJhY3RlcnMg6KmyIGFuZCDlpb0gYXJl IGJlaW5nIHVzZWQgd291bGQgc2VlbSBvZGQgYXQgYmVzdC4NCg0KQW5kLCBGV0lXLCB3cml0dGVu IENhbnRvbmVzZSBpcyBzdGlsbCBzb21ldGhpbmcgb2YgYSBhdmlzIHJhcmEsIGJ1dCB0aGVyZSdz IGJlZW4gYSBtaW5pLWJvb20gaW4gaXQgc2luY2UgSEsgd2VudCBiYWNrIHRvIHRoZSBtYWlubGFu ZC4gIFdoZW4gSSBsaXZlZCB0aGVyZSB0d2VudHktZml2ZSB5ZWFycyBhZ28sIGl0IHdhcyB1bmhl YXJkIG9mIGV4Y2VwdCBpbiBwZWRhZ29naWNhbCBtYXRlcmlhbHMsIG1vdmllIHNjcmlwdHMsIGFu ZCBncmFmZml0aS4NCk1hcmsNCg0KDQpPbiAxMC8xMi8wNywgTWFyayBEYXZpcyA8IG1hcmsuZGF2 aXNAaWN1LXByb2plY3Qub3JnPG1haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz4+IHdy b3RlOg0KVGhpcyBpcyBwcmVjaXNlbHkgd2h5IEkgdGhpbmsgdGhpcyBzaG91bGQgbm90IGJlIGJh a2VkIGludG8gZXh0bGFuZy4gRm9yIHNvbWUgYXBwbGljYXRpb25zIGl0IG1pZ2h0IGJlIGJldHRl ciBvZmYgdG8gZmFsbGJhY2sgInl1ZSwgZW4iIGFzDQoNCiAxLiAgeXVlLUhhbnQtSEsNCiAyLiAg eXVlLUhhbnQNCiAzLiAgeXVlDQogNC4gIHpoLUhhbnQtSEsNCiA1LiAgemgtSGFudA0KIDYuICB6 aA0KIDcuICBlbg0KDQpCdXQgdGhlcmUgaXMgYSBiaWcgbWF5YmUgaGVyZS4gQWNjb3JkaW5nIHRv IExlZSBDb2xsaW5zLCB3aG8gaXMgd2VsbCB2ZXJzZWQgaW4gdGhpcyBhcmVhLCB0aGVyZSBhcmUg dHdvIGNhc2VzOg0KDQoxLiBTdGFuZGFyZCB3cml0dGVuIENoaW5lc2UgcmVhZCBhcyBDYW50b25l c2UuDQoyLiBXcml0dGVuIENhbnRvbmVzZS4NCg0KMS4gQ2FuJ3QgYmUgZGlzdGluZ3Vpc2hlZCBh dCB0aGUgc2NyaXB0IGxldmVsIGZyb20gTWFuZGFyaW4sDQoyLiBjYW4gYmUgYXMgZWFzaWx5IGRp c2Nlcm5lZCBhcyBlYXNpbHkgYXMgYW55IG90aGVyIGxhbmd1YWdlLiBJdCdzIGFzIGRpZmZlcmVu dCwgc2F5LCBhcyBkdXRjaCBpcyBmcm9tIEVuZ2xpc2guIFNvbWUgd29yZHMgbG9vayB0aGUgc2Ft ZSwgYnV0IGEgbWFuZGFyaW4gc3BlYWtlciBjb3VsZG4ndCByZWFkIGl0Lg0KDQpTbyB0aGUgc2l0 dWF0aW9uIGlzIG5vdCB0aGF0IGNsZWFyLiBBbmQgY2VydGFpbmx5IGluIG90aGVyIGNpcmN1bXN0 YW5jZXMgKGxpa2UgYXVkaW8pLCBpdCBpcyBtdWNoIGJldHRlciB0byBhY3R1YWxseSBob25vciB0 aGUgdXNlcidzIHJlcXVlc3QsIGFuZCBmYWxsIGJhY2sgbGlrZQ0KDQogMS4gIHl1ZS1IYW50LUhL DQogMi4gIHl1ZS1IYW50DQogMy4gIHl1ZQ0KIDQuICBlbg0KIDUuICAoZGVmYXVsdCwgd2hpY2gg Y291bGQgZXhwYW5kIHRvKQ0KDQogICAgKiAgIHpoLUhhbnQtSEsNCiAgICAqICAgemgtSGFudA0K ICAgICogICB6aA0KDQpUaGF0J3Mgd2h5IGlmIHdlIGxlYXZlIHRoaXMgdXAgdG8gdGhlIGFwcGxp Y2F0aW9uLCB3aGljaCBrbm93cyB3aGF0IGRvbWFpbiBpdCBpcyB3b3JraW5nIGluLCB3ZSdyZSBi ZXR0ZXIgb2ZmIHRoYW4gaWYgd2UgaGFyZCBjb2RlIGEgcmVsYXRpb25zaGlwIHRoYXQgc29tZXRp bWVzIHdvcmtzLCBidXQgcmVxdWlyZXMgY29kZSBjaGFuZ2VzIGFueXdheSwgYW5kIEkgdGhpbmsg bW9yZSBvZnRlbiBmYWlscy4NCg0KVGhpcyBzaXR1YXRpb24gaXMgdmVyeSBzaW1pbGFyIHRvIGFu b3RoZXIgY2FzZSB0aGF0IHdlIGhhdmUgYWxyZWFkeS4gV2UgY291bGQgaGF2ZSB1c2VkIGV4dGxh bmcgd2l0aCBnc3cgKFN3aXNzIEdlcm1hbikuIFdlIGNvdWxkIGhhdmUgc2FpZDogSG1tLCB0aGVy ZSB3YXMgbm8gd2F5IHRvIHRhZyBTd2lzcyBHZXJtYW4gYmVmb3JlLCBzbyB3ZSBtaWdodCBoYXZl IGVuZGVkIHVwIHdpdGggc3VjaCBjb250ZW50IHRhZ2dlZCBhcyAiZGUiIGluc3RlYWQuIEFuZCwg aG1tbSwgd2hlbiB0aGUgU3dpc3Mgd3JpdGUgR2VybWFuLCB0aGV5IHR5cGljYWxseSB1c2UgSGln aCBHZXJtYW4sIHNvIHRoZSB3cml0dGVuIGZvcm0gaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgKHdp dGggdGhlIGV4Y2VwdGlvbiBvZiBzaGFycC1zKS4gU28gbGV0J3MgbWFrZSB0aGUgdGFnIGJlICJk ZS1nc3ciIGluc3RlYWQuDQoNCkJ1dCB3ZSBkaWRuJ3QgYmFrZSB0aGlzIHJlbGF0aW9uc2hpcCBp bnRvIHRoZSBjb2RlczsgaW5zdGVhZCB3ZSBsZWF2ZSB0aGlzIHRvIHRoZSBhcHBsaWNhdGlvbiwg dG8gaGFuZGxlIGFwcHJvcHJpYXRlIHRvIHRoZSBkb21haW4uDQoNCk1hcmsNCg0KT24gMTAvMTIv MDcsIEFkZGlzb24gUGhpbGxpcHMgPCBhZGRpc29uQHlhaG9vLWluYy5jb208bWFpbHRvOmFkZGlz b25AeWFob28taW5jLmNvbT4+IHdyb3RlOg0KSm9obiBDb3dhbiB3cm90ZToNCj4NCj4gRXZlbiBp ZiB5b3UgZG9uJ3QgdGFrZSB0aGF0IHZpZXcgKGFuZCBJIGRvbid0KSwgaXQncyBpZGxlIHRvIGRl bnkNCj4gdGhhdCBhbG1vc3QgZXZlcnl0aGluZyB0ZXh0dWFsIHRhZ2dlZCAiemgiIG9yICJhciIg aXMgTWFuZGFyaW4gQ2hpbmVzZQ0KPiBvciBTdGFuZGFyZCBBcmFiaWMgcmVzcGVjdGl2ZWx5LCBh cyBhbiB1bmNvbnRyb3ZlcnNpYWwgY29uc2VxdWVuY2UNCj4gb2YgdGhlIGZhY3QgdGhhdCBhbG1v c3QgYWxsIHdyaXR0ZW4gZG9jdW1lbnRzIGluIENoaW5lc2Ugb3IgQXJhYmljDQo+ICphcmUqIE1h bmRhcmluIG9yIFN0YW5kYXJkIHJlc3BlY3RpdmVseS4NCj4NCg0KQWN0dWFsbHksIEkgZG9uJ3Qg a25vdyB0aGF0IEkgd291bGQgc2F5IHRoYXQsIGF0IGxlYXN0IGluIHRoZSBjYXNlIG9mDQpDaGlu ZXNlLg0KDQpJbiBmYWN0LCBmb3IgbW9zdCBDaGluZXNlIHdyaXR0ZW4gZG9jdW1lbnRzLCBJIHdv dWxkIHRlbmQgdG8gc2F5IHRoYXQgaXQNCmlzbid0IHBvc3NpYmxlIHRvIGRpc2Nlcm4gd2hpY2gg c3BlY2lmaWMgQ2hpbmVzZSBsYW5ndWFnZSB0aGV5IGFyZSBpbi4NCllvdSBjb3VsZCByZXByZXNl bnQgdGhhdCBhcyBiZWluZyAiaW4gTWFuZGFyaW4iLCBzaW5jZSB0aGF0IGlzIHRoZQ0Kc291cmNl IG9mIHRoZSB3cml0dGVuIGZvcm0sIGJ1dCBpbiBwcmFjdGljYWwgdGVybXMgdGhlcmUgaXMgbGl0 dGxlDQplbm91Z2ggZGlmZmVyZW5jZSBiZXR3ZWVuIENhbnRvbmVzZSBhbmQgTWFuZGFyaW4gYXQg dGhlIHdyaXR0ZW4gbGV2ZWwgdG8NCnJlYWxseSBrbm93LiBJbiBmYWN0LCBpdCBpcyBhIHZlcnkg dXNlZnVsIGZpY3Rpb24gdGhhdCB0aGVzZSBsYW5ndWFnZXMNCmFyZSAidGhlIHNhbWUiLg0KDQpU aGlzIGlzIG9uZSByZWFzb24gdGhhdCBJIHByZWZlciBteSB3b3JrYXJvdW5kIGZvciB0aGUgbG9v a3VwIGFsZ29yaXRobQ0KdXNpbmcgZXh0bGFuZ3MgdG8gTWFyaydzIHJlY2VudCBzdWdnZXN0aW9u IG9uIGxpc3Q6IGl0IHJlY29nbml6ZXMgdGhhdCwNCmZvciB3cml0dGVuIHJlc291cmNlcywgImdl bmVyaWMiIENoaW5lc2UgcGx1cyBzdWJ0YWdzIGlzIGEgYmV0dGVyDQpmYWxsYmFjayB0aGFuIHRo ZSBzZWNvbmQgbGFuZ3VhZ2UgaW4geW91ciBsYW5ndWFnZSBwcmlvcml0eSBsaXN0Lg0KDQpbW0Fz IGEgcmVtaW5kZXIgTWFyaydzIHN1Z2dlc3Rpb24gd2FzIHRvIG1ha2UgZmFsbGJhY2sgZm9yIHRo ZSBMUEwNCiJ6aC15dWUtSGFudC1ISztlbiIgdG8gYmU6DQoNCiAgemgteXVlLUhhbnQtSEsNCiAg emgteXVlLUhhbnQNCiAgemgteXVlDQogIGVuDQogIHpoLUhhbnQtSEsNCiAgemgtSGFudA0KICB6 aA0KICAoZGVmYXVsdCkNCg0KQW5kIG1pbmUgd2FzOg0KDQogIHpoLXl1ZS1IYW50LUhLDQogIHpo LXl1ZS1IYW50DQogIHpoLXl1ZQ0KICB6aC1IYW50LUhLDQogIHpoLUhhbnQNCiAgemgNCiAgZW4N CiAgKGRlZmF1bHQpDQoNCl1dDQoNCkFkZGlzb24NCg0KLS0NCkFkZGlzb24gUGhpbGxpcHMNCkds b2JhbGl6YXRpb24gQXJjaGl0ZWN0IC0tIFlhaG9vISBJbmMuDQpDaGFpciAtLSBXM0MgSW50ZXJu YXRpb25hbGl6YXRpb24gQ29yZSBXRw0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBhbiBhcmNo aXRlY3R1cmUuDQpJdCBpcyBub3QgYSBmZWF0dXJlLg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMdHJ1IG1haWxpbmcgbGlzdA0KTHRydUBpZXRm Lm9yZzxtYWlsdG86THRydUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCg0KDQotLQ0KTWFyaw0KDQoNCg0KLS0NCk1hcmsNCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AC6CD8ABNAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUgOSAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIg NSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1pbmdMaVUiOw0KCXBhbm9z ZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWxp Z2VudE1vbm87DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcMDAyN0xpSGVpIFByb1wwMDI3IjsNCglwYW5vc2UtMTowIDAgMCAwIDAg MCAwIDAgMCAwO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uZ21h aWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbF9xdW90ZTt9DQpzcGFuLnENCgl7bXNvLXN0 eWxlLW5hbWU6cTt9DQpzcGFuLmUNCgl7bXNvLXN0eWxlLW5hbWU6ZTt9DQpzcGFuLnNnDQoJe21z by1zdHlsZS1uYW1lOnNnO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KIC8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozMjY1OTE3MDI7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MjEzMDI4NDg7fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6Njg0NDgxMjIxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMDQ2NzU0NDA7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+DQo8 L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+SSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBkZWJhdGUgdGhhdCB3cml0 dGVuIENhbnRvbmVzZSBhbmQgd3JpdHRlbg0KTWFuZGFyaW4gbWF5IGJlIHF1aXRlIHVuaW50ZWxs aWdpYmxlOyBJIGRpZG7igJl0IGtub3cgdGhpcyBtdWNoIGRldGFpbCwgYnV0IEkNCmNlcnRhaW5s eSBkb27igJl0IGZpbmQgaXQgc3VycHJpc2luZy4gVGhlIHByb2JsZW0gaXMgdGhhdCDigJx6aOKA nSBjYW4gbGVnaXRpbWF0ZWx5DQpiZSBhcHBsaWVkIHRvIGVpdGhlci4gU28sIGl04oCZcyBub3Qg YSBtYXR0ZXIgb2Ygc2F5aW5nIHRoYXQgaXTigJlzIE9LIHRvIGZhbGxiYWNrDQpmcm9tIGEgcmVx dWVzdCB0byB6aC15dWUgdG8gTWFuZGFyaW4gcmVzb3VyY2VzLiBJdOKAmXMgYSBtYXR0ZXIgb2Yg aG93IHRvIGRlYWwNCndpdGggdGhlIHZhZ3VhcmllcyBvZiDigJx6aOKAnS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPlBldGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IE1hcmsgRGF2aXMNClttYWlsdG86bWFyay5kYXZpc0BpY3UtcHJv amVjdC5vcmddIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMTIsIDIwMDcgMTox NyBQTTxicj4NCjxiPlRvOjwvYj4gQWRkaXNvbiBQaGlsbGlwczxicj4NCjxiPkNjOjwvYj4gTFRS VSBXb3JraW5nIEdyb3VwOyBEb3VnIEV3ZWxsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHRy dV0gUmU6IEV4dGVuZGVkIGxhbmd1YWdlIHRhZ3MgKGxvbmcgcmVwbHkpPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+U29ycnkgZm9yIHRoZSBjb25mdXNpb24sIEkgZGlkDQptZWFuIHRoZSBxdWVyeSdz IGJlaW5nICZxdW90O3l1ZS1IYW50LUhLLCBlbiZxdW90Oy48YnI+DQo8YnI+DQpBbHNvLCBnb3Qg YSBub3RlIGZyb20gSm9obiBKZW5raW5zIGFib3V0IENhbnRvbmVzZTo8bzpwPjwvbzpwPjwvcD4N Cg0KPGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6MzAuMHB0Jz4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UaGUgZm9ybWVy IGlzIGxpa2UgaGF2aW5nDQpTcGFuaWFyZHMgcmVhZCBhbmQgd3JpdGUgRnJlbmNoIGJ1dCBwcm9u b3VuY2UgaXQgYXMgaWYgaXQgd2VyZSBTcGFuaXNoLiAmbmJzcDtBDQpGcmVuY2htYW4gd291bGRu J3QgdW5kZXJzdGFuZCBpdCBpZiBpdCB0aGV5IGhlYXJkIGl0IGV2ZW4gdGhvdWdoIGl0J3MgdGhl IHNhbWUNCndvcmRzIGFuZCBncmFtbWFyLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPlRoZSBsYXR0ZXIgaXMgdmVyeSBkaWZmZXJlbnQNCmFuZCwgYXMg TGVlIHNheXMsIGxhcmdlbHkgaW5jb21wcmVoZW5zaWJsZSB0byBhIE1hbmRhcmluIHNwZWFrZXIu ICZuYnNwO05vdA0KZW50aXJlbHksIGFzIHRoZXJlJ3MgYSBsb3Qgb2Ygb3ZlcmxhcCBiZXR3ZWVu IHRoZSB0d28gbGV4aWNhbGx5LCBidXQgZW5vdWdoDQpjb21tb24gd29yZHMgYXJlIGRpZmZlcmVu dCBhcyB0byB0aHJvdyB0aGUgcmVhZGVyIG9mZi4gJm5ic3A7SSd2ZSBiZWVuIGNhdWdodCBhDQpj b3VwbGUgb2YgdGltZXMgbm90IGJlaW5nIGFibGUgdG8gbWFrZSBvdXQgYWRzIGluIHRoZSBIb25n IEtvbmcgdW5kZXJncm91bmQNCnVudGlsIEkgcmVhbGl6ZWQgdGhhdCB0aGV5IHdlcmUgaW4gQ2Fu dG9uZXNlLCBub3Qgc3RhbmRhcmQgd3JpdHRlbiBDaGluZXNlLg0KJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UaGUgZXhhbXBsZSBvZiBFbmdsaXNoIGFu ZA0KRHV0Y2ggaXMgZ29vZCwgaW4gdGhhdCBlbm91Z2ggd29yZHMgYXJlIGNsb3NlIGVub3VnaCB5 b3UgY2FuIGdldCBhIHZhZ3VlIHNlbnNlDQpvZiB3aGF0J3MgYmVpbmcgc2FpZCwgYnV0IHlvdSBj YW4ndCByZWFsbHkgcmVhZCBpdC4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz5FLmcuLCB0aGUgRW5nbGlzaCBzZW50ZW5jZSwNCiZxdW90O1RoYW5rIHlv dTsgdGhhdCdzIGEgZ29vZCBib29rLiZxdW90OyBpczo8L3NwYW4+PG86cD48L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuisneisnTwvc3Bhbj48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQnPjsgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5Og0KIk1TIEdvdGhpYyInPumCozwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiTVMgR290aGljIic+5pys5pu45b6I 5aW9PC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiTVMg R290aGljIic+44CCPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiInTGlIZWkgUHJvJyIsInNlcmlmIic+c3RhbmRhcmQNCndyaXR0ZW4gQ2hpbmVz ZSwgYnV0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiTVMgR290aGljIic+5ZSU6KmyPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEx LjVwdCc+IDsgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Og0KTWluZ0xpVSc+5Zew5pys5pu45aW95aW95Zq5PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7jgII8L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IidMaUhlaSBQcm8nIiwic2VyaWYi Jz5pbg0KQ2FudG9uZXNlLiBUaGUgTWFuZGFyaW4gc3BlYWtlciBjb3VsZCBmaWd1cmUgb3V0IHRo YXQgaXQncyBzb21ldGhpbmcgYWJvdXQgZ29vZA0KYm9va3MsIGJ1dCB0aGF0J3MgaXQuIFRoZXkg d291bGRuJ3QgaGF2ZSBhIGNsdWUgYXMgdG8gdGhlIG1lYW5pbmcgb2YgPC9zcGFuPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiTVMgR290aGljIic+5ZSUPC9zcGFu PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiVGFsaWdlbnRNb25v Iiwic2VyaWYiJz4sJm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTpNaW5nTGlVJz7ll7A8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEw LjVwdDtmb250LWZhbWlseToiVGFsaWdlbnRNb25vIiwic2VyaWYiJz4sIG9yJm5ic3A7PC9zcGFu PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpNaW5nTGlVJz7lmrk8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjVwdDtmb250LWZhbWlseToiVGFsaWdl bnRNb25vIiwic2VyaWYiJz4sIGFuZCB0aGUgd2F5IHRoZSBmYW1pbGlhcg0KY2hhcmFjdGVycyZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiTVMg R290aGljIic+6KmyPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseToiVGFsaWdlbnRNb25vIiwic2VyaWYiJz4gYW5kJm5ic3A7PC9zcGFuPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiTVMgR290aGljIic+5aW9PC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiVGFsaWdlbnRNb25vIiwi c2VyaWYiJz4gYXJlIGJlaW5nIHVzZWQNCndvdWxkIHNlZW0gb2RkIGF0IGJlc3QuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPkFuZCwNCkZXSVcsIHdyaXR0ZW4gQ2FudG9uZXNlIGlzIHN0aWxsIHNvbWV0aGluZyBv ZiBhIGF2aXMgcmFyYSwgYnV0IHRoZXJlJ3MgYmVlbiBhDQptaW5pLWJvb20gaW4gaXQgc2luY2Ug SEsgd2VudCBiYWNrIHRvIHRoZSBtYWlubGFuZC4gJm5ic3A7V2hlbiBJIGxpdmVkIHRoZXJlDQp0 d2VudHktZml2ZSB5ZWFycyBhZ28sIGl0IHdhcyB1bmhlYXJkIG9mIGV4Y2VwdA0KaW4mbmJzcDtw ZWRhZ29naWNhbCZuYnNwO21hdGVyaWFscywgbW92aWUgc2NyaXB0cywgYW5kIGdyYWZmaXRpLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+TWFyazxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBj bGFzcz1nbWFpbHF1b3RlPk9uIDEwLzEyLzA3LCA8Yj5NYXJrIERhdmlzPC9iPiAmbHQ7PGENCmhy ZWY9Im1haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZyI+IG1hcmsuZGF2aXNAaWN1LXBy b2plY3Qub3JnPC9hPiZndDsNCndyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+VGhpcyBpcyBwcmVjaXNl bHkgd2h5IEkgdGhpbmsNCnRoaXMgc2hvdWxkIG5vdCBiZSBiYWtlZCBpbnRvIGV4dGxhbmcuIEZv ciBzb21lIGFwcGxpY2F0aW9ucyBpdCBtaWdodCBiZSBiZXR0ZXINCm9mZiB0byBmYWxsYmFjayAm cXVvdDt5dWUsIGVuJnF1b3Q7IGFzIDxvOnA+PC9vOnA+PC9wPg0KDQo8b2wgc3RhcnQ9MSB0eXBl PTE+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwxIGxldmVsMSBsZm8x Jz55dWUtSGFudC1ISzxvOnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAg ICAgbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEnPnl1ZS1IYW50PG86cD48L286cD48L2xpPg0KIDxs aSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KICAgICBtc28tbGlzdDpsMSBsZXZlbDEgbGZvMSc+eXVlPG86 cD48L286cD48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KICAgICBtc28tbGlzdDpsMSBs ZXZlbDEgbGZvMSc+emgtSGFudC1ISzxvOnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEnPnpoLUhhbnQ8bzpwPjwvbzpwPjwv bGk+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwxIGxldmVsMSBsZm8x Jz56aDxvOnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzEnPmVuPG86cD48L286cD48L2xpPg0KPC9vbD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxicj4NCkJ1dCB0aGVyZSBpcyBhIGJpZyBtYXliZSBoZXJlLiBBY2NvcmRpbmcg dG8gTGVlIENvbGxpbnMsIHdobyBpcyB3ZWxsIHZlcnNlZCBpbg0KdGhpcyBhcmVhLCB0aGVyZSBh cmUgdHdvIGNhc2VzOjxzcGFuIGNsYXNzPXE+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6MzAuMHB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjEuIFN0YW5kYXJkIHdyaXR0ZW4gQ2hpbmVzZSByZWFkIGFzIENhbnRvbmVzZS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0OjMwLjBwdCc+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4yLiBXcml0dGVuIENhbnRvbmVzZS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXYgc3R5bGU9J21hcmdpbi1sZWZ0OjMwLjBwdCc+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxk aXYgc3R5bGU9J21hcmdpbi1sZWZ0OjMwLjBwdCc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4xLiBD YW4ndCBiZSBkaXN0aW5ndWlzaGVkIGF0IHRoZSBzY3JpcHQgbGV2ZWwgZnJvbSBNYW5kYXJpbiwN Cjxicj4NCjIuIGNhbiBiZSBhcyBlYXNpbHkgZGlzY2VybmVkIGFzIGVhc2lseSBhcyBhbnkgb3Ro ZXIgbGFuZ3VhZ2UuIEl0J3MgYXMNCmRpZmZlcmVudCwgc2F5LCBhcyBkdXRjaCBpcyBmcm9tIEVu Z2xpc2guIFNvbWUgd29yZHMgbG9vayB0aGUgc2FtZSwgYnV0IGENCm1hbmRhcmluIHNwZWFrZXIg Y291bGRuJ3QgcmVhZCBpdC4gPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+DQpTbyB0aGUgc2l0dWF0 aW9uIGlzIG5vdCB0aGF0IGNsZWFyLiBBbmQgY2VydGFpbmx5IGluIG90aGVyIGNpcmN1bXN0YW5j ZXMgKGxpa2UNCmF1ZGlvKSwgaXQgaXMgbXVjaCBiZXR0ZXIgdG8gYWN0dWFsbHkgaG9ub3IgdGhl IHVzZXIncyByZXF1ZXN0LCBhbmQgZmFsbCBiYWNrDQpsaWtlIDxvOnA+PC9vOnA+PC9wPg0KDQo8 b2wgc3RhcnQ9MSB0eXBlPTE+DQogPGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0 OmwwIGxldmVsMSBsZm8yJz55dWUtSGFudC1ISzxvOnA+PC9vOnA+PC9saT4NCiA8bGkgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCiAgICAgbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPnl1ZS1IYW50PG86cD48 L286cD48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KICAgICBtc28tbGlzdDpsMCBsZXZl bDEgbGZvMic+eXVlPG86cD48L286cD48L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KICAg ICBtc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+ZW48bzpwPjwvbzpwPjwvbGk+DQogPGxpIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQogICAgIG1zby1saXN0OmwwIGxldmVsMSBsZm8yJz4oZGVmYXVsdCwgd2hp Y2ggY291bGQgZXhwYW5kIHRvKTxvOnA+PC9vOnA+PC9saT4NCjwvb2w+DQoNCjxvbCBzdGFydD01 IHR5cGU9MT4NCiA8b2wgc3RhcnQ9MSB0eXBlPTE+DQogIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDoNCiAgICAg IGF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzInPnpoLUhhbnQtSEs8bzpwPjwvbzpwPjwvbGk+ DQogIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDoNCiAgICAgIGF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIn PnpoLUhhbnQ8bzpwPjwvbzpwPjwvbGk+DQogIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDoNCiAgICAgIGF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzInPnpoPG86cD48L286cD48L2xpPg0KIDwvb2w+DQo8L29s Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KVGhhdCdzIHdoeSBpZiB3ZSBsZWF2ZSB0aGlz IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiwgd2hpY2gga25vd3Mgd2hhdCBkb21haW4gaXQNCmlzIHdv cmtpbmcgaW4sIHdlJ3JlIGJldHRlciBvZmYgdGhhbiBpZiB3ZSBoYXJkIGNvZGUgYSByZWxhdGlv bnNoaXAgdGhhdA0Kc29tZXRpbWVzIHdvcmtzLCBidXQgcmVxdWlyZXMgY29kZSBjaGFuZ2VzIGFu eXdheSwgYW5kIEkgdGhpbmsgbW9yZSBvZnRlbg0KZmFpbHMuIDxicj4NCjxicj4NClRoaXMgc2l0 dWF0aW9uIGlzIHZlcnkgc2ltaWxhciB0byBhbm90aGVyIGNhc2UgdGhhdCB3ZSBoYXZlIGFscmVh ZHkuIFdlIGNvdWxkDQpoYXZlIHVzZWQgZXh0bGFuZyB3aXRoIGdzdyAoU3dpc3MgR2VybWFuKS4g V2UgY291bGQgaGF2ZSBzYWlkOiBIbW0sIHRoZXJlIHdhcw0Kbm8gd2F5IHRvIHRhZyBTd2lzcyBH ZXJtYW4gYmVmb3JlLCBzbyB3ZSBtaWdodCBoYXZlIGVuZGVkIHVwIHdpdGggc3VjaCBjb250ZW50 DQp0YWdnZWQgYXMgJnF1b3Q7ZGUmcXVvdDsgaW5zdGVhZC4gQW5kLCBobW1tLCB3aGVuIHRoZSBT d2lzcyB3cml0ZSBHZXJtYW4sIHRoZXkNCnR5cGljYWxseSB1c2UgSGlnaCBHZXJtYW4sIHNvIHRo ZSB3cml0dGVuIGZvcm0gaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgKHdpdGgNCnRoZSBleGNlcHRp b24gb2Ygc2hhcnAtcykuIFNvIGxldCdzIG1ha2UgdGhlIHRhZyBiZSAmcXVvdDtkZS1nc3cmcXVv dDsgaW5zdGVhZC4NCjxicj4NCjxicj4NCkJ1dCB3ZSBkaWRuJ3QgYmFrZSB0aGlzIHJlbGF0aW9u c2hpcCBpbnRvIHRoZSBjb2RlczsgaW5zdGVhZCB3ZSBsZWF2ZSB0aGlzIHRvDQp0aGUgYXBwbGlj YXRpb24sIHRvIGhhbmRsZSBhcHByb3ByaWF0ZSB0byB0aGUgZG9tYWluLjxicj4NCjxicj4NCk1h cms8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gY2xhc3M9ZT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1nbWFpbHF1 b3RlPk9uIDEwLzEyLzA3LCA8Yj5BZGRpc29uIFBoaWxsaXBzPC9iPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzphZGRpc29uQHlhaG9vLWluYy5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmFkZGlzb25AeWFo b28taW5jLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPkpvaG4gQ293YW4gd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgRXZlbiBp ZiB5b3UgZG9uJ3QgdGFrZSB0aGF0IHZpZXcgKGFuZCBJIGRvbid0KSwgaXQncyBpZGxlIHRvIGRl bnk8YnI+DQomZ3Q7IHRoYXQgYWxtb3N0IGV2ZXJ5dGhpbmcgdGV4dHVhbCB0YWdnZWQgJnF1b3Q7 emgmcXVvdDsgb3IgJnF1b3Q7YXImcXVvdDsgaXMNCk1hbmRhcmluIENoaW5lc2U8YnI+DQomZ3Q7 IG9yIFN0YW5kYXJkIEFyYWJpYyByZXNwZWN0aXZlbHksIGFzIGFuIHVuY29udHJvdmVyc2lhbCBj b25zZXF1ZW5jZSA8YnI+DQomZ3Q7IG9mIHRoZSBmYWN0IHRoYXQgYWxtb3N0IGFsbCB3cml0dGVu IGRvY3VtZW50cyBpbiBDaGluZXNlIG9yIEFyYWJpYzxicj4NCiZndDsgKmFyZSogTWFuZGFyaW4g b3IgU3RhbmRhcmQgcmVzcGVjdGl2ZWx5Ljxicj4NCiZndDs8YnI+DQo8YnI+DQpBY3R1YWxseSwg SSBkb24ndCBrbm93IHRoYXQgSSB3b3VsZCBzYXkgdGhhdCwgYXQgbGVhc3QgaW4gdGhlIGNhc2Ug b2Y8YnI+DQpDaGluZXNlLiA8YnI+DQo8YnI+DQpJbiBmYWN0LCBmb3IgbW9zdCBDaGluZXNlIHdy aXR0ZW4gZG9jdW1lbnRzLCBJIHdvdWxkIHRlbmQgdG8gc2F5IHRoYXQgaXQ8YnI+DQppc24ndCBw b3NzaWJsZSB0byBkaXNjZXJuIHdoaWNoIHNwZWNpZmljIENoaW5lc2UgbGFuZ3VhZ2UgdGhleSBh cmUgaW4uPGJyPg0KWW91IGNvdWxkIHJlcHJlc2VudCB0aGF0IGFzIGJlaW5nICZxdW90O2luIE1h bmRhcmluJnF1b3Q7LCBzaW5jZSB0aGF0IGlzIHRoZSA8YnI+DQpzb3VyY2Ugb2YgdGhlIHdyaXR0 ZW4gZm9ybSwgYnV0IGluIHByYWN0aWNhbCB0ZXJtcyB0aGVyZSBpcyBsaXR0bGU8YnI+DQplbm91 Z2ggZGlmZmVyZW5jZSBiZXR3ZWVuIENhbnRvbmVzZSBhbmQgTWFuZGFyaW4gYXQgdGhlIHdyaXR0 ZW4gbGV2ZWwgdG88YnI+DQpyZWFsbHkga25vdy4gSW4gZmFjdCwgaXQgaXMgYSB2ZXJ5IHVzZWZ1 bCBmaWN0aW9uIHRoYXQgdGhlc2UgbGFuZ3VhZ2VzIDxicj4NCmFyZSAmcXVvdDt0aGUgc2FtZSZx dW90Oy48YnI+DQo8YnI+DQpUaGlzIGlzIG9uZSByZWFzb24gdGhhdCBJIHByZWZlciBteSB3b3Jr YXJvdW5kIGZvciB0aGUgbG9va3VwIGFsZ29yaXRobTxicj4NCnVzaW5nIGV4dGxhbmdzIHRvIE1h cmsncyByZWNlbnQgc3VnZ2VzdGlvbiBvbiBsaXN0OiBpdCByZWNvZ25pemVzIHRoYXQsPGJyPg0K Zm9yIHdyaXR0ZW4gcmVzb3VyY2VzLCAmcXVvdDtnZW5lcmljJnF1b3Q7IENoaW5lc2UgcGx1cyBz dWJ0YWdzIGlzIGEgYmV0dGVyIDxicj4NCmZhbGxiYWNrIHRoYW4gdGhlIHNlY29uZCBsYW5ndWFn ZSBpbiB5b3VyIGxhbmd1YWdlIHByaW9yaXR5IGxpc3QuPGJyPg0KPGJyPg0KW1tBcyBhIHJlbWlu ZGVyIE1hcmsncyBzdWdnZXN0aW9uIHdhcyB0byBtYWtlIGZhbGxiYWNrIGZvciB0aGUgTFBMPGJy Pg0KJnF1b3Q7emgteXVlLUhhbnQtSEs7ZW4mcXVvdDsgdG8gYmU6PGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7emgteXVlLUhhbnQtSEs8YnI+DQombmJzcDsmbmJzcDt6aC15dWUtSGFudCA8YnI+DQom bmJzcDsmbmJzcDt6aC15dWU8YnI+DQombmJzcDsmbmJzcDtlbjxicj4NCiZuYnNwOyZuYnNwO3po LUhhbnQtSEs8YnI+DQombmJzcDsmbmJzcDt6aC1IYW50PGJyPg0KJm5ic3A7Jm5ic3A7emg8YnI+ DQombmJzcDsmbmJzcDsoZGVmYXVsdCk8YnI+DQo8YnI+DQpBbmQgbWluZSB3YXM6PGJyPg0KPGJy Pg0KJm5ic3A7Jm5ic3A7emgteXVlLUhhbnQtSEs8YnI+DQombmJzcDsmbmJzcDt6aC15dWUtSGFu dDxicj4NCiZuYnNwOyZuYnNwO3poLXl1ZTxicj4NCiZuYnNwOyZuYnNwO3poLUhhbnQtSEs8YnI+ DQombmJzcDsmbmJzcDt6aC1IYW50PGJyPg0KJm5ic3A7Jm5ic3A7emg8YnI+DQombmJzcDsmbmJz cDtlbjxicj4NCiZuYnNwOyZuYnNwOyhkZWZhdWx0KTxicj4NCjxicj4NCl1dPGJyPg0KPGJyPg0K QWRkaXNvbjxicj4NCjxicj4NCi0tPGJyPg0KQWRkaXNvbiBQaGlsbGlwczxicj4NCkdsb2JhbGl6 YXRpb24gQXJjaGl0ZWN0IC0tIFlhaG9vISBJbmMuPGJyPg0KQ2hhaXIgLS0gVzNDIEludGVybmF0 aW9uYWxpemF0aW9uIENvcmUgV0c8YnI+DQo8YnI+DQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBh biBhcmNoaXRlY3R1cmUuPGJyPg0KSXQgaXMgbm90IGEgZmVhdHVyZS48YnI+DQo8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+DQpM dHJ1IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+THRydUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnIgY2xlYXI9YWxsPg0KPG86cD48 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+LS0gPGJyPg0KPHNwYW4g Y2xhc3M9c2c+TWFyayA8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGJyPg0KPGJyIGNsZWFyPWFsbD4NCjxicj4NCi0tIDxicj4NCk1hcmsgPG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AC6CD8ABNAEXMSGC117re_-- --===============0047960568== 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 --===============0047960568==-- From ltru-bounces@ietf.org Fri Oct 12 19:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTWq-0004lV-UQ; Fri, 12 Oct 2007 19:02:48 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgTWp-0004lN-Cb for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 19:02:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgTWp-0004lE-1b for ltru@ietf.org; Fri, 12 Oct 2007 19:02:47 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgTWo-0002HP-MB for ltru@ietf.org; Fri, 12 Oct 2007 19:02:46 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IgTWo-0004Cu-Ay; Fri, 12 Oct 2007 19:02:46 -0400 Date: Fri, 12 Oct 2007 19:02:46 -0400 To: Peter Constable Subject: Re: [Ltru] Re: Extended language tags (long reply) Message-ID: <20071012230246.GD4791@mercury.ccil.org> References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> <30b660a20710121317t3799c8e4xb4e974237483c44@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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 Peter Constable scripsit: > I don't think there's debate that written Cantonese and written > Mandarin may be quite unintelligible; I didn't know this much detail, > but I certainly don't find it surprising. The problem is that 'zh' > can legitimately be applied to either. So, it's not a matter of > saying that it's OK to fallback from a request to zh-yue to Mandarin > resources. It's a matter of how to deal with the vaguaries of 'zh'. Apparently, however, almost all publicly accessible documents that are tagged "zh" are in Mandarin. The issue is whether this fact has special significance. I think these three cases represent the different situations that may exist: 1) Cantonese. Lack of specifically tagged resources will cause Mandarin ones to be provided (de facto); this is probably okay, because people who can read Cantonese can (for the most part) read Mandarin. 2) Pular. Lack of specifically tagged resources might cause resources in any Fulah language to be produced. This is probably harmless. 3) Arbereshe Albanian. Lack of resources specifically tagged for that language will probably cause the production of resources in Standard Albanian. However, the most useful fallback in practice is probably Italian, which is entirely outside the Albanian macrolanguage. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Please leave your values Check your assumptions. In fact, at the front desk. check your assumptions at the door. --sign in Paris hotel --Cordelia Vorkosigan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 19:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgU3G-0004w1-90; Fri, 12 Oct 2007 19:36:18 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgU3E-0004vs-NA for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 19:36:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgU3E-0004vj-CX for ltru@ietf.org; Fri, 12 Oct 2007 19:36:16 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgU3E-0003Ob-0G for ltru@ietf.org; Fri, 12 Oct 2007 19:36:16 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.177.2; Fri, 12 Oct 2007 16:36:15 -0700 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.39]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Fri, 12 Oct 2007 16:36:15 -0700 From: Shawn Steele CC: LTRU Working Group Date: Fri, 12 Oct 2007 16:36:12 -0700 Thread-Topic: language tag parsing Thread-Index: AcgNJBNAidSOZWLmTBi214KwRqIvVAAAVI3g Message-ID: References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> <470F9225.6030108@yahoo-inc.com> <30b660a20710120959p7581ddf5y9439f23a877190ca@mail.gmail.com> <30b660a20710121317t3799c8e4xb4e974237483c44@mail.gmail.com> <20071012230246.GD4791@mercury.ccil.org> In-Reply-To: <20071012230246.GD4791@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] language tag parsing X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think that fallback for certain languages to a macro language is less int= eresting in some cases than others, but I don't see harm in having the extr= a tag if the application knows when that is interesting and when it isn't. I think its clear that some applications have different look up / matching/= filtering /whatever behavior requirements, so I don't think RFC 4647 can s= ay "This is the one way that works." As an example I think most of the peo= ple on this list have mentioned implementations that currently do more that= what RFC 4646/4647 specify. I think that a successor to RFC 4647 should suggest that applications be a = bit smarter. Its reasonably trivial to parse the proposed extlang tag and = discover that they have a "zh" macro language, "cmn" language, "hant" scrip= t, "HK" regional dialect, etc. >From there it is simple for the application to note that "zh-HK" or "cmn-Ha= nt" are possible matches. The application could also go farther and note t= hat with zh-yue-Hant-HK, perhaps zh-HK isn't a good match because the appli= cation believes that most "zh" data is Mandarin. Or it could figure that's= OK too because many Cantonese speakers also understand Mandarin. I think that RFC 4647 should provide matching guidelines rather than "MUST = trim from the right". For extra information, like "Breton users might spea= k French" or "most zh data is Mandarin", the application can either investi= gate its own desired behavior, or perhaps this could be included in the reg= istry. - Shawn _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Oct 12 23:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgY5L-00063Q-KN; Fri, 12 Oct 2007 23:54:43 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgY5J-00062P-QB for ltru-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 23:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgY5J-0005wz-Ge for ltru@ietf.org; Fri, 12 Oct 2007 23:54:41 -0400 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgY59-00039e-Bv for ltru@ietf.org; Fri, 12 Oct 2007 23:54:37 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta15.adelphia.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20071013035400.UHPG7709.mta15.adelphia.net@DGBP7M81>; Fri, 12 Oct 2007 23:54:00 -0400 Message-ID: <010c01c80d4c$b0ba8af0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <009401c80ca0$5176a5d0$6401a8c0@DGBP7M81> <20071012141502.GM2710@mercury.ccil.org> Subject: Re: [Ltru] Re: Extended language tags (long reply) Date: Fri, 12 Oct 2007 20:54: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> And so once again, the concept of "macrolanguage" is represented not >> as ISO 639-3 intended it, as a family of languages that are sometimes >> considered a single language for some purposes, but rather as a >> specific, dominant language within that family. > > Even if you don't take that view (and I don't), it's idle to deny that > almost everything textual tagged "zh" or "ar" is Mandarin Chinese or > Standard Arabic respectively, as an uncontroversial consequence of the > fact that almost all written documents in Chinese or Arabic *are* > Mandarin or Standard respectively. Yes, but it is a consequence of that fact, not a deliberate tagging convention. People are not making a conscious decision to restrict use of "zh" to Mandarin and resort to "zh-specific" for other Chinese languages, on those rare occasions that they occur. This is why I'm not on board with the oft-stated premise that "zh-yue" will cause an intentional fallback to Mandarin. If it causes a fallback to "zh", then it may well retrieve Mandarin, since (as you say) almost all written documents in Chinese are Mandarin. But that isn't by design. -- 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 13 00:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgYaF-0008Qa-JX; Sat, 13 Oct 2007 00:26:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IgYaE-0008QP-HC for ltru-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 00:26:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgYaE-0008Ft-5N for ltru@ietf.org; Sat, 13 Oct 2007 00:26:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgYZo-0001pE-Vq for ltru@ietf.org; Sat, 13 Oct 2007 00:26: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 l9D4Q94J015427 for ; Sat, 13 Oct 2007 13:26:09 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4564_6c56001a_7944_11dc_954b_0014221fa3c9; Sat, 13 Oct 2007 13:26:09 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51463) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 13 Oct 2007 13:22:42 +0900 Message-Id: <6.0.0.20.2.20071013131532.099dc510@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 13 Oct 2007 13:17:07 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Matching Text In-Reply-To: <00b201c80ca2$e6082d70$6401a8c0@DGBP7M81> References: <00b201c80ca2$e6082d70$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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 16:38 07/10/12, Doug Ewell wrote: >Mark Davis wrote: > >> We've been talking about two different models for dealing with macrolanguages: extlang and no-extlang. In our telephone conversations, a third has come up: partial-extlang. >> >> The partial-extlang model is where we only make X a secondary language for Y when it can reliably be assumed that someone who understands X will also understand Y. That would be the case if all of the microlanguages of Y are mutually intelligible, or if Y is generally identified with a "prestige" variant. With this model we wouldn't make all the microlanguages be secondary, just certain ones like those having ar and zh as macrolanguages. An example might be zh-yue. > >Would we have to make this decision on a case-by-case basis for each of several hundred encompassed languages? I think if we have to do this for each encompased language (e.g. zh-yue it is, but min, not zh-min, or some such), then that will be quite a bit of work. If we can restrict it to be done once per macrolanguage, I think the overhead would be very manageable. Which one seems more appropriate? 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 15 02:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhJZO-0006z5-PP; Mon, 15 Oct 2007 02:36:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IhJZN-0006w6-CT for ltru-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 02:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhJYF-00056N-TV for ltru@lists.ietf.org; Mon, 15 Oct 2007 02:35:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhJYA-0003Wl-Tu for ltru@lists.ietf.org; Mon, 15 Oct 2007 02:35:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IhJXe-0002Rs-Ca for ltru@lists.ietf.org; Mon, 15 Oct 2007 06:35:06 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Oct 2007 06:35:06 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Oct 2007 06:35:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Mon, 15 Oct 2007 08:32:16 +0200 Lines: 15 Message-ID: References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com><20071011130656.GD2710@mercury.ccil.org> <006801c80c2d$bb378a20$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > More succinctly: some view "macrolanguage" as being effectively > equivalent to some dominant or (likely) mutually intelligible > member of the group, while others view "macrolanguage" as being > simply an abstraction, not corresponding to any specific member > of the group. Thanks to all for your explanations of "prestige variant" and the definition of "microlanguage". =20 Frank P.S. to Mark, please post an URL to your paper if it's published. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 15 16:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWpj-0002UY-1M; Mon, 15 Oct 2007 16:46:39 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IhWph-0002Li-7F for ltru-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 16:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWpf-0002G6-R8 for ltru@ietf.org; Mon, 15 Oct 2007 16:46:35 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhWpZ-0003Mw-LI for ltru@ietf.org; Mon, 15 Oct 2007 16:46:35 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 107BF240828; Mon, 15 Oct 2007 21:45:57 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 1E8C01579EF; Mon, 15 Oct 2007 22:39:40 +0200 (CEST) Date: Mon, 15 Oct 2007 22:39:41 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20071015203941.GA8698@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] The funny language tag app. of the day X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Does anyone know an implementation of this standards track RFC? G. Zorn Request for Comments: 2484 Microsoft Corporation Category: Standards Track January 1999 PPP LCP Internationalization Configuration Option 1. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5]. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Oct 15 22:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhbwA-0007ba-0y; Mon, 15 Oct 2007 22:13:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ihbw7-0007az-LX for ltru-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 22:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihbw6-0007ap-IT for ltru@lists.ietf.org; Mon, 15 Oct 2007 22:13:34 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihbw0-0006jg-CB for ltru@lists.ietf.org; Mon, 15 Oct 2007 22:13:34 -0400 Received: by nz-out-0506.google.com with SMTP id i28so1072358nzi for ; Mon, 15 Oct 2007 19:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=7vjp2JiH+5lwy9o9mWbuh+QWwfVYtIYQZvkm7rWfGWQ=; b=GjxQZsAuApFHsHCx9aoiWD+s/9mxqF2QA28Omkr0EWUTmLYwV96I1FfwV3dMfklpzY1v3cA6XIgzzBHYWsil5lgvxHi5zZnmXhZbwWRq5gZwAcpy0L2knqXxqgZuvQVb5HEG/DYSUN0KvKF2sSwDXhdkzTAz8QPybC876F+5SKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=PwyzvKm4VmuFZ0y6m+FaKo2lBWzkumsv/xv54xpBwwRFg4pDXYtzJVCXts6HQXcaTewHl5CbL1oM01DGDP2t2l1SeR9L1Ahx6sElP05hGPOhp9sHTdFVh0Gl0NFB52t9Gl29kbOrJmoe4/jC8BjIBQNKah9/+w/MiyXbYDCMN2E= Received: by 10.114.168.1 with SMTP id q1mr7771782wae.1192500775200; Mon, 15 Oct 2007 19:12:55 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Mon, 15 Oct 2007 19:12:55 -0700 (PDT) Message-ID: <30b660a20710151912i3f6a346ctf4b67767af6142ea@mail.gmail.com> Date: Mon, 15 Oct 2007 19:12:55 -0700 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: Matching Text In-Reply-To: MIME-Version: 1.0 References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011130656.GD2710@mercury.ccil.org> <006801c80c2d$bb378a20$6801a8c0@oemcomputer> X-Google-Sender-Auth: 0275b99e1a82b3b3 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="===============1550517809==" Errors-To: ltru-bounces@ietf.org --===============1550517809== Content-Type: multipart/alternative; boundary="----=_Part_33932_2188285.1192500775185" ------=_Part_33932_2188285.1192500775185 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline It's on my homepage, http://macchiato.com/. However, it's a presentation, not a paper, so it is only a sketch of what I will actually discuss. Mark On 10/14/07, Frank Ellermann wrote: > > Randy Presuhn wrote: > > > More succinctly: some view "macrolanguage" as being effectively > > equivalent to some dominant or (likely) mutually intelligible > > member of the group, while others view "macrolanguage" as being > > simply an abstraction, not corresponding to any specific member > > of the group. > > Thanks to all for your explanations of "prestige variant" and the > definition of "microlanguage". > > Frank > > P.S. to Mark, please post an URL to your paper if it's published. > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_33932_2188285.1192500775185 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline It's on my homepage, http://macchiato.com/. However, it's a presentation, not a paper, so it is only a sketch of what I will actually discuss.

Mark

On 10/14/07, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
Randy Presuhn wrote:

> More succinctly: some view "macrolanguage" as being effectively
> equivalent to some dominant or (likely) mutually intelligible
> member of the group, while others view "macrolanguage" as being
> simply an abstraction, not corresponding to any specific member
> of the group.

Thanks to all for your explanations of "prestige variant" and the
definition of "microlanguage".

Frank

P.S. to Mark, please post an URL to your paper if it's published.




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



--
Mark ------=_Part_33932_2188285.1192500775185-- --===============1550517809== 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 --===============1550517809==-- From ltru-bounces@ietf.org Tue Oct 16 22:51:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihyyv-0001Zr-Iu; Tue, 16 Oct 2007 22:50:02 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ihyyt-0001Uy-Fo for ltru-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 22:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihyys-0001Gt-TG for ltru@ietf.org; Tue, 16 Oct 2007 22:49:58 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihyyf-0002zE-9z for ltru@ietf.org; Tue, 16 Oct 2007 22:49:53 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071017024924.EYMZ2217.mta10.adelphia.net@DGBP7M81>; Tue, 16 Oct 2007 22:49:24 -0400 Message-ID: <002101c81068$53b6a0e0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 16 Oct 2007 19:49:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [ot] he/iw reversed (was: Re: Matching Text) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > It's on my homepage, http://macchiato.com/. However, it's a > presentation, not a paper, so it is only a sketch of what I will > actually discuss. I wish I could go. I wish I wish I wish. Just out of curiosity, can you explain the comment on frame 9: "he/iw reversed: compatibility" I think I know what it means, but I hope I'm wrong. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 NEW URL --> http://home.roadrunner.com/~dewell <-- NEW URL 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 16 23:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhzAQ-0003np-LF; Tue, 16 Oct 2007 23:01:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IhzAP-0003mG-2l for ltru-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 23:01:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhzAO-0003m1-7I for ltru@ietf.org; Tue, 16 Oct 2007 23:01:52 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhzAN-0004As-V6 for ltru@ietf.org; Tue, 16 Oct 2007 23:01:52 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IhzAN-00008Q-LV; Tue, 16 Oct 2007 23:01:51 -0400 Date: Tue, 16 Oct 2007 23:01:51 -0400 To: Doug Ewell Subject: Re: [Ltru] [ot] he/iw reversed (was: Re: Matching Text) Message-ID: <20071017030151.GI3867@mercury.ccil.org> References: <002101c81068$53b6a0e0$6401a8c0@DGBP7M81> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101c81068$53b6a0e0$6401a8c0@DGBP7M81> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Just out of curiosity, can you explain the comment on frame 9: "he/iw > reversed: compatibility" > > I think I know what it means, but I hope I'm wrong. It means, as I happen to know, that "iw" is used internally rather than "he", for historical reasons. This is of course perfectly allowable. -- The Imperials are decadent, 300 pound John Cowan free-range chickens (except they have http://www.ccil.org/~cowan teeth, arms instead of wings, and dinosaurlike tails). --Elyse Grasso _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Oct 18 18:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidyz-0003Jk-Eq; Thu, 18 Oct 2007 18:36:49 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iidyx-0003Jf-CP for ltru-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 18:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidyw-0003JO-Cc for ltru@ietf.org; Thu, 18 Oct 2007 18:36:46 -0400 Received: from mta17.mail.adelphia.net ([68.168.78.99] helo=mta17.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iidym-0004CJ-2N for ltru@ietf.org; Thu, 18 Oct 2007 18:36:42 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071017143358.YGEH26865.mta13.adelphia.net@DGBP7M81>; Wed, 17 Oct 2007 10:33:58 -0400 Message-ID: <005701c810ca$c1476920$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <002101c81068$53b6a0e0$6401a8c0@DGBP7M81> <20071017030151.GI3867@mercury.ccil.org> Subject: Re: [Ltru] [ot] he/iw reversed (was: Re: Matching Text) Date: Wed, 17 Oct 2007 07:33:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 1.6 (+) 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 John Cowan wrote: >> Just out of curiosity, can you explain the comment on frame 9: >> "he/iw reversed: compatibility" > > It means, as I happen to know, that "iw" is used internally rather > than "he", for historical reasons. This is of course perfectly > allowable. Oh, that's fine. They can use anything they like internally. I was afraid it had something to do with preferring "iw" over "he" in pages tagged by users, finding better matches with "iw" or exposing "iw" to users in the UI. "iw" was withdrawn from ISO 639 eighteen years ago, along with "in" and "ji", long before there was widespread language tagging of electronic documents. There should be no reason to encourage its continued use. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 NEW URL --> http://home.roadrunner.com/~dewell <-- NEW URL 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 20 00:37:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij63d-0007g2-Ql; Sat, 20 Oct 2007 00:35:29 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ij63b-0007fx-4x for ltru-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 00:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij63a-0007fo-AR for ltru@ietf.org; Sat, 20 Oct 2007 00:35:26 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij63Q-0008GB-Uj for ltru@ietf.org; Sat, 20 Oct 2007 00:35:24 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071020043457.CWGG26917.mta9.adelphia.net@DGBP7M81>; Sat, 20 Oct 2007 00:34:57 -0400 Message-ID: <000b01c812d2$91be2950$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "Unicode Mailing List" , "LTRU Working Group" , Date: Fri, 19 Oct 2007 21:34:56 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] [OT] Seeking French and German linguistic advice X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 the brief off-topic post. I'm looking for a bit of linguistic information about French and German from native (or "nearly native") speakers of those languages who understand the concepts of "phoneme" and "minimal pair." Please reply to me OFF-LINE. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 NEW E-MAIL --> dewell at roadrunner dot com NEW URL --> http://home.roadrunner.com/~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 20 14:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjIvX-00060x-OH; Sat, 20 Oct 2007 14:19:59 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IjCFU-0003bL-4L for ltru-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 07:12:08 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IjCFS-0003YS-S4 for ltru@ietf.org; Sat, 20 Oct 2007 07:12:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ij9Xv-00043y-2I for ltru@ietf.org; Sat, 20 Oct 2007 04:18:59 -0400 Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ij9Xp-0006RO-5Z for ltru@ietf.org; Sat, 20 Oct 2007 04:18:57 -0400 Received: from c83-250-198-41.bredband.comhem.se ([83.250.198.41]:62285) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Ij9XQ-0002Wa-9H; Sat, 20 Oct 2007 10:18:28 +0200 In-Reply-To: <000b01c812d2$91be2950$6401a8c0@DGBP7M81> References: <000b01c812d2$91be2950$6401a8c0@DGBP7M81> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Hans Aberg Date: Sat, 20 Oct 2007 10:16:52 +0200 To: Doug Ewell X-Mailer: Apple Mail (2.752.2) X-Originating-IP: 83.250.198.41 X-Scan-Result: No virus found in message 1Ij9XQ-0002Wa-9H. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Ij9XQ-0002Wa-9H 83b6b56f265188cb2cad9de549d31cf5 X-Spam-Score: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-TMDA-Confirmed: Sat, 20 Oct 2007 07:12:06 -0400 X-Mailman-Approved-At: Sat, 20 Oct 2007 14:19:58 -0400 Cc: ietf-languages@iana.org, LTRU Working Group , Unicode Mailing List Subject: [Ltru] Re: [OT] Seeking French and German linguistic advice X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 20 Oct 2007, at 06:34, Doug Ewell wrote: > I'm looking for a bit of linguistic information about French and =20 > German from native (or "nearly native") speakers of those languages =20= > who understand the concepts of "phoneme" and "minimal pair." The Usenet newsgroup sci.lang has a number of linguists discussion =20 such matters. Hans =C5berg _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 21 04:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjWUM-0004kd-Fs; Sun, 21 Oct 2007 04:48:50 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IjWUJ-0004iT-K5 for ltru-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 04:48:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjWUI-0004gn-Jl for ltru@ietf.org; Sun, 21 Oct 2007 04:48:46 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjWUI-000665-2N for ltru@ietf.org; Sun, 21 Oct 2007 04:48:46 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0A7C9240817; Sun, 21 Oct 2007 09:48:39 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id EA5D51579EF; Sun, 21 Oct 2007 08:48:10 +0000 (GMT) Date: Sun, 21 Oct 2007 08:48:10 +0000 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20071021084810.GA12764@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [Ltru] [iesg-secretary@ietf.org: Last Call: draft-klensin-unicode-escapes (ASCII Escaping of Unicode Characters) to BCP] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Although we no longer need such ASCII escapes, this document may interest readers here since LTRU spent a long time on this subject. --3V7upXqbjpZ4EhLz Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: stephane@laperouse.bortzmeyer.org Delivered-To: stephane@laperouse.bortzmeyer.org Received: by horcrux (Postfix, from userid 10) id E23C21579EF; Thu, 18 Oct 2007 21:19:30 +0200 (CEST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by mail.bortzmeyer.org (Postfix) with ESMTP id E9B7E240822 for ; Thu, 18 Oct 2007 21:05:17 +0200 (CEST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id CBFD71C00E7 for ; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B434A1C00DD for ; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by relay2.nic.fr (Postfix) with ESMTP id A70DA58ECC9 for ; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: (from bortzmeyer@localhost) by maya40.nic.fr (8.12.4/8.12.4) id l9IJ5GDc726814 for stephane@laperouse.bortzmeyer.org; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id l9IJ5G8l726749 for ; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: by relay1.nic.fr (Postfix) id 856DCA1DB0E; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Delivered-To: bortzmeyer@nic.fr Received: from mx1.nic.fr (mx1.nic.fr [192.134.4.10]) by relay1.nic.fr (Postfix) with ESMTP id 82DE0A1DA88; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: from mx1.nic.fr (localhost [127.0.0.1]) by mx1.nic.fr (Postfix) with SMTP id 770A4171408A; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: by mx1.nic.fr (Postfix, from userid 500) id 5DBD4171408C; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.nic.fr (Postfix) with ESMTP id 44EDD171408A; Thu, 18 Oct 2007 21:05:16 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiaLr-0001mw-SN; Thu, 18 Oct 2007 14:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiaLp-0001mN-5q for ietf-announce@ietf.org; Thu, 18 Oct 2007 14:44:09 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiaLo-0004ap-4J for ietf-announce@ietf.org; Thu, 18 Oct 2007 14:44:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0BF4126E60 for ; Thu, 18 Oct 2007 18:44:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IiaLi-0000SF-Ul for ietf-announce@ietf.org; Thu, 18 Oct 2007 14:44:02 -0400 X-test-idtracker: no To: IETF-Announce Old-From: The IESG Message-Id: Date: Thu, 18 Oct 2007 14:44:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Old-Subject: Last Call: draft-klensin-unicode-escapes (ASCII Escaping of Unicode Characters) to BCP X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.10.18.113754 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_900_999 0, __CP_URI_IN_BODY 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __SANE_MSGID 0' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 Subject: Last Call: draft-klensin-unicode-escapes (ASCII Escaping of Unicode Characters) to BCP From: The IESG The IESG has received a request from an individual submitter to consider the following document: - 'ASCII Escaping of Unicode Characters ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-11-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-klensin-unicode-escapes-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15606&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --3V7upXqbjpZ4EhLz 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 --3V7upXqbjpZ4EhLz-- From ltru-bounces@ietf.org Sun Oct 21 09:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjaqA-0003cB-3a; Sun, 21 Oct 2007 09:27:38 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ijaq8-0003ai-8d for ltru-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 09:27:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijaq7-0003M7-2d for ltru@lists.ietf.org; Sun, 21 Oct 2007 09:27: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 1Ijapw-0006X4-Ro for ltru@lists.ietf.org; Sun, 21 Oct 2007 09:27:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ijape-0000xn-7t for ltru@lists.ietf.org; Sun, 21 Oct 2007 13:27:06 +0000 Received: from 1cust221.tnt1.hbg2.deu.da.uu.net ([149.225.10.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 13:27:06 +0000 Received: from nobody by 1cust221.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 13:27:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Sun, 21 Oct 2007 15:26:55 +0200 Organization: http://purl.net/xyzzy Lines: 11 Message-ID: References: <20071021084810.GA12764@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust221.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: Last Call:draft-klensin-unicode-escapes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Although we no longer need such ASCII escapes For definitions of "we" covering "TINW"... So far ltru2xml.awk 0.7 won't survive its first encounter with an unencoded "&" in a registry, I hope your converters are already smarter. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Oct 21 14:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijfbl-0001Oj-U7; Sun, 21 Oct 2007 14:33:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ijfbk-0001NJ-LX for ltru-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 14:33:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijfbj-0001Ma-OL for ltru@ietf.org; Sun, 21 Oct 2007 14:33:03 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijfbf-0003Do-Dl for ltru@ietf.org; Sun, 21 Oct 2007 14:32:59 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071021183258.GITD17119.mta11.adelphia.net@DGBP7M81> for ; Sun, 21 Oct 2007 14:32:58 -0400 Message-ID: <001201c81410$cdfc37b0$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 21 Oct 2007 11:32:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: Last Call:draft-klensin-unicode-escapes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > So far ltru2xml.awk 0.7 won't survive its first > encounter with an unencoded "&" in a registry, > I hope your converters are already smarter. Fortunately, there are no unencoded "&" characters in either the current Registry or the one embedded in draft-4645bis, so this is moot. Perhaps we could specify in RFC 4646bis that standalone "&" must not be added to the Registry. If any description from an ISO standard uses standalone "&", we could specify that it must be changed to the word "and". This might provide a modicum of backward compatibility. However, in general, some tools will need to be updated. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 NEW E-MAIL --> dewell at roadrunner dot com NEW URL --> http://home.roadrunner.com/~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 22 02:20:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijqcf-0000YI-VD; Mon, 22 Oct 2007 02:18:45 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ijqce-0000YC-72 for ltru-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 02:18:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijqcd-0000Xg-5I for ltru@lists.ietf.org; Mon, 22 Oct 2007 02:18:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ijqcc-00022H-OM for ltru@lists.ietf.org; Mon, 22 Oct 2007 02:18:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ijqbl-0001Id-Q4 for ltru@lists.ietf.org; Mon, 22 Oct 2007 06:17:49 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 06:17:49 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 06:17:49 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Mon, 22 Oct 2007 08:15:00 +0200 Lines: 27 Message-ID: References: <001201c81410$cdfc37b0$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: Last Call:draft-klensin-unicode-escapes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 ltru2xml.awk 0.7 won't survive its first >> encounter with an unencoded "&" in a registry, >> I hope your converters are already smarter. =20 > Fortunately, there are no unencoded "&" characters in either the = current=20 > Registry or the one embedded in draft-4645bis, so this is moot. I know, otherwise would have FAILed in the validation: I fixed the encoding=3D"UTF-8" manually for this test, of course ltru2xml.awk 0.7 doesn't claim to support = UTF-8. > Perhaps we could specify in RFC 4646bis that standalone "&" must > not be added to the Registry. Authors of XML converters are supposed to get this right. We should however get rid of hex. NCRs if "we" (TINW) adopt UTF-8 in 4646bis. > NEW URL --> http://home.roadrunner.com/~dewell Tnx for info, bookmark updated. It could be added to the right column "for standard authors" on .=20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 23 14:21:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOMC-0001vK-UU; Tue, 23 Oct 2007 14:20:00 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IkOMB-0001tt-Pp for ltru-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 14:19:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOMB-0001tk-GH for ltru@ietf.org; Tue, 23 Oct 2007 14:19:59 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkOM4-0005od-HV for ltru@ietf.org; Tue, 23 Oct 2007 14:19:59 -0400 Received: by wa-out-1112.google.com with SMTP id k40so2687059wah for ; Tue, 23 Oct 2007 11:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=CoOdkW8WF+1xidy7WZJs6DkNxjFrEVekEWqgspTjPNE=; b=sI3mh1QWIRCBn4ButhYxsPQfpGGpdmiedDMKbUbg/5QrPJ92jhsG8dT6vZCpKpS89QgAZY0cNHqeO9Iqng8M++sOJuJe1pt+88rVIhZ1H0O+55mzIHtiDWt7booBP1nDk7S9WzOCf6OOCDYfp+MGFrFETajw5az/NQqHozFZ+FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=AgIOBYRhVyayGbCjigZ4Vyvi6juqjhcV+mCcVQg5pzJc9WuzJGIqOWrY/YVWH1QvbpL2GHawDVW49blFLe93lxQ8Xu9nkeh9N6M4BSFszKolQboZe5tfWK3EtxN7AEXscqblqPY2zezGOPwsbZ2GKfGwXBl6RyohhKL9us6k7+Y= Received: by 10.114.93.17 with SMTP id q17mr2453973wab.1193163560479; Tue, 23 Oct 2007 11:19:20 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Tue, 23 Oct 2007 11:19:20 -0700 (PDT) Message-ID: <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> Date: Tue, 23 Oct 2007 13:19:20 -0500 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference In-Reply-To: <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> MIME-Version: 1.0 References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> X-Google-Sender-Auth: c780cb3fa9f9bd8b X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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="===============1902217978==" Errors-To: ltru-bounces@ietf.org --===============1902217978== Content-Type: multipart/alternative; boundary="----=_Part_3107_14924362.1193163560475" ------=_Part_3107_14924362.1193163560475 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline The last I heard (I was at the conference, then UTC last week), we were debating over the time of the next phone meeting. I would actually prefer it postponed until next week, since I'm on vacation this week. I think it would also be useful to pull in Martin, and for him a time later in the day would be vastly more appealing (after 16 or 17 PT?). Mark ------=_Part_3107_14924362.1193163560475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
The last I heard (I was at the conference, then UTC last week), we were debating over the time of the next phone meeting. I would actually prefer it postponed until next week, since I'm on vacation this week. I think it would also be useful to pull in Martin, and for him a time later in the day would be vastly more appealing (after 16 or 17 PT?).
 
Mark
------=_Part_3107_14924362.1193163560475-- --===============1902217978== 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 --===============1902217978==-- From ltru-bounces@ietf.org Tue Oct 23 14:46:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOkt-00058w-M7; Tue, 23 Oct 2007 14:45:31 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IkOks-00058i-R9 for ltru-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 14:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkOks-0004xb-HX for ltru@ietf.org; Tue, 23 Oct 2007 14:45:30 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkOkf-00078w-Bj for ltru@ietf.org; Tue, 23 Oct 2007 14:45:24 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kmjGMm8bn2UGe8/5TNOPIm0wjuNfXuIIn6FiFC18b2Dq8A8VDkOn7+PotFYQPPnQ; 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 [64.105.35.68] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IkOkY-00032i-Py for ltru@ietf.org; Tue, 23 Oct 2007 14:45:11 -0400 Message-ID: <002a01c815a4$e4172100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81><30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference Date: Tue, 23 Oct 2007 11:45:30 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a1c365959aa5908afc34299b8e5b6b2ef350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.68 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 potential teleconference participant... > From: "Mark Davis" > To: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Tuesday, October 23, 2007 11:19 AM > Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference > > The last I heard (I was at the conference, then UTC last week), we were > debating over the time of the next phone meeting. I would actually prefer it > postponed until next week, since I'm on vacation this week. I think it would > also be useful to pull in Martin, and for him a time later in the day would > be vastly more appealing (after 16 or 17 PT?). ... I would prefer to *NOT* postpone it. The later time could work for me as well, but I doubt that it would increase participation by those in Europe. On the other hand, a call at 6:00 a.m. PT would be 22:00 in Japan. Not great, but probably doable, particularly since the work cultures in both time zones tend to permit more flexibility in these matters. That would be in the middle of the afternoon in Europe, leaving little excuse for non-participation. Whatever time is decided, please post it to this list. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 23 22:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkVjL-0005a3-2H; Tue, 23 Oct 2007 22:12:23 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IkVjK-0005Zg-2p for ltru-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 22:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkVjJ-0005Kt-PF for ltru@ietf.org; Tue, 23 Oct 2007 22:12:21 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkVin-0000Be-Jg for ltru@ietf.org; Tue, 23 Oct 2007 22:12:06 -0400 Received: by wa-out-1112.google.com with SMTP id k40so74864wah for ; Tue, 23 Oct 2007 19:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=gSIalQrGvdsPMQYclph0gUximmP/AIhw53G34lt96v0=; b=sst/0W5HrUW3ARLOay8PdF+AyywYgE1ymbxCBuRuc7OJTF9lFur//1WHiI2eLJ212bshJ64/SxPLykJTBbKCmSndWdnAVG2kOjzBPBt3MDCwjcbRBmMJKRM24jvrAWfWVW5ppq4bMjJfsFJZ1t/OAh3CRwdTfIf+zsxPbfXDjvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=DbUd/1JnQOIRDtbG29FHT9pVtPaiNGpwHsAnqHUWeagQ7mdpidXx2J1+pb+lvjBUHslSL8eJNM2HDrFvRW7RErsWub1Y4fGxm+0LVO/6olyo1uoAiuEg7FBIXLpAd38kZcYcJxWLD3XOqp/oLT1Il5ybvs3NRmWHap9r9H5ab2M= Received: by 10.115.95.1 with SMTP id x1mr72314wal.1193191891571; Tue, 23 Oct 2007 19:11:31 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Tue, 23 Oct 2007 19:11:31 -0700 (PDT) Message-ID: <30b660a20710231911l50ada56bo5ff70d59510a5212@mail.gmail.com> Date: Tue, 23 Oct 2007 21:11:31 -0500 From: "Mark Davis" To: "Randy Presuhn" Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference In-Reply-To: <002a01c815a4$e4172100$6801a8c0@oemcomputer> MIME-Version: 1.0 References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> <002a01c815a4$e4172100$6801a8c0@oemcomputer> X-Google-Sender-Auth: 92f63fe72c2c1abb X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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="===============0477772383==" Errors-To: ltru-bounces@ietf.org --===============0477772383== Content-Type: multipart/alternative; boundary="----=_Part_4827_10914366.1193191891597" ------=_Part_4827_10914366.1193191891597 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This week: - Tomorrow (Wednesday) I can't make it at 6PT, but can probably make 9PT. - On Friday I will be back at work, and could make either 6PT or 9PT. Generally, we haven't seen a lot of Europeans take advantage of the earlier calling time, so if they aren't going to call in, we might as well move to make it better for Asian callers like Martin. Mark On 10/23/07, Randy Presuhn wrote: > > Hi - > > As a potential teleconference participant... > > > From: "Mark Davis" > > To: "Doug Ewell" > > Cc: "LTRU Working Group" > > Sent: Tuesday, October 23, 2007 11:19 AM > > Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference > > > > The last I heard (I was at the conference, then UTC last week), we were > > debating over the time of the next phone meeting. I would actually > prefer it > > postponed until next week, since I'm on vacation this week. I think it > would > > also be useful to pull in Martin, and for him a time later in the day > would > > be vastly more appealing (after 16 or 17 PT?). > ... > > I would prefer to *NOT* postpone it. > > The later time could work for me as well, but I doubt that it would > increase > participation by those in Europe. > > On the other hand, a call at 6:00 a.m. PT would be 22:00 in > Japan. Not great, but probably doable, particularly since the > work cultures in both time zones tend to permit more flexibility > in these matters. That would be in the middle of the afternoon > in Europe, leaving little excuse for non-participation. > > Whatever time is decided, please post it to this list. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_4827_10914366.1193191891597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This week:
  • Tomorrow (Wednesday) I can't make it at 6PT, but can probably make 9PT.
  • On Friday I will be back at work, and could make either 6PT or 9PT.

Generally, we haven't seen a lot of Europeans take advantage of the earlier calling time, so if they aren't going to call in, we might as well move to make it better for Asian callers like Martin.

 
Mark

 
On 10/23/07, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
Hi -

As a potential teleconference participant...

> From: "Mark Davis" < mark.davis@icu-project.org>
> To: "Doug Ewell" <dewell@roadrunner.com>
> Cc: "LTRU Working Group" < ltru@ietf.org>
> Sent: Tuesday, October 23, 2007 11:19 AM
> Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference
>
> The last I heard (I was at the conference, then UTC last week), we were
> debating over the time of the next phone meeting. I would actually prefer it
> postponed until next week, since I'm on vacation this week. I think it would
> also be useful to pull in Martin, and for him a time later in the day would
> be vastly more appealing (after 16 or 17 PT?).
...

I would prefer to *NOT* postpone it.

The later time could work for me as well, but I doubt that it would increase
participation by those in Europe.

On the other hand, a call at 6:00 a.m. PT would be 22:00 in
Japan.  Not great, but probably doable, particularly since the
work cultures in both time zones tend to permit more flexibility
in these matters.  That would be in the middle of the afternoon
in Europe, leaving little excuse for non-participation.

Whatever time is decided, please post it to this list.

Randy



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



--
Mark ------=_Part_4827_10914366.1193191891597-- --===============0477772383== 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 --===============0477772383==-- From ltru-bounces@ietf.org Tue Oct 23 23:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWbG-0007YP-I9; Tue, 23 Oct 2007 23:08:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IkWbF-0007X5-6V for ltru-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 23:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWbE-0007Wx-T3 for ltru@ietf.org; Tue, 23 Oct 2007 23:08:04 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkWb8-00025Y-KM for ltru@ietf.org; Tue, 23 Oct 2007 23:08:04 -0400 Received: from [10.72.76.58] (snvvpn2-10-72-76-c58.corp.yahoo.com [10.72.76.58]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9O37bCF052423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 20:07:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=rtWvu7vWaN4wYG3g/4iy/vRjNxndgoCYFnAScOYcXWebsPSzHFrOhB1kTHRHZJKp Message-ID: <471EB6F9.6000701@yahoo-inc.com> Date: Tue, 23 Oct 2007 20:07:37 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> <002a01c815a4$e4172100$6801a8c0@oemcomputer> <30b660a20710231911l50ada56bo5ff70d59510a5212@mail.gmail.com> In-Reply-To: <30b660a20710231911l50ada56bo5ff70d59510a5212@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) 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: , Errors-To: ltru-bounces@ietf.org It is kind of late to be rescheduling. On the other hand, it is kind of late to be scheduling in the first place. I intended to send out a reminder just now. I guess it would be prudent to schedule another date? Friday this week works for me (Thursday definitely does not). I can do 6 AM Pacific Friday, with a hard stop at 7 AM (for the W3C HCG call). Addison Mark Davis wrote: > This week: > > * Tomorrow (Wednesday) I can't make it at 6PT, but can probably make > 9PT. > * On Friday I will be back at work, and could make either 6PT or 9PT. > > Generally, we haven't seen a lot of Europeans take advantage of the > earlier calling time, so if they aren't going to call in, we might as > well move to make it better for Asian callers like Martin. > > > Mark > > > On 10/23/07, *Randy Presuhn* > wrote: > > Hi - > > As a potential teleconference participant... > > > From: "Mark Davis" < mark.davis@icu-project.org > > > > To: "Doug Ewell" > > > Cc: "LTRU Working Group" < ltru@ietf.org > > > Sent: Tuesday, October 23, 2007 11:19 AM > > Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference > > > > The last I heard (I was at the conference, then UTC last week), > we were > > debating over the time of the next phone meeting. I would > actually prefer it > > postponed until next week, since I'm on vacation this week. I > think it would > > also be useful to pull in Martin, and for him a time later in the > day would > > be vastly more appealing (after 16 or 17 PT?). > ... > > I would prefer to *NOT* postpone it. > > The later time could work for me as well, but I doubt that it would > increase > participation by those in Europe. > > On the other hand, a call at 6:00 a.m. PT would be 22:00 in > Japan. Not great, but probably doable, particularly since the > work cultures in both time zones tend to permit more flexibility > in these matters. That would be in the middle of the afternoon > in Europe, leaving little excuse for non-participation. > > Whatever time is decided, please post it to this list. > > Randy > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > -- > Mark > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 23 23:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWlg-0005Hy-3z; Tue, 23 Oct 2007 23:18:52 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IkWlf-0005Ht-CQ for ltru-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 23:18:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkWlf-0005Hl-2L for ltru@ietf.org; Tue, 23 Oct 2007 23:18:51 -0400 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkWle-0004uS-Qj for ltru@ietf.org; Tue, 23 Oct 2007 23:18:50 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IkWld-0002sG-HG; Tue, 23 Oct 2007 23:18:49 -0400 Date: Tue, 23 Oct 2007 23:18:49 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference Message-ID: <20071024031849.GH29533@mercury.ccil.org> References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> <002a01c815a4$e4172100$6801a8c0@oemcomputer> <30b660a20710231911l50ada56bo5ff70d59510a5212@mail.gmail.com> <471EB6F9.6000701@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471EB6F9.6000701@yahoo-inc.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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 Addison Phillips scripsit: > Friday this week works for me (Thursday definitely does not). I can do 6 > AM Pacific Friday, with a hard stop at 7 AM (for the W3C HCG call). I can do Wed or Fri at 6 PT or 9 PT (9 ET or 12 ET). -- Long-short-short, long-short-short / Dactyls in dimeter, John Cowan Verse form with choriambs / (Masculine rhyme): cowan@ccil.org One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Oct 24 02:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ika8D-0005MP-OX; Wed, 24 Oct 2007 02:54:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ika8C-0005MK-47 for ltru-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 02:54:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ika8A-0005KN-06 for ltru@ietf.org; Wed, 24 Oct 2007 02:54:18 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ika84-0002FG-Kk for ltru@ietf.org; Wed, 24 Oct 2007 02:54:12 -0400 Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20071024065412.TWQL26865.mta13.adelphia.net@DGBP7M81> for ; Wed, 24 Oct 2007 02:54:12 -0400 Message-ID: <003701c8160a$b0313cc0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 23 Oct 2007 23:54:13 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.2 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ltru] Re: Summary of 2007-10-03 teleconference X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org 6 am PDT would be fine for me, but you already knew that. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 NEW E-MAIL --> dewell at roadrunner dot com NEW URL --> http://home.roadrunner.com/~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 24 03:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkavT-0005fs-NQ; Wed, 24 Oct 2007 03:45:15 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IkavR-0005aD-Bp for ltru-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 03:45:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkavQ-0004ul-Vm for ltru@ietf.org; Wed, 24 Oct 2007 03:45:13 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikauj-0003ol-KX for ltru@ietf.org; Wed, 24 Oct 2007 03:44:36 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l9O7iQeO016712 for ; Wed, 24 Oct 2007 16:44:26 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 491a_f1e4be92_8204_11dc_9c68_0014221fa3c9; Wed, 24 Oct 2007 16:44:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:34636) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 24 Oct 2007 16:40:49 +0900 Message-Id: <6.0.0.20.2.20071024161803.08118920@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 24 Oct 2007 16:21:50 +0900 To: "Mark Davis" , "Randy Presuhn" From: Martin Duerst Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference In-Reply-To: <30b660a20710231911l50ada56bo5ff70d59510a5212@mail.gmail.co m> References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> <002a01c815a4$e4172100$6801a8c0@oemcomputer> <30b660a20710231911l50ada56bo5ff70d59510a5212@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: 2409bba43e9c8d580670fda8b695204a 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 11:11 07/10/24, Mark Davis wrote: >This week: > * Tomorrow (Wednesday) I can't make it at 6PT, but can probably make 9PT. > * On Friday I will be back at work, and could make either 6PT or 9PT. > >Generally, we haven't seen a lot of Europeans take advantage of the earlier calling time, so if they aren't going to call in, we might as well move to make it better for Asian callers like Martin. If it starts 22:00 here, I can probably make it, but later isn't a good idea. The other way round, 06:00 or later as a start should work, but I really need to know this well ahead. 10:00 or later very much depends on the day of the week. Please also note that with the move to winter time in the US, Japan and the US will move nearer together, and therefore US late/ Japan early (and Europe pretty much out of the picture, sorry) makes more sense than the other way round. But please don't expect too much from me participating. And let's make sure Peter Constable can be on the call. 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 24 11:07:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikhoq-00047f-W7; Wed, 24 Oct 2007 11:06:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ikhop-00047a-4B for ltru-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:06:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikhoo-00047Q-QQ for ltru@ietf.org; Wed, 24 Oct 2007 11:06:50 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikhoi-0001Nk-H0 for ltru@ietf.org; Wed, 24 Oct 2007 11:06:50 -0400 Received: by wa-out-1112.google.com with SMTP id k40so393588wah for ; Wed, 24 Oct 2007 08:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=UkoOCK8rWFw++2NT2WQbq22akWdjDZn3JsvDjAfBeEE=; b=BvChlDj5NA8spI4p8Vadej8RLF47wpBrmI/F/BU9ePwfcVxlI7sORfJMhzjD+QVljxMzs/Tf7p2nY6/bq9U1QE6I+MPxB1ihJa+5vrWHOIlUXDv9f8rQpg21/aa6oldnUyNXDYW6kZ4n+c6WobPE8k9hLf6GlXB7T2kWpOy0rUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZuNR8xn2inmW2Hm3YgOSaxd59fUgCNbgjckpXigKMFQNDzzJBBKFW/JU08QW6twW4PT2HFSGU+mcjfzuzFl98rxb9Eojr8W9nI29d9Qw37SPLVmuuEr/S9w8RmSqEi9OesN2gH4st0MijxAszzoNVEmKO2Kj8/BYl46sP7T0Sh4= Received: by 10.115.74.1 with SMTP id b1mr797525wal.1193238378315; Wed, 24 Oct 2007 08:06:18 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Wed, 24 Oct 2007 08:06:18 -0700 (PDT) Message-ID: <30b660a20710240806hc415e95r7039e7947491ffec@mail.gmail.com> Date: Wed, 24 Oct 2007 10:06:18 -0500 From: "Mark Davis" To: "John Cowan" Subject: Re: [Ltru] Re: Summary of 2007-10-03 teleconference In-Reply-To: <20071024031849.GH29533@mercury.ccil.org> MIME-Version: 1.0 References: <008901c80a0a$55f74bc0$6401a8c0@DGBP7M81> <30b660a20710081743y6107cdb0if085a854682d20fa@mail.gmail.com> <30b660a20710231119i50b2f4bexb15d0a69cc32ecfe@mail.gmail.com> <002a01c815a4$e4172100$6801a8c0@oemcomputer> <30b660a20710231911l50ada56bo5ff70d59510a5212@mail.gmail.com> <471EB6F9.6000701@yahoo-inc.com> <20071024031849.GH29533@mercury.ccil.org> X-Google-Sender-Auth: 519de11f27aa0e86 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: , Content-Type: multipart/mixed; boundary="===============1513073318==" Errors-To: ltru-bounces@ietf.org --===============1513073318== Content-Type: multipart/alternative; boundary="----=_Part_6982_7603015.1193238378295" ------=_Part_6982_7603015.1193238378295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Ok, how about 6PT on Friday this week, and then for next week let's still keep discussing a time that works for Martin. Mark On 10/23/07, John Cowan wrote: > > Addison Phillips scripsit: > > > Friday this week works for me (Thursday definitely does not). I can do 6 > > AM Pacific Friday, with a hard stop at 7 AM (for the W3C HCG call). > > I can do Wed or Fri at 6 PT or 9 PT (9 ET or 12 ET). > > -- > Long-short-short, long-short-short / Dactyls in dimeter, John Cowan > Verse form with choriambs / (Masculine rhyme): cowan@ccil.org > One sentence (two stanzas) / Hexasyllabically > Challenges poets who / Don't have the time. --robison who's at texas > dot net > -- Mark ------=_Part_6982_7603015.1193238378295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Ok, how about 6PT on Friday this week, and then for next week let's still keep discussing a time that works for Martin.
 
Mark
 
On 10/23/07, John Cowan <cowan@ccil.org> wrote:
Addison Phillips scripsit:

> Friday this week works for me (Thursday definitely does not). I can do 6
> AM Pacific Friday, with a hard stop at 7 AM (for the W3C HCG call).

I can do Wed or Fri at 6 PT or 9 PT (9 ET or 12 ET).

--
Long-short-short, long-short-short / Dactyls in dimeter,     John Cowan
Verse form with choriambs / (Masculine rhyme):           cowan@ccil.org
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas dot net



--
Mark ------=_Part_6982_7603015.1193238378295-- --===============1513073318== 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 --===============1513073318==-- From ltru-bounces@ietf.org Fri Oct 26 00:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGVC-00056W-FA; Fri, 26 Oct 2007 00:08:54 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IlGVA-0004xk-TM for ltru-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 00:08:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGVA-0004ee-3Z for ltru@lists.ietf.org; Fri, 26 Oct 2007 00:08:52 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlGUW-0001ZR-P1 for ltru@lists.ietf.org; Fri, 26 Oct 2007 00:08:42 -0400 Received: by wa-out-1112.google.com with SMTP id j4so944991wah for ; Thu, 25 Oct 2007 21:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=phweU4B1u5oAo/Fzm31Z9zb0ekwp+P57aUKZMgsLO88=; b=VSLoPk6ctAXq/vXpWPF+tuDtPzDbuPd0QgVhOSJXj7+Ou50MpP3vuQplZ5xvtR1hJjXGhYjD8f/a/9k/c513xztGBvaOvKW9spbv4m2+zrtG2eA4jWG/MUALEIU22nuhw2gek2h1VZEGX56eGAB/9QS0UKSrruqoQW7Vuo7FCuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HCbcWb3hnxNQZ/7oaTIb5GvU9vNhaIMi54WWnNktZH0diQzpg38eFAd/M7ov6DhAO9++upW+Oey2/qn5bb8BRWt0ZyQLbjj0QAIchhWpi4jMAZ1tnbVOrE00pYp2VK6TbAgHLAsXnuNPX+jCYoHgTE4cMbVaun5kCkpu+W/0Kz0= Received: by 10.114.67.2 with SMTP id p2mr2965206waa.1193371666894; Thu, 25 Oct 2007 21:07:46 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 25 Oct 2007 21:07:46 -0700 (PDT) Message-ID: <30b660a20710252107p69391a48u47cf05b944e1b704@mail.gmail.com> Date: Thu, 25 Oct 2007 21:07:46 -0700 From: "Mark Davis" To: ltru@lists.ietf.org Subject: Re: [Ltru] Re: Matching Text In-Reply-To: <30b660a20710151912i3f6a346ctf4b67767af6142ea@mail.gmail.com> MIME-Version: 1.0 References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011130656.GD2710@mercury.ccil.org> <006801c80c2d$bb378a20$6801a8c0@oemcomputer> <30b660a20710151912i3f6a346ctf4b67767af6142ea@mail.gmail.com> X-Google-Sender-Auth: 12eca630f14036c2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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="===============1532219179==" Errors-To: ltru-bounces@ietf.org --===============1532219179== Content-Type: multipart/alternative; boundary="----=_Part_4615_4307531.1193371666889" ------=_Part_4615_4307531.1193371666889 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Back in town, so will be attending the 6:00PT meeting tomorrow (Addison, I assume it is the same call-in numbers). I had suggested that we include proposed text changes for each of the possible options that we are considering, where it affects implementations, in RFC 4747. I haven't seen anything on the list about that, so I'll start off with the no-extlang option. I suggest that others try their hands at the extlang or partial extlang options so that we can compare the issues with real text in front of us. ================ Add to end of 3.4.1 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt, most of the way to the end) ... Often the implementation-defined default result is English, since that is quite often the "root" used for common resource lookup. However, that is often not the best choice where other information is available. Certain languages are closely related, and the lookup process may take that into account. For example, since the the tag "gsw-CH" (for Swiss German as used in Switzerland) was first available on 2006-12-08, Swiss German ("Schwyzerduetsch") text may have been tagged with "de-CH" instead. ISO 639 was not (and is still not) clear on whether "de" meant only High German or also included variants such as Low German or not. Thus Swiss German material may be tagged with "de". Moreover, essentially all Swiss German speakers are comfortable in High German, so where Swiss German is not available, High German is a very good fallback. Thus when given the language priority list: "gsw-CH, fr-CH", an implementation using lookup may augment the default values to also include the lookup of related values, such as the following search order: 1. gsw-CH 2. gsw 3. fr-CH // next language 4. fr 5. implementation defined default: 5a. de-CH // special fallback from gsw-CH 5b. de 5c. en // root In this way, other likely possibilities are tried before the final fallback to the root value. Note that typically the fallback to related languages should include the script and region codes if available. Thus the lookup process may take into account what languages people are likely to understand, given a language priority list. For example, a Breton speaker is very likely to also understand French, given the language priority list. Thus the implementation may choose to use the following lookup for the language priority list "br-FR, de": 1. br-FR 2. br 3. de 4. implementation defined default: 4a. fr-FR // special fallback from br (Breton) 4b. fr 4c. en Similarly, Romanian and Moldavian, Tagalog and Filipino, Serbo-Croatian and Croatian, may all be useful in doing related language lookup. The Macrolanguage information in the registry MAY be useful to implementations in this regard. That is, an implementation MAY choose to use that information in falling back from encompassed languages to macro languages. For example, given the language priority list with Cantonese in Traditional Script as used in Hong Kong, followed by French ("yue-Hant-HK, fr"), the lookup could be the following: 1. yue-Hant-HK 2. yue-Hant 3. yue-HK 4. fr 5. implementation defined default: 5a. zh-Hant-Hk 5b. zh-Hant 5c. zh 5d. en Whether such fallback should be used -- and if so, the precise way in which such a fallback is done -- is application-dependent. Where it is very likely that the audience requesting Cantonese (as above) will accept and understand Mandarin (the predominant content for 'zh'), then this fallback might be useful. Where there is risk that that the audience requesting Cantonese will not be conversant with Mandarin, and would prefer an alternative in the language priority list, it should be avoided. (This might be the case, for example, with audio using yue-Zxxx-US.) For many macrolanguages, there is a single predominant form which is strongly identified with the macrolanguage. For example, "zh" is overwhelmingly used for Mandarin content (formally 'cmn'), and "ar" is overwhelmingly used for Standard Arabic content (formally 'arb'). While theoretically there is a distinction between these pairs, in practice they are treated as interchangeable, so no such distinction can be depended upon. Therefore in such cases, lookup SHOULD typically fall back from either one to the other. For other macrolanguages, this is not the case, and fallback to content that might be any any of the encompassed languages may be worse than falling back to other default values, such as the predominant language for a region. Care must be taken with any of these choices. If an implementation provides a UI for selecting language priority lists, it may be better to give the user the option of having explicit fallbacks (such as from Cantonese to Mandarin or Tagalog to Filipino), rather than trying to guess the user's intent (and run the distinct risk of getting it wrong). For that purpose, when a user adds a language to the priority list, the UI may suggest macrolanguages, or other related languages, as additional fallbacks. ------=_Part_4615_4307531.1193371666889 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Back in town, so will be attending the 6:00PT meeting tomorrow (Addison, I assume it is the same call-in numbers).

I had suggested that we include proposed text changes for each of the possible options that we are considering, where it affects implementations, in RFC 4747. I haven't seen anything on the list about that, so I'll start off with the no-extlang option. I suggest that others try their hands at the extlang or partial extlang options so that we can compare the issues with real text in front of us.

================

Add to end of 3.4.1 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt, most of the way to the end)

...
Often the implementation-defined default result is English, since that is quite often the "root" used for common resource lookup. However, that is often not the best choice where other information is available.

Certain languages are closely related, and the lookup process may take that into account. For example, since the the tag "gsw-CH" (for Swiss German as used in Switzerland) was first available on 2006-12-08, Swiss German ("Schwyzerduetsch") text may have been tagged with "de-CH" instead. ISO 639 was not (and is still not) clear on whether "de" meant only High German or also included variants such as Low German or not. Thus Swiss German material may be tagged with "de". Moreover, essentially all Swiss German speakers are comfortable in High German, so where Swiss German is not available, High German is a very good fallback. Thus when given the language priority list: "gsw-CH, fr-CH", an implementation using lookup may augment the default values to also include the lookup of related values, such as the following search order:

1. gsw-CH
2. gsw
3. fr-CH // next language
4. fr
5. implementation defined default:
    5a. de-CH // special fallback from gsw-CH
    5b. de
    5c. en // root

In this way, other likely possibilities are tried before the final fallback to the root value. Note that typically the fallback to related languages should include the script and region codes if available.

Thus the lookup process may take into account what languages people are likely to understand, given a language priority list. For example, a Breton speaker is very likely to also understand French, given the language priority list. Thus the implementation may choose to use the following lookup for the language priority list "br-FR, de":

1. br-FR
2. br
3. de
4. implementation defined default:
    4a. fr-FR // special fallback from br (Breton)
    4b. fr
    4c. en

Similarly, Romanian and Moldavian, Tagalog and Filipino, Serbo-Croatian and Croatian, may all be useful in doing related language lookup.

The Macrolanguage information in the registry MAY be useful to implementations in this regard. That is, an implementation MAY choose to use that information in falling back from encompassed languages to macro languages. For example, given the language priority list with Cantonese in Traditional Script as used in Hong Kong, followed by French ("yue-Hant-HK, fr"), the lookup could be the following:

1. yue-Hant-HK
2. yue-Hant
3. yue-HK
4. fr
5. implementation defined default:
  5a. zh-Hant-Hk
  5b. zh-Hant
  5c. zh
  5d. en

Whether such fallback should be used -- and if so, the precise way in which such a fallback is done -- is application-dependent.  Where it is very likely that the audience requesting Cantonese (as above) will accept and understand Mandarin (the predominant content for 'zh'), then this fallback might be useful. Where there is risk that that the audience requesting Cantonese will not be conversant with Mandarin, and would prefer an alternative in the language priority list, it should be avoided. (This might be the case, for example, with audio using yue-Zxxx-US.)

For many macrolanguages, there is a single predominant form which is strongly identified with the macrolanguage. For example, "zh" is overwhelmingly used for Mandarin content (formally 'cmn'), and "ar" is overwhelmingly used for Standard Arabic content (formally 'arb'). While theoretically there is a distinction between these pairs, in practice they are treated as interchangeable, so no such distinction can be depended upon. Therefore in such cases, lookup SHOULD typically fall back from either one to the other. For other macrolanguages, this is not the case, and fallback to content that might be any any of the encompassed languages may be worse than falling back to other default values, such as the predominant language for a region.

Care must be taken with any of these choices. If an implementation provides a UI for selecting language priority lists, it may be better to give the user the option of having explicit fallbacks (such as from Cantonese to Mandarin or Tagalog to Filipino), rather than trying to guess the user's intent (and run the distinct risk of getting it wrong). For that purpose, when a user adds a language to the priority list, the UI may suggest macrolanguages, or other related languages, as additional fallbacks.









------=_Part_4615_4307531.1193371666889-- --===============1532219179== 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 --===============1532219179==-- From ltru-bounces@ietf.org Fri Oct 26 00:20:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGfV-00026W-CQ; Fri, 26 Oct 2007 00:19:33 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IlGfU-00021q-UP for ltru-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 00:19:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGfU-0001O2-Ig for ltru@ietf.org; Fri, 26 Oct 2007 00:19:32 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGfK-0001MJ-6q for ltru@ietf.org; Fri, 26 Oct 2007 00:19:22 -0400 Received: from [10.72.77.81] (snvvpn2-10-72-77-c81.corp.yahoo.com [10.72.77.81]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9Q4JAwb003814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Oct 2007 21:19:11 -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=qPzbJyzmoEBy/S3sSS6hPZXws42ZmNFNr0yjxhp78vAw6mSWrQc3rbuZ5FCAo29c Message-ID: <47216ABE.1090602@yahoo-inc.com> Date: Thu, 25 Oct 2007 21:19:10 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 08170828343bcf1325e4a0fb4584481c Subject: [Ltru] teleconference details X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: 6 AM Pacific (I guess??) US Dial-In #: +1.888.371.8922 International Dial-In #: +1.617.224.4792 Participant Passcode: 58371972 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 26 04:11:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKHZ-0004Ye-HW; Fri, 26 Oct 2007 04:11:05 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IlKHX-0004X9-Ne for ltru-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 04:11:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlKHX-0004X0-E1 for ltru@lists.ietf.org; Fri, 26 Oct 2007 04:11: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 1IlKHR-00025b-7O for ltru@lists.ietf.org; Fri, 26 Oct 2007 04:11:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlKH1-0002Th-SF for ltru@lists.ietf.org; Fri, 26 Oct 2007 08:10:32 +0000 Received: from 1cust187.tnt3.hbg2.deu.da.uu.net ([149.225.14.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 08:10:31 +0000 Received: from nobody by 1cust187.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 08:10:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Fri, 26 Oct 2007 10:10:22 +0200 Organization: http://purl.net/xyzzy Lines: 16 Message-ID: References: <30b660a20710101803q30bc4c0cvee9e9f4e27b00782@mail.gmail.com> <20071011130656.GD2710@mercury.ccil.org><006801c80c2d$bb378a20$6801a8c0@oemcomputer><30b660a20710151912i3f6a346ctf4b67767af6142ea@mail.gmail.com> <30b660a20710252107p69391a48u47cf05b944e1b704@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1cust187.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: Matching Text X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 had suggested that we include proposed text changes for each of > the possible options that we are considering, where it affects > implementations, in RFC 4747. I haven't seen anything on the list > about that, so I'll start off with the no-extlang option. Thanks. > Add to end of 3.4.1 (http://www.rfc-editor.org/rfc/bcp/bcp47.txt [...] You're talking about a section in RFC 4647, it follows that you intend to create a 4647bis. (No problem, I just didn't know it.) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 30 04:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm4H-0005eB-S6; Tue, 30 Oct 2007 04:03:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Imm4F-0005d9-Sx for ltru-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm4A-0005cc-8W for ltru@lists.ietf.org; Tue, 30 Oct 2007 04:03:14 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imm43-0004tT-OV for ltru@lists.ietf.org; Tue, 30 Oct 2007 04:03:14 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 29 Oct 2007 22:36:29 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Mon, 29 Oct 2007 22:36:34 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Mon, 29 Oct 2007 22:36:30 -0700 Thread-Topic: Astur-Leonese: a macrolanguage case study Thread-Index: AcgattM0wDGH8FshT02GtKA6hKSoLQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: Subject: [Ltru] Astur-Leonese: a macrolanguage case study X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1832762731==" Errors-To: ltru-bounces@ietf.org --===============1832762731== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C4D4NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C4D4NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's a what-if based on a realistic scenario: "ast" is currently treated = in ISO 639 as an individual-language entry with names "Asturian; Asturleone= se; Bable; Leonese". What if ISO 639 changed the scope of "ast" to macrolan= guage, and added two new encompassed individual-language entries: "Asturian= ; Bable" and "Leonese"? While I haven't yet seen really clear evidence, there are some people claim= ing that Leonese is a distinct language from Asturian and requesting a dist= inct ISO 639 ID. Suppose a sufficient case is made: since "ast" currently d= enotes both the Asturian and Leonese varieties, we cannot simply narrow "as= t" to denote only Asturian and add something new for Leonese. One possible = outcome is the one I describe above: "ast" becomes a macrolanguage. (A poss= ible variation is that Mirandese, "mwl", is included in the macrolanguage.) What would the impact be in a 4646bis world with / without extlang subtags? I suppose that depends on various details of the scenario. (Per above, this= discussion assumes it is already determined that Asturian and Leonese are = distinct.) Possible scenario A: There's a bunch of existing "ast" content, virtually a= ll of which is Asturian, not Leonese. (Note: in principle, the mirror scenario, with Leonese predominant, is hypo= thetically possible, but not in practice: "Asturian" is recognized in Spani= sh law and is actively being developed; if Leonese is functionally distinct= , it does not have comparable status and attention at present.) Possible scenario B: There's a bunch of existing "ast" content, but neither= Asturian or Leonese has a significantly greater proportion that the other. Possible scenario C: There isn't much existing "ast" content. (In terms of general macrolanguage cases, scenario A would be similar to th= e Mandarin versus Cantonese contrast, except that there's nowhere near as m= uch "ast" content as there is "zh" content; scenario C would be similar to = cases like Bikol, Cree, Hmong, Zapotec or several others. Scenario B is pro= bably somewhat akin to "Serbo-Croatian" (hbs), Norwegian (nor) and "Persian= " (fas). For general macrolanguages, there's probably a fourth scenario typ= e: two or more distinct undeveloped varieties exist, and a "standard" devel= oped variety emerges that is either distinct from the former, or is designe= d to be more or less neutral relative to the others - a possible characteri= zation for the Arabic case, and potentially applicable to how some groups s= uch as Dinka or Fulah may evolve.) Peter Microsoft has an open Program Management position working on international = text and fonts. For details, go to: http://members.microsoft.com/careers/search/details.aspx?JobID=3D69CF50EA-5= FB5-47C8-9083-FCE0EF9CF547 --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C4D4NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s a what-if based on a realistic scenario: “ast” is currently treated in ISO 639 as an individual-language entry with names “Asturian; Asturleonese; Bable; Leonese”. What= if ISO 639 changed the scope of “ast” to macrolanguage, and added = two new encompassed individual-language entries: “Asturian; Bable” = and “Leonese”?

 

While I haven’t yet seen really clear evidence, = there are some people claiming that Leonese is a distinct language from Asturian = and requesting a distinct ISO 639 ID. Suppose a sufficient case is made: since = “ast” currently denotes both the Asturian and Leonese varieties, we cannot simply narrow “ast” to denote only Asturian and add something new for Leonese. One possible outcome is the one I describe above: “ast”= ; becomes a macrolanguage. (A possible variation is that Mirandese, “mw= l”, is included in the macrolanguage.)

 

What would the impact be in a 4646bis world with / wit= hout extlang subtags?

 

I suppose that depends on various details of the scena= rio. (Per above, this discussion assumes it is already determined that Asturian = and Leonese are distinct.)

 

Possible scenario A: There’s a bunch of existing= “ast” content, virtually all of which is Asturian, not Leonese.

 

(Note: in principle, the mirror scenario, with Leonese= predominant, is hypothetically possible, but not in practice: “Asturian” is recognized in Spanish law and is actively being developed; if Leonese is functionally distinct, it does not have comparable status and attention at present.)

 

Possible scenario B: There’s a bunch of existing= “ast” content, but neither Asturian or Leonese has a significantly greater propor= tion that the other.

 

Possible scenario C: There isn’t much existing &= #8220;ast” content.

 

 

(In terms of general macrolanguage cases, scenario A w= ould be similar to the Mandarin versus Cantonese contrast, except that thereR= 17;s nowhere near as much “ast” content as there is “zh” content; scenario C would be similar to cases like Bikol, Cree, Hmong, Zapo= tec or several others. Scenario B is probably somewhat akin to “Serbo-Croati= an” (hbs), Norwegian (nor) and “Persian” (fas). For general macrola= nguages, there’s probably a fourth scenario type: two or more distinct undevel= oped varieties exist, and a “standard” developed variety emerges tha= t is either distinct from the former, or is designed to be more or less neutral relative to the others – a possible characterization for the Arabic c= ase, and potentially applicable to how some groups such as Dinka or Fulah may evolve.)

 

 

Peter

&nb= sp;

Microsof= t has an open Program Management position working on international text and fonts. F= or details, go to:

http://members.microsoft.com/careers/s= earch/details.aspx?JobID=3D69CF50EA-5FB5-47C8-9083-FCE0EF9CF547<= span style=3D'font-size:9.0pt'>

 

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C4D4NAEXMSGC117re_-- --===============1832762731== 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 --===============1832762731==-- From ltru-bounces@ietf.org Tue Oct 30 10:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsMW-0005pT-SG; Tue, 30 Oct 2007 10:46:36 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1ImsMV-0005os-Jb for ltru-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 10:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsMV-0005oj-A5 for ltru@lists.ietf.org; Tue, 30 Oct 2007 10:46:35 -0400 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImsMO-0006yb-Dv for ltru@lists.ietf.org; Tue, 30 Oct 2007 10:46:35 -0400 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1ImsM5-0004se-HK; Tue, 30 Oct 2007 10:46:09 -0400 Date: Tue, 30 Oct 2007 10:46:09 -0400 To: Peter Constable Subject: Re: [Ltru] Astur-Leonese: a macrolanguage case study Message-ID: <20071030144609.GD11046@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > What would the impact be in a 4646bis world with / without extlang subtags? Without extlang subtags, of course, nothing happens. Once a primary language subtag, always a primary language subtag, so both camps agree that 'mwl' remains unchanged. I'd argue for adding the new code elements as extlang subtags, but I could live with restricting extlangs to the set as of Date C. In either case the "Macrolanguage:" header gets inserted into the records for the new subtags. -- I could dance with you till the cows John Cowan come home. On second thought, I'd http://www.ccil.org/~cowan rather dance with the cows when you cowan@ccil.org came home. --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Oct 30 11:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imsxh-000218-DQ; Tue, 30 Oct 2007 11:25:01 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Imsxg-0001vs-Hm for ltru-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 11:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imsxg-0001pL-7n for ltru@ietf.org; Tue, 30 Oct 2007 11:25:00 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImsxP-0008H8-W8 for ltru@ietf.org; Tue, 30 Oct 2007 11:24:50 -0400 Received: from [10.72.74.12] (snvvpn1-10-72-74-c12.corp.yahoo.com [10.72.74.12]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id l9UFNe8B086831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Oct 2007 08:23:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=sHn8Pr5GIDt1SfB6rXyLaCdmpwplpX9lRCPWGbTejFbQS2EBmxPBj1wd7n7gY2cS Message-ID: <47274C7B.5020903@yahoo-inc.com> Date: Tue, 30 Oct 2007 08:23:39 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] teleconference timing this week?? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Chairs, Could you please choose and announce an appropriate time for teleconferences? I think there is general agreement from those participating that these are valuable. However, we have enjoyed relatively low participation. It would be good to announce the time and details in advance. I'm happy to continue providing access via our teleconferencing service. Our last meeting (at 6 a.m. Pacific Daylight Time on Thursday) was somewhat inconvenient and now time changes are starting to occur between Summer and Standard time, rendering the call more inconvenient for some. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG 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 30 12:19:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtni-00073o-4l; Tue, 30 Oct 2007 12:18:46 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Imtnh-00073j-TU for ltru-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtnh-00072r-JU for ltru@lists.ietf.org; Tue, 30 Oct 2007 12:18:45 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imtna-0001st-Ln for ltru@lists.ietf.org; Tue, 30 Oct 2007 12:18:45 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 30 Oct 2007 09:18:02 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 30 Oct 2007 09:18:07 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Tue, 30 Oct 2007 09:18:06 -0700 Subject: RE: [Ltru] Astur-Leonese: a macrolanguage case study Thread-Topic: [Ltru] Astur-Leonese: a macrolanguage case study Thread-Index: AcgbA54Wr6kAkIb5TY25us7N4gAqKwADJgtQ Message-ID: References: <20071030144609.GD11046@mercury.ccil.org> In-Reply-To: <20071030144609.GD11046@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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="===============1459513200==" Errors-To: ltru-bounces@ietf.org --===============1459513200== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C576NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C576NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:cowan@ccil.org] > > What would the impact be in a 4646bis world with / without extlang > subtags? > > Without extlang subtags, of course, nothing happens. Nothing happens to tags; that doesn't mean there isn't any impact for data,= tagging recommendations and matching behaviour / implementations. Peter Microsoft has an open Program Management position working on international = text and fonts. For details, go to: http://members.microsoft.com/careers/search/details.aspx?JobID=3D69CF50EA-5= FB5-47C8-9083-FCE0EF9CF547 --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C576NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> From: John Cowan [mailto:cowan@ccil.org]

 

 

> > What would the impact be in a 4646bis wor= ld with / without extlang

> subtags?

>

> Without extlang subtags, of course, nothing ha= ppens.

 

Nothing happens to tags= ; that doesn't mean there isn't any impact for data, tagging recommendations and m= atching behaviour / implementations.

 

 

 

Peter=

 

Microsof= t has an open Program Management position working on international text and fonts. F= or details, go to:

http://members.microsoft.com/careers/se= arch/details.aspx?JobID=3D69CF50EA-5FB5-47C8-9083-FCE0EF9CF547

 

 

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C576NAEXMSGC117re_-- --===============1459513200== 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 --===============1459513200==-- From ltru-bounces@ietf.org Tue Oct 30 12:25:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtu3-0000Yo-7L; Tue, 30 Oct 2007 12:25:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Imtu2-0000XV-BW for ltru-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imtu2-0000XN-1s for ltru@lists.ietf.org; Tue, 30 Oct 2007 12:25:18 -0400 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imttu-00024s-Iy for ltru@lists.ietf.org; Tue, 30 Oct 2007 12:25:18 -0400 Received: by rv-out-0910.google.com with SMTP id k20so1924872rvb for ; Tue, 30 Oct 2007 09:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=KSYrNeaSJSaFbvwZug4pq60ocDaM/I7g/8VJ4PFyfig=; b=cm+IK9pRxEdDVVqMSvdfumQJsLA6/f2fOaLPRr8yC4LV0lyr86Qmq97m//l6fyOQBdaCbS/xUXXmOqGudwsXNkOO9XUvNQIgLqQ5iaijPJyNnine5hxRpveJw/ovn2UbVDueJvL172rvNgj7arOAgnR1CyR5dHe/+1UpXJEPneA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MmJQ72W6FlFiuzr1aTRRgWjgxsPKCu8m0LYjWHiS/5OiyMiFgPBQmVDaX64a93k7yrovbXybRJBe5dBCgwiRQyfN/TczmhobdEg0LkIFeKYn5cEi6uz7qawGoxWH9habf0fg6UtbLoZ4+4VO9OALZcf79O/UqdClnUlclMZ48No= Received: by 10.141.141.3 with SMTP id t3mr3420543rvn.1193761494739; Tue, 30 Oct 2007 09:24:54 -0700 (PDT) Received: by 10.141.211.8 with HTTP; Tue, 30 Oct 2007 09:24:54 -0700 (PDT) Message-ID: <41a006820710300924q4b9fe977yb52d1174cebf8294@mail.gmail.com> Date: Tue, 30 Oct 2007 17:24:54 +0100 From: GerardM To: "Peter Constable" Subject: Re: [Ltru] Astur-Leonese: a macrolanguage case study In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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="===============1763980514==" Errors-To: ltru-bounces@ietf.org --===============1763980514== Content-Type: multipart/alternative; boundary="----=_Part_1425_4104597.1193761494733" ------=_Part_1425_4104597.1193761494733 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SG9pLApXaGVuIHRoZXJlIGlzIGEgbGFuZ3VhZ2UgY29udGludXVtLCB0aGVyZSBjYW4gYmUgYSBk aXN0aW5jdGlvbiBiZXR3ZWVuIG9uZQphbmQgdGhlIG90aGVyIHdpdGhvdXQgdGhlcmUgYmVpbmcg YSByZWFzb24gZm9yIHNlcGFyYXRlIGxhbmd1YWdlIGNvZGVzLiBBCmxhbmd1YWdlIGNvZGUgb25s eSBtYWtlcyBzZW5zZSB3aGVuIHRoZSBsYW5ndWFnZXMgYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4K VGhlIElTTy02MzktMyBkb2VzIG5vdCBjYXRlciB3ZWxsIGZvciB0aGlzLiBUaGUgSVNPLTYzOS02 IHdpbGwgcHJvdmlkZSB0aGUKaGllcmFyY2hpY2FsIHN0cnVjdHVyZSBuZWVkZWQgdG8gZGVhbCBw cm9wZXJseSB3aXRoIHRoZXNlIGlzc3Vlcy4KCklTTy02MzktMyBvbmx5IGFsbG93cyBmb3IgeWVz L25vIGRpZmZlcmVudCBhbmQgdGhlcmUgYXJlIHJlYXNvbnMgd2h5IHlvdQp3YW50IHRvIG1ha2Ug YSBkaXN0aW5jdGlvbiB3aXRob3V0IHByb25vdW5jaW5nIGl0IGEgbGFuZ3VhZ2UuIFRoZSBzYW1l IGlzCnRydWUgZm9yIE1vbnRlbmVncmluLiBUZWNobmljYWxseSBpcyBpcyBub3QgYSBkaWZmZXJl bnQgbGFuZ3VhZ2UuIFlvdSBkbwpob3dldmVyIHdhbnQgdG8gYmUgYWJsZSB0byBpbmRpY2F0ZSBp dCBiZWluZyBNb250ZW5lZ3Jpbi4KClNvIGZyb20gbXkgcGVyc3BlY3RpdmUsIGFyZSB0aGVzZSBw YXJ0IG9mIGEgbGFuZ3VhZ2UgY29udGludXVtIG9yIGFyZSB0aGV5Cm11dHVhbGx5IGV4Y2x1c2l2 ZSA/CgpUaGFua3MsCiAgICBHZXJhcmQKCk9uIDEwLzMwLzA3LCBQZXRlciBDb25zdGFibGUgPHBl dGVyY29uQG1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4gIEhlcmUncyBhIHdoYXQtaWYgYmFzZWQg b24gYSByZWFsaXN0aWMgc2NlbmFyaW86ICJhc3QiIGlzIGN1cnJlbnRseQo+IHRyZWF0ZWQgaW4g SVNPIDYzOSBhcyBhbiBpbmRpdmlkdWFsLWxhbmd1YWdlIGVudHJ5IHdpdGggbmFtZXMgIkFzdHVy aWFuOwo+IEFzdHVybGVvbmVzZTsgQmFibGU7IExlb25lc2UiLiBXaGF0IGlmIElTTyA2MzkgY2hh bmdlZCB0aGUgc2NvcGUgb2YgImFzdCIgdG8KPiBtYWNyb2xhbmd1YWdlLCBhbmQgYWRkZWQgdHdv IG5ldyBlbmNvbXBhc3NlZCBpbmRpdmlkdWFsLWxhbmd1YWdlIGVudHJpZXM6Cj4gIkFzdHVyaWFu OyBCYWJsZSIgYW5kICJMZW9uZXNlIj8KPgo+Cj4KPiBXaGlsZSBJIGhhdmVuJ3QgeWV0IHNlZW4g cmVhbGx5IGNsZWFyIGV2aWRlbmNlLCB0aGVyZSBhcmUgc29tZSBwZW9wbGUKPiBjbGFpbWluZyB0 aGF0IExlb25lc2UgaXMgYSBkaXN0aW5jdCBsYW5ndWFnZSBmcm9tIEFzdHVyaWFuIGFuZCByZXF1 ZXN0aW5nIGEKPiBkaXN0aW5jdCBJU08gNjM5IElELiBTdXBwb3NlIGEgc3VmZmljaWVudCBjYXNl IGlzIG1hZGU6IHNpbmNlICJhc3QiCj4gY3VycmVudGx5IGRlbm90ZXMgYm90aCB0aGUgQXN0dXJp YW4gYW5kIExlb25lc2UgdmFyaWV0aWVzLCB3ZSBjYW5ub3Qgc2ltcGx5Cj4gbmFycm93ICJhc3Qi IHRvIGRlbm90ZSBvbmx5IEFzdHVyaWFuIGFuZCBhZGQgc29tZXRoaW5nIG5ldyBmb3IgTGVvbmVz ZS4gT25lCj4gcG9zc2libGUgb3V0Y29tZSBpcyB0aGUgb25lIEkgZGVzY3JpYmUgYWJvdmU6ICJh c3QiIGJlY29tZXMgYSBtYWNyb2xhbmd1YWdlLgo+IChBIHBvc3NpYmxlIHZhcmlhdGlvbiBpcyB0 aGF0IE1pcmFuZGVzZSwgIm13bCIsIGlzIGluY2x1ZGVkIGluIHRoZQo+IG1hY3JvbGFuZ3VhZ2Uu KQo+Cj4KPgo+IFdoYXQgd291bGQgdGhlIGltcGFjdCBiZSBpbiBhIDQ2NDZiaXMgd29ybGQgd2l0 aCAvIHdpdGhvdXQgZXh0bGFuZwo+IHN1YnRhZ3M/Cj4KPgo+Cj4gSSBzdXBwb3NlIHRoYXQgZGVw ZW5kcyBvbiB2YXJpb3VzIGRldGFpbHMgb2YgdGhlIHNjZW5hcmlvLiAoUGVyIGFib3ZlLAo+IHRo aXMgZGlzY3Vzc2lvbiBhc3N1bWVzIGl0IGlzIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IEFzdHVy aWFuIGFuZCBMZW9uZXNlCj4gYXJlIGRpc3RpbmN0LikKPgo+Cj4KPiBQb3NzaWJsZSBzY2VuYXJp byBBOiBUaGVyZSdzIGEgYnVuY2ggb2YgZXhpc3RpbmcgImFzdCIgY29udGVudCwgdmlydHVhbGx5 Cj4gYWxsIG9mIHdoaWNoIGlzIEFzdHVyaWFuLCBub3QgTGVvbmVzZS4KPgo+Cj4KPiAoTm90ZTog aW4gcHJpbmNpcGxlLCB0aGUgbWlycm9yIHNjZW5hcmlvLCB3aXRoIExlb25lc2UgcHJlZG9taW5h bnQsIGlzCj4gaHlwb3RoZXRpY2FsbHkgcG9zc2libGUsIGJ1dCBub3QgaW4gcHJhY3RpY2U6ICJB c3R1cmlhbiIgaXMgcmVjb2duaXplZCBpbgo+IFNwYW5pc2ggbGF3IGFuZCBpcyBhY3RpdmVseSBi ZWluZyBkZXZlbG9wZWQ7IGlmIExlb25lc2UgaXMgZnVuY3Rpb25hbGx5Cj4gZGlzdGluY3QsIGl0 IGRvZXMgbm90IGhhdmUgY29tcGFyYWJsZSBzdGF0dXMgYW5kIGF0dGVudGlvbiBhdCBwcmVzZW50 LikKPgo+Cj4KPiBQb3NzaWJsZSBzY2VuYXJpbyBCOiBUaGVyZSdzIGEgYnVuY2ggb2YgZXhpc3Rp bmcgImFzdCIgY29udGVudCwgYnV0Cj4gbmVpdGhlciBBc3R1cmlhbiBvciBMZW9uZXNlIGhhcyBh IHNpZ25pZmljYW50bHkgZ3JlYXRlciBwcm9wb3J0aW9uIHRoYXQgdGhlCj4gb3RoZXIuCj4KPgo+ Cj4gUG9zc2libGUgc2NlbmFyaW8gQzogVGhlcmUgaXNuJ3QgbXVjaCBleGlzdGluZyAiYXN0IiBj b250ZW50Lgo+Cj4KPgo+Cj4KPiAoSW4gdGVybXMgb2YgZ2VuZXJhbCBtYWNyb2xhbmd1YWdlIGNh c2VzLCBzY2VuYXJpbyBBIHdvdWxkIGJlIHNpbWlsYXIgdG8KPiB0aGUgTWFuZGFyaW4gdmVyc3Vz IENhbnRvbmVzZSBjb250cmFzdCwgZXhjZXB0IHRoYXQgdGhlcmUncyBub3doZXJlIG5lYXIgYXMK PiBtdWNoICJhc3QiIGNvbnRlbnQgYXMgdGhlcmUgaXMgInpoIiBjb250ZW50OyBzY2VuYXJpbyBD IHdvdWxkIGJlIHNpbWlsYXIgdG8KPiBjYXNlcyBsaWtlIEJpa29sLCBDcmVlLCBIbW9uZywgWmFw b3RlYyBvciBzZXZlcmFsIG90aGVycy4gU2NlbmFyaW8gQiBpcwo+IHByb2JhYmx5IHNvbWV3aGF0 IGFraW4gdG8gIlNlcmJvLUNyb2F0aWFuIiAoaGJzKSwgTm9yd2VnaWFuIChub3IpIGFuZAo+ICJQ ZXJzaWFuIiAoZmFzKS4gRm9yIGdlbmVyYWwgbWFjcm9sYW5ndWFnZXMsIHRoZXJlJ3MgcHJvYmFi bHkgYSBmb3VydGgKPiBzY2VuYXJpbyB0eXBlOiB0d28gb3IgbW9yZSBkaXN0aW5jdCB1bmRldmVs b3BlZCB2YXJpZXRpZXMgZXhpc3QsIGFuZCBhCj4gInN0YW5kYXJkIiBkZXZlbG9wZWQgdmFyaWV0 eSBlbWVyZ2VzIHRoYXQgaXMgZWl0aGVyIGRpc3RpbmN0IGZyb20gdGhlCj4gZm9ybWVyLCBvciBp cyBkZXNpZ25lZCB0byBiZSBtb3JlIG9yIGxlc3MgbmV1dHJhbCByZWxhdGl2ZSB0byB0aGUgb3Ro ZXJzIOKAkyBhCj4gcG9zc2libGUgY2hhcmFjdGVyaXphdGlvbiBmb3IgdGhlIEFyYWJpYyBjYXNl LCBhbmQgcG90ZW50aWFsbHkgYXBwbGljYWJsZSB0bwo+IGhvdyBzb21lIGdyb3VwcyBzdWNoIGFz IERpbmthIG9yIEZ1bGFoIG1heSBldm9sdmUuKQo+Cj4KPgo+Cj4KPiBQZXRlcgo+Cj4KPgo+IE1p Y3Jvc29mdCBoYXMgYW4gb3BlbiBQcm9ncmFtIE1hbmFnZW1lbnQgcG9zaXRpb24gd29ya2luZyBv biBpbnRlcm5hdGlvbmFsCj4gdGV4dCBhbmQgZm9udHMuIEZvciBkZXRhaWxzLCBnbyB0bzoKPgo+ Cj4gaHR0cDovL21lbWJlcnMubWljcm9zb2Z0LmNvbS9jYXJlZXJzL3NlYXJjaC9kZXRhaWxzLmFz cHg/Sm9iSUQ9NjlDRjUwRUEtNUZCNS00N0M4LTkwODMtRkNFMEVGOUNGNTQ3Cj4KPgo+Cj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBMdHJ1IG1haWxp bmcgbGlzdAo+IEx0cnVAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sdHJ1Cj4KPgo= ------=_Part_1425_4104597.1193761494733 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SG9pLDxicj5XaGVuIHRoZXJlIGlzIGEgbGFuZ3VhZ2UgY29udGludXVtLCB0aGVyZSBjYW4gYmUg YSBkaXN0aW5jdGlvbgpiZXR3ZWVuIG9uZSBhbmQgdGhlIG90aGVyIHdpdGhvdXQgdGhlcmUgYmVp bmcgYSByZWFzb24gZm9yIHNlcGFyYXRlCmxhbmd1YWdlIGNvZGVzLiBBIGxhbmd1YWdlIGNvZGUg b25seSBtYWtlcyBzZW5zZSB3aGVuIHRoZSBsYW5ndWFnZXMgYXJlCm11dHVhbGx5IGV4Y2x1c2l2 ZS4gVGhlIElTTy02MzktMyBkb2VzIG5vdCBjYXRlciB3ZWxsIGZvciB0aGlzLiBUaGUKSVNPLTYz OS02IHdpbGwgcHJvdmlkZSB0aGUgaGllcmFyY2hpY2FsIHN0cnVjdHVyZSBuZWVkZWQgdG8gZGVh bApwcm9wZXJseSB3aXRoIHRoZXNlIGlzc3Vlcy4gPGJyPjxicj5JU08tNjM5LTMgb25seSBhbGxv d3MgZm9yIHllcy9ubyBkaWZmZXJlbnQgYW5kIHRoZXJlIGFyZQpyZWFzb25zIHdoeSB5b3Ugd2Fu dCB0byBtYWtlIGEgZGlzdGluY3Rpb24gd2l0aG91dCBwcm9ub3VuY2luZyBpdCBhCmxhbmd1YWdl LiBUaGUgc2FtZSBpcyB0cnVlIGZvciBNb250ZW5lZ3Jpbi4gVGVjaG5pY2FsbHkgaXMgaXMgbm90 IGEKZGlmZmVyZW50IGxhbmd1YWdlLiBZb3UgZG8gaG93ZXZlciB3YW50IHRvIGJlIGFibGUgdG8g aW5kaWNhdGUgaXQgYmVpbmcKTW9udGVuZWdyaW4uCjxicj48YnI+U28gZnJvbSBteSBwZXJzcGVj dGl2ZSwgYXJlIHRoZXNlIHBhcnQgb2YgYSBsYW5ndWFnZSBjb250aW51dW0gb3IgYXJlIHRoZXkg bXV0dWFsbHkgZXhjbHVzaXZlID88YnI+PGJyPlRoYW5rcyw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEdlcmFyZCA8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAxMC8zMC8w NywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlBldGVyIENvbnN0YWJsZQo8L2I+ICZsdDs8 YSBocmVmPSJtYWlsdG86cGV0ZXJjb25AbWljcm9zb2Z0LmNvbSI+cGV0ZXJjb25AbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2lu OiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KCgoKCgoKCgoKPGRpdiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPHA+SGVyZSdz IGEgd2hhdC1pZiBiYXNlZCBvbiBhIHJlYWxpc3RpYyBzY2VuYXJpbzoKImFzdCIgaXMgY3VycmVu dGx5IHRyZWF0ZWQgaW4gSVNPIDYzOSBhcyBhbiBpbmRpdmlkdWFsLWxhbmd1YWdlCmVudHJ5IHdp dGggbmFtZXMgIkFzdHVyaWFuOyBBc3R1cmxlb25lc2U7IEJhYmxlOyBMZW9uZXNlIi4gV2hhdCBp ZgpJU08gNjM5IGNoYW5nZWQgdGhlIHNjb3BlIG9mICJhc3QiIHRvIG1hY3JvbGFuZ3VhZ2UsIGFu ZCBhZGRlZCB0d28KbmV3IGVuY29tcGFzc2VkIGluZGl2aWR1YWwtbGFuZ3VhZ2UgZW50cmllczog IkFzdHVyaWFuOyBCYWJsZSIgYW5kCiJMZW9uZXNlIj88L3A+Cgo8cD4mbmJzcDs8L3A+Cgo8cD5X aGlsZSBJIGhhdmVuJ3QgeWV0IHNlZW4gcmVhbGx5IGNsZWFyIGV2aWRlbmNlLCB0aGVyZQphcmUg c29tZSBwZW9wbGUgY2xhaW1pbmcgdGhhdCBMZW9uZXNlIGlzIGEgZGlzdGluY3QgbGFuZ3VhZ2Ug ZnJvbSBBc3R1cmlhbiBhbmQKcmVxdWVzdGluZyBhIGRpc3RpbmN0IElTTyA2MzkgSUQuIFN1cHBv c2UgYSBzdWZmaWNpZW50IGNhc2UgaXMgbWFkZTogc2luY2UgImFzdCIKY3VycmVudGx5IGRlbm90 ZXMgYm90aCB0aGUgQXN0dXJpYW4gYW5kIExlb25lc2UgdmFyaWV0aWVzLCB3ZSBjYW5ub3Qgc2lt cGx5Cm5hcnJvdyAiYXN0IiB0byBkZW5vdGUgb25seSBBc3R1cmlhbiBhbmQgYWRkIHNvbWV0aGlu ZyBuZXcgZm9yCkxlb25lc2UuIE9uZSBwb3NzaWJsZSBvdXRjb21lIGlzIHRoZSBvbmUgSSBkZXNj cmliZSBhYm92ZTogImFzdCIKYmVjb21lcyBhIG1hY3JvbGFuZ3VhZ2UuIChBIHBvc3NpYmxlIHZh cmlhdGlvbiBpcyB0aGF0IE1pcmFuZGVzZSwgIm13bCIsCmlzIGluY2x1ZGVkIGluIHRoZSBtYWNy b2xhbmd1YWdlLik8L3A+Cgo8cD4mbmJzcDs8L3A+Cgo8cD5XaGF0IHdvdWxkIHRoZSBpbXBhY3Qg YmUgaW4gYSA0NjQ2YmlzIHdvcmxkIHdpdGggLyB3aXRob3V0CmV4dGxhbmcgc3VidGFncz88L3A+ Cgo8cD4mbmJzcDs8L3A+Cgo8cD5JIHN1cHBvc2UgdGhhdCBkZXBlbmRzIG9uIHZhcmlvdXMgZGV0 YWlscyBvZiB0aGUgc2NlbmFyaW8uCihQZXIgYWJvdmUsIHRoaXMgZGlzY3Vzc2lvbiBhc3N1bWVz IGl0IGlzIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IEFzdHVyaWFuIGFuZApMZW9uZXNlIGFyZSBk aXN0aW5jdC4pPC9wPgoKPHA+Jm5ic3A7PC9wPgoKPHA+UG9zc2libGUgc2NlbmFyaW8gQTogVGhl cmUncyBhIGJ1bmNoIG9mIGV4aXN0aW5nICJhc3QiCmNvbnRlbnQsIHZpcnR1YWxseSBhbGwgb2Yg d2hpY2ggaXMgQXN0dXJpYW4sIG5vdCBMZW9uZXNlLiA8L3A+Cgo8cD4mbmJzcDs8L3A+Cgo8cD4o Tm90ZTogaW4gcHJpbmNpcGxlLCB0aGUgbWlycm9yIHNjZW5hcmlvLCB3aXRoIExlb25lc2UgcHJl ZG9taW5hbnQsCmlzIGh5cG90aGV0aWNhbGx5IHBvc3NpYmxlLCBidXQgbm90IGluIHByYWN0aWNl OiAiQXN0dXJpYW4iIGlzCnJlY29nbml6ZWQgaW4gU3BhbmlzaCBsYXcgYW5kIGlzIGFjdGl2ZWx5 IGJlaW5nIGRldmVsb3BlZDsgaWYgTGVvbmVzZSBpcwpmdW5jdGlvbmFsbHkgZGlzdGluY3QsIGl0 IGRvZXMgbm90IGhhdmUgY29tcGFyYWJsZSBzdGF0dXMgYW5kIGF0dGVudGlvbiBhdApwcmVzZW50 Lik8L3A+Cgo8cD4mbmJzcDs8L3A+Cgo8cD5Qb3NzaWJsZSBzY2VuYXJpbyBCOiBUaGVyZSdzIGEg YnVuY2ggb2YgZXhpc3RpbmcgImFzdCIKY29udGVudCwgYnV0IG5laXRoZXIgQXN0dXJpYW4gb3Ig TGVvbmVzZSBoYXMgYSBzaWduaWZpY2FudGx5IGdyZWF0ZXIgcHJvcG9ydGlvbgp0aGF0IHRoZSBv dGhlci48L3A+Cgo8cD4mbmJzcDs8L3A+Cgo8cD5Qb3NzaWJsZSBzY2VuYXJpbyBDOiBUaGVyZSBp c24ndCBtdWNoIGV4aXN0aW5nICJhc3QiCmNvbnRlbnQuPC9wPgoKPHA+Jm5ic3A7PC9wPgoKPHA+ Jm5ic3A7PC9wPgoKPHA+KEluIHRlcm1zIG9mIGdlbmVyYWwgbWFjcm9sYW5ndWFnZSBjYXNlcywg c2NlbmFyaW8gQSB3b3VsZApiZSBzaW1pbGFyIHRvIHRoZSBNYW5kYXJpbiB2ZXJzdXMgQ2FudG9u ZXNlIGNvbnRyYXN0LCBleGNlcHQgdGhhdCB0aGVyZSdzCm5vd2hlcmUgbmVhciBhcyBtdWNoICJh c3QiIGNvbnRlbnQgYXMgdGhlcmUgaXMgInpoIgpjb250ZW50OyBzY2VuYXJpbyBDIHdvdWxkIGJl IHNpbWlsYXIgdG8gY2FzZXMgbGlrZSBCaWtvbCwgQ3JlZSwgSG1vbmcsIFphcG90ZWMgb3IKc2V2 ZXJhbCBvdGhlcnMuIFNjZW5hcmlvIEIgaXMgcHJvYmFibHkgc29tZXdoYXQgYWtpbiB0byAiU2Vy Ym8tQ3JvYXRpYW4iCihoYnMpLCBOb3J3ZWdpYW4gKG5vcikgYW5kICJQZXJzaWFuIiAoZmFzKS4g Rm9yIGdlbmVyYWwgbWFjcm9sYW5ndWFnZXMsCnRoZXJlJ3MgcHJvYmFibHkgYSBmb3VydGggc2Nl bmFyaW8gdHlwZTogdHdvIG9yIG1vcmUgZGlzdGluY3QgdW5kZXZlbG9wZWQKdmFyaWV0aWVzIGV4 aXN0LCBhbmQgYSAic3RhbmRhcmQiIGRldmVsb3BlZCB2YXJpZXR5IGVtZXJnZXMgdGhhdCBpcwpl aXRoZXIgZGlzdGluY3QgZnJvbSB0aGUgZm9ybWVyLCBvciBpcyBkZXNpZ25lZCB0byBiZSBtb3Jl IG9yIGxlc3MgbmV1dHJhbApyZWxhdGl2ZSB0byB0aGUgb3RoZXJzIOKAkyBhIHBvc3NpYmxlIGNo YXJhY3Rlcml6YXRpb24gZm9yIHRoZSBBcmFiaWMgY2FzZSwKYW5kIHBvdGVudGlhbGx5IGFwcGxp Y2FibGUgdG8gaG93IHNvbWUgZ3JvdXBzIHN1Y2ggYXMgRGlua2Egb3IgRnVsYWggbWF5CmV2b2x2 ZS4pPC9wPgoKPHA+Jm5ic3A7PC9wPgoKPHA+Jm5ic3A7PC9wPgoKPHA+UGV0ZXI8L3A+Cgo8cD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGNvbG9yOiByZ2IoMTQ4LCA1NCwgNTIpOyI+Jm5i c3A7PC9zcGFuPjwvcD4KCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgY29sb3I6IHJn YigxNDgsIDU0LCA1Mik7Ij5NaWNyb3NvZnQgaGFzIGFuCm9wZW4gUHJvZ3JhbSBNYW5hZ2VtZW50 IHBvc2l0aW9uIHdvcmtpbmcgb24gaW50ZXJuYXRpb25hbCB0ZXh0IGFuZCBmb250cy4gRm9yCmRl dGFpbHMsIGdvIHRvOjwvc3Bhbj48L3A+Cgo8cD48YSBocmVmPSJodHRwOi8vbWVtYmVycy5taWNy b3NvZnQuY29tL2NhcmVlcnMvc2VhcmNoL2RldGFpbHMuYXNweD9Kb2JJRD02OUNGNTBFQS01RkI1 LTQ3QzgtOTA4My1GQ0UwRUY5Q0Y1NDciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4g dG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOXB0OyBjb2xvcjogYmx1ZTsiPgpodHRwOi8vbWVtYmVycy5taWNyb3NvZnQuY29tL2Nh cmVlcnMvc2VhcmNoL2RldGFpbHMuYXNweD9Kb2JJRD02OUNGNTBFQS01RkI1LTQ3QzgtOTA4My1G Q0UwRUY5Q0Y1NDc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsiPjwvc3Bh bj48L3A+Cgo8cD4mbmJzcDs8L3A+Cgo8L2Rpdj4KCjwvZGl2PgoKCjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxpbmcgbGlzdDxi cj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSIgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmciPkx0cnVAaWV0Zi5vcmc8L2E+PGJyPjxhIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVm PSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9i bGFuayI+Cmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJy Pjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= ------=_Part_1425_4104597.1193761494733-- --===============1763980514== 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 --===============1763980514==-- From ltru-bounces@ietf.org Tue Oct 30 13:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imv5d-0000Vw-Ca; Tue, 30 Oct 2007 13:41:21 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Imv5c-0000VO-JQ for ltru-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 13:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imv5c-0000VA-9W for ltru@lists.ietf.org; Tue, 30 Oct 2007 13:41:20 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imv5V-00055c-NI for ltru@lists.ietf.org; Tue, 30 Oct 2007 13:41:20 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 30 Oct 2007 10:40:46 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Tue, 30 Oct 2007 10:40:52 -0700 From: Peter Constable To: "ltru@lists.ietf.org" Date: Tue, 30 Oct 2007 10:40:50 -0700 Subject: RE: [Ltru] Astur-Leonese: a macrolanguage case study Thread-Topic: [Ltru] Astur-Leonese: a macrolanguage case study Thread-Index: AcgbEWmahrNAaSJcS9WlzieNDUskQAACokvg Message-ID: References: <41a006820710300924q4b9fe977yb52d1174cebf8294@mail.gmail.com> In-Reply-To: <41a006820710300924q4b9fe977yb52d1174cebf8294@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 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="===============1313176091==" Errors-To: ltru-bounces@ietf.org --===============1313176091== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C62ENAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C62ENAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUgaGllcmFyY2hpY2FsIHN0cnVjdHVyZSwgSSBkb27igJl0IGtub3cgb2YgYSBuZWVkIGZvciB0 YWdzIHRvIHJlZmxlY3QgaGllcmFyY2hpY2FsIHN0cnVjdHVyZSBpbiBnZW5lcmFsLg0KDQpJU08g NjM5LTMgZG9lcyBub3QgcmVxdWlyZSBtdXR1YWwgZXhjbHVzaXZpdHkgaW4gdGhlIGNhc2Ugb2Yg bWFjcm9sYW5ndWFnZXMuIEl0IGRvZXMgbGltaXQgdGhlIGRlZ3JlZSBvZiBzcGVjaWZpY2l0eSB0 byBkaXN0aW5jdGlvbnMgYmV0d2VlbiBpbmRpdmlkdWFsIGxhbmd1YWdlcywgYW5kIGRvZXMgc28g YnkgZGVzaWduLiBCQ1A0NyBhbGxvd3MgZm9yIGdyZWF0ZXIgc3BlY2lmaWNpdHksIGJlIGRlc2ln biwgYW5kIHNvIHRoZSB0d28gYXJlIGNvbXBsZW1lbnRhcnkuIE9uZSBtaWdodCBzYXkgdGhhdCA2 MzktNiBoYXMgYSBiZW5lZml0IGluIHRoYXQgaXQgaGFzIGFsbCBsZXZlbHMgb2Ygc3BlY2lmaWNp dHksIHRob3VnaCBpbiBzbyBkb2luZyBpdCBzaW1wbHkgZGlzcmVnYXJkcyB0aGUgbGFuZ3VhZ2Uv ZGlhbGVjdCBpc3N1ZTsgdGhhdCBtYXkgbm90IGFsd2F5cyBiZSBhIGJlbmVmaXQgc2luY2UgaXQg cHJvdmlkZXMgbm8gY29udmVudGlvbnMgYXMgdG8gaG93IGNvbnRlbnQgc2hvdWxkIHVzZWZ1bGx5 IGJlIHRhZ2dlZCAoaS5lLiBhdCB3aGF0IGxldmVscyBvZiBzcGVjaWZpY2l0eSkgdGhlcmVieSBo aW5kZXJpbmcgaW50ZXJvcGVyYWJpbGl0eS4gKEludGVyb3AgY2FuIGJlIHJlc3RvcmVkIG9ubHkg YnkgYXBwbGljYXRpb25zIGNhcnJ5aW5nIGxhcmdlIGRhdGEgdGFibGVzLikNCg0KSSBkbyBub3Qg a25vdyBpZiBBc3R1cmlhbiBhbmQgTGVvbmVzZSBzaG91bGQgYmUgY29uc2lkZXJlZCBkaXN0aW5j dCAvIG11dHVhbGx5IGV4Y2x1c2l2ZS4gU3VwcG9zZSB0aGV5IGFyZSBub3Q6IGl04oCZcyBub3Qg Y2xlYXIgaWYgdGhlcmXigJlkIGJlIGEgbmVlZCB0byBoYXZlIGRpc3RpbmN0IHRhZ3MuIElmIHRo ZXJlIGlzIGEgbmVlZCBpbiBzb21lIHNjZW5hcmlvcywgdGhvdWdoLCBCQ1A0NyBwcm92aWRlcyB0 aGUgbWVhbnMuDQoNCg0KUGV0ZXINCg0KTWljcm9zb2Z0IGhhcyBhbiBvcGVuIFByb2dyYW0gTWFu YWdlbWVudCBwb3NpdGlvbiB3b3JraW5nIG9uIGludGVybmF0aW9uYWwgdGV4dCBhbmQgZm9udHMu IEZvciBkZXRhaWxzLCBnbyB0bzoNCmh0dHA6Ly9tZW1iZXJzLm1pY3Jvc29mdC5jb20vY2FyZWVy cy9zZWFyY2gvZGV0YWlscy5hc3B4P0pvYklEPTY5Q0Y1MEVBLTVGQjUtNDdDOC05MDgzLUZDRTBF RjlDRjU0Nw0KDQoNCg0KRnJvbTogR2VyYXJkTSBbbWFpbHRvOmdlcmFyZC5tZWlqc3NlbkBnbWFp bC5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDA3IDk6MjUgQU0NClRvOiBQZXRl ciBDb25zdGFibGUNCkNjOiBsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW0x0cnVd IEFzdHVyLUxlb25lc2U6IGEgbWFjcm9sYW5ndWFnZSBjYXNlIHN0dWR5DQoNCkhvaSwNCldoZW4g dGhlcmUgaXMgYSBsYW5ndWFnZSBjb250aW51dW0sIHRoZXJlIGNhbiBiZSBhIGRpc3RpbmN0aW9u IGJldHdlZW4gb25lIGFuZCB0aGUgb3RoZXIgd2l0aG91dCB0aGVyZSBiZWluZyBhIHJlYXNvbiBm b3Igc2VwYXJhdGUgbGFuZ3VhZ2UgY29kZXMuIEEgbGFuZ3VhZ2UgY29kZSBvbmx5IG1ha2VzIHNl bnNlIHdoZW4gdGhlIGxhbmd1YWdlcyBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiBUaGUgSVNPLTYz OS0zIGRvZXMgbm90IGNhdGVyIHdlbGwgZm9yIHRoaXMuIFRoZSBJU08tNjM5LTYgd2lsbCBwcm92 aWRlIHRoZSBoaWVyYXJjaGljYWwgc3RydWN0dXJlIG5lZWRlZCB0byBkZWFsIHByb3Blcmx5IHdp dGggdGhlc2UgaXNzdWVzLg0KDQpJU08tNjM5LTMgb25seSBhbGxvd3MgZm9yIHllcy9ubyBkaWZm ZXJlbnQgYW5kIHRoZXJlIGFyZSByZWFzb25zIHdoeSB5b3Ugd2FudCB0byBtYWtlIGEgZGlzdGlu Y3Rpb24gd2l0aG91dCBwcm9ub3VuY2luZyBpdCBhIGxhbmd1YWdlLiBUaGUgc2FtZSBpcyB0cnVl IGZvciBNb250ZW5lZ3Jpbi4gVGVjaG5pY2FsbHkgaXMgaXMgbm90IGEgZGlmZmVyZW50IGxhbmd1 YWdlLiBZb3UgZG8gaG93ZXZlciB3YW50IHRvIGJlIGFibGUgdG8gaW5kaWNhdGUgaXQgYmVpbmcg TW9udGVuZWdyaW4uDQoNClNvIGZyb20gbXkgcGVyc3BlY3RpdmUsIGFyZSB0aGVzZSBwYXJ0IG9m IGEgbGFuZ3VhZ2UgY29udGludXVtIG9yIGFyZSB0aGV5IG11dHVhbGx5IGV4Y2x1c2l2ZSA/DQoN ClRoYW5rcywNCiAgICBHZXJhcmQNCk9uIDEwLzMwLzA3LCBQZXRlciBDb25zdGFibGUgPHBldGVy Y29uQG1pY3Jvc29mdC5jb208bWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN Cg0KSGVyZSdzIGEgd2hhdC1pZiBiYXNlZCBvbiBhIHJlYWxpc3RpYyBzY2VuYXJpbzogImFzdCIg aXMgY3VycmVudGx5IHRyZWF0ZWQgaW4gSVNPIDYzOSBhcyBhbiBpbmRpdmlkdWFsLWxhbmd1YWdl IGVudHJ5IHdpdGggbmFtZXMgIkFzdHVyaWFuOyBBc3R1cmxlb25lc2U7IEJhYmxlOyBMZW9uZXNl Ii4gV2hhdCBpZiBJU08gNjM5IGNoYW5nZWQgdGhlIHNjb3BlIG9mICJhc3QiIHRvIG1hY3JvbGFu Z3VhZ2UsIGFuZCBhZGRlZCB0d28gbmV3IGVuY29tcGFzc2VkIGluZGl2aWR1YWwtbGFuZ3VhZ2Ug ZW50cmllczogIkFzdHVyaWFuOyBCYWJsZSIgYW5kICJMZW9uZXNlIj8NCg0KDQoNCldoaWxlIEkg aGF2ZW4ndCB5ZXQgc2VlbiByZWFsbHkgY2xlYXIgZXZpZGVuY2UsIHRoZXJlIGFyZSBzb21lIHBl b3BsZSBjbGFpbWluZyB0aGF0IExlb25lc2UgaXMgYSBkaXN0aW5jdCBsYW5ndWFnZSBmcm9tIEFz dHVyaWFuIGFuZCByZXF1ZXN0aW5nIGEgZGlzdGluY3QgSVNPIDYzOSBJRC4gU3VwcG9zZSBhIHN1 ZmZpY2llbnQgY2FzZSBpcyBtYWRlOiBzaW5jZSAiYXN0IiBjdXJyZW50bHkgZGVub3RlcyBib3Ro IHRoZSBBc3R1cmlhbiBhbmQgTGVvbmVzZSB2YXJpZXRpZXMsIHdlIGNhbm5vdCBzaW1wbHkgbmFy cm93ICJhc3QiIHRvIGRlbm90ZSBvbmx5IEFzdHVyaWFuIGFuZCBhZGQgc29tZXRoaW5nIG5ldyBm b3IgTGVvbmVzZS4gT25lIHBvc3NpYmxlIG91dGNvbWUgaXMgdGhlIG9uZSBJIGRlc2NyaWJlIGFi b3ZlOiAiYXN0IiBiZWNvbWVzIGEgbWFjcm9sYW5ndWFnZS4gKEEgcG9zc2libGUgdmFyaWF0aW9u IGlzIHRoYXQgTWlyYW5kZXNlLCAibXdsIiwgaXMgaW5jbHVkZWQgaW4gdGhlIG1hY3JvbGFuZ3Vh Z2UuKQ0KDQoNCg0KV2hhdCB3b3VsZCB0aGUgaW1wYWN0IGJlIGluIGEgNDY0NmJpcyB3b3JsZCB3 aXRoIC8gd2l0aG91dCBleHRsYW5nIHN1YnRhZ3M/DQoNCg0KDQpJIHN1cHBvc2UgdGhhdCBkZXBl bmRzIG9uIHZhcmlvdXMgZGV0YWlscyBvZiB0aGUgc2NlbmFyaW8uIChQZXIgYWJvdmUsIHRoaXMg ZGlzY3Vzc2lvbiBhc3N1bWVzIGl0IGlzIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IEFzdHVyaWFu IGFuZCBMZW9uZXNlIGFyZSBkaXN0aW5jdC4pDQoNCg0KDQpQb3NzaWJsZSBzY2VuYXJpbyBBOiBU aGVyZSdzIGEgYnVuY2ggb2YgZXhpc3RpbmcgImFzdCIgY29udGVudCwgdmlydHVhbGx5IGFsbCBv ZiB3aGljaCBpcyBBc3R1cmlhbiwgbm90IExlb25lc2UuDQoNCg0KDQooTm90ZTogaW4gcHJpbmNp cGxlLCB0aGUgbWlycm9yIHNjZW5hcmlvLCB3aXRoIExlb25lc2UgcHJlZG9taW5hbnQsIGlzIGh5 cG90aGV0aWNhbGx5IHBvc3NpYmxlLCBidXQgbm90IGluIHByYWN0aWNlOiAiQXN0dXJpYW4iIGlz IHJlY29nbml6ZWQgaW4gU3BhbmlzaCBsYXcgYW5kIGlzIGFjdGl2ZWx5IGJlaW5nIGRldmVsb3Bl ZDsgaWYgTGVvbmVzZSBpcyBmdW5jdGlvbmFsbHkgZGlzdGluY3QsIGl0IGRvZXMgbm90IGhhdmUg Y29tcGFyYWJsZSBzdGF0dXMgYW5kIGF0dGVudGlvbiBhdCBwcmVzZW50LikNCg0KDQoNClBvc3Np YmxlIHNjZW5hcmlvIEI6IFRoZXJlJ3MgYSBidW5jaCBvZiBleGlzdGluZyAiYXN0IiBjb250ZW50 LCBidXQgbmVpdGhlciBBc3R1cmlhbiBvciBMZW9uZXNlIGhhcyBhIHNpZ25pZmljYW50bHkgZ3Jl YXRlciBwcm9wb3J0aW9uIHRoYXQgdGhlIG90aGVyLg0KDQoNCg0KUG9zc2libGUgc2NlbmFyaW8g QzogVGhlcmUgaXNuJ3QgbXVjaCBleGlzdGluZyAiYXN0IiBjb250ZW50Lg0KDQoNCg0KDQoNCihJ biB0ZXJtcyBvZiBnZW5lcmFsIG1hY3JvbGFuZ3VhZ2UgY2FzZXMsIHNjZW5hcmlvIEEgd291bGQg YmUgc2ltaWxhciB0byB0aGUgTWFuZGFyaW4gdmVyc3VzIENhbnRvbmVzZSBjb250cmFzdCwgZXhj ZXB0IHRoYXQgdGhlcmUncyBub3doZXJlIG5lYXIgYXMgbXVjaCAiYXN0IiBjb250ZW50IGFzIHRo ZXJlIGlzICJ6aCIgY29udGVudDsgc2NlbmFyaW8gQyB3b3VsZCBiZSBzaW1pbGFyIHRvIGNhc2Vz IGxpa2UgQmlrb2wsIENyZWUsIEhtb25nLCBaYXBvdGVjIG9yIHNldmVyYWwgb3RoZXJzLiBTY2Vu YXJpbyBCIGlzIHByb2JhYmx5IHNvbWV3aGF0IGFraW4gdG8gIlNlcmJvLUNyb2F0aWFuIiAoaGJz KSwgTm9yd2VnaWFuIChub3IpIGFuZCAiUGVyc2lhbiIgKGZhcykuIEZvciBnZW5lcmFsIG1hY3Jv bGFuZ3VhZ2VzLCB0aGVyZSdzIHByb2JhYmx5IGEgZm91cnRoIHNjZW5hcmlvIHR5cGU6IHR3byBv ciBtb3JlIGRpc3RpbmN0IHVuZGV2ZWxvcGVkIHZhcmlldGllcyBleGlzdCwgYW5kIGEgInN0YW5k YXJkIiBkZXZlbG9wZWQgdmFyaWV0eSBlbWVyZ2VzIHRoYXQgaXMgZWl0aGVyIGRpc3RpbmN0IGZy b20gdGhlIGZvcm1lciwgb3IgaXMgZGVzaWduZWQgdG8gYmUgbW9yZSBvciBsZXNzIG5ldXRyYWwg cmVsYXRpdmUgdG8gdGhlIG90aGVycyDigJMgYSBwb3NzaWJsZSBjaGFyYWN0ZXJpemF0aW9uIGZv ciB0aGUgQXJhYmljIGNhc2UsIGFuZCBwb3RlbnRpYWxseSBhcHBsaWNhYmxlIHRvIGhvdyBzb21l IGdyb3VwcyBzdWNoIGFzIERpbmthIG9yIEZ1bGFoIG1heSBldm9sdmUuKQ0KDQoNCg0KDQoNClBl dGVyDQoNCg0KDQpNaWNyb3NvZnQgaGFzIGFuIG9wZW4gUHJvZ3JhbSBNYW5hZ2VtZW50IHBvc2l0 aW9uIHdvcmtpbmcgb24gaW50ZXJuYXRpb25hbCB0ZXh0IGFuZCBmb250cy4gRm9yIGRldGFpbHMs IGdvIHRvOg0KDQpodHRwOi8vbWVtYmVycy5taWNyb3NvZnQuY29tL2NhcmVlcnMvc2VhcmNoL2Rl dGFpbHMuYXNweD9Kb2JJRD02OUNGNTBFQS01RkI1LTQ3QzgtOTA4My1GQ0UwRUY5Q0Y1NDcNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMdHJ1 IG1haWxpbmcgbGlzdA0KTHRydUBpZXRmLm9yZzxtYWlsdG86THRydUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C62ENAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvYT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCIgeG1sbnM6cT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHht bG5zOkQ9IkRBVjoiIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS9leGNlbC8yMDAzL3htbCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L3NoYXJlcG9pbnQvc29hcC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vc2hhcmVwb2ludC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9kYXRhL3VkYyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgeG1sbnM6c3BzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC8iIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2Ui IHhtbG5zOnVkY3hmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZp bGUiIHhtbG5zOndmPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC93b3JrZmxvdy8iIHhtbG5zOm12ZXI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9y Zy9tYXJrdXAtY29tcGF0aWJpbGl0eS8yMDA2IiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzPSJodHRwOi8vc2NoZW1h cy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L3JlbGF0aW9uc2hpcHMiIHhtbG5zOmV4 MTJ0PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2VzLzIwMDYv dHlwZXMiIHhtbG5zOmV4MTJtPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdl L3NlcnZpY2VzLzIwMDYvbWVzc2FnZXMiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPg0KPCEtLQ0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1 bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNvcmRpYSBOZXciOw0KCXBhbm9zZS0xOjIgMTEgMyA0IDIgMiAyIDIgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUg MyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K IC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u Z21haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbF9xdW90ZTt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjk5LjI1cHQgODUuMDVwdCA4NS4wNXB0IDg1LjA1cHQ7fQ0KZGl2 LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlv bjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+UmUgaGll cmFyY2hpY2FsIHN0cnVjdHVyZSwgSSBkb27igJl0IGtub3cgb2YgYSBuZWVkIGZvciB0YWdzIHRv DQpyZWZsZWN0IGhpZXJhcmNoaWNhbCBzdHJ1Y3R1cmUgaW4gZ2VuZXJhbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPklTTyA2MzktMyBkb2VzIG5vdCByZXF1aXJlIG11dHVhbCBleGNs dXNpdml0eSBpbiB0aGUgY2FzZSBvZg0KbWFjcm9sYW5ndWFnZXMuIEl0IGRvZXMgbGltaXQgdGhl IGRlZ3JlZSBvZiBzcGVjaWZpY2l0eSB0byBkaXN0aW5jdGlvbnMgYmV0d2Vlbg0KaW5kaXZpZHVh bCBsYW5ndWFnZXMsIGFuZCBkb2VzIHNvIGJ5IGRlc2lnbi4gQkNQNDcgYWxsb3dzIGZvciBncmVh dGVyDQpzcGVjaWZpY2l0eSwgYmUgZGVzaWduLCBhbmQgc28gdGhlIHR3byBhcmUgY29tcGxlbWVu dGFyeS4gT25lIG1pZ2h0IHNheSB0aGF0DQo2MzktNiBoYXMgYSBiZW5lZml0IGluIHRoYXQgaXQg aGFzIGFsbCBsZXZlbHMgb2Ygc3BlY2lmaWNpdHksIHRob3VnaCBpbiBzbw0KZG9pbmcgaXQgc2lt cGx5IGRpc3JlZ2FyZHMgdGhlIGxhbmd1YWdlL2RpYWxlY3QgaXNzdWU7IHRoYXQgbWF5IG5vdCBh bHdheXMgYmUgYQ0KYmVuZWZpdCBzaW5jZSBpdCBwcm92aWRlcyBubyBjb252ZW50aW9ucyBhcyB0 byBob3cgY29udGVudCBzaG91bGQgdXNlZnVsbHkgYmUNCnRhZ2dlZCAoaS5lLiBhdCB3aGF0IGxl dmVscyBvZiBzcGVjaWZpY2l0eSkgdGhlcmVieSBoaW5kZXJpbmcgaW50ZXJvcGVyYWJpbGl0eS4N CihJbnRlcm9wIGNhbiBiZSByZXN0b3JlZCBvbmx5IGJ5IGFwcGxpY2F0aW9ucyBjYXJyeWluZyBs YXJnZSBkYXRhIHRhYmxlcy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5JIGRvIG5v dCBrbm93IGlmIEFzdHVyaWFuIGFuZCBMZW9uZXNlIHNob3VsZCBiZSBjb25zaWRlcmVkDQpkaXN0 aW5jdCAvIG11dHVhbGx5IGV4Y2x1c2l2ZS4gU3VwcG9zZSB0aGV5IGFyZSBub3Q6IGl04oCZcyBu b3QgY2xlYXIgaWYgdGhlcmXigJlkDQpiZSBhIG5lZWQgdG8gaGF2ZSBkaXN0aW5jdCB0YWdzLiBJ ZiB0aGVyZSBpcyBhIG5lZWQgaW4gc29tZSBzY2VuYXJpb3MsIHRob3VnaCwNCkJDUDQ3IHByb3Zp ZGVzIHRoZSBtZWFucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MUY0OTdEJz5QZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojOTQzNjM0Jz5NaWNyb3NvZnQgaGFz IGFuIG9wZW4gUHJvZ3JhbSBNYW5hZ2VtZW50IHBvc2l0aW9uIHdvcmtpbmcgb24NCmludGVybmF0 aW9uYWwgdGV4dCBhbmQgZm9udHMuIEZvciBkZXRhaWxzLCBnbyB0bzo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48YQ0K aHJlZj0iaHR0cDovL21lbWJlcnMubWljcm9zb2Z0LmNvbS9jYXJlZXJzL3NlYXJjaC9kZXRhaWxz LmFzcHg/Sm9iSUQ9NjlDRjUwRUEtNUZCNS00N0M4LTkwODMtRkNFMEVGOUNGNTQ3Ij48c3Bhbg0K c3R5bGU9J2NvbG9yOmJsdWUnPmh0dHA6Ly9tZW1iZXJzLm1pY3Jvc29mdC5jb20vY2FyZWVycy9z ZWFyY2gvZGV0YWlscy5hc3B4P0pvYklEPTY5Q0Y1MEVBLTVGQjUtNDdDOC05MDgzLUZDRTBFRjlD RjU0Nzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gR2VyYXJkTQ0K W21haWx0bzpnZXJhcmQubWVpanNzZW5AZ21haWwuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgT2N0b2JlciAzMCwgMjAwNyA5OjI1IEFNPGJyPg0KPGI+VG86PC9iPiBQZXRlciBDb25z dGFibGU8YnI+DQo8Yj5DYzo8L2I+IGx0cnVAbGlzdHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtMdHJ1XSBBc3R1ci1MZW9uZXNlOiBhIG1hY3JvbGFuZ3VhZ2UgY2FzZSBzdHVk eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPkhvaSw8YnI+DQpXaGVuIHRoZXJlIGlzIGEgbGFuZ3Vh Z2UgY29udGludXVtLCB0aGVyZSBjYW4gYmUgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIG9uZSBhbmQN CnRoZSBvdGhlciB3aXRob3V0IHRoZXJlIGJlaW5nIGEgcmVhc29uIGZvciBzZXBhcmF0ZSBsYW5n dWFnZSBjb2Rlcy4gQSBsYW5ndWFnZQ0KY29kZSBvbmx5IG1ha2VzIHNlbnNlIHdoZW4gdGhlIGxh bmd1YWdlcyBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiBUaGUgSVNPLTYzOS0zDQpkb2VzIG5vdCBj YXRlciB3ZWxsIGZvciB0aGlzLiBUaGUgSVNPLTYzOS02IHdpbGwgcHJvdmlkZSB0aGUgaGllcmFy Y2hpY2FsDQpzdHJ1Y3R1cmUgbmVlZGVkIHRvIGRlYWwgcHJvcGVybHkgd2l0aCB0aGVzZSBpc3N1 ZXMuIDxicj4NCjxicj4NCklTTy02MzktMyBvbmx5IGFsbG93cyBmb3IgeWVzL25vIGRpZmZlcmVu dCBhbmQgdGhlcmUgYXJlIHJlYXNvbnMgd2h5IHlvdSB3YW50DQp0byBtYWtlIGEgZGlzdGluY3Rp b24gd2l0aG91dCBwcm9ub3VuY2luZyBpdCBhIGxhbmd1YWdlLiBUaGUgc2FtZSBpcyB0cnVlIGZv cg0KTW9udGVuZWdyaW4uIFRlY2huaWNhbGx5IGlzIGlzIG5vdCBhIGRpZmZlcmVudCBsYW5ndWFn ZS4gWW91IGRvIGhvd2V2ZXIgd2FudCB0bw0KYmUgYWJsZSB0byBpbmRpY2F0ZSBpdCBiZWluZyBN b250ZW5lZ3Jpbi4gPGJyPg0KPGJyPg0KU28gZnJvbSBteSBwZXJzcGVjdGl2ZSwgYXJlIHRoZXNl IHBhcnQgb2YgYSBsYW5ndWFnZSBjb250aW51dW0gb3IgYXJlIHRoZXkNCm11dHVhbGx5IGV4Y2x1 c2l2ZSA/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBHZXJhcmQg PG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFz cz1nbWFpbHF1b3RlPk9uIDEwLzMwLzA3LCA8Yj5QZXRlciBDb25zdGFibGUgPC9iPiZsdDs8YQ0K aHJlZj0ibWFpbHRvOnBldGVyY29uQG1pY3Jvc29mdC5jb20iPnBldGVyY29uQG1pY3Jvc29mdC5j b208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+ DQoNCjxwPkhlcmUncyBhIHdoYXQtaWYgYmFzZWQgb24gYSByZWFsaXN0aWMgc2NlbmFyaW86ICZx dW90O2FzdCZxdW90OyBpcyBjdXJyZW50bHkNCnRyZWF0ZWQgaW4gSVNPIDYzOSBhcyBhbiBpbmRp dmlkdWFsLWxhbmd1YWdlIGVudHJ5IHdpdGggbmFtZXMgJnF1b3Q7QXN0dXJpYW47DQpBc3R1cmxl b25lc2U7IEJhYmxlOyBMZW9uZXNlJnF1b3Q7LiBXaGF0IGlmIElTTyA2MzkgY2hhbmdlZCB0aGUg c2NvcGUgb2YNCiZxdW90O2FzdCZxdW90OyB0byBtYWNyb2xhbmd1YWdlLCBhbmQgYWRkZWQgdHdv IG5ldyBlbmNvbXBhc3NlZA0KaW5kaXZpZHVhbC1sYW5ndWFnZSBlbnRyaWVzOiAmcXVvdDtBc3R1 cmlhbjsgQmFibGUmcXVvdDsgYW5kDQomcXVvdDtMZW9uZXNlJnF1b3Q7PzxvOnA+PC9vOnA+PC9w Pg0KDQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHA+V2hpbGUgSSBoYXZlbid0IHlldCBz ZWVuIHJlYWxseSBjbGVhciBldmlkZW5jZSwgdGhlcmUgYXJlIHNvbWUgcGVvcGxlDQpjbGFpbWlu ZyB0aGF0IExlb25lc2UgaXMgYSBkaXN0aW5jdCBsYW5ndWFnZSBmcm9tIEFzdHVyaWFuIGFuZCBy ZXF1ZXN0aW5nIGENCmRpc3RpbmN0IElTTyA2MzkgSUQuIFN1cHBvc2UgYSBzdWZmaWNpZW50IGNh c2UgaXMgbWFkZTogc2luY2UgJnF1b3Q7YXN0JnF1b3Q7DQpjdXJyZW50bHkgZGVub3RlcyBib3Ro IHRoZSBBc3R1cmlhbiBhbmQgTGVvbmVzZSB2YXJpZXRpZXMsIHdlIGNhbm5vdCBzaW1wbHkNCm5h cnJvdyAmcXVvdDthc3QmcXVvdDsgdG8gZGVub3RlIG9ubHkgQXN0dXJpYW4gYW5kIGFkZCBzb21l dGhpbmcgbmV3IGZvcg0KTGVvbmVzZS4gT25lIHBvc3NpYmxlIG91dGNvbWUgaXMgdGhlIG9uZSBJ IGRlc2NyaWJlIGFib3ZlOiAmcXVvdDthc3QmcXVvdDsNCmJlY29tZXMgYSBtYWNyb2xhbmd1YWdl LiAoQSBwb3NzaWJsZSB2YXJpYXRpb24gaXMgdGhhdCBNaXJhbmRlc2UsICZxdW90O213bCZxdW90 OywNCmlzIGluY2x1ZGVkIGluIHRoZSBtYWNyb2xhbmd1YWdlLik8bzpwPjwvbzpwPjwvcD4NCg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjxwPldoYXQgd291bGQgdGhlIGltcGFjdCBiZSBp biBhIDQ2NDZiaXMgd29ybGQgd2l0aCAvIHdpdGhvdXQgZXh0bGFuZyBzdWJ0YWdzPzxvOnA+PC9v OnA+PC9wPg0KDQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHA+SSBzdXBwb3NlIHRoYXQg ZGVwZW5kcyBvbiB2YXJpb3VzIGRldGFpbHMgb2YgdGhlIHNjZW5hcmlvLiAoUGVyIGFib3ZlLCB0 aGlzDQpkaXNjdXNzaW9uIGFzc3VtZXMgaXQgaXMgYWxyZWFkeSBkZXRlcm1pbmVkIHRoYXQgQXN0 dXJpYW4gYW5kIExlb25lc2UgYXJlDQpkaXN0aW5jdC4pPG86cD48L286cD48L3A+DQoNCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cD5Qb3NzaWJsZSBzY2VuYXJpbyBBOiBUaGVyZSdzIGEg YnVuY2ggb2YgZXhpc3RpbmcgJnF1b3Q7YXN0JnF1b3Q7IGNvbnRlbnQsDQp2aXJ0dWFsbHkgYWxs IG9mIHdoaWNoIGlzIEFzdHVyaWFuLCBub3QgTGVvbmVzZS4gPG86cD48L286cD48L3A+DQoNCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cD4oTm90ZTogaW4gcHJpbmNpcGxlLCB0aGUgbWly cm9yIHNjZW5hcmlvLCB3aXRoIExlb25lc2UgcHJlZG9taW5hbnQsIGlzDQpoeXBvdGhldGljYWxs eSBwb3NzaWJsZSwgYnV0IG5vdCBpbiBwcmFjdGljZTogJnF1b3Q7QXN0dXJpYW4mcXVvdDsgaXMg cmVjb2duaXplZA0KaW4gU3BhbmlzaCBsYXcgYW5kIGlzIGFjdGl2ZWx5IGJlaW5nIGRldmVsb3Bl ZDsgaWYgTGVvbmVzZSBpcyBmdW5jdGlvbmFsbHkNCmRpc3RpbmN0LCBpdCBkb2VzIG5vdCBoYXZl IGNvbXBhcmFibGUgc3RhdHVzIGFuZCBhdHRlbnRpb24gYXQgcHJlc2VudC4pPG86cD48L286cD48 L3A+DQoNCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cD5Qb3NzaWJsZSBzY2VuYXJpbyBC OiBUaGVyZSdzIGEgYnVuY2ggb2YgZXhpc3RpbmcgJnF1b3Q7YXN0JnF1b3Q7IGNvbnRlbnQsDQpi dXQgbmVpdGhlciBBc3R1cmlhbiBvciBMZW9uZXNlIGhhcyBhIHNpZ25pZmljYW50bHkgZ3JlYXRl ciBwcm9wb3J0aW9uIHRoYXQgdGhlDQpvdGhlci48bzpwPjwvbzpwPjwvcD4NCg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQoNCjxwPlBvc3NpYmxlIHNjZW5hcmlvIEM6IFRoZXJlIGlzbid0IG11 Y2ggZXhpc3RpbmcgJnF1b3Q7YXN0JnF1b3Q7IGNvbnRlbnQuPG86cD48L286cD48L3A+DQoNCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHA+ KEluIHRlcm1zIG9mIGdlbmVyYWwgbWFjcm9sYW5ndWFnZSBjYXNlcywgc2NlbmFyaW8gQSB3b3Vs ZCBiZSBzaW1pbGFyIHRvIHRoZQ0KTWFuZGFyaW4gdmVyc3VzIENhbnRvbmVzZSBjb250cmFzdCwg ZXhjZXB0IHRoYXQgdGhlcmUncyBub3doZXJlIG5lYXIgYXMgbXVjaA0KJnF1b3Q7YXN0JnF1b3Q7 IGNvbnRlbnQgYXMgdGhlcmUgaXMgJnF1b3Q7emgmcXVvdDsgY29udGVudDsgc2NlbmFyaW8gQyB3 b3VsZCBiZQ0Kc2ltaWxhciB0byBjYXNlcyBsaWtlIEJpa29sLCBDcmVlLCBIbW9uZywgWmFwb3Rl YyBvciBzZXZlcmFsIG90aGVycy4gU2NlbmFyaW8gQg0KaXMgcHJvYmFibHkgc29tZXdoYXQgYWtp biB0byAmcXVvdDtTZXJiby1Dcm9hdGlhbiZxdW90OyAoaGJzKSwgTm9yd2VnaWFuIChub3IpDQph bmQgJnF1b3Q7UGVyc2lhbiZxdW90OyAoZmFzKS4gRm9yIGdlbmVyYWwgbWFjcm9sYW5ndWFnZXMs IHRoZXJlJ3MgcHJvYmFibHkgYQ0KZm91cnRoIHNjZW5hcmlvIHR5cGU6IHR3byBvciBtb3JlIGRp c3RpbmN0IHVuZGV2ZWxvcGVkIHZhcmlldGllcyBleGlzdCwgYW5kIGENCiZxdW90O3N0YW5kYXJk JnF1b3Q7IGRldmVsb3BlZCB2YXJpZXR5IGVtZXJnZXMgdGhhdCBpcyBlaXRoZXIgZGlzdGluY3Qg ZnJvbSB0aGUNCmZvcm1lciwgb3IgaXMgZGVzaWduZWQgdG8gYmUgbW9yZSBvciBsZXNzIG5ldXRy YWwgcmVsYXRpdmUgdG8gdGhlIG90aGVycyDigJMgYQ0KcG9zc2libGUgY2hhcmFjdGVyaXphdGlv biBmb3IgdGhlIEFyYWJpYyBjYXNlLCBhbmQgcG90ZW50aWFsbHkgYXBwbGljYWJsZSB0bw0KaG93 IHNvbWUgZ3JvdXBzIHN1Y2ggYXMgRGlua2Egb3IgRnVsYWggbWF5IGV2b2x2ZS4pPG86cD48L286 cD48L3A+DQoNCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCg0KPHA+UGV0ZXI8bzpwPjwvbzpwPjwvcD4NCg0KPHA+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdDtjb2xvcjojOTQzNjM0Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoN CjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Y29sb3I6Izk0MzYzNCc+TWljcm9zb2Z0 IGhhcyBhbiBvcGVuIFByb2dyYW0NCk1hbmFnZW1lbnQgcG9zaXRpb24gd29ya2luZyBvbiBpbnRl cm5hdGlvbmFsIHRleHQgYW5kIGZvbnRzLiBGb3IgZGV0YWlscywgZ28NCnRvOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCg0KPHA+PGENCmhyZWY9Imh0dHA6Ly9tZW1iZXJzLm1pY3Jvc29mdC5jb20v Y2FyZWVycy9zZWFyY2gvZGV0YWlscy5hc3B4P0pvYklEPTY5Q0Y1MEVBLTVGQjUtNDdDOC05MDgz LUZDRTBFRjlDRjU0NyINCnRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjku MHB0Jz5odHRwOi8vbWVtYmVycy5taWNyb3NvZnQuY29tL2NhcmVlcnMvc2VhcmNoL2RldGFpbHMu YXNweD9Kb2JJRD02OUNGNTBFQS01RkI1LTQ3QzgtOTA4My1GQ0UwRUY5Q0Y1NDc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KDQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkx0cnUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkx0cnVAaWV0Zi5vcmci Pkx0cnVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rp dj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561AD95C62ENAEXMSGC117re_-- --===============1313176091== 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 --===============1313176091==-- From ltru-bounces@ietf.org Wed Oct 31 12:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InG4D-000255-4N; Wed, 31 Oct 2007 12:05:17 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1InG4C-00023h-0J for ltru-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InG4B-000231-Lw for ltru@ietf.org; Wed, 31 Oct 2007 12:05:15 -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 1InG45-0005FQ-GK for ltru@ietf.org; Wed, 31 Oct 2007 12:05:15 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 31 Oct 2007 09:04:32 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) with mapi; Wed, 31 Oct 2007 09:04:38 -0700 From: Peter Constable To: Addison Phillips , 'LTRU Working Group' Date: Wed, 31 Oct 2007 09:04:26 -0700 Subject: RE: [Ltru] teleconference timing this week?? Thread-Topic: [Ltru] teleconference timing this week?? Thread-Index: AcgbCVSefhNqEs/+T+GT7jJeJG0o4gAzk/Lg Message-ID: References: <47274C7B.5020903@yahoo-inc.com> In-Reply-To: <47274C7B.5020903@yahoo-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1670721038==" Errors-To: ltru-bounces@ietf.org --===============1670721038== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uJ3Qga25vdyBpZiB5b3Ugd2VyZSBwbGFubmluZyB0byB0ZWxlY29uZiB0b2RheSBhdCA5QU0g UFQgLS0gSSd2ZSBnb3QgYSBjb25mbGljdC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBBZGRpc29uIFBoaWxsaXBzIFttYWlsdG86YWRkaXNvbkB5YWhvby1pbmMuY29t XQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDA3IDg6MjQgQU0NCj4gVG86ICdMVFJV IFdvcmtpbmcgR3JvdXAnDQo+IFN1YmplY3Q6IFtMdHJ1XSB0ZWxlY29uZmVyZW5jZSB0aW1pbmcg dGhpcyB3ZWVrPz8NCj4NCj4gQ2hhaXJzLA0KPg0KPiBDb3VsZCB5b3UgcGxlYXNlIGNob29zZSBh bmQgYW5ub3VuY2UgYW4gYXBwcm9wcmlhdGUgdGltZSBmb3INCj4gdGVsZWNvbmZlcmVuY2VzPyBJ IHRoaW5rIHRoZXJlIGlzIGdlbmVyYWwgYWdyZWVtZW50IGZyb20gdGhvc2UNCj4gcGFydGljaXBh dGluZyB0aGF0IHRoZXNlIGFyZSB2YWx1YWJsZS4gSG93ZXZlciwgd2UgaGF2ZSBlbmpveWVkDQo+ IHJlbGF0aXZlbHkgbG93IHBhcnRpY2lwYXRpb24uIEl0IHdvdWxkIGJlIGdvb2QgdG8gYW5ub3Vu Y2UgdGhlIHRpbWUgYW5kDQo+IGRldGFpbHMgaW4gYWR2YW5jZS4gSSdtIGhhcHB5IHRvIGNvbnRp bnVlIHByb3ZpZGluZyBhY2Nlc3MgdmlhIG91cg0KPiB0ZWxlY29uZmVyZW5jaW5nIHNlcnZpY2Uu IE91ciBsYXN0IG1lZXRpbmcgKGF0IDYgYS5tLiBQYWNpZmljIERheWxpZ2h0DQo+IFRpbWUgb24g VGh1cnNkYXkpIHdhcyBzb21ld2hhdCBpbmNvbnZlbmllbnQgYW5kIG5vdyB0aW1lIGNoYW5nZXMg YXJlDQo+IHN0YXJ0aW5nIHRvIG9jY3VyIGJldHdlZW4gU3VtbWVyIGFuZCBTdGFuZGFyZCB0aW1l LCByZW5kZXJpbmcgdGhlIGNhbGwNCj4gbW9yZSBpbmNvbnZlbmllbnQgZm9yIHNvbWUuDQo+DQo+ IEFkZGlzb24NCj4NCj4gLS0NCj4gQWRkaXNvbiBQaGlsbGlwcw0KPiBHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCAtLSBZYWhvbyEgSW5jLg0KPiBDaGFpciAtLSBXM0MgSW50ZXJuYXRpb25hbGl6YXRp b24gQ29yZSBXRw0KPg0KPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBhbiBhcmNoaXRlY3R1cmUu DQo+IEl0IGlzIG5vdCBhIGZlYXR1cmUuDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K --===============1670721038== 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 --===============1670721038==--