From ltru-bounces@ietf.org Thu Nov 01 20:28: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 1InkNb-0004ZR-EI; Thu, 01 Nov 2007 20:27:19 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1InkNa-0004Z1-S9 for ltru-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 20:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InkNa-0004Yi-II for ltru@ietf.org; Thu, 01 Nov 2007 20:27:18 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InkNT-0000f5-8v for ltru@ietf.org; Thu, 01 Nov 2007 20:27:17 -0400 Received: by rv-out-0910.google.com with SMTP id l15so547431rvb for ; Thu, 01 Nov 2007 17:26:30 -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=t5IpZ/ETUd6FbJEBwK7BM/KNnPc775mcJymjxfu9prk=; b=VJ76cDnveoR/MNnuwK+AkfXwj/kGzx1anAaBzvJubsZkZ7wYePKEbFZt4kvG0O4gpp9lNZxgigaV9xZ+GjwtHVxK84eOwuXfWyh0tuJvJZG1F8QFZXrPzOTZB8j8uTa0CUErR7g0EVxrAAL04Qwx+D64o/SKjK0PRhysCEIQxDM= 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=rdkoxWUgIDW57E8MHsttnw/GAASJ74/jOlJgn0Q6P1EB7NjDUnDmo6HqofXxxgxAiVMtB49uYrEX04IvcnlOOieEXB01OvWSITnOZz7+H72NjvAADIYpoxeXC4frSBz6PWgzJwpjwFISB7WGM1WXQPDgAWo+LZ3PFS8c5GYIh8I= Received: by 10.114.196.1 with SMTP id t1mr1234550waf.1193963190606; Thu, 01 Nov 2007 17:26:30 -0700 (PDT) Received: by 10.114.192.9 with HTTP; Thu, 1 Nov 2007 17:26:30 -0700 (PDT) Message-ID: <30b660a20711011726w11a17813g1fc2461b326e24c0@mail.gmail.com> Date: Thu, 1 Nov 2007 17:26:30 -0700 From: "Mark Davis" To: "Martin Duerst" , "Randy Presuhn" Subject: Re: [Ltru] teleconference timing this week?? In-Reply-To: <47274C7B.5020903@yahoo-inc.com> MIME-Version: 1.0 References: <47274C7B.5020903@yahoo-inc.com> X-Google-Sender-Auth: a438e89a828f7c97 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0427878753==" Errors-To: ltru-bounces@ietf.org --===============0427878753== Content-Type: multipart/alternative; boundary="----=_Part_14305_7964766.1193963190607" ------=_Part_14305_7964766.1193963190607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Chairs, Did you see this message? Mark On 10/30/07, Addison Phillips wrote: > > 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 > -- Mark ------=_Part_14305_7964766.1193963190607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Chairs,

Did you see this message?

Mark

On 10/30/07, Addison Phillips <addison@yahoo-inc.com> wrote:
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



--
Mark ------=_Part_14305_7964766.1193963190607-- --===============0427878753== 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 --===============0427878753==-- From ltru-bounces@ietf.org Thu Nov 01 23:33: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 1InnGD-0008Bx-4u; Thu, 01 Nov 2007 23:31:53 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1InnGC-0008Ah-6x for ltru-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 23:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InnGB-000875-TL for ltru@ietf.org; Thu, 01 Nov 2007 23:31:51 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InnFz-0005pv-Kd for ltru@ietf.org; Thu, 01 Nov 2007 23:31:45 -0400 Received: from [10.72.74.0] (snvvpn1-10-72-74-c0.corp.yahoo.com [10.72.74.0]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lA23U1lW093680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2007 20:30:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=KnS9s5fZboILGJC7oGgdA7bf51Gnq6k4k+MGTg7kAyloCKl4fvfnNFma5JMRthrD Message-ID: <472A99B8.9000004@yahoo-inc.com> Date: Thu, 01 Nov 2007 20:30:00 -0700 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] teleconference timing this week?? References: <47274C7B.5020903@yahoo-inc.com> <30b660a20711011726w11a17813g1fc2461b326e24c0@mail.gmail.com> In-Reply-To: <30b660a20711011726w11a17813g1fc2461b326e24c0@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I can definitely report that there will not be a teleconference tomorrow. I have a conflicting call with India and there has been no prior announcement from the chairs. Addison Mark Davis wrote: > Chairs, > > Did you see this message? > > Mark > > On 10/30/07, *Addison Phillips* > wrote: > > 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 > > > > > -- > 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 Sat Nov 03 19:58: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 1IoSsQ-0005as-3s; Sat, 03 Nov 2007 19:58:06 -0400 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IoSsP-0005ad-4g for ltru-confirm+ok@megatron.ietf.org; Sat, 03 Nov 2007 19:58:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoSsO-0005Zs-Qi for ltru@ietf.org; Sat, 03 Nov 2007 19:58:04 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoSsN-0007GY-V5 for ltru@ietf.org; Sat, 03 Nov 2007 19:58:04 -0400 Received: from [10.72.76.208] (snvvpn2-10-72-76-c208.corp.yahoo.com [10.72.76.208]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lA3Nw2w5028011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 Nov 2007 16:58:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=hT6Hj8XRE27g6JcnNT8gPYkDoFclscvP/wpE3FkDAvPsGISB9zUgi4vE7OW2c0t9 Message-ID: <472D0B0A.3010200@yahoo-inc.com> Date: Sat, 03 Nov 2007 16:58:02 -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] trying again: 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 Chairs, Could you please choose and announce an appropriate time for teleconferences? Or announce that there will be no teleconferences? I note that this week I'm in Boston at the W3C Technical Plenary. However, I am happy to carve out time to participate, as well as to provide the teleconference service. I feel some urgency to completing this work and think that the last teleconference made significant progress. 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 Nov 04 13:14: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 1Iojzn-0003UY-4h; Sun, 04 Nov 2007 13:14:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iojzl-0003Ty-VL for ltru-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 13:14:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iojzl-0003TV-L7 for ltru@ietf.org; Sun, 04 Nov 2007 13:14:49 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iojzl-0000NT-Bu for ltru@ietf.org; Sun, 04 Nov 2007 13:14:49 -0500 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 <20071104181448.OZU28086.mta10.adelphia.net@DGBP7M81> for ; Sun, 4 Nov 2007 13:14:48 -0500 Message-ID: <009101c81f0e$964fbb30$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 4 Nov 2007 10:14:48 -0800 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ltru] Re: trying again: 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: > I feel some urgency to completing this work and think that the last > teleconference made significant progress. Although I don't plan to participate in further teleconferences on the topic of extlang, I agree that we need to step up the pace. The level of urgency in this group seems to have waned considerably. -- 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 Nov 07 19:10: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 1IpuyZ-0001Ia-0O; Wed, 07 Nov 2007 19:10:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IpuyX-0001He-T4 for ltru-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 19:10:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpuyX-0001HW-Is for ltru@ietf.org; Wed, 07 Nov 2007 19:10:25 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpuyU-000089-TM for ltru@ietf.org; Wed, 07 Nov 2007 19:10:25 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1728371nzf for ; Wed, 07 Nov 2007 16:10:22 -0800 (PST) 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=SX2vRZKAP+HRVOOOjSoPkvSOsRsPeYmm6Jn8eqG6iG8=; b=UvROUEhacx2nt43KawMqc+EGksIPLlqGayBHBazEMvCeq5cQ5fScEPtnDstCu3bRFiWVgTHNjGuqPPVD6MwJkMSlkSmZCM3J5SRW4QgvOIxZkmx2qcg2Eerlh+G13IyoPC3UlSF+2KKsoTON1plee12FQ7N+8bV44suabIPVnVc= 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=QUy+cahfTVqy0ch6r99bwaEhEG8KkKKJQ81igrG7akVIiG6faa7gNBBRYVorYGwR3qI3N+m8cu14ltN2yNE3rcZOD8cRnPp+RRoEJ8odcphJ1Bbwzu1wJOhTMc2M2vthQFrtsB01RiKtUQH1ZsL5oN91ceS4gqIBrnZUaeOTcus= Received: by 10.114.109.1 with SMTP id h1mr520603wac.1194480621599; Wed, 07 Nov 2007 16:10:21 -0800 (PST) Received: by 10.114.192.9 with HTTP; Wed, 7 Nov 2007 16:10:21 -0800 (PST) Message-ID: <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> Date: Wed, 7 Nov 2007 16:10:21 -0800 From: "Mark Davis" To: verdy_p@wanadoo.fr In-Reply-To: <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> X-Google-Sender-Auth: 78452b53e4609ab4 X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: LTRU Working Group , Rick McGowan , unicode@unicode.org Subject: [Ltru] Re: The "QU" territory/region code (was New Public Review Issue: #116 Proposed Update UTS #35 LDML) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1281016021==" Errors-To: ltru-bounces@ietf.org --===============1281016021== Content-Type: multipart/alternative; boundary="----=_Part_39261_2211515.1194480621586" ------=_Part_39261_2211515.1194480621586 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a misreading of the text. One of the reasons for the last revision of BCP 47 was to make it absolutely clear when codes were valid or not. The valid codes are all and only those that are in http://www.iana.org/assignments/language-subtag-registry. EU is not there (as a region), thus it is not valid. Now, personally, I agree with you that not having EU in BCP 47 is unproductive. However, there was unfortunately no consensus in the working group to add the exceptionally reserved codes. That's what forced us to use QU in the first place in CLDR. If BCP 47 ever changes, we'd be pleased as punch to deprecate QU in its favor. (In retrospect, I also think it was unproductive to have incomplete M49 codes (http://unstats.un.org/unsd/methods/m49/m49regin.htm). It wouldn't hurt to add the very few M49 codes that are excluded from BCP 47, even if deprecated, if only to make testing and cross mapping easier.) Mark On 11/7/07, Philippe Verdy wrote: > > Rick McGowan wrote: > > The Unicode CLDR committee is planning to release a minor version, 1.5.1 > , > > by the end of November. There are a few changes in the specificiation > > associated with this change. > > > > http://unicode.org/draft/reports/tr35/tr35.html > > Notable changes include: > > * Added C10. Likely Subtags for locale IDs or language tags. > > One problem about a "private use" territory code currently used (QU): > > [quote[TR35]] > 3. Identifiers > (...) > A locale ID is an extension of a language ID, and thus the structure > and > field values are based on [BCP47]. The registry of data for that > successor is now being maintained by IANA. The canonical form of a > locale > ID uses "_" instead of the "-" used in [BCP47]; however, > implementations > providing APIs for CLDR locale IDs should treat "-" as equivalent to > "_" > on input. > (...) > Locale Field Definitions > -------------- ---------- ------------------------------------------ > Field Allowable Allowable values > Characters > -------------- ---------- ------------------------------------------ > (...) > territory_code ASCII [BCP47] subtag values marked as Type: > letters, region, or any UN M.49 code that doesn't > numbers correspond to a [BCP47] region subtag. > There are three private use codes defined > in LDML: > QO Outlying Oceania > QU European Union > ZZ Unknown or Invalid Territory > The private use codes from XA..XZ will > never be used by CLDR, and are thus safe > for use for other purposes by > applications using CLDR data. > -------------- ---------- ----------------------------------------- > [/quote[TR35]] > > Now let's look at the normative [BCP-47] reference: > > [quote[BCP-47]] > 2.2.4. Region Subtags > (...) > The following rules apply to the region subtags: > (...) > 2. All two-character subtags following the primary subtag were > defined in the IANA registry according to the assignments found > in [ISO3166-1] ("Codes for the representation of names of > countries and their subdivisions -- Part 1: Country codes") using > the list of alpha-2 country codes, or using assignments > subsequently made by the ISO 3166 maintenance agency or governing > standardization bodies. > [/quote] > > Note that [BCP47] cites [ISO3166-1] as a source of codes, but it > ***forgets > to list it in the list of normative references*** at end of the document. > It's not very precise about the list being effectively used; it just gives > the name of the whole document within the text itself: "Codes for the > representation of names of countries and their subdivisions -- Part 1: > Country codes", and refers to the "list of alpha-2 country codes"; it > speaks > about "assignments", but does not indicate the normative status. > > From there, I can find this official page: > http://www.iso.org/iso/iso-3166-1_decoding_table where the "EU" code is in > yellow background described as "exceptional reservations". This links to > this page: > http://www.iso.org/iso/customizing_iso_3166-1.htm, which says: > > [quote] > To avoid transitional application problems and to aid users who require > specific additional code elements for the functioning of their coding > systems, the ISO 3166/MA may set aside code elements which it undertakes > not > to use for other than specified purposes during a limited or indeterminate > period of time. These are called reserved code elements and their use is > normally restricted to the application they were reserved for. > (...) > Code elements not included in the current version of ISO 3166-1 may be > reserved by the ISO 3166/MA, > * (...) > * as "exceptional reservations", at the request of national ISO member > bodies, governments and international organizations. This applies to > certain > code elements required in order to support a particular application, as > specified by the requesting body and limited to such use; any further use > of > such code elements is subject to approval by the ISO 3166/MA. > [/quote] > > So [BCP47] indicates that the [ISO3166-1] country code "EU", listed in the > list of alpha-2 country code for the European Union, should be used as it > was reserved for indeterminate time. BCP47 does not seem to restrict the > use > of alpha-2 codes that were "exceptionally reserved". > > For [ISO3166-1], the code "EU" is an exception reservation; its use in > LDML > (if it has to become an international standard) would conform to the > needed > "support for a particular application". All that is needed is that Unicode > requests approval by the ISO 3166/MA. > > Why is LDML using the private use code "QU", apparently in contradiction > with BCP47? Shouldn't it be changed to use "EU" according to BCP47 > recommandation and the other policy in LDML that warns against the use of > private use codes that can be changed at any time? > > Does Unicode want to request approval by ISO 3166/MA for the use of the > "EU" > code in LDML and CLDR (as indicated in ISO3166-1)? I think it would be in > the interest of many applications that already use "EU" in the > localization > data, but NOT "QU" because it is a "user-assigned code element" not meant > for interchange. > > Note that [ISO3166-1] also says: > > [quote] > When exchanging data with users of ISO 3166-1 not connected to this > particular in-house application the definition of these user-assigned code > elements should be given. > [/quote] > > This is what is performed in the LDML specification, but is it enough to > permit interchange of data? > > > > > -- Mark ------=_Part_39261_2211515.1194480621586 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a misreading of the text. One of the reasons for the last revision of BCP 47 was to make it absolutely clear when codes were valid or not. The valid codes are all and only those that are in http://www.iana.org/assignments/language-subtag-registry. EU is not there (as a region), thus it is not valid.

Now, personally, I agree with you that not having EU in BCP 47 is unproductive. However, there was unfortunately no consensus in the working group to add the exceptionally reserved codes. That's what forced us to use QU in the first place in CLDR. If BCP 47 ever changes, we'd be pleased as punch to deprecate QU in its favor.

(In retrospect, I also think it was unproductive to have incomplete M49 codes ( http://unstats.un.org/unsd/methods/m49/m49regin.htm). It wouldn't hurt to add the very few M49 codes that are excluded from BCP 47, even if deprecated, if only to make testing and cross mapping easier.)

Mark

On 11/7/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
Rick McGowan wrote:
> The Unicode CLDR committee is planning to release a minor version, 1.5.1,
> by the end of November. There are a few changes in the specificiation
> associated with this change.
>
>       http://unicode.org/draft/reports/tr35/tr35.html
> Notable changes include:
> * Added C10. Likely Subtags for locale IDs or language tags.

One problem about a "private use" territory code currently used (QU):

[quote[TR35]]
   3. Identifiers
   (...)
   A locale ID is an extension of a language ID, and thus the structure and
   field values are based on [BCP47]. The registry of data for that
   successor is now being maintained by IANA. The canonical form of a locale
   ID uses "_" instead of the "-" used in [BCP47]; however, implementations
   providing APIs for CLDR locale IDs should treat "-" as equivalent to "_"
   on input.
   (...)
                    Locale Field Definitions
   --------------  ----------  ------------------------------------------
   Field           Allowable   Allowable values
                   Characters
   --------------  ----------  ------------------------------------------
   (...)
   territory_code  ASCII       [BCP47] subtag values marked as Type:
                   letters,    region, or any UN M.49 code that doesn't
                   numbers     correspond to a [BCP47] region subtag.
                               There are three private use codes defined
                               in LDML:
                                   QO Outlying Oceania
                                   QU European Union
                                   ZZ Unknown or Invalid Territory
                               The private use codes from XA..XZ will
                               never be used by CLDR, and are thus safe
                               for use for other purposes by
                               applications using CLDR data.
   --------------  ----------  -----------------------------------------
[/quote[TR35]]

Now let's look at the normative [BCP-47] reference:

[quote[BCP-47]]
2.2.4. Region Subtags
   (...)
   The following rules apply to the region subtags:
   (...)
   2.  All two-character subtags following the primary subtag were
       defined in the IANA registry according to the assignments found
       in [ISO3166-1] ("Codes for the representation of names of
       countries and their subdivisions -- Part 1: Country codes") using
       the list of alpha-2 country codes, or using assignments
       subsequently made by the ISO 3166 maintenance agency or governing
       standardization bodies.
[/quote]

Note that [BCP47] cites [ISO3166-1] as a source of codes, but it ***forgets
to list it in the list of normative references*** at end of the document.
It's not very precise about the list being effectively used; it just gives
the name of the whole document within the text itself: "Codes for the
representation of names of countries and their subdivisions -- Part 1:
Country codes", and refers to the "list of alpha-2 country codes"; it speaks
about "assignments", but does not indicate the normative status.

From there, I can find this official page:
http://www.iso.org/iso/iso-3166-1_decoding_table where the "EU" code is in
yellow background described as "exceptional reservations". This links to
this page:
http://www.iso.org/iso/customizing_iso_3166-1.htm , which says:

[quote]
To avoid transitional application problems and to aid users who require
specific additional code elements for the functioning of their coding
systems, the ISO 3166/MA may set aside code elements which it undertakes not
to use for other than specified purposes during a limited or indeterminate
period of time. These are called reserved code elements and their use is
normally restricted to the application they were reserved for.
(...)
Code elements not included in the current version of ISO 3166-1 may be
reserved by the ISO 3166/MA,
* (...)
* as "exceptional reservations", at the request of national ISO member
bodies, governments and international organizations. This applies to certain
code elements required in order to support a particular application, as
specified by the requesting body and limited to such use; any further use of
such code elements is subject to approval by the ISO 3166/MA.
[/quote]

So [BCP47] indicates that the [ISO3166-1] country code "EU", listed in the
list of alpha-2 country code for the European Union, should be used as it
was reserved for indeterminate time. BCP47 does not seem to restrict the use
of alpha-2 codes that were "exceptionally reserved".

For [ISO3166-1], the code "EU" is an exception reservation; its use in LDML
(if it has to become an international standard) would conform to the needed
"support for a particular application". All that is needed is that Unicode
requests approval by the ISO 3166/MA.

Why is LDML using the private use code "QU", apparently in contradiction
with BCP47? Shouldn't it be changed to use "EU" according to BCP47
recommandation and the other policy in LDML that warns against the use of
private use codes that can be changed at any time?

Does Unicode want to request approval by ISO 3166/MA for the use of the "EU"
code in LDML and CLDR (as indicated in ISO3166-1)? I think it would be in
the interest of many applications that already use "EU" in the localization
data, but NOT "QU" because it is a "user-assigned code element" not meant
for interchange.

Note that [ISO3166-1] also says:

[quote]
When exchanging data with users of ISO 3166-1 not connected to this
particular in-house application the definition of these user-assigned code
elements should be given.
[/quote]

This is what is performed in the LDML specification, but is it enough to
permit interchange of data?







--
Mark ------=_Part_39261_2211515.1194480621586-- --===============1281016021== 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 --===============1281016021==-- From ltru-bounces@ietf.org Wed Nov 07 21:19: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 1IpwzW-00041i-Hy; Wed, 07 Nov 2007 21:19:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IpwzU-000407-Q0 for ltru-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 21:19:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwzU-0003ys-FO for ltru@ietf.org; Wed, 07 Nov 2007 21:19:32 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpwzR-00043W-Nm for ltru@ietf.org; Wed, 07 Nov 2007 21:19:32 -0500 Received: by wa-out-1112.google.com with SMTP id k40so27251wah for ; Wed, 07 Nov 2007 18:19:29 -0800 (PST) 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=CGpPz+/onSTHcJMhcPqw0PX3Ssuzgqn2bkaXLou47BM=; b=tnCr8soOHQBV8n3+I5EDCgiEWWWYn/GMu5T8wyH1vD5ZKnrRyK3m6cFIBC7wOHi+nBg675IGGtAXTt9cw93ELxVnl7ZouDwnOK8t7SGgh9Xs2oRmAk5vHOZUWNNQDNqkivjTuvfVCVkJvjy/jzDrOsHRG249pyuWgkBKHFX4BPU= 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=jDK8fgem4/B+2gaXfjJu4OBTb0c+oi+fQudykRe6z5TFzIYxCEy+L877WZBsa+t4hs5LxS65RKqKVpNmH9jUjey3iExe+7g0/uIwBKqHv/shp+LD0ArEIDnrOf0n2G708DPKSpHOU5B0q+aMpoZDfktmKyjUlGz375RY6RNR+Ps= Received: by 10.114.167.2 with SMTP id p2mr25947wae.1194488368577; Wed, 07 Nov 2007 18:19:28 -0800 (PST) Received: by 10.114.192.9 with HTTP; Wed, 7 Nov 2007 18:19:28 -0800 (PST) Message-ID: <30b660a20711071819o43030b6dpf268493728ee3f30@mail.gmail.com> Date: Wed, 7 Nov 2007 18:19:28 -0800 From: "Mark Davis" To: verdy_p@wanadoo.fr In-Reply-To: <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> X-Google-Sender-Auth: 041ce8398b6b48c3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: LTRU Working Group , Rick McGowan , unicode@unicode.org Subject: [Ltru] Re: The "QU" territory/region code (was New Public Review Issue: #116 Proposed Update UTS #35 LDML) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0241619997==" Errors-To: ltru-bounces@ietf.org --===============0241619997== Content-Type: multipart/alternative; boundary="----=_Part_39623_3796186.1194488368578" ------=_Part_39623_3796186.1194488368578 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/7/07, Philippe Verdy wrote: > > Mark Davis wrote: > > This is a misreading of the text. One of the reasons for the last > > revision of BCP 47 was to make it absolutely clear when codes were > > valid or not. The valid codes are all and only those that are in > > http://www.iana.org/assignments/language-subtag-registry. EU is not > > there (as a region), thus it is not valid. > > Note that your URL is NOT directly referenced by [BCP47], and the > terminology used cannot clearly state that fact. So it is not so clear in > the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA > website. Note that [BCP47] does not even list [ISO3166-1] as a normative > reference, and not even as an informative reference (most probably this > was > forgotten)! > > Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request > to > the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in > LDML and CLDR, even if there's still no agreement without BCP47 (what the > IETF wants to restrict for BCP47 would be immediately invalidated by any > authorization made by the ISO 3166-1/MA). > > That's why I finished my message with this question: did you request such > authorization to the ISO 3166-1/MA? > > > > -- Mark ------=_Part_39623_3796186.1194488368578 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/7/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
Mark Davis wrote:
> This is a misreading of the text. One of the reasons for the last
> revision of BCP 47 was to make it absolutely clear when codes were
> valid or not. The valid codes are all and only those that are in
> http://www.iana.org/assignments/language-subtag-registry. EU is not
> there (as a region), thus it is not valid.

Note that your URL is NOT directly referenced by [BCP47], and the
terminology used cannot clearly state that fact. So it is not so clear in
the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
website. Note that [BCP47] does not even list [ISO3166-1] as a normative
reference, and not even as an informative reference (most probably this was
forgotten)!

Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
LDML and CLDR, even if there's still no agreement without BCP47 (what the
IETF wants to restrict for BCP47 would be immediately invalidated by any
authorization made by the ISO 3166-1/MA).

That's why I finished my message with this question: did you request such
authorization to the ISO 3166-1/MA?






--
Mark ------=_Part_39623_3796186.1194488368578-- --===============0241619997== 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 --===============0241619997==-- From ltru-bounces@ietf.org Wed Nov 07 21:30:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipx9u-0006j0-Io; Wed, 07 Nov 2007 21:30:18 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ipx9t-0006hX-Jg for ltru-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 21:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipx9t-0006hO-9o for ltru@ietf.org; Wed, 07 Nov 2007 21:30:17 -0500 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipx9r-0004I6-1E for ltru@ietf.org; Wed, 07 Nov 2007 21:30:17 -0500 Received: by nz-out-0506.google.com with SMTP id n1so16334nzf for ; Wed, 07 Nov 2007 18:30:14 -0800 (PST) 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=9D8ctrkRTa7wQtEgoV8iUXRuUAcZr99WcYnhrmY4nwc=; b=nZ3My/vrLqezVMsXDpVL0JdyF6qDVrf0AQkQUyzgH8fZVhtOmvKZ/o01QtcxRSUhMJS4ujY3eRicqX9NV3Pv9jVD1IUbrhTzzcmXEZKDV8VTgoiZmN5MfZs0iZYMlkNY4sN1sqByz8DinTom9gO9WZu1XHRdgaQWARm9+fM15Ho= 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=QkRhHyFm8AMlC/BKE3q3WBg+cXGey/Rs5wI65U1iSOhGMwAph+0XPE7xzmOREtdpbnhqWni+UjZLgqLFl6ocpzZS/+YWlzMDRWW8iYsmqpp5VjrNpPid5Nsr51GEMllhhapfqmmj0EXDIYtc8wlRvJXG6Hz6aIlO5TvwF+MSByY= Received: by 10.115.49.16 with SMTP id b16mr41046wak.1194489013203; Wed, 07 Nov 2007 18:30:13 -0800 (PST) Received: by 10.114.192.9 with HTTP; Wed, 7 Nov 2007 18:30:13 -0800 (PST) Message-ID: <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> Date: Wed, 7 Nov 2007 18:30:13 -0800 From: "Mark Davis" To: verdy_p@wanadoo.fr In-Reply-To: <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> X-Google-Sender-Auth: 1f96363c9cf1df83 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: LTRU Working Group , Rick McGowan , unicode@unicode.org Subject: [Ltru] Re: The "QU" territory/region code (was New Public Review Issue: #116 Proposed Update UTS #35 LDML) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0244102905==" Errors-To: ltru-bounces@ietf.org --===============0244102905== Content-Type: multipart/alternative; boundary="----=_Part_39648_2388003.1194489013201" ------=_Part_39648_2388003.1194489013201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/7/07, Philippe Verdy wrote: > > Mark Davis wrote: > > This is a misreading of the text. One of the reasons for the last > > revision of BCP 47 was to make it absolutely clear when codes were > > valid or not. The valid codes are all and only those that are in > > http://www.iana.org/assignments/language-subtag-registry. EU is not > > there (as a region), thus it is not valid. > > Note that your URL is NOT directly referenced by [BCP47], and the > terminology used cannot clearly state that fact. So it is not so clear in > the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA > website. Note that [BCP47] does not even list [ISO3166-1] as a normative > reference, and not even as an informative reference (most probably this > was > forgotten)! No. I agree that in an ideal world we'd just have the URL in BCP 47, but it clearly states that The Language Subtag Registry maintained by IANA is the source for valid subtags: other standards referenced in this section provide the source material for that registry. So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is just a *source* for data, and not all codes defined in 3166 will be valid in BCP 47. Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to > the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in > LDML and CLDR, even if there's still no agreement without BCP47 (what the > IETF wants to restrict for BCP47 would be immediately invalidated by any > authorization made by the ISO 3166-1/MA). The Unicode Consortium could clearly use EU. No problem there. However, a goal of the Unicode CLDR group was and is to be compatible with BCP 47, and EU cannot be used there, conformantly. That's why I finished my message with this question: did you request such > authorization to the ISO 3166-1/MA? That is moot, since the goal is compatibility with BCP 47, not with 3166. There is some background on BCP 47 on Addison's site ( http://www.inter-locale.com/); that might be easier to understand than the spec. -- Mark ------=_Part_39648_2388003.1194489013201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/7/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
Mark Davis wrote:
> This is a misreading of the text. One of the reasons for the last
> revision of BCP 47 was to make it absolutely clear when codes were
> valid or not. The valid codes are all and only those that are in
> http://www.iana.org/assignments/language-subtag-registry. EU is not
> there (as a region), thus it is not valid.

Note that your URL is NOT directly referenced by [BCP47], and the
terminology used cannot clearly state that fact. So it is not so clear in
the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
website. Note that [BCP47] does not even list [ISO3166-1] as a normative
reference, and not even as an informative reference (most probably this was
forgotten)!

No.

I agree that in an ideal world we'd just have the URL in BCP 47, but it clearly states that 
    The Language Subtag
    Registry maintained by IANA is the source for valid subtags: other
   standards referenced in this section provide the source material for
   that registry.
So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is just a *source* for data, and not all codes defined in 3166 will be valid in BCP 47.

Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
LDML and CLDR, even if there's still no agreement without BCP47 (what the
IETF wants to restrict for BCP47 would be immediately invalidated by any
authorization made by the ISO 3166-1/MA).

The Unicode Consortium could clearly use EU. No problem there. However, a goal of the Unicode CLDR group was and is to be compatible with BCP 47, and EU cannot be used there, conformantly.

That's why I finished my message with this question: did you request such
authorization to the ISO 3166-1/MA?

That is moot, since the goal is compatibility with BCP 47, not with 3166.

There is some background on BCP 47 on Addison's site ( http://www.inter-locale.com/); that might be easier to understand than the spec.




--
Mark ------=_Part_39648_2388003.1194489013201-- --===============0244102905== 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 --===============0244102905==-- From ltru-bounces@ietf.org Wed Nov 07 23:00: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 1IpyZO-0003TT-5N; Wed, 07 Nov 2007 23:00:42 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IpyZN-0003TN-M9 for ltru-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 23:00:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpyZN-0003TF-Aw for ltru@ietf.org; Wed, 07 Nov 2007 23:00:41 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpyZL-0006gU-0p for ltru@ietf.org; Wed, 07 Nov 2007 23:00:41 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lA840YwB022561 for ; Thu, 8 Nov 2007 13:00:35 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 22be_284f9258_8daf_11dc_9f82_0014221f2a2d; Thu, 08 Nov 2007 13:00:34 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:38671) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 8 Nov 2007 12:56:48 +0900 Message-Id: <6.0.0.20.2.20071108125239.02439b80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 08 Nov 2007 12:58:44 +0900 To: "Mark Davis" , verdy_p@wanadoo.fr From: Martin Duerst Subject: Re: [Ltru] Re: The "QU" territory/region code (was New Public ReviewIssue: #116 Proposed Update UTS #35 LDML) In-Reply-To: <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.co m> References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> <30b660a20711071830o26443cdbg2adb35eb7f2a477b@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: cd26b070c2577ac175cd3a6d878c6248 Cc: Rick McGowan , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark, others, [removing the Unicode mailing list from the cc.] The LTRU WG has agreed some years ago to not use "exceptionally reserved" codes from 3166-1. We clearly don't want to reopen every single discussion that we had leading to RFC 4646, but if necessary, we can reconsider some of thae decisions for RFC 4646bis. As an example, would it make sense for the LTRU WG to ask for permission from the ISO 3166-1/MA? Regards, Martin. P.S.: When we finalized HTML4, the Euro character was still not officially and finally approved by the UTC and ISO/IEC JTC1/SC2/WG2. We nevertheless assessed the risks and took the chance and defined a € entity, with mapping to the proposed codepoint. At 11:30 07/11/08, Mark Davis wrote: >On 11/7/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote: >>Mark Davis wrote: >>> This is a misreading of the text. One of the reasons for the last >>> revision of BCP 47 was to make it absolutely clear when codes were >>> valid or not. The valid codes are all and only those that are in >>> http://www.iana.org/assignments/language-subtag-registry. EU is not >>> there (as a region), thus it is not valid. >> >>Note that your URL is NOT directly referenced by [BCP47], and the >>terminology used cannot clearly state that fact. So it is not so clear in >>the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA >>website. Note that [BCP47] does not even list [ISO3166-1] as a normative >>reference, and not even as an informative reference (most probably this was >>forgotten)! > >No. > >I agree that in an ideal world we'd just have the URL in BCP 47, but it clearly states that > > > The Language Subtag > Registry maintained by IANA is the source for valid subtags: other > standards referenced in this section provide the source material for > that registry. > >So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is just a *source* for data, and not all codes defined in 3166 will be valid in BCP 47. >>Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to >>the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in >>LDML and CLDR, even if there's still no agreement without BCP47 (what the >>IETF wants to restrict for BCP47 would be immediately invalidated by any >>authorization made by the ISO 3166-1/MA). > >The Unicode Consortium could clearly use EU. No problem there. However, a goal of the Unicode CLDR group was and is to be compatible with BCP 47, and EU cannot be used there, conformantly. > >>That's why I finished my message with this question: did you request such >>authorization to the ISO 3166-1/MA? > >That is moot, since the goal is compatibility with BCP 47, not with 3166. > >There is some background on BCP 47 on Addison's site ( http://www.inter-locale.com/); that might be easier to understand than the spec. > > > > >-- >Mark >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 07 23:53: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 1IpzOw-0001ep-CG; Wed, 07 Nov 2007 23:53:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IpzOv-0001ee-Q4 for ltru-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 23:53:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpzOv-0001eW-GI for ltru@ietf.org; Wed, 07 Nov 2007 23:53:57 -0500 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpzOu-0008Ba-7E for ltru@ietf.org; Wed, 07 Nov 2007 23:53:57 -0500 Received: by wa-out-1112.google.com with SMTP id k40so88494wah for ; Wed, 07 Nov 2007 20:53:53 -0800 (PST) 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=RWj+PLwHpy63lWlq9dpIJ8aB0rc1TGYhGp5fRj3ty1I=; b=CC96LDCWT2JyAj2VSiAJdqcK8vepP34+ss22eimb5WLw+igDfr7UI86KhjilgX2b35VOKYVjYMtHiOhwB1MpkC262C1ZXsuyr1uZGBJcwSQ67mW0hoND0i+EU3N4Bp18r72/Cx+mwud1ovvRu5dJqjlLbsNfuv1miAZQyBbEZ5M= 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=T4c9GBmAlfOsl9WCqfxnS4u8juRJQELPeKmvNlFmEmKyfWWH785zfQtxkVWTi8KpGMIJsnz26eBWcu7G4+8pd8GKa5NYhN0DOLke0LIg0t7WI6fzqHA2+cuDblABERN+RsB09fUHu+H5XXqYbvxFQTLqQuj3Hgj8Ubg4w4J3oXs= Received: by 10.114.110.1 with SMTP id i1mr130873wac.1194497633086; Wed, 07 Nov 2007 20:53:53 -0800 (PST) Received: by 10.114.192.9 with HTTP; Wed, 7 Nov 2007 20:53:53 -0800 (PST) Message-ID: <30b660a20711072053i229e9214u38cc7dac753508a1@mail.gmail.com> Date: Wed, 7 Nov 2007 20:53:53 -0800 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] Re: The "QU" territory/region code (was New Public ReviewIssue: #116 Proposed Update UTS #35 LDML) In-Reply-To: <6.0.0.20.2.20071108125239.02439b80@localhost> MIME-Version: 1.0 References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> <6.0.0.20.2.20071108125239.02439b80@localhost> X-Google-Sender-Auth: dab3873952802203 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: verdy_p@wanadoo.fr, Rick McGowan , 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="===============0342884458==" Errors-To: ltru-bounces@ietf.org --===============0342884458== Content-Type: multipart/alternative; boundary="----=_Part_39918_4167621.1194497633081" ------=_Part_39918_4167621.1194497633081 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd be very much in favor of it -- CLDR only adds a very small number of codes to BCP 47 (it uses private use codes for compatibility). The QU code is a hack because we don't have EU, so it'd be very nice to get rid of that. (BTW, we don't really have to petition ISO to use it; if we want to use EU, there is nothing stopping us.) Mark On 11/7/07, Martin Duerst wrote: > > Mark, others, > > [removing the Unicode mailing list from the cc.] > > The LTRU WG has agreed some years ago to not use > "exceptionally reserved" codes from 3166-1. > We clearly don't want to reopen every > single discussion that we had leading to RFC 4646, but > if necessary, we can reconsider some of thae decisions > for RFC 4646bis. As an example, would it make sense for > the LTRU WG to ask for permission from the ISO 3166-1/MA? > > Regards, Martin. > > P.S.: When we finalized HTML4, the Euro character was still > not officially and finally approved by the UTC and > ISO/IEC JTC1/SC2/WG2. We nevertheless assessed the > risks and took the chance and defined a € entity, > with mapping to the proposed codepoint. > > > At 11:30 07/11/08, Mark Davis wrote: > > > >On 11/7/07, Philippe Verdy <verdy_p@wanadoo.fr> > wrote: > >>Mark Davis wrote: > >>> This is a misreading of the text. One of the reasons for the last > >>> revision of BCP 47 was to make it absolutely clear when codes were > >>> valid or not. The valid codes are all and only those that are in > >>> > http://www.iana.org/assignments/language-subtag-registry. EU is not > >>> there (as a region), thus it is not valid. > >> > >>Note that your URL is NOT directly referenced by [BCP47], and the > >>terminology used cannot clearly state that fact. So it is not so clear > in > >>the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA > >>website. Note that [BCP47] does not even list [ISO3166-1] as a normative > >>reference, and not even as an informative reference (most probably this > was > >>forgotten)! > > > >No. > > > >I agree that in an ideal world we'd just have the URL in BCP 47, but it > clearly states that > > > > > > The Language Subtag > > Registry maintained by IANA is the source for valid subtags: other > > standards referenced in this section provide the source material for > > that registry. > > > >So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is > just a *source* for data, and not all codes defined in 3166 will be valid in > BCP 47. > >>Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request > to > >>the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" > in > >>LDML and CLDR, even if there's still no agreement without BCP47 (what > the > >>IETF wants to restrict for BCP47 would be immediately invalidated by any > >>authorization made by the ISO 3166-1/MA). > > > >The Unicode Consortium could clearly use EU. No problem there. However, a > goal of the Unicode CLDR group was and is to be compatible with BCP 47, and > EU cannot be used there, conformantly. > > > >>That's why I finished my message with this question: did you request > such > >>authorization to the ISO 3166-1/MA? > > > >That is moot, since the goal is compatibility with BCP 47, not with 3166. > > > >There is some background on BCP 47 on Addison's site ( > http://www.inter-locale.com/); that might be easier to understand than the > spec. > > > > > > > > > >-- > >Mark > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > -- Mark ------=_Part_39918_4167621.1194497633081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd be very much in favor of it -- CLDR only adds a very small number of codes to BCP 47 (it uses private use codes for compatibility). The QU code is a hack because we don't have EU, so it'd be very nice to get rid of that. (BTW, we don't really have to petition ISO to use it; if we want to use EU, there is nothing stopping us.)

Mark

On 11/7/07, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
Mark, others,

[removing the Unicode mailing list from the cc.]

The LTRU WG has agreed some years ago to not use
"exceptionally reserved" codes from 3166-1.
We clearly don't want to reopen every
single discussion that we had leading to RFC 4646, but
if necessary, we can reconsider some of thae decisions
for RFC 4646bis. As an example, would it make sense for
the LTRU WG to ask for permission from the ISO 3166-1/MA?

Regards,    Martin.

P.S.: When we finalized HTML4, the Euro character was still
      not officially and finally approved by the UTC and
      ISO/IEC JTC1/SC2/WG2. We nevertheless assessed the
      risks and took the chance and defined a &euro; entity,
      with mapping to the proposed codepoint.


At 11:30 07/11/08, Mark Davis wrote:


>On 11/7/07, Philippe Verdy <<mailto:verdy_p@wanadoo.fr> verdy_p@wanadoo.fr> wrote:
>>Mark Davis wrote:
>>> This is a misreading of the text. One of the reasons for the last
>>> revision of BCP 47 was to make it absolutely clear when codes were
>>> valid or not. The valid codes are all and only those that are in
>>> <http://www.iana.org/assignments/language-subtag-registry >http://www.iana.org/assignments/language-subtag-registry. EU is not
>>> there (as a region), thus it is not valid.
>>
>>Note that your URL is NOT directly referenced by [BCP47], and the
>>terminology used cannot clearly state that fact. So it is not so clear in
>>the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
>>website. Note that [BCP47] does not even list [ISO3166-1] as a normative
>>reference, and not even as an informative reference (most probably this was
>>forgotten)!
>
>No.
>
>I agree that in an ideal world we'd just have the URL in BCP 47, but it clearly states that
>
>
>    The Language Subtag
>    Registry maintained by IANA is the source for valid subtags: other
>   standards referenced in this section provide the source material for
>   that registry.
>
>So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is just a *source* for data, and not all codes defined in 3166 will be valid in BCP 47.
>>Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
>>the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
>>LDML and CLDR, even if there's still no agreement without BCP47 (what the
>>IETF wants to restrict for BCP47 would be immediately invalidated by any
>>authorization made by the ISO 3166-1/MA).
>
>The Unicode Consortium could clearly use EU. No problem there. However, a goal of the Unicode CLDR group was and is to be compatible with BCP 47, and EU cannot be used there, conformantly.
>
>>That's why I finished my message with this question: did you request such
>>authorization to the ISO 3166-1/MA?
>
>That is moot, since the goal is compatibility with BCP 47, not with 3166.
>
>There is some background on BCP 47 on Addison's site ( http://www.inter-locale.com/); that might be easier to understand than the spec.
>
>
>
>
>--
>Mark
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru


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




--
Mark ------=_Part_39918_4167621.1194497633081-- --===============0342884458== 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 --===============0342884458==-- From ltru-bounces@ietf.org Thu Nov 08 01:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq14i-0001Wg-EB; Thu, 08 Nov 2007 01:41:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq14g-0001TH-M7 for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 01:41:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq14g-0001Rl-9l for ltru@lists.ietf.org; Thu, 08 Nov 2007 01:41:10 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq14d-00028u-IT for ltru@lists.ietf.org; Thu, 08 Nov 2007 01:41:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iq14Z-00072E-1B for ltru@lists.ietf.org; Thu, 08 Nov 2007 06:41:03 +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, 08 Nov 2007 06:41:03 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 06:41:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 07:37:52 +0100 Lines: 18 Message-ID: References: <200711070057.lA70vxnL025875@unicode.org><002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org><30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com><002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org><30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.co m> <6.0.0.20.2.20071108125239.02439b80@localhost> 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: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 asked: > As an example, would it make sense for the LTRU WG > to ask for permission from the ISO 3166-1/MA? No. =20 | Country Codes | | The IANA is not in the business of deciding what is and what is | not a country. | | The selection of the ISO 3166 list as a basis for country code | top-level domain names was made with the knowledge that ISO has a | procedure for determining which entities should be and should not | be on that list. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 01:57:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1Ka-0001As-1I; Thu, 08 Nov 2007 01:57:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq1KY-00017b-Pa for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 01:57:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1KY-00017A-Ev for ltru@ietf.org; Thu, 08 Nov 2007 01:57:34 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq1KY-0002zZ-3Z for ltru@ietf.org; Thu, 08 Nov 2007 01:57:34 -0500 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 <20071108065733.FFJ18384.mta9.adelphia.net@DGBP7M81>; Thu, 8 Nov 2007 01:57:33 -0500 Message-ID: <004b01c821d4$a32dcbd0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "Mark Davis" , References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> Date: Wed, 7 Nov 2007 22:57:32 -0800 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: 79899194edc4f33a41f49410777972f8 Cc: LTRU Working Group , Rick McGowan , unicode@unicode.org Subject: [Ltru] Re: The "QU" territory/region code (was New Public Review Issue: #116 Proposed Update UTS #35 LDML) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > (In retrospect, I also think it was unproductive to have incomplete > M49 codes ( http://unstats.un.org/unsd/methods/m49/m49regin.htm). It > wouldn't hurt to add the very few M49 codes that are excluded from BCP > 47, even if deprecated, if only to make testing and cross mapping > easier.) I disagree rather strongly. Non-geographical, non-linguistic groupings such as "Landlocked developing countries" and "Transition countries" (the modern name for the category once known as "Communist states") have no place in language tags or computer locales. -- 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 Thu Nov 08 02:38: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 1Iq1yZ-0002t0-2R; Thu, 08 Nov 2007 02:38:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq1Fs-00052G-6i for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 01:52:44 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq1Fr-000527-Tc for ltru@ietf.org; Thu, 08 Nov 2007 01:52:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1EL-0003h5-8A for ltru@ietf.org; Thu, 08 Nov 2007 01:51:09 -0500 Received: from smtp2a.orange.fr ([80.12.242.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq1EI-0002Ol-BH for ltru@ietf.org; Thu, 08 Nov 2007 01:51:09 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a07.orange.fr (SMTP Server) with ESMTP id 4C78D700008A for ; Thu, 8 Nov 2007 07:50:58 +0100 (CET) Received: from HARNON (APoitiers-258-1-42-114.w90-45.abo.wanadoo.fr [90.45.117.114]) by mwinf2a07.orange.fr (SMTP Server) with ESMTP id DC1C97000085; Thu, 8 Nov 2007 07:50:57 +0100 (CET) X-ME-UUID: 20071108065057901.DC1C97000085@mwinf2a07.orange.fr From: "Philippe Verdy" To: "'Martin Duerst'" , "'Mark Davis'" References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> <6.0.0.20.2.20071108125239.02439b80@localhost> Subject: RE: [Ltru] Re: The "QU" territory/region code (was New Public ReviewIssue: #116 Proposed Update UTS #35 LDML) Date: Thu, 8 Nov 2007 07:50:49 +0100 Organization: Ordinateur Personnel Message-ID: <002b01c821d3$b30d52b0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcghvpxPCvD/z7z+SVWO7mG2FKE+LwAE3ZBQ In-Reply-To: <6.0.0.20.2.20071108125239.02439b80@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-TMDA-Confirmed: Thu, 08 Nov 2007 01:52:43 -0500 X-Mailman-Approved-At: Thu, 08 Nov 2007 02:38:54 -0500 Cc: 'Rick McGowan' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: verdy_p@wanadoo.fr List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > De=A0: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Envoy=E9=A0: jeudi 8 novembre 2007 04:59 > =C0=A0: Mark Davis; verdy_p@wanadoo.fr > Cc=A0: LTRU Working Group; Rick McGowan > Objet=A0: Re: [Ltru] Re: The "QU" territory/region code (was New = Public > ReviewIssue: #116 Proposed Update UTS #35 LDML) >=20 > Mark, others, >=20 > [removing the Unicode mailing list from the cc.] >=20 > The LTRU WG has agreed some years ago to not use > "exceptionally reserved" codes from 3166-1. > We clearly don't want to reopen every > single discussion that we had leading to RFC 4646, but > if necessary, we can reconsider some of thae decisions > for RFC 4646bis. As an example, would it make sense for > the LTRU WG to ask for permission from the ISO 3166-1/MA? No. I am suggesting instead that the Unicode Consortium makes this = request for use in LDML/CLDR data and specification. No discussion needed to = change the BCP47 policy. The only affected thing will be to replace "QU" by "EU" in the CLDR = data, but to make this, Unicode (and the promoters of the CLDR project) needs approval by ISM 3166/MA. And this use should remain documented in the = LDML specs, saying that the use is for a exceptionally reserved code, and = that this was approved by ISO 3166/MA, in addition to the other codes used = and allowed in BCP 47. In fact, given that "EU" is already widely used in localization data, it would really make sense to unify this use with the codification in LDML/CLDR, instead of maintaining two codes (EU and QU) in applications = for all the localized data applicable to the same region. And then this would demonstrate that the exceptional use, permitted by = ISO 3166/MA (for interchanged data with preexisting standards), which later allowed the IETF/ISOC to accept the creation and registration of the .EU ccTLD, now registered at IANA, and that would also be used and = documented in CLDR/LDML by Unicode, should better be approved by the sponsors of BCP47 = for inclusion the locale tags registry. For now, the locale tags IANA registry at can only document the "QU" = region as "private use", but certainly not "European Union" as currently = assumed in CLDR/LDML. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 03: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 1Iq2ne-0000o7-JR; Thu, 08 Nov 2007 03:31:42 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq2nd-0000nv-Gf for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 03:31:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2nY-0000ln-8f for ltru@ietf.org; Thu, 08 Nov 2007 03:31:36 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq2nX-0005iH-TG for ltru@ietf.org; Thu, 08 Nov 2007 03:31:36 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0D0D31C00E9; Thu, 8 Nov 2007 09:31:35 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0867C1C009B; Thu, 8 Nov 2007 09:31:35 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id EE97358ECC1; Thu, 8 Nov 2007 09:31:34 +0100 (CET) Date: Thu, 8 Nov 2007 09:31:34 +0100 From: Stephane Bortzmeyer To: verdy_p@wanadoo.fr, unicode@unicode.org Message-ID: <20071108083134.GB7228@nic.fr> References: <200711070057.lA70vxnL025875@unicode.org> <002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org> <30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com> <002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org> <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: LTRU Working Group Subject: [Ltru] Re: The "QU" territory/region code (was New Public Review Issue: #116 Proposed Update UTS #35 LDML) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Nov 07, 2007 at 06:30:13PM -0800, Mark Davis wrote a message of 103 lines which said: > There is some background on BCP 47 on Addison's site ( > http://www.inter-locale.com/); that might be easier to understand > than the spec. I suggest http://www.langtag.net/ which I find more beginner-friendly. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 04:07: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 1Iq3Mh-0003yp-Up; Thu, 08 Nov 2007 04:07:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq3Mh-0003xa-NQ for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:07:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3Mh-0003xS-Bk for ltru@lists.ietf.org; Thu, 08 Nov 2007 04:07:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq3Me-0006Kp-2Y for ltru@lists.ietf.org; Thu, 08 Nov 2007 04:07:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iq3Ma-0007co-3m for ltru@lists.ietf.org; Thu, 08 Nov 2007 09:07:48 +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, 08 Nov 2007 09:07:48 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 09:07:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 10:04:14 +0100 Lines: 16 Message-ID: References: <200711070057.lA70vxnL025875@unicode.org><002701c82188$e454ca10$0a01a8c0@rodage.dyndns.org><30b660a20711071610o611ba69elbd837001785590c8@mail.gmail.com><002801c821a3$f8578410$0a01a8c0@rodage.dyndns.org><30b660a20711071830o26443cdbg2adb35eb7f2a477b@mail.gmail.com> <20071108083134.GB7228@nic.fr> 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: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: =20 >> There is some background on BCP 47 on Addison's site=20 >> (http://www.inter-locale.com/); that might be easier=20 >> to understand than the spec. =20 > I suggest http://www.langtag.net/ which I find more=20 > beginner-friendly. Oops, I completely missed that there's a new version 01 of http://tools.ietf.org/html/draft-phillips-record-jar Why on earth did ICANN recognise EU as "ccTLD" ? Until today I thought it's a gTLD like ASIA or CAT. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 04:16: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 1Iq3VA-0005Ex-8Q; Thu, 08 Nov 2007 04:16:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq3V8-0005Ck-Bc for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:16:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3V7-0005Cc-Vu for ltru@lists.ietf.org; Thu, 08 Nov 2007 04:16:37 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq3V2-0006an-RR for ltru@lists.ietf.org; Thu, 08 Nov 2007 04:16:37 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6ABC11C00D9; Thu, 8 Nov 2007 10:16:32 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 664581C009B; Thu, 8 Nov 2007 10:16:32 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 59EBA58ECBE; Thu, 8 Nov 2007 10:16:32 +0100 (CET) Date: Thu, 8 Nov 2007 10:16:32 +0100 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20071108091632.GA15306@nic.fr> References: <20071108083134.GB7228@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [Quite off-topic for LTRU, I suggest to go on in private] On Thu, Nov 08, 2007 at 10:04:14AM +0100, Frank Ellermann wrote a message of 16 lines which said: > Why on earth did ICANN recognise EU as "ccTLD" ? Until today I > thought it's a gTLD like ASIA or CAT. There is no clear list of what TLD are ccTLD and what are gTLD. Try to find one on ICANN or IANA Web site. There are other TLD from the exceptional list (some moved later to the normal list). ".uk" is the best known but there are others like ".ac". _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 07: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 1Iq6pc-0000OI-4w; Thu, 08 Nov 2007 07:50:00 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq6pa-0000Mv-Gn for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 07:49:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6pa-0000Mm-3G for ltru@lists.ietf.org; Thu, 08 Nov 2007 07:49:58 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq6pX-0003sP-8z for ltru@lists.ietf.org; Thu, 08 Nov 2007 07:49:58 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iq6pP-0003Hu-TX for ltru@lists.ietf.org; Thu, 08 Nov 2007 12:49:47 +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, 08 Nov 2007 12:49:47 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 12:49:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 13:46:18 +0100 Lines: 24 Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > [Quite off-topic for LTRU, I suggest to go on in private] Maybe. If I got Mark's drift correctly the CLDR folks try to stay in sync with BCP 47. The BC 47 folks (=3D LTRU) try to stay in sync with RFC 1591 (=3D IANA), i.e. ISO 3166 country codes. And IANA has "EU" on a web page , a redirection to . They have a link to the "ccTLD" redirection on their main page. > There is no clear list of what TLD are ccTLD and what are gTLD. > Try to find one on ICANN or IANA Web site. See above for IANA, for ICANN see the eu ccTLD registry agreement on > There are other TLD from the exceptional list Yes, I know the grandfathered cases (three cleared by Debbie). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 08:20: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 1Iq7Id-0007J5-98; Thu, 08 Nov 2007 08:19:59 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq7Ib-0007H0-NU for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 08:19:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq7Ib-0007GY-9w for ltru@lists.ietf.org; Thu, 08 Nov 2007 08:19:57 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq7IZ-0004aS-4q for ltru@lists.ietf.org; Thu, 08 Nov 2007 08:19:57 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Iq7IY-0004uG-1K; Thu, 08 Nov 2007 08:19:54 -0500 Date: Thu, 8 Nov 2007 08:19:54 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: The "QU" territory/region code Message-ID: <20071108131953.GA29353@mercury.ccil.org> References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > Maybe. If I got Mark's drift correctly the CLDR folks try to stay > in sync with BCP 47. Yes. > The BCP 47 folks (= LTRU) try to stay in sync with RFC 1591 (= IANA), > i.e. ISO 3166 country codes. No. The DNS and language-tags are separate and independent consumers of ISO 3166, and what IANA does for one is irrelevant to what it does for the other. > And IANA has "EU" on a web page > , a redirection to > . They have a link to the > "ccTLD" redirection on their main page. The European Union (which is what "EU" means as an exceptionally reserved ISO 3166 code element) isn't relevant to language tagging: there are no EU vs. non-EU regional variants of languages. -- Here lies the Christian, John Cowan judge, and poet Peter, http://www.ccil.org/~cowan Who broke the laws of God cowan@ccil.org and man and metre. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 10:13: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 1Iq94T-0004Tz-US; Thu, 08 Nov 2007 10:13:29 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq94S-0004RQ-8E for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:13:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq94R-0004Q4-St for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:13:27 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq94O-0008HB-E0 for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:13:27 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id DAB5B1C00DA; Thu, 8 Nov 2007 16:13:23 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D63291C0075; Thu, 8 Nov 2007 16:13:23 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id CA2D958ECBE; Thu, 8 Nov 2007 16:13:23 +0100 (CET) Date: Thu, 8 Nov 2007 16:13:23 +0100 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20071108151323.GA20640@nic.fr> References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071108131953.GA29353@mercury.ccil.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Frank Ellermann , ltru@lists.ietf.org Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Nov 08, 2007 at 08:19:54AM -0500, John Cowan wrote a message of 34 lines which said: > The European Union (which is what "EU" means as an exceptionally > reserved ISO 3166 code element) isn't relevant to language tagging: > there are no EU vs. non-EU regional variants of languages. This point is not relevant for the Language Subtag Registry. We just registered BL and MF and I can assure you that there is no regional variants of French in these tiny islands... More seriously, the LSR does not check if a country-or-region-code is linguistically significiant before adding it. If it's in ISO 3166, it's added. Period. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 10:21: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 1Iq9C5-0004t0-GD; Thu, 08 Nov 2007 10:21:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq9C4-0004rN-TZ for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9C4-0004pZ-IQ for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:21:20 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9C2-00005q-8n for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:21:20 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Iq9By-0006HA-Af; Thu, 08 Nov 2007 10:21:14 -0500 Date: Thu, 8 Nov 2007 10:21:14 -0500 To: Stephane Bortzmeyer Message-ID: <20071108152114.GC29353@mercury.ccil.org> References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071108151323.GA20640@nic.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Frank Ellermann , ltru@lists.ietf.org Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > More seriously, the LSR does not check if a country-or-region-code is > linguistically significiant before adding it. If it's in ISO 3166, > it's added. Period. Very true, but EU is not "in" (that is, is not a code element of) 3166; it is extraordinarily reserved by 3166. As such, special justification is required before it can be used. That special justification is lacking here. I'm not even clear on what the justification is for using it in locales. What element of a (computer) locale is specified by being in the EU or out of it? It can't be currency, as the EU and the eurozone aren't coterminous. -- I suggest you call for help, John Cowan or learn the difficult art of mud-breathing. cowan@ccil.org --Great-Souled Sam http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 10:33: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 1Iq9O0-00033T-2u; Thu, 08 Nov 2007 10:33:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq9Ny-0002zr-Ax for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:33:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9Ny-0002ze-06 for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:33:38 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9Nv-0000Zu-Dv for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:33:37 -0500 Received: from [10.72.72.225] (snvvpn1-10-72-72-c225.corp.yahoo.com [10.72.72.225]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lA8FXGRU060563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 07:33:17 -0800 (PST) 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=G/vxoAIKMb3uMmdrTV9vzyFh9H1cVk0sDSFVmcPTdB9czy81TiXAElChtQj7eLOT Message-ID: <47332C3C.4040103@yahoo-inc.com> Date: Thu, 08 Nov 2007 07:33:16 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: The "QU" territory/region code References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> In-Reply-To: <20071108152114.GC29353@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > > I'm not even clear on what the justification is for using it in > locales. What element of a (computer) locale is specified by > being in the EU or out of it? It can't be currency, as the > EU and the eurozone aren't coterminous. > I don't believe it is used in locale *identifiers*. It is used in locale *data*. In particular, there is a region display name for European Union. European Union which you find in the document located here: http://tinyurl.com/25t3nr CLDR uses the ILSR as a source for region codes (I believe) because of the stability rules we've installed. For that matter, I use it for various projects for precisely the same reason. Actually, this whole conversation is overblown. I don't think CLDR's use of 'QU' is evil or a bad choice. I wish ISO 3166 would assign, rather than exceptionally reserve, 'EU' to ensure proper allocation of the code for applications that need it. As John notes, in practical fact there is no real use for this in language tags (unless one wishes to posit a "EU official" version of a language for EU (say) translation purposes, such as for regulations or some-such without favoring a particular country-specific flavor). Kind of like "es-419", eh? Not really a language, but useful sometimes. 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 Nov 08 10:38: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 1Iq9Sd-0000TQ-ME; Thu, 08 Nov 2007 10:38:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq9Sd-0000TL-EO for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:38:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9Sc-0000TD-O2 for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:38:26 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9Sa-0000lK-82 for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:38:26 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iq9SQ-0001Jr-Cf for ltru@lists.ietf.org; Thu, 08 Nov 2007 15:38:14 +0000 Received: from c-180-160-96.hh.dial.de.ignite.net ([62.180.160.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 15:38:14 +0000 Received: from nobody by c-180-160-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 15:38:14 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 16:37:43 +0100 Organization: Lines: 26 Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.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: c-180-160-96.hh.dial.de.ignite.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: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: =20 >> The BCP 47 folks (=3D LTRU) try to stay in sync with RFC 1591 (=3D = IANA), >> i.e. ISO 3166 country codes. =20 > No. The DNS and language-tags are separate and independent consumers > of ISO 3166, and what IANA does for one is irrelevant to what it does > for the other. Sorry, my statement was unclear. What you wrote is what I meant, in the spirit of RFC 1591 (IANA) we're not in the business of deciding what's a country: > The European Union (which is what "EU" means as an exceptionally = reserved > ISO 3166 code element) isn't relevant to language tagging: there are = no > EU vs. non-EU regional variants of languages. Yes. Besides EU members have territories in all oceans and continents, it's messier than UM. The CLDR QU might be nearer to LTRU region 150. Frank=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 10:52: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 1Iq9gW-0008VA-DS; Thu, 08 Nov 2007 10:52:48 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq9gT-0008UI-U2 for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9gT-0008UA-IQ for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:52:45 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9gR-0001PH-6B for ltru@lists.ietf.org; Thu, 08 Nov 2007 10:52:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iq9gN-0003QH-PG for ltru@lists.ietf.org; Thu, 08 Nov 2007 15:52:39 +0000 Received: from c-180-160-96.hh.dial.de.ignite.net ([62.180.160.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 15:52:39 +0000 Received: from nobody by c-180-160-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 15:52:39 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 16:52:10 +0100 Organization: Lines: 20 Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> 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: c-180-160-96.hh.dial.de.ignite.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: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: =20 > This point is not relevant for the Language Subtag Registry. We just > registered BL and MF and I can assure you that there is no regional > variants of French in these tiny islands... ...for another opinion see=20 | Population: 33,102 (October 2004 census) | Ethnic groups: creole (mulatto), black, Guadeloupe Mestizo = (French-East | Asia), white, East Indian [...] | Languages: French (official language), English, Dutch, French=20 | Patois, Spanish, Papiamento (dialect of Netherlands | Antilles) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 11:11: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 1Iq9yl-0006Op-3r; Thu, 08 Nov 2007 11:11:39 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iq9yh-0006KR-Ly for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:11:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9yh-0006K0-76 for ltru@lists.ietf.org; Thu, 08 Nov 2007 11:11:35 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9yb-0001yq-Of for ltru@lists.ietf.org; Thu, 08 Nov 2007 11:11:34 -0500 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.222.3; Thu, 8 Nov 2007 08:11:16 -0800 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; Thu, 8 Nov 2007 08:11:29 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Thu, 8 Nov 2007 08:11:27 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgiHMBTKorAo5XqSXS4nt/AJeUAzQABRMwA Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> <47332C3C.4040103@yahoo-inc.com> In-Reply-To: <47332C3C.4040103@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: 08e48e05374109708c00c6208b534009 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="===============0350321607==" Errors-To: ltru-bounces@ietf.org --===============0350321607== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBBZGRpc29uIFBoaWxsaXBzIFttYWlsdG86YWRkaXNvbkB5YWhvby1pbmMuY29tXQ0K DQoNCj4gSSBkb24ndCBiZWxpZXZlIGl0IGlzIHVzZWQgaW4gbG9jYWxlICppZGVudGlmaWVycyou IEl0IGlzIHVzZWQgaW4NCj4gbG9jYWxlDQo+ICpkYXRhKi4gSW4gcGFydGljdWxhciwgdGhlcmUg aXMgYSByZWdpb24gZGlzcGxheSBuYW1lIGZvciBFdXJvcGVhbg0KPiBVbmlvbi4NCj4NCj4gICA8 dGVycml0b3J5IHR5cGU9IlFVIj5FdXJvcGVhbiBVbmlvbjwvdGVycml0b3J5Pg0KDQpJZiBDTERS IGlzIHVzaW5nIGl0IGZvciBhIHdheSBub3QgcmVsYXRlZCB0byBJRVRGIExhbmd1YWdlIHRhZ3Ms IGFzIGFwcGVhcnMgdG8gYmUgdGhlIGNhc2UgaGVyZSwgdGhlbiB3aHkgYXJlIHdlIGRpc2N1c3Np bmcgaXQgb24gdGhpcyBsaXN0Pw0KDQoNCg0KUGV0ZXINCg== --===============0350321607== 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 --===============0350321607==-- From ltru-bounces@ietf.org Thu Nov 08 11:22: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 1IqA9C-0001vY-4h; Thu, 08 Nov 2007 11:22:26 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqA9A-0001v8-9z for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqA99-0001uw-Oy for ltru@lists.ietf.org; Thu, 08 Nov 2007 11:22:23 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqA97-0002JP-CQ for ltru@lists.ietf.org; Thu, 08 Nov 2007 11:22:23 -0500 Received: from [10.72.72.225] (snvvpn1-10-72-72-c225.corp.yahoo.com [10.72.72.225]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lA8GMDCc062976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 08:22:14 -0800 (PST) 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=HTFYDTpYvPk5OUHRZGB0NbWTjeXEozfUhUKkjADhGRHU+OzXl0vTl4OZRhV4ODRQ Message-ID: <473337B5.90402@yahoo-inc.com> Date: Thu, 08 Nov 2007 08:22:13 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] Re: The "QU" territory/region code References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> <47332C3C.4040103@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: 2409bba43e9c8d580670fda8b695204a Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > >> I don't believe it is used in locale *identifiers*. It is used in >> locale >> *data*. In particular, there is a region display name for European >> Union. >> >> European Union > > If CLDR is using it for a way not related to IETF Language tags, as appears to be the case here, then why are we discussing it on this list? > It's an application of the language subtag registry. Not its primary application, but it is an application. In practice, this isn't *that* interesting a discussion for this list, since it's a "private" decision about a private use code. 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 Nov 08 12:54: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 1IqBZt-0008P1-KG; Thu, 08 Nov 2007 12:54:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqBZs-0008Ov-Ua for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:54:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBZs-0008On-Ie for ltru@lists.ietf.org; Thu, 08 Nov 2007 12:54:04 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBZn-0005f3-0N for ltru@lists.ietf.org; Thu, 08 Nov 2007 12:54:04 -0500 Received: by nz-out-0506.google.com with SMTP id i28so211338nzi for ; Thu, 08 Nov 2007 09:53:58 -0800 (PST) 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=y8bFqzw/wmX/m0wcC8bKgfbfwus1M8arfypQy4b34Q4=; b=Put/4maz5EjJcGFgrOUwIeYoPATfvcfONl2dFqdBGA5fdkFlRnUOK7NWpohUBR/r9cI9LZp8kj+IDoUyrVngFfjUp/DSrmh7RaGopxdXjKw5dFkdStL8hNzWE8UsxN//EjwI6VQmyNWeYm5i+rpVVBeOqnbxcyIKGGD+dolZg/c= 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=JCpFOGD5pTpAZ4yfE/ETCDf+LEtxjm9uii0uengOT481/j8Ab4KZhhFaKf0O4NSwqDYgjOHD+Os/9UEhXhYcCeWO13/AjLh3vSMWgG37rWAV8S0vkgAN0YhcxGEN1x1CBVBDps/L6oADlk5J9hR+0GkVBURjfi1NuYgDv1NaeQc= Received: by 10.115.23.12 with SMTP id a12mr127891waj.1194544434380; Thu, 08 Nov 2007 09:53:54 -0800 (PST) Received: by 10.114.192.9 with HTTP; Thu, 8 Nov 2007 09:53:54 -0800 (PST) Message-ID: <30b660a20711080953l717834belbb656c52da43d85d@mail.gmail.com> Date: Thu, 8 Nov 2007 10:53:54 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <47332C3C.4040103@yahoo-inc.com> MIME-Version: 1.0 References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> <47332C3C.4040103@yahoo-inc.com> X-Google-Sender-Auth: fe3aea63c25d25c0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1248824533==" Errors-To: ltru-bounces@ietf.org --===============1248824533== Content-Type: multipart/alternative; boundary="----=_Part_676_15080480.1194544434363" ------=_Part_676_15080480.1194544434363 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Addison. On 11/8/07, Addison Phillips wrote: > > John Cowan wrote: > > > > I'm not even clear on what the justification is for using it in > > locales. What element of a (computer) locale is specified by > > being in the EU or out of it? It can't be currency, as the > > EU and the eurozone aren't coterminous. > > > > I don't believe it is used in locale *identifiers*. It is used in locale > *data*. In particular, there is a region display name for European Union. > > European Union > > which you find in the document located here: > > http://tinyurl.com/25t3nr > > CLDR uses the ILSR as a source for region codes (I believe) because of > the stability rules we've installed. For that matter, I use it for > various projects for precisely the same reason. > > Actually, this whole conversation is overblown. I don't think CLDR's use > of 'QU' is evil or a bad choice. I wish ISO 3166 would assign, rather > than exceptionally reserve, 'EU' to ensure proper allocation of the code > for applications that need it. > > As John notes, in practical fact there is no real use for this in > language tags (unless one wishes to posit a "EU official" version of a > language for EU (say) translation purposes, such as for regulations or > some-such without favoring a particular country-specific flavor). > > Kind of like "es-419", eh? Not really a language, but useful sometimes. > > 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_676_15080480.1194544434363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Addison.

On 11/8/07, Addison Phillips <addison@yahoo-inc.com> wrote:
John Cowan wrote:
>
> I'm not even clear on what the justification is for using it in
> locales.   What element of a (computer) locale is specified by
> being in the EU or out of it?  It can't be currency, as the
> EU and the eurozone aren't coterminous.
>

I don't believe it is used in locale *identifiers*. It is used in locale
*data*. In particular, there is a region display name for European Union.

  <territory type="QU">European Union</territory>

which you find in the document located here:

  http://tinyurl.com/25t3nr

CLDR uses the ILSR as a source for region codes (I believe) because of
the stability rules we've installed. For that matter, I use it for
various projects for precisely the same reason.

Actually, this whole conversation is overblown. I don't think CLDR's use
of 'QU' is evil or a bad choice. I wish ISO 3166 would assign, rather
than exceptionally reserve, 'EU' to ensure proper allocation of the code
for applications that need it.

As John notes, in practical fact there is no real use for this in
language tags (unless one wishes to posit a "EU official" version of a
language for EU (say) translation purposes, such as for regulations or
some-such without favoring a particular country-specific flavor).

Kind of like "es-419", eh? Not really a language, but useful sometimes.

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_676_15080480.1194544434363-- --===============1248824533== 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 --===============1248824533==-- From ltru-bounces@ietf.org Thu Nov 08 13:41: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 1IqCJN-0007kN-5W; Thu, 08 Nov 2007 13:41:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqCJL-0007ja-DH for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 13:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCJK-0007hu-R3 for ltru@lists.ietf.org; Thu, 08 Nov 2007 13:41:03 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqCJH-0007XJ-D8 for ltru@lists.ietf.org; Thu, 08 Nov 2007 13:41:02 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IqCJD-0001dT-Ra for ltru@lists.ietf.org; Thu, 08 Nov 2007 18:40:55 +0000 Received: from c-180-160-96.hh.dial.de.ignite.net ([62.180.160.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 18:40:55 +0000 Received: from nobody by c-180-160-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 18:40:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 19:40:28 +0100 Organization: Lines: 19 Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org><20071108151323.GA20640@nic.fr><20071108152114.GC29353@mercury.ccil.org><47332C3C.4040103@yahoo-inc.com> <30b660a20711080953l717834belbb656c52da43d85d@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: c-180-160-96.hh.dial.de.ignite.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: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] CLDR as LSTR application (was: The "QU" territory/region code) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: > CLDR uses the ILSR as a source for region codes (I believe) While we're half OT, apparently some info isn't automatically copied when available, e.g. languages_and_scripts.html still says Zxxx for dsb, frr, frs, hsb, and nds. It has Latn for fy and gsw, apparently the LSTR isn't a source for this list, or I looked at an old file. More OT: Deseret and Shavian aren't "und", they're "en" :-) Too lazy to check TUS for Tagalog, was that Berber / Tuareg ? Completely OT: Does the CLDR mailing list still exist ? I tried to forward a mail some weeks ago (via GMaNe), but it never arrived. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 13:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCZj-00016R-FM; Thu, 08 Nov 2007 13:57:59 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqCZi-00013C-DR for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 13:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCZi-000134-3W for ltru@lists.ietf.org; Thu, 08 Nov 2007 13:57:58 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqCZf-00088y-EZ for ltru@lists.ietf.org; Thu, 08 Nov 2007 13:57:58 -0500 Received: from [10.72.72.81] (snvvpn1-10-72-72-c81.corp.yahoo.com [10.72.72.81]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lA8IvlrU073152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 10:57:48 -0800 (PST) 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=Spl7n2OgKgB07tQG0+FIqxclobxV76REWV+luPXcy2lefemx1IPb3UevhMT7Jjds Message-ID: <47335C2B.5020208@yahoo-inc.com> Date: Thu, 08 Nov 2007 10:57:47 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] CLDR as LSTR application References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org><20071108151323.GA20640@nic.fr><20071108152114.GC29353@mercury.ccil.org><47332C3C.4040103@yahoo-inc.com> <30b660a20711080953l717834belbb656c52da43d85d@mail.gmail.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: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > >> CLDR uses the ILSR as a source for region codes (I believe) > > While we're half OT, apparently some info isn't automatically > copied when available, e.g. languages_and_scripts.html still > says Zxxx for dsb, frr, frs, hsb, and nds. It has Latn for > fy and gsw, apparently the LSTR isn't a source for this list, > or I looked at an old file. It *might* be a timing issue. CLDR has regular releases, so the data may depend on when the snapshot of the LSR was taken. However, it also might be that they don't copy the data at all but maintain their own list independently. You'd have to ask "them". > > More OT: Deseret and Shavian aren't "und", they're "en" :-) > Too lazy to check TUS for Tagalog, was that Berber / Tuareg ? Tagalog? It's the script used (mostly formerly used, IIRC) to write the eponymous language Tagalog, a Filipino language unrelated to North African languages or regions. Its language code is "tl". > > Completely OT: Does the CLDR mailing list still exist ? I > tried to forward a mail some weeks ago (via GMaNe), but it > never arrived. > Yes. Are you subscribed to it? Note also that all Unicode lists were down for a period of time a few weeks ago for a server upgrade. This was generally well-announced on the Unicode list, but perhaps not so well on the other lists. 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 Nov 08 14:54: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 1IqDSR-00050x-85; Thu, 08 Nov 2007 14:54:31 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqDSQ-00050D-8d for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 14:54:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDSP-000505-VC for ltru@lists.ietf.org; Thu, 08 Nov 2007 14:54:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqDSL-0001Vj-U3 for ltru@lists.ietf.org; Thu, 08 Nov 2007 14:54:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IqDSC-0003PL-Dq for ltru@lists.ietf.org; Thu, 08 Nov 2007 19:54:16 +0000 Received: from c-180-160-96.hh.dial.de.ignite.net ([62.180.160.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 19:54:16 +0000 Received: from nobody by c-180-160-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 19:54:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 8 Nov 2007 20:53:47 +0100 Organization: Lines: 35 Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org><20071108151323.GA20640@nic.fr><20071108152114.GC29353@mercury.ccil.org><47332C3C.4040103@yahoo-inc.com> <30b660a20711080953l717834belbb656c52da43d85d@mail.gmail.com> <47335C2B.5020208@yahoo-inc.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: c-180-160-96.hh.dial.de.ignite.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: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Ltru] OT: CLDR as LSTR application X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: =20 > You'd have to ask "them". I'm tired of trying to fix obscure list issues for this year, yesterday it ended up with Cc:s to the last three IETF Chairs (it wasn't even one of my mail problems in this case), a week ago it started to involve several W3C I18N folks. Armed with OE, old @xyzzy mailboxes over quota, and mail2news at GMaNe these threads tend to be kafkaesk . =20 > Tagalog? It's the script used (mostly formerly used, IIRC) > to write the eponymous language Tagalog, a Filipino language > unrelated to North African languages or regions. ACK, I confused it with Tifinagh. =20 > Are you subscribed to it? is visible in=20 , but that could be a hallucination on GMaNe's side, if only articles X-posted to other lists (typically the Unicode list) appear in this "newsgroup". > This was generally well-announced on the Unicode list, but > perhaps not so well on the other lists. IIRC I tested the forward from the Unicode to the CLDR list after this announcement, and that ended up in a /dev/null not under my control. Or something. We should use Wikis instead of lists, Wikis are cute.=20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 08 16:49: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 1IqFFv-0007nV-U7; Thu, 08 Nov 2007 16:49:43 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqFFv-0007nH-AR for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:49:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFFu-0007n8-Ub for ltru@lists.ietf.org; Thu, 08 Nov 2007 16:49:42 -0500 Received: from qb-out-0506.google.com ([72.14.204.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFFt-0004kn-2c for ltru@lists.ietf.org; Thu, 08 Nov 2007 16:49:42 -0500 Received: by qb-out-0506.google.com with SMTP id a10so1728747qbd for ; Thu, 08 Nov 2007 13:49:40 -0800 (PST) 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=E2EuQvHNnA+PRV2ZkRqIuITzysnWUJqs8m1z9ngsX8I=; b=YpNov/Z28EQO3MB/FYkYJCJ7vKJse77YYcG8CNylpCkgLhOPnRKecGL3SrU+SVU6Qo7SW5t18jzQTAMgB9J9lqgbqOI6YHszr/vldmsV2kJg1bHXZAs7hzzU8XWjlrI1VP8N3VtvqS120+lQDsJNwkknYZuGIdnbmgMbdxEjtcc= 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=p5y4cpG+TxSK04yJ2LKr0HkKC0mhFswFtYHS7ALT02mfvVv9kky3S0R+Pknr706uNdYD1a3HrzsNmcqr3+PzgA1s0joSHuQAHVDMBci+vUhdr97FDjcsTTkZ6MSlrw9zmLarO62ZEF+jpzePNmWd3Th5qL4S3nmhiDTnKMSiiaU= Received: by 10.115.88.1 with SMTP id q1mr146672wal.1194558579363; Thu, 08 Nov 2007 13:49:39 -0800 (PST) Received: by 10.114.192.9 with HTTP; Thu, 8 Nov 2007 13:49:39 -0800 (PST) Message-ID: <30b660a20711081349i5a5107e6u846a2d9c84801fa9@mail.gmail.com> Date: Thu, 8 Nov 2007 13:49:39 -0800 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] CLDR as LSTR application In-Reply-To: <47335C2B.5020208@yahoo-inc.com> MIME-Version: 1.0 References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> <47332C3C.4040103@yahoo-inc.com> <30b660a20711080953l717834belbb656c52da43d85d@mail.gmail.com> <47335C2B.5020208@yahoo-inc.com> X-Google-Sender-Auth: 2b048ac6d6705c71 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Frank Ellermann , "rick@unicode.org" , 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="===============0825337609==" Errors-To: ltru-bounces@ietf.org --===============0825337609== Content-Type: multipart/alternative; boundary="----=_Part_1706_9640961.1194558579332" ------=_Part_1706_9640961.1194558579332 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/8/07, Addison Phillips wrote: > > Frank Ellermann wrote: > > > >> CLDR uses the ILSR as a source for region codes (I believe) > > > > While we're half OT, apparently some info isn't automatically > > copied when available, e.g . languages_and_scripts.html still > > says Zxxx for dsb, frr, frs, hsb, and nds. It has Latn for > > fy and gsw, apparently the LSTR isn't a source for this list, > > or I looked at an old file. > > It *might* be a timing issue. CLDR has regular releases, so the data may > depend on when the snapshot of the LSR was taken. There is a timing issue. CLDR picks up the latest version of the LSR during each cycle, but that takes some time. Also, some of the data is not automatically incorporated: Rick McGowan is responsible for incorporating the language-territory information, including suppress script. We are right in the middle of a bug-fix release, so any feedback from the experts here would be very useful. There is a table of "likely subtags" for which review from people here would be particularly useful. http://unicode.org/cldr/data/charts/supplemental/likely_subtags.html Description: http://unicode.org/draft/reports/tr35/tr35.html#Likely_Subtags However, it also might be that they don't copy the data at all but > maintain their own list independently. You'd have to ask "them". > > > > > More OT: Deseret and Shavian aren't "und", they're "en" :-) > > Too lazy to check TUS for Tagalog, was that Berber / Tuareg ? und, Zzzz, ZZ means that we don't have the information yet. (While we want to -- over time -- flesh out all the data, the focus is on the highest use cases, so Deseret and Shavian are lower priority; but I'm forwarding this to Rick.) Tagalog? It's the script used (mostly formerly used, IIRC) to write the > eponymous language Tagalog, a Filipino language unrelated to North > African languages or regions. Its language code is "tl". > > > > > Completely OT: Does the CLDR mailing list still exist ? I > > tried to forward a mail some weeks ago (via GMaNe), but it > > never arrived. > > > > Yes. Are you subscribed to it? Note also that all Unicode lists were > down for a period of time a few weeks ago for a server upgrade. This was > generally well-announced on the Unicode list, but perhaps not so well on > the other lists. There are two CLDR lists; one for the public (which doesn't get a lot of traffic), and one for members (that has much more). We also have a weekly meeting, where most of the decisions get made. 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_1706_9640961.1194558579332 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/8/07, Addison Phillips <addison@yahoo-inc.com > wrote:
Frank Ellermann wrote:
>
>> CLDR uses the ILSR as a source for region codes (I believe)
>
> While we're half OT, apparently some info isn't automatically
> copied when available, e.g . languages_and_scripts.html still
> says Zxxx for dsb, frr, frs, hsb, and nds.  It has Latn for
> fy and gsw, apparently the LSTR isn't a source for this list,
> or I looked at an old file.

It *might* be a timing issue. CLDR has regular releases, so the data may
depend on when the snapshot of the LSR was taken.

There is a timing issue. CLDR picks up the latest version of the LSR during each cycle, but that takes some time. Also, some of the data is not automatically incorporated: Rick McGowan is responsible for incorporating the language-territory information, including suppress script.

We are right in the middle of a bug-fix release, so any feedback from the experts here would be very useful. There is a table of "likely subtags" for which review from people here would be particularly useful.

http://unicode.org/cldr/data/charts/supplemental/likely_subtags.html

Description: http://unicode.org/draft/reports/tr35/tr35.html#Likely_Subtags

However, it also might be that they don't copy the data at all but
maintain their own list independently. You'd have to ask "them".

>
> More OT:  Deseret and Shavian aren't "und", they're "en" :-)
> Too lazy to check TUS for Tagalog, was that Berber / Tuareg ?

und, Zzzz, ZZ means that we don't have the information yet. (While we want to -- over time -- flesh out all the data, the focus is on the highest use cases, so Deseret and Shavian are lower priority; but I'm forwarding this to Rick.)

Tagalog? It's the script used (mostly formerly used, IIRC) to write the
eponymous language Tagalog, a Filipino language unrelated to North
African languages or regions. Its language code is "tl".

>
> Completely OT:  Does the CLDR mailing list still exist ?  I
> tried to forward a mail some weeks ago (via GMaNe), but it
> never arrived.
>

Yes. Are you subscribed to it? Note also that all Unicode lists were
down for a period of time a few weeks ago for a server upgrade. This was
generally well-announced on the Unicode list, but perhaps not so well on
  the other lists.

There are two CLDR lists; one for the public (which doesn't get a lot of traffic), and one for members (that has much more). We also have a weekly meeting, where most of the decisions get made.

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_1706_9640961.1194558579332-- --===============0825337609== 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 --===============0825337609==-- From ltru-bounces@ietf.org Thu Nov 08 21:10: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 1IqJKc-00070s-H0; Thu, 08 Nov 2007 21:10:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqJKb-0006zV-EE for ltru-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 21:10:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqJKb-0006zN-4m for ltru@lists.ietf.org; Thu, 08 Nov 2007 21:10:49 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqJKY-0005Gh-SR for ltru@lists.ietf.org; Thu, 08 Nov 2007 21:10:49 -0500 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.222.3; Thu, 8 Nov 2007 18:10:33 -0800 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; Thu, 8 Nov 2007 18:10:45 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Thu, 8 Nov 2007 18:10:43 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgiI45oj++GbsPmRsmbt1/EXoRfqgAUU+Fg Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> <47332C3C.4040103@yahoo-inc.com> <473337B5.90402@yahoo-inc.com> In-Reply-To: <473337B5.90402@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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1898851218==" Errors-To: ltru-bounces@ietf.org --===============1898851218== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJdCdzIGFuIGFwcGxpY2F0aW9uIG9mIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkuIE5v dCBpdHMgcHJpbWFyeQ0KPiBhcHBsaWNhdGlvbiwgYnV0IGl0IGlzIGFuIGFwcGxpY2F0aW9uLg0K DQpXZWxsLCBJJ20gbm90IG9wcG9zZWQgdG8gcXVlc3Rpb25zIG9mIHdoYXQgbWFrZXMgc2Vuc2Ug Zm9yIGFuIGVjb3N5c3RlbSBvZiBjbG9zZWx5IHJlbGF0ZWQgdGFnZ2luZyBzY2hlbWVzLiBOb2Jv ZHkgd291bGQgYmUgc2VydmVkIGluIHRoZSBsb25nIHJ1biBpZiB3ZSBoYWQgdG8gaGF2ZSBjb21w bGV0ZWx5IHNlcGFyYXRlIHNjaGVtZXMgYW5kIGluZnJhc3RydWN0dXJlcyBmb3IgdGhpbmdzIHRo YXQgb3ZlcmxhcCA5NSUsIHNvIGl0IG1heSBtYWtlIHNlbnNlIHRvIGFsbG93IGEgMiUgY29tcHJv bWlzZSBvZiBzY29wZSBpbiBvbmUgcGxhY2Ugb3IgYW5vdGhlciB0byBwcm92aWRlIGEgc2luZ2xl LCBjb2hlcmVudCBlY29zeXN0ZW0gb2YgcmVsYXRlZCBzY2hlbWVzLg0KDQooT2YgY291cnNlIHlv dSBkb24ndCBjb21wcm9taXNlIEEgZm9yIHNvbWV0aGluZyBpbiBCIHdoZW4gdGhhdCBzb21ldGhp bmcgcmVhbGx5IGlzbid0IHJlbGV2YW50IGZvciBCIC0tIGEgc2VwYXJhdGUgcXVlc3Rpb24gYWx0 b2dldGhlci4pDQoNCg0KUGV0ZXINCg== --===============1898851218== 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 --===============1898851218==-- From ltru-bounces@ietf.org Fri Nov 09 11:46: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 1IqX0C-0007s9-RE; Fri, 09 Nov 2007 11:46:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqX0B-0007o3-CE for ltru-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 11:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqX0B-0007nv-2b for ltru@lists.ietf.org; Fri, 09 Nov 2007 11:46:39 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqX07-0004bA-O5 for ltru@lists.ietf.org; Fri, 09 Nov 2007 11:46:39 -0500 Received: by rv-out-0910.google.com with SMTP id k20so515219rvb for ; Fri, 09 Nov 2007 08:46:30 -0800 (PST) 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=AujuC5ASrPcFXJMG6Gc7GkOk+Q2Q0o5Ql/e9aOSWwIY=; b=gyEKtgj52bp3ZwJfuXfvSTLhHYcMVmzkqyk5HjUa21k1SRHbYv+lSS1D+sWMCAUXnr/ydHAyUvp+Ki2SMjiH4xWZYMk6zjzpmxqqjAv4YjLN9OkqOXPkoMgrt/fu0YITDfJxrZKVOpLWfWIU0S3jbGtT4rU00kqzlv+9MuvXAk4= 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=dDTzQTiDNYxY9ROsBbbHc3FtAB4QoSX7pOOcZMelW6H76SjWcXvvzQe82sXgsd0WU+xWdPoEf4yHvkb2dojN9Mai4LBxMfkQW/9hw+nbduCpLOEZh6RC2iTBV6ZLBFkPUJwd9kVj08+kHCxTBI8GlGo1vLMroaEPMaSeuerXdfk= Received: by 10.114.169.2 with SMTP id r2mr250931wae.1194626790690; Fri, 09 Nov 2007 08:46:30 -0800 (PST) Received: by 10.114.192.9 with HTTP; Fri, 9 Nov 2007 08:46:30 -0800 (PST) Message-ID: <30b660a20711090846o66bee0e6sd16ba0c4928c1a19@mail.gmail.com> Date: Fri, 9 Nov 2007 08:46:30 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: MIME-Version: 1.0 References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <20071108151323.GA20640@nic.fr> <20071108152114.GC29353@mercury.ccil.org> <47332C3C.4040103@yahoo-inc.com> <473337B5.90402@yahoo-inc.com> X-Google-Sender-Auth: b79423d0c43d3682 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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="===============1181488712==" Errors-To: ltru-bounces@ietf.org --===============1181488712== Content-Type: multipart/alternative; boundary="----=_Part_5123_29471840.1194626790685" ------=_Part_5123_29471840.1194626790685 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. On Nov 8, 2007 6:10 PM, Peter Constable wrote: > > It's an application of the language subtag registry. Not its primary > > application, but it is an application. > > Well, I'm not opposed to questions of what makes sense for an ecosystem of > closely related tagging schemes. Nobody would be served in the long run if > we had to have completely separate schemes and infrastructures for things > that overlap 95%, so it may make sense to allow a 2% compromise of scope in > one place or another to provide a single, coherent ecosystem of related > schemes. > > (Of course you don't compromise A for something in B when that something > really isn't relevant for B -- a separate question altogether.) > > > Peter > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_5123_29471840.1194626790685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree.

On Nov 8, 2007 6:10 PM, Peter Constable <petercon@microsoft.com> wrote:
> It's an application of the language subtag registry. Not its primary
> application, but it is an application.

Well, I'm not opposed to questions of what makes sense for an ecosystem of closely related tagging schemes. Nobody would be served in the long run if we had to have completely separate schemes and infrastructures for things that overlap 95%, so it may make sense to allow a 2% compromise of scope in one place or another to provide a single, coherent ecosystem of related schemes.

(Of course you don't compromise A for something in B when that something really isn't relevant for B -- a separate question altogether.)


Peter

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




--
Mark ------=_Part_5123_29471840.1194626790685-- --===============1181488712== 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 --===============1181488712==-- From ltru-bounces@ietf.org Fri Nov 09 19:08: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 1Iqdtb-0005gz-4f; Fri, 09 Nov 2007 19:08:19 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IqdtZ-0005gQ-Gp for ltru-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 19:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqdtZ-0005gG-7D for ltru@lists.ietf.org; Fri, 09 Nov 2007 19:08:17 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqdtV-0004yj-9A for ltru@lists.ietf.org; Fri, 09 Nov 2007 19:08:17 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 2D1D0240823; Sat, 10 Nov 2007 00:08:03 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 0C5F4158F01; Fri, 9 Nov 2007 14:54:11 +0100 (CET) Date: Fri, 9 Nov 2007 14:54:11 +0100 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Message-ID: <20071109135411.GB6701@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.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 1.9 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] An example of the use of language tags for tracking users X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 ICANN Anti-Phishing Working Group has put forward a set of best practice recommendations, currently in draft state: http://gnso.icann.org/mailing-lists/archives/registrars/msg05187.html One of them is relevant to us. They ask for the registrar to collect and store "technical details of the registration" and mention, among other things, some HTTP headers. Accept-Language is explicitely mentioned. For me, it is a good example of why the Security Considerations need to explain the privacy issue associated with language tags. Because other parts of the draft mention reputation systems, we may seen that users whose Accept-Language indicate, say, russian, being screened more... _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 09 20:18: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 1Iqezw-0005h0-4W; Fri, 09 Nov 2007 20:18:56 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iqezu-0005fN-7H for ltru-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 20:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqezt-0005fF-Tq for ltru@lists.ietf.org; Fri, 09 Nov 2007 20:18:53 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqezq-0006mB-0Y for ltru@lists.ietf.org; Fri, 09 Nov 2007 20:18:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iqezm-00017w-Ef for ltru@lists.ietf.org; Sat, 10 Nov 2007 01:18:46 +0000 Received: from c-180-160-255.hh.dial.de.ignite.net ([62.180.160.255]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Nov 2007 01:18:46 +0000 Received: from nobody by c-180-160-255.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Nov 2007 01:18:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Sat, 10 Nov 2007 02:18:12 +0100 Organization: Lines: 35 Message-ID: References: <20071109135411.GB6701@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: c-180-160-255.hh.dial.de.ignite.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: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Ltru] Re: An example of the use of language tags for tracking users X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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=B4wrote: > The ICANN Anti-Phishing Working Group has put forward a set of best > practice recommendations, currently in draft state: > http://gnso.icann.org/mailing-lists/archives/registrars/msg05187.html Thanks for the link. I'm not too impressed by a DOC attachement with a reference to SORBS, the content appears to be okay, though. > They ask for the registrar to collect and store "technical details=20 > of the registration" and mention, among other things, some HTTP=20 > headers. Accept-Language is explicitely mentioned. Yeah, I knew why I sabotaged it with Netscape 2.02. OTOH I didn't try to sabotage it again with IE6 and FF2. =20 > For me, it is a good example of why the Security Considerations need > to explain the privacy issue associated with language tags. They do. > we may see that users whose Accept-Language indicate, say, russian, > being screened more... Wrt to the (shaky) GeoIP the drift of the draft is apparently about plausibility, Russian is perfectly plausible for a registration from somebody with a "Russian IP" and an address in Russia. It's less plausible with a German DialUP IP from somebody claiming to live in Florida. I'd be surprised if "Leo" feels threatened by such simple plausibility checks. Frank --=20 http://www.spamhaus.org/rokso/listing.lasso?spammer=3DLeo%20Kuvayev%20/%2= 0BadCow _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Nov 11 11:31: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 1IrFiw-0006w4-7r; Sun, 11 Nov 2007 11:31:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IrFiu-0006sZ-US for ltru-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 11:31:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrFiu-0006sR-L3 for ltru@ietf.org; Sun, 11 Nov 2007 11:31:48 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrFis-0000Ld-97 for ltru@ietf.org; Sun, 11 Nov 2007 11:31:48 -0500 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 <20071111163144.PQEV5651.mta10.adelphia.net@DGBP7M81> for ; Sun, 11 Nov 2007 11:31:44 -0500 Message-ID: <003201c82480$59511900$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 11 Nov 2007 08:31:44 -0800 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: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Re: An example of the use of language tags for tracking users X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > For me, it is a good example of why the Security Considerations need > to explain the privacy issue associated with language tags. Because > other parts of the draft mention reputation systems, we may seen that > users whose Accept-Language indicate, say, russian, being screened > more... The first three paragraphs of the existing Security Considerations section already talk about this. I don't think it should be necessary to describe every possible scenario where language tags could be used for profiling. -- 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 Sun Nov 11 21:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOke-0003OF-2z; Sun, 11 Nov 2007 21:10:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IrOkc-0003LR-Kq for ltru-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 21:10:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOkc-0003LA-A0 for ltru@ietf.org; Sun, 11 Nov 2007 21:10:10 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrOkb-0003LK-GS for ltru@ietf.org; Sun, 11 Nov 2007 21:10:10 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAC2A2bh022628 for ; Mon, 12 Nov 2007 11:10:02 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0f4f_6097b9f2_90c4_11dc_803d_0014221f2a2d; Mon, 12 Nov 2007 11:10:01 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:43463) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 12 Nov 2007 11:06:13 +0900 Message-Id: <6.0.0.20.2.20071112105656.09b20bb0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 12 Nov 2007 10:58:01 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: An example of the use of language tags for tracking users In-Reply-To: <003201c82480$59511900$6601a8c0@DGBP7M81> References: <003201c82480$59511900$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:31 07/11/12, Doug Ewell wrote: >Stephane Bortzmeyer wrote: > >> For me, it is a good example of why the Security Considerations need to explain the privacy issue associated with language tags. Because other parts of the draft mention reputation systems, we may seen that users whose Accept-Language indicate, say, russian, being screened more... > >The first three paragraphs of the existing Security Considerations section already talk about this. I don't think it should be necessary to describe every possible scenario where language tags could be used for profiling. Chair hat on: Stephane, if you think that the current text is not sufficient, please provide additional wording. 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 Nov 12 22:10: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 1IrmAS-0001Pb-Dn; Mon, 12 Nov 2007 22:10:24 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IrmAR-0001PU-Bl for ltru-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 22:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrmAR-0001Oc-13 for ltru@lists.ietf.org; Mon, 12 Nov 2007 22:10:23 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrmAL-0000QW-FU for ltru@lists.ietf.org; Mon, 12 Nov 2007 22:10:23 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAD3ABmg027679 for ; Tue, 13 Nov 2007 12:10:13 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 3749_f22f4412_9195_11dc_8435_0014221f2a2d; Tue, 13 Nov 2007 12:10:11 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56488) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 13 Nov 2007 12:06:23 +0900 Message-Id: <6.0.0.20.2.20071113111836.0894b600@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 13 Nov 2007 11:22:41 +0900 To: John Cowan , Frank Ellermann From: Martin Duerst Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <20071108131953.GA29353@mercury.ccil.org> References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 22:19 07/11/08, John Cowan wrote: >Frank Ellermann scripsit: >> And IANA has "EU" on a web page >> , a redirection to >> . They have a link to the >> "ccTLD" redirection on their main page. > >The European Union (which is what "EU" means as an exceptionally reserved >ISO 3166 code element) isn't relevant to language tagging: there are no >EU vs. non-EU regional variants of languages. This seems to be the current consensus. What I'm a bit worried about, and would like to see some confirmation, is the following scenario. Assume for one reason or another, some EU variant of a language develops, is defined, or what not. Obviously at least to me, the region subtag 'EU' would be most suited in this case. Is it possible that the ietf-languages list just adds this subtag to the registry, or would we have to convene a WG and write another version of what's currently RFC 4646? If the later is the case, my preference would be to carefully tweak our texts so that we can avoid rechartering just for the potential scenario described above. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 13 00:12: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 1Iro4a-0001Gu-CZ; Tue, 13 Nov 2007 00:12:28 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iro4Z-0001Gp-6O for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 00:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iro4Y-0001Gc-Sk for ltru@lists.ietf.org; Tue, 13 Nov 2007 00:12:26 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iro4Y-0003g2-8J for ltru@lists.ietf.org; Tue, 13 Nov 2007 00:12:26 -0500 Received: from [10.72.73.5] (snvvpn1-10-72-73-c5.corp.yahoo.com [10.72.73.5]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAD5C9Nn067044; Mon, 12 Nov 2007 21:12:09 -0800 (PST) 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=ooPFOlcjvgDuHQYhxO1qtbwaUr7u9cohxirf0czy5QWrWLtuAkxZywJ3nPkzqzNd Message-ID: <47393229.7010405@yahoo-inc.com> Date: Mon, 12 Nov 2007 21:12:09 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: The "QU" territory/region code References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <6.0.0.20.2.20071113111836.0894b600@localhost> In-Reply-To: <6.0.0.20.2.20071113111836.0894b600@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Martin, Actually, I think I already described a case for EU being used in language tags. I think we would, given the present rules, be required to amend RFC 4646. One could register a variant to represent the same meaning as 'EU'. But registering 'EU' is not permitted (for very good reason). The way to get 'EU' would be to petition ISO 3166 MA to do more than exceptionally reserve it. This doesn't strike me as bad, wrong, or problematic. Addison PS> Could you or Randy ***please*** respond to repeated requests for action on teleconference scheduling? Martin Duerst wrote: > At 22:19 07/11/08, John Cowan wrote: >> Frank Ellermann scripsit: > >>> And IANA has "EU" on a web page >>> , a redirection to >>> . They have a link to the >>> "ccTLD" redirection on their main page. >> The European Union (which is what "EU" means as an exceptionally reserved >> ISO 3166 code element) isn't relevant to language tagging: there are no >> EU vs. non-EU regional variants of languages. > > This seems to be the current consensus. > > What I'm a bit worried about, and would like to see some confirmation, > is the following scenario. Assume for one reason or another, some EU > variant of a language develops, is defined, or what not. Obviously > at least to me, the region subtag 'EU' would be most suited in this > case. Is it possible that the ietf-languages list just adds this > subtag to the registry, or would we have to convene a WG and write > another version of what's currently RFC 4646? If the later is the > case, my preference would be to carefully tweak our texts so that > we can avoid rechartering just for the potential scenario described > above. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. 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 Nov 13 02:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrpmB-0007iI-6d; Tue, 13 Nov 2007 02:01:35 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Irpm9-0007i1-PZ for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 02:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irpm9-0007ht-Di for ltru@lists.ietf.org; Tue, 13 Nov 2007 02:01:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irpm6-00069y-N9 for ltru@lists.ietf.org; Tue, 13 Nov 2007 02:01:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IrplK-0001Kq-6n for ltru@lists.ietf.org; Tue, 13 Nov 2007 07:00:42 +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, 13 Nov 2007 07:00:42 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Nov 2007 07:00:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Tue, 13 Nov 2007 07:55:41 +0100 Lines: 18 Message-ID: References: <20071108083134.GB7228@nic.fr> <20071108091632.GA15306@nic.fr> <20071108131953.GA29353@mercury.ccil.org> <6.0.0.20.2.20071113111836.0894b600@localhost> 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: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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 D=FCrst wrote: > Assume for one reason or another, some EU variant of a language > develops, is defined, or what not. Obviously at least to me,=20 > the region subtag 'EU' would be most suited in this case. EU is no proper "region" wrt language tagging, it includes the new MF and other parts of the world far away from Brussels (Bruxelles). > Is it possible that the ietf-languages list just adds this subtag > to the registry They could approve a variant "eurocrat" with several prefixes, if a kind of "EU-lingo" has to be identified. Or they could ask Debbie how to transform EU in a proper region tag, but I fear the result for language tagging wouldn't be much better than say UM. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 13 06:20: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 1IrtoT-0001Hg-Mq; Tue, 13 Nov 2007 06:20:14 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IrtoS-0001Hb-Vd for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 06:20:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrtoS-0001HT-M6 for ltru@ietf.org; Tue, 13 Nov 2007 06:20:12 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrtoN-0005tJ-7D for ltru@ietf.org; Tue, 13 Nov 2007 06:20:12 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lADBK1ZF029618 for ; Tue, 13 Nov 2007 20:20:02 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1db3_604fff38_91da_11dc_971d_0014221fa3c9; Tue, 13 Nov 2007 20:20:01 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46087) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 13 Nov 2007 20:16:13 +0900 Message-Id: <6.0.0.20.2.20071113193802.0ab17ba0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 13 Nov 2007 19:40:02 +0900 To: Addison Phillips , "'LTRU Working Group'" From: Martin Duerst Subject: Re: [Ltru] trying again: teleconference??? In-Reply-To: <472D0B0A.3010200@yahoo-inc.com> References: <472D0B0A.3010200@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 08:58 07/11/04, Addison Phillips wrote: >Chairs, > >Could you please choose and announce an appropriate time for >teleconferences? Or announce that there will be no teleconferences? It's difficult to just announce something. Addison, can you list up some possible slots for this week (e.g. your Thursday late or Friday early)? If we had a slot that people were able to agree on before, and that's not totally in the middle of the night for me, I'll try to participate, too. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 13 10:58: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 1IrxaY-0003xP-Aj; Tue, 13 Nov 2007 10:22:06 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IrxZF-0002Sq-4N for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 10:20:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxZB-0002Oq-7w for ltru@ietf.org; Tue, 13 Nov 2007 10:20:41 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxZ8-0006LH-J0 for ltru@ietf.org; Tue, 13 Nov 2007 10:20:41 -0500 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 <20071113152037.YGHW27057.mta15.adelphia.net@DGBP7M81>; Tue, 13 Nov 2007 10:20:37 -0500 Message-ID: <002501c82608$beecc140$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 13 Nov 2007 07:20:37 -0800 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: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > What I'm a bit worried about, and would like to see some confirmation, > is the following scenario. Assume for one reason or another, some EU > variant of a language develops, is defined, or what not. Back to this in a moment. > Obviously at least to me, the region subtag 'EU' would be most suited > in this case. Is it possible that the ietf-languages list just adds > this subtag to the registry, or would we have to convene a WG and > write another version of what's currently RFC 4646? If the later is > the case, my preference would be to carefully tweak our texts so that > we can avoid rechartering just for the potential scenario described > above. Both RFC 4646 and draft-4646bis is that they refer to code elements "assigned" in ISO 3166-1. RFC 4645 uses the terms "valid" and "assigned" in populating the initial LSR. Exceptionally reserved code elements are not "assigned" according to the ISO 3166/MA definition, and thus they don't qualify to have region subtags derived from them according to our definition. We would need to change the requirements in 4646bis, and possibly in 4645bis, or else recharter the group to do this in the future. As Addison said, if we really need a region subtag EU, someone needs to petition ISO 3166/MA to assign the code element. This discussion, however, continues to presume a (potential) need for a region subtag to describe language usage in exactly these countries (as of 2007-11-03): AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, IT, LT, LU, LV, MT, NL, PL, PT, RO, SE, SI, SK and all of their dependencies, but NOT neighboring countries such as Iceland, Norway, Switzerland, or the Baltics. And the list of EU countries changes with some regularity -- there are currently three "official candidate states" and four "potential candidates" -- making code instability not merely a possibility, as it is with all country coding systems, but a certainty. This is not at all (IMHO) like the recent addition of BL and MF to 3166 and the LSR, two countries (if that they are) which don't appear to exhibit distinct language usage. In that case, we are mirroring the decisions made by ISO 3166/MA, as we claim to do, without consideration of the linguistic angle. In the case of EU, we are actively seeking an exception to our rules, which implies we must have a pretty good reason to do so. Thanks to numeric region codes based on UN M.49, we now have lots of way to indicate pan-European usage: 039, 150, 151, 154, 155. This has nothing to do with serving the language-tagging needs of Europe. Bureaucratic jargon is NOT a regional variation; as Frank said, a variant would be better suited to this. Even Michael Everson's famous crusade against use of "euro" as a plural was NOT an instance of "EU usage," but rather a misinterpretation of an EU directive by local Irish officials and journalists. -- 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 Tue Nov 13 11:23: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 1IryYK-0001HA-7J; Tue, 13 Nov 2007 11:23:52 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IryYI-0001H2-Ut for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 11:23:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryYI-0001Gs-IN for ltru@ietf.org; Tue, 13 Nov 2007 11:23:50 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IryYI-0004aL-1g for ltru@ietf.org; Tue, 13 Nov 2007 11:23:50 -0500 Received: from [10.72.73.5] (snvvpn1-10-72-73-c5.corp.yahoo.com [10.72.73.5]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lADGNej8082302; Tue, 13 Nov 2007 08:23:41 -0800 (PST) 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=rXVYvuSrr6r4wLIGpdWEmrnAm18SL+yukSyXSUqRyx7WPykCWrfgneSF2m/sKuI9 Message-ID: <4739CF8C.3050408@yahoo-inc.com> Date: Tue, 13 Nov 2007 08:23:40 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] trying again: teleconference??? References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> In-Reply-To: <6.0.0.20.2.20071113193802.0ab17ba0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > At 08:58 07/11/04, Addison Phillips wrote: >> Chairs, >> >> Could you please choose and announce an appropriate time for >> teleconferences? Or announce that there will be no teleconferences? > > It's difficult to just announce something. Addison, can you list up > some possible slots for this week (e.g. your Thursday late or > Friday early)? If we had a slot that people were able to agree on > before, and that's not totally in the middle of the night for me, > I'll try to participate, too. > Martin, I'm not suggesting we "just announce" something. Previously on this list there was a discussion of possible times. Normally, it is up to the chair(s) of the group to coordinate scheduling of activities such as this, etc. and make the final announcement. In any case, I'm happy to suggest some times (I just did this for W3C-I18N-Core, so I can be eco-friendly and recycle the bits: see below), but you or Randy should take ownership of gathering input and selecting the date/time. Addison Here are some optional *times*. I can do any of these on either Wednesdays or Thursdays. Note that London is currently effectively the same as GMT. (A) 07:00 Pacific 15:00 London 02:00 Sydney (next day) 00:00 Tokyo (next day) 10:00 Toronto (B) 14:00 Pacific 22:00 London 09:00 Sydney 07:00 Tokyo 17:00 Toronto (C) 12:00 Pacific 20:00 London 07:00 Sydney 05:00 Tokyo 15:00 Toronto (D) 22:00 Pacific 06:00 London 17:00 Sydney 15:00 Tokyo 01:00 Toronto -- 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 Nov 13 12:59: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 1Is037-00085g-Dl; Tue, 13 Nov 2007 12:59:45 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Is036-000845-HQ for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 12:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is036-00083x-7Z for ltru@ietf.org; Tue, 13 Nov 2007 12:59:44 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is033-0006C6-7Q for ltru@ietf.org; Tue, 13 Nov 2007 12:59:44 -0500 Received: from [10.72.73.5] (snvvpn1-10-72-73-c5.corp.yahoo.com [10.72.73.5]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lADHxaM4099567; Tue, 13 Nov 2007 09:59:36 -0800 (PST) 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=beKX3/me+GQA6InLhLfSr87qXXC2/CMyqfcrk3ktRFIbjemX2FIZusA20JtOQmxm Message-ID: <4739E608.2080005@yahoo-inc.com> Date: Tue, 13 Nov 2007 09:59:36 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: The "QU" territory/region code References: <002501c82608$beecc140$6601a8c0@DGBP7M81> In-Reply-To: <002501c82608$beecc140$6601a8c0@DGBP7M81> 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 lADHxaM4099567 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 What follows is a bit of a rant, albeit with a textual propose for our=20 draft (remember our draft?). Pardon my dust. :-) Okay, here's my concern: there was, at one time, a very long and=20 not-very-friendly thread on ietf-languages in which folks mostly from=20 the software industry attempted (and failed) to register "es-americas"=20 to identify some kind of Latin American or mid-Atlantic Spanish. The=20 argument against this (basically) was that there was no such "real"=20 language, as in "a language recognized by linguistic scholars". There=20 were, however, some who thought they had a quite real need to identify=20 an artificially created linguistic variant. In RFC 4646 we explicitly acknowledged the potential for use of the UN=20 M.49 code "419" for this purpose. I agree with Doug that one of the UN M.49 codes could be used to=20 identify an artificial linguistic variant for the EU. However, I would=20 be unsurprised if, for example, the EC were to adopt specially=20 controlled language variations for translating EU "stuff" without having=20 to choose particular local variants (or translate into all of them).=20 Thus I can imagine an "fr-EU" or "de-EU" which is both "not a real=20 language" and also not "fr-FR" or "de-DE". This could also be addressed=20 as "fr-x-euro" or "de-eunion" or some-such. What bothers me is the sense that "we" (there is no "we") know better=20 than the users making the request about their application's needs. I=20 tend to be a little more promiscuous about supporting variants as a=20 result. There are cases where the thing being requested isn't well=20 thought out. But I am not altogether happy with the notion that there is=20 only one way to use language tags or that "there is no such language as=20 X hence no use for this subtag in language tags". We don't actually know=20 that. So: I think it would be just grand if 'EU' were actually assigned by ISO=20 3166 and not just reserved. Further, I would support our acknowledging=20 the "exceptional reservation" as "an assignment" in 4646bis. To that=20 end, I'd propose changing Section 2.2.4, item 2 in the list to read: -- All two-character subtags following the primary subtag, with one=20 exception, were defined in the IANA registry according to the=20 assignments found in [ISO3166=E2=80=911] (International Organization for=20 Standardization, =E2=80=9CISO 3166-1:1997. Codes for the representation o= f names=20 of countries and their subdivisions -- Part 1: Country codes,=E2=80=9D 19= 97.)=20 ("Codes for the representation of names of countries and their=20 subdivisions -- Part 1: Country codes") using the list of alpha-2=20 country codes, or using assignments subsequently made by the ISO 3166=20 maintenance agency or governing standardization bodies. The one=20 exception is the code 'EU' (European Union), which is "exceptionally=20 reserved" for that purpose (but not "assigned") by ISO 3166. This code=20 is assigned in the registry and is subject to the same constraints that=20 appear elsewhere in this document as if it were actually assigned by ISO=20 3166. -- Regards, Addison Doug Ewell wrote: > Martin Duerst wrote: >=20 >> What I'm a bit worried about, and would like to see some confirmation,= =20 >> is the following scenario. Assume for one reason or another, some EU=20 >> variant of a language develops, is defined, or what not. >=20 > Back to this in a moment. >=20 >> Obviously at least to me, the region subtag 'EU' would be most suited=20 >> in this case. Is it possible that the ietf-languages list just adds=20 >> this subtag to the registry, or would we have to convene a WG and=20 >> write another version of what's currently RFC 4646? If the later is=20 >> the case, my preference would be to carefully tweak our texts so that=20 >> we can avoid rechartering just for the potential scenario described=20 >> above. >=20 > Both RFC 4646 and draft-4646bis is that they refer to code elements=20 > "assigned" in ISO 3166-1. RFC 4645 uses the terms "valid" and=20 > "assigned" in populating the initial LSR. Exceptionally reserved code=20 > elements are not "assigned" according to the ISO 3166/MA definition, an= d=20 > thus they don't qualify to have region subtags derived from them=20 > according to our definition. We would need to change the requirements=20 > in 4646bis, and possibly in 4645bis, or else recharter the group to do=20 > this in the future. >=20 > As Addison said, if we really need a region subtag EU, someone needs to= =20 > petition ISO 3166/MA to assign the code element. >=20 > This discussion, however, continues to presume a (potential) need for a= =20 > region subtag to describe language usage in exactly these countries (as= =20 > of 2007-11-03): >=20 > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, IT, LT, LU,= =20 > LV, MT, NL, PL, PT, RO, SE, SI, SK >=20 > and all of their dependencies, but NOT neighboring countries such as=20 > Iceland, Norway, Switzerland, or the Baltics. And the list of EU=20 > countries changes with some regularity -- there are currently three=20 > "official candidate states" and four "potential candidates" -- making=20 > code instability not merely a possibility, as it is with all country=20 > coding systems, but a certainty. >=20 > This is not at all (IMHO) like the recent addition of BL and MF to 3166= =20 > and the LSR, two countries (if that they are) which don't appear to=20 > exhibit distinct language usage. In that case, we are mirroring the=20 > decisions made by ISO 3166/MA, as we claim to do, without consideration= =20 > of the linguistic angle. In the case of EU, we are actively seeking an= =20 > exception to our rules, which implies we must have a pretty good reason= =20 > to do so. >=20 > Thanks to numeric region codes based on UN M.49, we now have lots of wa= y=20 > to indicate pan-European usage: 039, 150, 151, 154, 155. This has=20 > nothing to do with serving the language-tagging needs of Europe. >=20 > Bureaucratic jargon is NOT a regional variation; as Frank said, a=20 > variant would be better suited to this. Even Michael Everson's famous=20 > crusade against use of "euro" as a plural was NOT an instance of "EU=20 > usage," but rather a misinterpretation of an EU directive by local Iris= h=20 > officials and journalists. >=20 --=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 Tue Nov 13 21:07:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is7ev-0004G0-Gf; Tue, 13 Nov 2007 21:07:17 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Is7et-0004Ax-8F for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 21:07:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is7es-00049k-UA for ltru@ietf.org; Tue, 13 Nov 2007 21:07:14 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is7ep-0001xA-5i for ltru@ietf.org; Tue, 13 Nov 2007 21:07:14 -0500 Received: by wa-out-1112.google.com with SMTP id k40so34764wah for ; Tue, 13 Nov 2007 18:07:10 -0800 (PST) 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=f8FN3YNn7MRZEvm9jxivt1kbZAnbQi2XbY4j1tNDcC0=; b=T0RqsZna78wSGjbffPcM17tDGOf6niRgZ+EoUK+RTkHt5yeGz5Ypmlx493LlfljXPxbfkrlbK7T/1kcqrdfavnOQyNdbQNjnj7E8BYfML5VmmCQvLihMiAbn1Z5JV+CI6klQTpoqMA+9rui9m3A6FgHhHLKriSlZEEQrxkAcG88= 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=ak95IOgVmeHhPXvphyUVI95LSBr6yIs0Im1RoGDetevsaAucsT1dszWQB2LOS1bnjnhOpDlWbklGcdbad3EtlztRaJFi79M6JwSkqrObaehlM5ES7HW2Oy0tiYf/C/Ywe03HT6B0xAmluBWGrEwhY14r60yuEar3CJ9DigJrKWQ= Received: by 10.114.56.1 with SMTP id e1mr651747waa.1195006030362; Tue, 13 Nov 2007 18:07:10 -0800 (PST) Received: by 10.114.192.9 with HTTP; Tue, 13 Nov 2007 18:07:10 -0800 (PST) Message-ID: <30b660a20711131807m59670a7cteb8eb85f87c9d060@mail.gmail.com> Date: Tue, 13 Nov 2007 18:07:10 -0800 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <4739E608.2080005@yahoo-inc.com> MIME-Version: 1.0 References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> X-Google-Sender-Auth: f3936cfb8250367f X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a 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="===============0450760346==" Errors-To: ltru-bounces@ietf.org --===============0450760346== Content-Type: multipart/alternative; boundary="----=_Part_11636_10808144.1195006030317" ------=_Part_11636_10808144.1195006030317 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline KzEKCkkgZmlybWx5IGFncmVlLiBCQ1AgNDcgaXMgbm90IG9ubHkgdGhlIHNvdXJjZSBvZiBsYW5n dWFnZSB0YWdzOyBpdCBpcwoqdGhlICpyZWZlcmVuY2UKZm9yIHN0YWJpbGl6ZWQsIG1haW50YWlu YWJsZSBjb2RlcyBmb3IgbGFuZ3VhZ2VzLCBzY3JpcHRzLCBhbmQgcmVnaW9ucy4KU29tZW9uZSBj aXRpbmcgInJlZ2lvbnMgYXMgZGVmaW5lZCBieSBCQ1AgNDciLCBldmVuIHdoZW4gbm90IHVzZWQg aW4KbGFuZ3VhZ2UgY29kZXMsIGhhcyBhIHN0YWJsZSwgd2VsbC1kZWZpbmVkLCBtYWludGFpbmFi bGUgY29kZSB0aGF0IGFsc28KZW5jb21wYXNzZXMgVU4gTS40OSByZWdpb25zLiBBbmQgdGhpcyBp cyBhIGdvb2QgdGhpbmcsIHNpbmNlIGl0IHByb21vdGVzIHRoZQp1c2UgKmFuZCBpbnRlcndvcmth YmlsaXR5ICp3aXRoIEJDUCA0NywgYW5kIHNvZnR3YXJlIGludGVybmF0aW9uYWxpemF0aW9uCm92 ZXJhbGwuCgpCeSBleGNsdWRpbmcgZWRnZSBjYXNlcyBsaWtlIEVVLCB3ZSBqdXN0IG1ha2UgaXQg aGFyZGVyIGZvciBwZW9wbGUgdG8gdXNlCkJDUCA0NyBhcyBpcywgYW5kIGZvcmNlIHRoZSBwcm9s aWZlcmF0aW9uIG9mIHByaXZhdGUgdXNlIGNvZGVzIChvciB3b3JzZQp5ZXQsIG5vbi1CQ1A0NyBj b2RlcykuCgpCeSBiZWluZyBwcmFnbWF0aWMsIGFuZCBoYW5kbGluZyBqdXN0IGEgZmV3IGtleSBj YXNlcyB0aGF0IGFyZSBpbXBvcnRhbnQgZm9yCmltcGxlbWVudGF0aW9ucywgd2UgbWFrZSBpdCBm YXIgZWFzaWVyIGZvciBwZW9wbGUgdG8gYWRvcHQgYW5kIHVzZSBCQ1AgNDcuCkFkZGluZyAiRVUi IHRvIDQ2NDZiaXMgd291bGQgYmUgb25lIG9mIHRob3NlIGtleSBjYXNlcy4gSXQgZG9lc24ndCBo dXJ0IHRvCmhhdmUgRVUgYXMgYSBjb2RlIGluIEJDUCA0Nywgbm8gbW9yZSB0aGFuIGl0IGh1cnRz IHRvIGhhdmUgQlYgYXMgYSBjb2RlLiBBbmQKdGhlIEVVIGlzIGEgZGFybidkIHNpZ2h0IG1vcmUg aW1wb3J0YW50IHRoYW4gYSBzbGV3IG9mIHRoZSByZWdpb24gY29kZXMgd2UKYWxyZWFkeSBoYXZl IC0tIHdoZXRoZXIgaW4gbGFuZ3VhZ2UgY29kZXMgb3IgaW4gaW50ZXJ3b3JraW5nIHdpdGggdGhl bSEKCkkgYWdyZWUgd2l0aCBBZGRpc29uJ3MgcHJvcG9zZWQgdGV4dC4KCk1hcmsKCk9uIE5vdiAx MywgMjAwNyA5OjU5IEFNLCBBZGRpc29uIFBoaWxsaXBzIDxhZGRpc29uQHlhaG9vLWluYy5jb20+ IHdyb3RlOgoKPiBXaGF0IGZvbGxvd3MgaXMgYSBiaXQgb2YgYSByYW50LCBhbGJlaXQgd2l0aCBh IHRleHR1YWwgcHJvcG9zZSBmb3Igb3VyCj4gZHJhZnQgKHJlbWVtYmVyIG91ciBkcmFmdD8pLiBQ YXJkb24gbXkgZHVzdC4gOi0pCj4KPiBPa2F5LCBoZXJlJ3MgbXkgY29uY2VybjogdGhlcmUgd2Fz LCBhdCBvbmUgdGltZSwgYSB2ZXJ5IGxvbmcgYW5kCj4gbm90LXZlcnktZnJpZW5kbHkgdGhyZWFk IG9uIGlldGYtbGFuZ3VhZ2VzIGluIHdoaWNoIGZvbGtzIG1vc3RseSBmcm9tCj4gdGhlIHNvZnR3 YXJlIGluZHVzdHJ5IGF0dGVtcHRlZCAoYW5kIGZhaWxlZCkgdG8gcmVnaXN0ZXIgImVzLWFtZXJp Y2FzIgo+IHRvIGlkZW50aWZ5IHNvbWUga2luZCBvZiBMYXRpbiBBbWVyaWNhbiBvciBtaWQtQXRs YW50aWMgU3BhbmlzaC4gVGhlCj4gYXJndW1lbnQgYWdhaW5zdCB0aGlzIChiYXNpY2FsbHkpIHdh cyB0aGF0IHRoZXJlIHdhcyBubyBzdWNoICJyZWFsIgo+IGxhbmd1YWdlLCBhcyBpbiAiYSBsYW5n dWFnZSByZWNvZ25pemVkIGJ5IGxpbmd1aXN0aWMgc2Nob2xhcnMiLiBUaGVyZQo+IHdlcmUsIGhv d2V2ZXIsIHNvbWUgd2hvIHRob3VnaHQgdGhleSBoYWQgYSBxdWl0ZSByZWFsIG5lZWQgdG8gaWRl bnRpZnkKPiBhbiBhcnRpZmljaWFsbHkgY3JlYXRlZCBsaW5ndWlzdGljIHZhcmlhbnQuCj4KPiBJ biBSRkMgNDY0NiB3ZSBleHBsaWNpdGx5IGFja25vd2xlZGdlZCB0aGUgcG90ZW50aWFsIGZvciB1 c2Ugb2YgdGhlIFVOCj4gTS40OSBjb2RlICI0MTkiIGZvciB0aGlzIHB1cnBvc2UuCj4KPiBJIGFn cmVlIHdpdGggRG91ZyB0aGF0IG9uZSBvZiB0aGUgVU4gTS40OSBjb2RlcyBjb3VsZCBiZSB1c2Vk IHRvCj4gaWRlbnRpZnkgYW4gYXJ0aWZpY2lhbCBsaW5ndWlzdGljIHZhcmlhbnQgZm9yIHRoZSBF VS4gSG93ZXZlciwgSSB3b3VsZAo+IGJlIHVuc3VycHJpc2VkIGlmLCBmb3IgZXhhbXBsZSwgdGhl IEVDIHdlcmUgdG8gYWRvcHQgc3BlY2lhbGx5Cj4gY29udHJvbGxlZCBsYW5ndWFnZSB2YXJpYXRp b25zIGZvciB0cmFuc2xhdGluZyBFVSAic3R1ZmYiIHdpdGhvdXQgaGF2aW5nCj4gdG8gY2hvb3Nl IHBhcnRpY3VsYXIgbG9jYWwgdmFyaWFudHMgKG9yIHRyYW5zbGF0ZSBpbnRvIGFsbCBvZiB0aGVt KS4KPiBUaHVzIEkgY2FuIGltYWdpbmUgYW4gImZyLUVVIiBvciAiZGUtRVUiIHdoaWNoIGlzIGJv dGggIm5vdCBhIHJlYWwKPiBsYW5ndWFnZSIgYW5kIGFsc28gbm90ICJmci1GUiIgb3IgImRlLURF Ii4gVGhpcyBjb3VsZCBhbHNvIGJlIGFkZHJlc3NlZAo+IGFzICJmci14LWV1cm8iIG9yICJkZS1l dW5pb24iIG9yIHNvbWUtc3VjaC4KPgo+IFdoYXQgYm90aGVycyBtZSBpcyB0aGUgc2Vuc2UgdGhh dCAid2UiICh0aGVyZSBpcyBubyAid2UiKSBrbm93IGJldHRlcgo+IHRoYW4gdGhlIHVzZXJzIG1h a2luZyB0aGUgcmVxdWVzdCBhYm91dCB0aGVpciBhcHBsaWNhdGlvbidzIG5lZWRzLiBJCj4gdGVu ZCB0byBiZSBhIGxpdHRsZSBtb3JlIHByb21pc2N1b3VzIGFib3V0IHN1cHBvcnRpbmcgdmFyaWFu dHMgYXMgYQo+IHJlc3VsdC4gVGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSB0aGluZyBiZWluZyBy ZXF1ZXN0ZWQgaXNuJ3Qgd2VsbAo+IHRob3VnaHQgb3V0LiBCdXQgSSBhbSBub3QgYWx0b2dldGhl ciBoYXBweSB3aXRoIHRoZSBub3Rpb24gdGhhdCB0aGVyZSBpcwo+IG9ubHkgb25lIHdheSB0byB1 c2UgbGFuZ3VhZ2UgdGFncyBvciB0aGF0ICJ0aGVyZSBpcyBubyBzdWNoIGxhbmd1YWdlIGFzCj4g WCBoZW5jZSBubyB1c2UgZm9yIHRoaXMgc3VidGFnIGluIGxhbmd1YWdlIHRhZ3MiLiBXZSBkb24n dCBhY3R1YWxseSBrbm93Cj4gdGhhdC4KPgo+IFNvOiBJIHRoaW5rIGl0IHdvdWxkIGJlIGp1c3Qg Z3JhbmQgaWYgJ0VVJyB3ZXJlIGFjdHVhbGx5IGFzc2lnbmVkIGJ5IElTTwo+IDMxNjYgYW5kIG5v dCBqdXN0IHJlc2VydmVkLiBGdXJ0aGVyLCBJIHdvdWxkIHN1cHBvcnQgb3VyIGFja25vd2xlZGdp bmcKPiB0aGUgImV4Y2VwdGlvbmFsIHJlc2VydmF0aW9uIiBhcyAiYW4gYXNzaWdubWVudCIgaW4g NDY0NmJpcy4gVG8gdGhhdAo+IGVuZCwgSSdkIHByb3Bvc2UgY2hhbmdpbmcgU2VjdGlvbiAyLjIu NCwgaXRlbSAyIGluIHRoZSBsaXN0IHRvIHJlYWQ6Cj4KPiAtLQo+IEFsbCB0d28tY2hhcmFjdGVy IHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZywgd2l0aCBvbmUKPiBleGNlcHRp b24sIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlCj4g YXNzaWdubWVudHMgZm91bmQgaW4gW0lTTzMxNjbigJExXSAoSW50ZXJuYXRpb25hbCBPcmdhbml6 YXRpb24gZm9yCj4gU3RhbmRhcmRpemF0aW9uLCAiSVNPIDMxNjYtMToxOTk3LiBDb2RlcyBmb3Ig dGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzCj4gb2YgY291bnRyaWVzIGFuZCB0aGVpciBzdWJk aXZpc2lvbnMgLS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzLCIgMTk5Ny4pCj4gKCJDb2RlcyBmb3Ig dGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcyBhbmQgdGhlaXIKPiBzdWJk aXZpc2lvbnMgLS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIikgdXNpbmcgdGhlIGxpc3Qgb2YgYWxw aGEtMgo+IGNvdW50cnkgY29kZXMsIG9yIHVzaW5nIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRseSBt YWRlIGJ5IHRoZSBJU08gMzE2Ngo+IG1haW50ZW5hbmNlIGFnZW5jeSBvciBnb3Zlcm5pbmcgc3Rh bmRhcmRpemF0aW9uIGJvZGllcy4gVGhlIG9uZQo+IGV4Y2VwdGlvbiBpcyB0aGUgY29kZSAnRVUn IChFdXJvcGVhbiBVbmlvbiksIHdoaWNoIGlzICJleGNlcHRpb25hbGx5Cj4gcmVzZXJ2ZWQiIGZv ciB0aGF0IHB1cnBvc2UgKGJ1dCBub3QgImFzc2lnbmVkIikgYnkgSVNPIDMxNjYuIFRoaXMgY29k ZQo+IGlzIGFzc2lnbmVkIGluIHRoZSByZWdpc3RyeSBhbmQgaXMgc3ViamVjdCB0byB0aGUgc2Ft ZSBjb25zdHJhaW50cyB0aGF0Cj4gYXBwZWFyIGVsc2V3aGVyZSBpbiB0aGlzIGRvY3VtZW50IGFz IGlmIGl0IHdlcmUgYWN0dWFsbHkgYXNzaWduZWQgYnkgSVNPCj4gMzE2Ni4KPiAtLQo+Cj4gUmVn YXJkcywKPgo+IEFkZGlzb24KPgo+IERvdWcgRXdlbGwgd3JvdGU6Cj4gPiBNYXJ0aW4gRHVlcnN0 IDxkdWVyc3QgYXQgaXQgZG90IGFveWFtYSBkb3QgYWMgZG90IGpwPiB3cm90ZToKPiA+Cj4gPj4g V2hhdCBJJ20gYSBiaXQgd29ycmllZCBhYm91dCwgYW5kIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUg Y29uZmlybWF0aW9uLAo+ID4+IGlzIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8uIEFzc3VtZSBmb3Ig b25lIHJlYXNvbiBvciBhbm90aGVyLCBzb21lIEVVCj4gPj4gdmFyaWFudCBvZiBhIGxhbmd1YWdl IGRldmVsb3BzLCBpcyBkZWZpbmVkLCBvciB3aGF0IG5vdC4KPiA+Cj4gPiBCYWNrIHRvIHRoaXMg aW4gYSBtb21lbnQuCj4gPgo+ID4+IE9idmlvdXNseSBhdCBsZWFzdCB0byBtZSwgdGhlIHJlZ2lv biBzdWJ0YWcgJ0VVJyB3b3VsZCBiZSBtb3N0IHN1aXRlZAo+ID4+IGluIHRoaXMgY2FzZS4gSXMg aXQgcG9zc2libGUgdGhhdCB0aGUgaWV0Zi1sYW5ndWFnZXMgbGlzdCBqdXN0IGFkZHMKPiA+PiB0 aGlzIHN1YnRhZyB0byB0aGUgcmVnaXN0cnksIG9yIHdvdWxkIHdlIGhhdmUgdG8gY29udmVuZSBh IFdHIGFuZAo+ID4+IHdyaXRlIGFub3RoZXIgdmVyc2lvbiBvZiB3aGF0J3MgY3VycmVudGx5IFJG QyA0NjQ2PyBJZiB0aGUgbGF0ZXIgaXMKPiA+PiB0aGUgY2FzZSwgbXkgcHJlZmVyZW5jZSB3b3Vs ZCBiZSB0byBjYXJlZnVsbHkgdHdlYWsgb3VyIHRleHRzIHNvIHRoYXQKPiA+PiB3ZSBjYW4gYXZv aWQgcmVjaGFydGVyaW5nIGp1c3QgZm9yIHRoZSBwb3RlbnRpYWwgc2NlbmFyaW8gZGVzY3JpYmVk Cj4gPj4gYWJvdmUuCj4gPgo+ID4gQm90aCBSRkMgNDY0NiBhbmQgZHJhZnQtNDY0NmJpcyBpcyB0 aGF0IHRoZXkgcmVmZXIgdG8gY29kZSBlbGVtZW50cwo+ID4gImFzc2lnbmVkIiBpbiBJU08gMzE2 Ni0xLiAgUkZDIDQ2NDUgdXNlcyB0aGUgdGVybXMgInZhbGlkIiBhbmQKPiA+ICJhc3NpZ25lZCIg aW4gcG9wdWxhdGluZyB0aGUgaW5pdGlhbCBMU1IuICBFeGNlcHRpb25hbGx5IHJlc2VydmVkIGNv ZGUKPiA+IGVsZW1lbnRzIGFyZSBub3QgImFzc2lnbmVkIiBhY2NvcmRpbmcgdG8gdGhlIElTTyAz MTY2L01BIGRlZmluaXRpb24sIGFuZAo+Cj4gPiB0aHVzIHRoZXkgZG9uJ3QgcXVhbGlmeSB0byBo YXZlIHJlZ2lvbiBzdWJ0YWdzIGRlcml2ZWQgZnJvbSB0aGVtCj4gPiBhY2NvcmRpbmcgdG8gb3Vy IGRlZmluaXRpb24uICBXZSB3b3VsZCBuZWVkIHRvIGNoYW5nZSB0aGUgcmVxdWlyZW1lbnRzCj4g PiBpbiA0NjQ2YmlzLCBhbmQgcG9zc2libHkgaW4gNDY0NWJpcywgb3IgZWxzZSByZWNoYXJ0ZXIg dGhlIGdyb3VwIHRvIGRvCj4gPiB0aGlzIGluIHRoZSBmdXR1cmUuCj4gPgo+ID4gQXMgQWRkaXNv biBzYWlkLCBpZiB3ZSByZWFsbHkgbmVlZCBhIHJlZ2lvbiBzdWJ0YWcgRVUsIHNvbWVvbmUgbmVl ZHMgdG8KPiA+IHBldGl0aW9uIElTTyAzMTY2L01BIHRvIGFzc2lnbiB0aGUgY29kZSBlbGVtZW50 Lgo+ID4KPiA+IFRoaXMgZGlzY3Vzc2lvbiwgaG93ZXZlciwgY29udGludWVzIHRvIHByZXN1bWUg YSAocG90ZW50aWFsKSBuZWVkIGZvciBhCj4gPiByZWdpb24gc3VidGFnIHRvIGRlc2NyaWJlIGxh bmd1YWdlIHVzYWdlIGluIGV4YWN0bHkgdGhlc2UgY291bnRyaWVzIChhcwo+ID4gb2YgMjAwNy0x MS0wMyk6Cj4gPgo+ID4gQVQsIEJFLCBCRywgQ1ksIENaLCBERSwgREssIEVFLCBFUywgRkksIEZS LCBHQiwgR1IsIEhVLCBJRSwgSVQsIExULCBMVSwKPiA+IExWLCBNVCwgTkwsIFBMLCBQVCwgUk8s IFNFLCBTSSwgU0sKPiA+Cj4gPiBhbmQgYWxsIG9mIHRoZWlyIGRlcGVuZGVuY2llcywgYnV0IE5P VCBuZWlnaGJvcmluZyBjb3VudHJpZXMgc3VjaCBhcwo+ID4gSWNlbGFuZCwgTm9yd2F5LCBTd2l0 emVybGFuZCwgb3IgdGhlIEJhbHRpY3MuICBBbmQgdGhlIGxpc3Qgb2YgRVUKPiA+IGNvdW50cmll cyBjaGFuZ2VzIHdpdGggc29tZSByZWd1bGFyaXR5IC0tIHRoZXJlIGFyZSBjdXJyZW50bHkgdGhy ZWUKPiA+ICJvZmZpY2lhbCBjYW5kaWRhdGUgc3RhdGVzIiBhbmQgZm91ciAicG90ZW50aWFsIGNh bmRpZGF0ZXMiIC0tIG1ha2luZwo+ID4gY29kZSBpbnN0YWJpbGl0eSBub3QgbWVyZWx5IGEgcG9z c2liaWxpdHksIGFzIGl0IGlzIHdpdGggYWxsIGNvdW50cnkKPiA+IGNvZGluZyBzeXN0ZW1zLCBi dXQgYSBjZXJ0YWludHkuCj4gPgo+ID4gVGhpcyBpcyBub3QgYXQgYWxsIChJTUhPKSBsaWtlIHRo ZSByZWNlbnQgYWRkaXRpb24gb2YgQkwgYW5kIE1GIHRvIDMxNjYKPiA+IGFuZCB0aGUgTFNSLCB0 d28gY291bnRyaWVzIChpZiB0aGF0IHRoZXkgYXJlKSB3aGljaCBkb24ndCBhcHBlYXIgdG8KPiA+ IGV4aGliaXQgZGlzdGluY3QgbGFuZ3VhZ2UgdXNhZ2UuICBJbiB0aGF0IGNhc2UsIHdlIGFyZSBt aXJyb3JpbmcgdGhlCj4gPiBkZWNpc2lvbnMgbWFkZSBieSBJU08gMzE2Ni9NQSwgYXMgd2UgY2xh aW0gdG8gZG8sIHdpdGhvdXQgY29uc2lkZXJhdGlvbgo+ID4gb2YgdGhlIGxpbmd1aXN0aWMgYW5n bGUuICBJbiB0aGUgY2FzZSBvZiBFVSwgd2UgYXJlIGFjdGl2ZWx5IHNlZWtpbmcgYW4KPiA+IGV4 Y2VwdGlvbiB0byBvdXIgcnVsZXMsIHdoaWNoIGltcGxpZXMgd2UgbXVzdCBoYXZlIGEgcHJldHR5 IGdvb2QgcmVhc29uCj4gPiB0byBkbyBzby4KPiA+Cj4gPiBUaGFua3MgdG8gbnVtZXJpYyByZWdp b24gY29kZXMgYmFzZWQgb24gVU4gTS40OSwgd2Ugbm93IGhhdmUgbG90cyBvZiB3YXkKPiA+IHRv IGluZGljYXRlIHBhbi1FdXJvcGVhbiB1c2FnZTogMDM5LCAxNTAsIDE1MSwgMTU0LCAxNTUuICBU aGlzIGhhcwo+ID4gbm90aGluZyB0byBkbyB3aXRoIHNlcnZpbmcgdGhlIGxhbmd1YWdlLXRhZ2dp bmcgbmVlZHMgb2YgRXVyb3BlLgo+ID4KPiA+IEJ1cmVhdWNyYXRpYyBqYXJnb24gaXMgTk9UIGEg cmVnaW9uYWwgdmFyaWF0aW9uOyBhcyBGcmFuayBzYWlkLCBhCj4gPiB2YXJpYW50IHdvdWxkIGJl IGJldHRlciBzdWl0ZWQgdG8gdGhpcy4gIEV2ZW4gTWljaGFlbCBFdmVyc29uJ3MgZmFtb3VzCj4g PiBjcnVzYWRlIGFnYWluc3QgdXNlIG9mICJldXJvIiBhcyBhIHBsdXJhbCB3YXMgTk9UIGFuIGlu c3RhbmNlIG9mICJFVQo+ID4gdXNhZ2UsIiBidXQgcmF0aGVyIGEgbWlzaW50ZXJwcmV0YXRpb24g b2YgYW4gRVUgZGlyZWN0aXZlIGJ5IGxvY2FsIElyaXNoCj4gPiBvZmZpY2lhbHMgYW5kIGpvdXJu YWxpc3RzLgo+ID4KPgo+Cj4gLS0KPiBBZGRpc29uIFBoaWxsaXBzCj4gR2xvYmFsaXphdGlvbiBB cmNoaXRlY3QgLS0gWWFob28hIEluYy4KPiBDaGFpciAtLSBXM0MgSW50ZXJuYXRpb25hbGl6YXRp b24gQ29yZSBXRwo+Cj4gSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgYW4gYXJjaGl0ZWN0dXJlLgo+ IEl0IGlzIG5vdCBhIGZlYXR1cmUuCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+CgoKCi0tIApNYXJr Cg== ------=_Part_11636_10808144.1195006030317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline KzE8YnI+PGJyPkkgZmlybWx5IGFncmVlLiBCQ1AgNDcgaXMgbm90IG9ubHkgdGhlIHNvdXJjZSBv ZiBsYW5ndWFnZSB0YWdzOyBpdCBpcyA8Yj50aGUgPC9iPnJlZmVyZW5jZSBmb3Igc3RhYmlsaXpl ZCwgbWFpbnRhaW5hYmxlIGNvZGVzIGZvciBsYW5ndWFnZXMsIHNjcmlwdHMsIGFuZCByZWdpb25z LiBTb21lb25lIGNpdGluZyAmcXVvdDtyZWdpb25zIGFzIGRlZmluZWQgYnkgQkNQIDQ3JnF1b3Q7 LCBldmVuIHdoZW4gbm90IHVzZWQgaW4gbGFuZ3VhZ2UgY29kZXMsIGhhcyBhIHN0YWJsZSwgd2Vs bC1kZWZpbmVkLCBtYWludGFpbmFibGUgY29kZSB0aGF0IGFsc28gZW5jb21wYXNzZXMgVU4gCk0u NDkgcmVnaW9ucy4gQW5kIHRoaXMgaXMgYSBnb29kIHRoaW5nLCBzaW5jZSBpdCBwcm9tb3RlcyB0 aGUgdXNlIDxiPjxpPmFuZCBpbnRlcndvcmthYmlsaXR5IDwvaT48L2I+d2l0aCBCQ1AgNDcsIGFu ZCBzb2Z0d2FyZSBpbnRlcm5hdGlvbmFsaXphdGlvbiBvdmVyYWxsLjxicj48YnI+QnkgZXhjbHVk aW5nIGVkZ2UgY2FzZXMgbGlrZSBFVSwgd2UganVzdCBtYWtlIGl0IGhhcmRlciBmb3IgcGVvcGxl IHRvIHVzZSBCQ1AgNDcgYXMgaXMsIGFuZCBmb3JjZSB0aGUgcHJvbGlmZXJhdGlvbiBvZiBwcml2 YXRlIHVzZSBjb2RlcyAob3Igd29yc2UgeWV0LCBub24tQkNQNDcgY29kZXMpLgo8YnI+PGJyPkJ5 IGJlaW5nIHByYWdtYXRpYywgYW5kIGhhbmRsaW5nIGp1c3QgYSBmZXcga2V5IGNhc2VzIHRoYXQg YXJlIGltcG9ydGFudCBmb3IgaW1wbGVtZW50YXRpb25zLCB3ZSBtYWtlIGl0IGZhciBlYXNpZXIg Zm9yIHBlb3BsZSB0byBhZG9wdCBhbmQgdXNlIEJDUCA0Ny4gQWRkaW5nICZxdW90O0VVJnF1b3Q7 IHRvIDQ2NDZiaXMgd291bGQgYmUgb25lIG9mIHRob3NlIGtleSBjYXNlcy4gSXQgZG9lc24mIzM5 O3QgaHVydCB0byBoYXZlIEVVIGFzIGEgY29kZSBpbiBCQ1AgNDcsIG5vIG1vcmUgdGhhbiBpdCBo dXJ0cyB0byBoYXZlIEJWIGFzIGEgY29kZS4gQW5kIHRoZSBFVSBpcyBhIGRhcm4mIzM5O2Qgc2ln aHQgbW9yZSBpbXBvcnRhbnQgdGhhbiBhIHNsZXcgb2YgdGhlIHJlZ2lvbiBjb2RlcyB3ZSBhbHJl YWR5IGhhdmUgLS0gd2hldGhlciBpbiBsYW5ndWFnZSBjb2RlcyBvciBpbiBpbnRlcndvcmtpbmcg d2l0aCB0aGVtIQo8YnI+PGJyPkkgYWdyZWUgd2l0aCBBZGRpc29uJiMzOTtzIHByb3Bvc2VkIHRl eHQuPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTm92IDEz LCAyMDA3IDk6NTkgQU0sIEFkZGlzb24gUGhpbGxpcHMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGRp c29uQHlhaG9vLWluYy5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGRpc29uQHlhaG9vLWluYy5jb208 L2E+Jmd0OyB3cm90ZToKPGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAw cHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpXaGF0IGZvbGxvd3MgaXMgYSBiaXQg b2YgYSByYW50LCBhbGJlaXQgd2l0aCBhIHRleHR1YWwgcHJvcG9zZSBmb3Igb3VyPGJyPmRyYWZ0 IChyZW1lbWJlciBvdXIgZHJhZnQ/KS4gUGFyZG9uIG15IGR1c3QuIDotKTxicj48YnI+T2theSwg aGVyZSYjMzk7cyBteSBjb25jZXJuOiB0aGVyZSB3YXMsIGF0IG9uZSB0aW1lLCBhIHZlcnkgbG9u ZyBhbmQ8YnI+bm90LXZlcnktZnJpZW5kbHkgdGhyZWFkIG9uIGlldGYtbGFuZ3VhZ2VzIGluIHdo aWNoIGZvbGtzIG1vc3RseSBmcm9tCjxicj50aGUgc29mdHdhcmUgaW5kdXN0cnkgYXR0ZW1wdGVk IChhbmQgZmFpbGVkKSB0byByZWdpc3RlciAmcXVvdDtlcy1hbWVyaWNhcyZxdW90Ozxicj50byBp ZGVudGlmeSBzb21lIGtpbmQgb2YgTGF0aW4gQW1lcmljYW4gb3IgbWlkLUF0bGFudGljIFNwYW5p c2guIFRoZTxicj5hcmd1bWVudCBhZ2FpbnN0IHRoaXMgKGJhc2ljYWxseSkgd2FzIHRoYXQgdGhl cmUgd2FzIG5vIHN1Y2ggJnF1b3Q7cmVhbCZxdW90Owo8YnI+bGFuZ3VhZ2UsIGFzIGluICZxdW90 O2EgbGFuZ3VhZ2UgcmVjb2duaXplZCBieSBsaW5ndWlzdGljIHNjaG9sYXJzJnF1b3Q7LiBUaGVy ZTxicj53ZXJlLCBob3dldmVyLCBzb21lIHdobyB0aG91Z2h0IHRoZXkgaGFkIGEgcXVpdGUgcmVh bCBuZWVkIHRvIGlkZW50aWZ5PGJyPmFuIGFydGlmaWNpYWxseSBjcmVhdGVkIGxpbmd1aXN0aWMg dmFyaWFudC48YnI+PGJyPkluIFJGQyA0NjQ2IHdlIGV4cGxpY2l0bHkgYWNrbm93bGVkZ2VkIHRo ZSBwb3RlbnRpYWwgZm9yIHVzZSBvZiB0aGUgVU4KPGJyPk0uNDkgY29kZSAmcXVvdDs0MTkmcXVv dDsgZm9yIHRoaXMgcHVycG9zZS48YnI+PGJyPkkgYWdyZWUgd2l0aCBEb3VnIHRoYXQgb25lIG9m IHRoZSBVTiBNLjQ5IGNvZGVzIGNvdWxkIGJlIHVzZWQgdG88YnI+aWRlbnRpZnkgYW4gYXJ0aWZp Y2lhbCBsaW5ndWlzdGljIHZhcmlhbnQgZm9yIHRoZSBFVS4gSG93ZXZlciwgSSB3b3VsZDxicj5i ZSB1bnN1cnByaXNlZCBpZiwgZm9yIGV4YW1wbGUsIHRoZSBFQyB3ZXJlIHRvIGFkb3B0IHNwZWNp YWxseQo8YnI+Y29udHJvbGxlZCBsYW5ndWFnZSB2YXJpYXRpb25zIGZvciB0cmFuc2xhdGluZyBF VSAmcXVvdDtzdHVmZiZxdW90OyB3aXRob3V0IGhhdmluZzxicj50byBjaG9vc2UgcGFydGljdWxh ciBsb2NhbCB2YXJpYW50cyAob3IgdHJhbnNsYXRlIGludG8gYWxsIG9mIHRoZW0pLjxicj5UaHVz IEkgY2FuIGltYWdpbmUgYW4gJnF1b3Q7ZnItRVUmcXVvdDsgb3IgJnF1b3Q7ZGUtRVUmcXVvdDsg d2hpY2ggaXMgYm90aCAmcXVvdDtub3QgYSByZWFsCjxicj5sYW5ndWFnZSZxdW90OyBhbmQgYWxz byBub3QgJnF1b3Q7ZnItRlImcXVvdDsgb3IgJnF1b3Q7ZGUtREUmcXVvdDsuIFRoaXMgY291bGQg YWxzbyBiZSBhZGRyZXNzZWQ8YnI+YXMgJnF1b3Q7ZnIteC1ldXJvJnF1b3Q7IG9yICZxdW90O2Rl LWV1bmlvbiZxdW90OyBvciBzb21lLXN1Y2guPGJyPjxicj5XaGF0IGJvdGhlcnMgbWUgaXMgdGhl IHNlbnNlIHRoYXQgJnF1b3Q7d2UmcXVvdDsgKHRoZXJlIGlzIG5vICZxdW90O3dlJnF1b3Q7KSBr bm93IGJldHRlcgo8YnI+dGhhbiB0aGUgdXNlcnMgbWFraW5nIHRoZSByZXF1ZXN0IGFib3V0IHRo ZWlyIGFwcGxpY2F0aW9uJiMzOTtzIG5lZWRzLiBJPGJyPnRlbmQgdG8gYmUgYSBsaXR0bGUgbW9y ZSBwcm9taXNjdW91cyBhYm91dCBzdXBwb3J0aW5nIHZhcmlhbnRzIGFzIGE8YnI+cmVzdWx0LiBU aGVyZSBhcmUgY2FzZXMgd2hlcmUgdGhlIHRoaW5nIGJlaW5nIHJlcXVlc3RlZCBpc24mIzM5O3Qg d2VsbAo8YnI+dGhvdWdodCBvdXQuIEJ1dCBJIGFtIG5vdCBhbHRvZ2V0aGVyIGhhcHB5IHdpdGgg dGhlIG5vdGlvbiB0aGF0IHRoZXJlIGlzPGJyPm9ubHkgb25lIHdheSB0byB1c2UgbGFuZ3VhZ2Ug dGFncyBvciB0aGF0ICZxdW90O3RoZXJlIGlzIG5vIHN1Y2ggbGFuZ3VhZ2UgYXM8YnI+WCBoZW5j ZSBubyB1c2UgZm9yIHRoaXMgc3VidGFnIGluIGxhbmd1YWdlIHRhZ3MmcXVvdDsuIFdlIGRvbiYj Mzk7dCBhY3R1YWxseSBrbm93Cjxicj50aGF0Ljxicj48YnI+U286IEkgdGhpbmsgaXQgd291bGQg YmUganVzdCBncmFuZCBpZiAmIzM5O0VVJiMzOTsgd2VyZSBhY3R1YWxseSBhc3NpZ25lZCBieSBJ U088YnI+MzE2NiBhbmQgbm90IGp1c3QgcmVzZXJ2ZWQuIEZ1cnRoZXIsIEkgd291bGQgc3VwcG9y dCBvdXIgYWNrbm93bGVkZ2luZzxicj50aGUgJnF1b3Q7ZXhjZXB0aW9uYWwgcmVzZXJ2YXRpb24m cXVvdDsgYXMgJnF1b3Q7YW4gYXNzaWdubWVudCZxdW90OyBpbiA0NjQ2YmlzLiBUbyB0aGF0Cjxi cj5lbmQsIEkmIzM5O2QgcHJvcG9zZSBjaGFuZ2luZyBTZWN0aW9uIDIuMi40LCBpdGVtIDIgaW4g dGhlIGxpc3QgdG8gcmVhZDo8YnI+PGJyPi0tPGJyPkFsbCB0d28tY2hhcmFjdGVyIHN1YnRhZ3Mg Zm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZywgd2l0aCBvbmU8YnI+ZXhjZXB0aW9uLCB3ZXJl IGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZTxicj4KCmFzc2ln bm1lbnRzIGZvdW5kIGluIFtJU08zMTY24oCRMV0gKEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9u IGZvcjxicj5TdGFuZGFyZGl6YXRpb24sICZxdW90O0lTTyAzMTY2LTE6MTk5Ny4gQ29kZXMgZm9y IHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lczxicj5vZiBjb3VudHJpZXMgYW5kIHRoZWlyIHN1 YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50cnkgY29kZXMsJnF1b3Q7IDE5OTcuKQo8YnI+KCZx dW90O0NvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgY291bnRyaWVzIGFu ZCB0aGVpcgo8YnI+c3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeSBjb2RlcyZxdW90Oykg dXNpbmcgdGhlIGxpc3Qgb2YgYWxwaGEtMjxicj5jb3VudHJ5IGNvZGVzLCBvciB1c2luZyBhc3Np Z25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDMxNjY8YnI+bWFpbnRlbmFuY2Ug YWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLiBUaGUgb25lPGJyPmV4 Y2VwdGlvbiBpcyB0aGUgY29kZSAmIzM5O0VVJiMzOTsgKEV1cm9wZWFuIFVuaW9uKSwgd2hpY2gg aXMgJnF1b3Q7ZXhjZXB0aW9uYWxseQo8YnI+cmVzZXJ2ZWQmcXVvdDsgZm9yIHRoYXQgcHVycG9z ZSAoYnV0IG5vdCAmcXVvdDthc3NpZ25lZCZxdW90OykgYnkgSVNPIDMxNjYuIFRoaXMgY29kZTxi cj5pcyBhc3NpZ25lZCBpbiB0aGUgcmVnaXN0cnkgYW5kIGlzIHN1YmplY3QgdG8gdGhlIHNhbWUg Y29uc3RyYWludHMgdGhhdDxicj5hcHBlYXIgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQgYXMg aWYgaXQgd2VyZSBhY3R1YWxseSBhc3NpZ25lZCBieSBJU08KPGJyPjMxNjYuPGJyPi0tPGJyPjxi cj5SZWdhcmRzLDxicj48YnI+QWRkaXNvbjxicj48ZGl2PjxkaXY+PC9kaXY+PGRpdj48YnI+RG91 ZyBFd2VsbCB3cm90ZTo8YnI+Jmd0OyBNYXJ0aW4gRHVlcnN0ICZsdDtkdWVyc3QgYXQgaXQgZG90 IGFveWFtYSBkb3QgYWMgZG90IGpwJmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jmd0OyBXaGF0 IEkmIzM5O20gYSBiaXQgd29ycmllZCBhYm91dCwgYW5kIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUg Y29uZmlybWF0aW9uLAo8YnI+Jmd0OyZndDsgaXMgdGhlIGZvbGxvd2luZyBzY2VuYXJpby4gQXNz dW1lIGZvciBvbmUgcmVhc29uIG9yIGFub3RoZXIsIHNvbWUgRVU8YnI+Jmd0OyZndDsgdmFyaWFu dCBvZiBhIGxhbmd1YWdlIGRldmVsb3BzLCBpcyBkZWZpbmVkLCBvciB3aGF0IG5vdC48YnI+Jmd0 Ozxicj4mZ3Q7IEJhY2sgdG8gdGhpcyBpbiBhIG1vbWVudC48YnI+Jmd0Ozxicj4mZ3Q7Jmd0OyBP YnZpb3VzbHkgYXQgbGVhc3QgdG8gbWUsIHRoZSByZWdpb24gc3VidGFnICYjMzk7RVUmIzM5OyB3 b3VsZCBiZSBtb3N0IHN1aXRlZAo8YnI+Jmd0OyZndDsgaW4gdGhpcyBjYXNlLiBJcyBpdCBwb3Nz aWJsZSB0aGF0IHRoZSBpZXRmLWxhbmd1YWdlcyBsaXN0IGp1c3QgYWRkczxicj4mZ3Q7Jmd0OyB0 aGlzIHN1YnRhZyB0byB0aGUgcmVnaXN0cnksIG9yIHdvdWxkIHdlIGhhdmUgdG8gY29udmVuZSBh IFdHIGFuZDxicj4mZ3Q7Jmd0OyB3cml0ZSBhbm90aGVyIHZlcnNpb24gb2Ygd2hhdCYjMzk7cyBj dXJyZW50bHkgUkZDIDQ2NDY/IElmIHRoZSBsYXRlciBpcwo8YnI+Jmd0OyZndDsgdGhlIGNhc2Us IG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gY2FyZWZ1bGx5IHR3ZWFrIG91ciB0ZXh0cyBzbyB0 aGF0PGJyPiZndDsmZ3Q7IHdlIGNhbiBhdm9pZCByZWNoYXJ0ZXJpbmcganVzdCBmb3IgdGhlIHBv dGVudGlhbCBzY2VuYXJpbyBkZXNjcmliZWQ8YnI+Jmd0OyZndDsgYWJvdmUuPGJyPiZndDs8YnI+ Jmd0OyBCb3RoIFJGQyA0NjQ2IGFuZCBkcmFmdC00NjQ2YmlzIGlzIHRoYXQgdGhleSByZWZlciB0 byBjb2RlIGVsZW1lbnRzCjxicj4mZ3Q7ICZxdW90O2Fzc2lnbmVkJnF1b3Q7IGluIElTTyAzMTY2 LTEuICZuYnNwO1JGQyA0NjQ1IHVzZXMgdGhlIHRlcm1zICZxdW90O3ZhbGlkJnF1b3Q7IGFuZDxi cj4mZ3Q7ICZxdW90O2Fzc2lnbmVkJnF1b3Q7IGluIHBvcHVsYXRpbmcgdGhlIGluaXRpYWwgTFNS LiAmbmJzcDtFeGNlcHRpb25hbGx5IHJlc2VydmVkIGNvZGU8YnI+Jmd0OyBlbGVtZW50cyBhcmUg bm90ICZxdW90O2Fzc2lnbmVkJnF1b3Q7IGFjY29yZGluZyB0byB0aGUgSVNPIDMxNjYvTUEgZGVm aW5pdGlvbiwgYW5kCjxicj4mZ3Q7IHRodXMgdGhleSBkb24mIzM5O3QgcXVhbGlmeSB0byBoYXZl IHJlZ2lvbiBzdWJ0YWdzIGRlcml2ZWQgZnJvbSB0aGVtPGJyPiZndDsgYWNjb3JkaW5nIHRvIG91 ciBkZWZpbml0aW9uLiAmbmJzcDtXZSB3b3VsZCBuZWVkIHRvIGNoYW5nZSB0aGUgcmVxdWlyZW1l bnRzPGJyPiZndDsgaW4gNDY0NmJpcywgYW5kIHBvc3NpYmx5IGluIDQ2NDViaXMsIG9yIGVsc2Ug cmVjaGFydGVyIHRoZSBncm91cCB0byBkbwo8YnI+Jmd0OyB0aGlzIGluIHRoZSBmdXR1cmUuPGJy PiZndDs8YnI+Jmd0OyBBcyBBZGRpc29uIHNhaWQsIGlmIHdlIHJlYWxseSBuZWVkIGEgcmVnaW9u IHN1YnRhZyBFVSwgc29tZW9uZSBuZWVkcyB0bzxicj4mZ3Q7IHBldGl0aW9uIElTTyAzMTY2L01B IHRvIGFzc2lnbiB0aGUgY29kZSBlbGVtZW50Ljxicj4mZ3Q7PGJyPiZndDsgVGhpcyBkaXNjdXNz aW9uLCBob3dldmVyLCBjb250aW51ZXMgdG8gcHJlc3VtZSBhIChwb3RlbnRpYWwpIG5lZWQgZm9y IGEKPGJyPiZndDsgcmVnaW9uIHN1YnRhZyB0byBkZXNjcmliZSBsYW5ndWFnZSB1c2FnZSBpbiBl eGFjdGx5IHRoZXNlIGNvdW50cmllcyAoYXM8YnI+Jmd0OyBvZiAyMDA3LTExLTAzKTo8YnI+Jmd0 Ozxicj4mZ3Q7IEFULCBCRSwgQkcsIENZLCBDWiwgREUsIERLLCBFRSwgRVMsIEZJLCBGUiwgR0Is IEdSLCBIVSwgSUUsIElULCBMVCwgTFUsPGJyPiZndDsgTFYsIE1ULCBOTCwgUEwsIFBULCBSTywg U0UsIFNJLCBTSwo8YnI+Jmd0Ozxicj4mZ3Q7IGFuZCBhbGwgb2YgdGhlaXIgZGVwZW5kZW5jaWVz LCBidXQgTk9UIG5laWdoYm9yaW5nIGNvdW50cmllcyBzdWNoIGFzPGJyPiZndDsgSWNlbGFuZCwg Tm9yd2F5LCBTd2l0emVybGFuZCwgb3IgdGhlIEJhbHRpY3MuICZuYnNwO0FuZCB0aGUgbGlzdCBv ZiBFVTxicj4mZ3Q7IGNvdW50cmllcyBjaGFuZ2VzIHdpdGggc29tZSByZWd1bGFyaXR5IC0tIHRo ZXJlIGFyZSBjdXJyZW50bHkgdGhyZWUKPGJyPiZndDsgJnF1b3Q7b2ZmaWNpYWwgY2FuZGlkYXRl IHN0YXRlcyZxdW90OyBhbmQgZm91ciAmcXVvdDtwb3RlbnRpYWwgY2FuZGlkYXRlcyZxdW90OyAt LSBtYWtpbmc8YnI+Jmd0OyBjb2RlIGluc3RhYmlsaXR5IG5vdCBtZXJlbHkgYSBwb3NzaWJpbGl0 eSwgYXMgaXQgaXMgd2l0aCBhbGwgY291bnRyeTxicj4mZ3Q7IGNvZGluZyBzeXN0ZW1zLCBidXQg YSBjZXJ0YWludHkuPGJyPgomZ3Q7Cjxicj4mZ3Q7IFRoaXMgaXMgbm90IGF0IGFsbCAoSU1ITykg bGlrZSB0aGUgcmVjZW50IGFkZGl0aW9uIG9mIEJMIGFuZCBNRiB0byAzMTY2PGJyPiZndDsgYW5k IHRoZSBMU1IsIHR3byBjb3VudHJpZXMgKGlmIHRoYXQgdGhleSBhcmUpIHdoaWNoIGRvbiYjMzk7 dCBhcHBlYXIgdG88YnI+Jmd0OyBleGhpYml0IGRpc3RpbmN0IGxhbmd1YWdlIHVzYWdlLiAmbmJz cDtJbiB0aGF0IGNhc2UsIHdlIGFyZSBtaXJyb3JpbmcgdGhlCjxicj4mZ3Q7IGRlY2lzaW9ucyBt YWRlIGJ5IElTTyAzMTY2L01BLCBhcyB3ZSBjbGFpbSB0byBkbywgd2l0aG91dCBjb25zaWRlcmF0 aW9uPGJyPiZndDsgb2YgdGhlIGxpbmd1aXN0aWMgYW5nbGUuICZuYnNwO0luIHRoZSBjYXNlIG9m IEVVLCB3ZSBhcmUgYWN0aXZlbHkgc2Vla2luZyBhbjxicj4mZ3Q7IGV4Y2VwdGlvbiB0byBvdXIg cnVsZXMsIHdoaWNoIGltcGxpZXMgd2UgbXVzdCBoYXZlIGEgcHJldHR5IGdvb2QgcmVhc29uCjxi cj4mZ3Q7IHRvIGRvIHNvLjxicj4mZ3Q7PGJyPiZndDsgVGhhbmtzIHRvIG51bWVyaWMgcmVnaW9u IGNvZGVzIGJhc2VkIG9uIFVOIE0uNDksIHdlIG5vdyBoYXZlIGxvdHMgb2Ygd2F5PGJyPiZndDsg dG8gaW5kaWNhdGUgcGFuLUV1cm9wZWFuIHVzYWdlOiAwMzksIDE1MCwgMTUxLCAxNTQsIDE1NS4g Jm5ic3A7VGhpcyBoYXM8YnI+Jmd0OyBub3RoaW5nIHRvIGRvIHdpdGggc2VydmluZyB0aGUgbGFu Z3VhZ2UtdGFnZ2luZyBuZWVkcyBvZiBFdXJvcGUuCjxicj4mZ3Q7PGJyPiZndDsgQnVyZWF1Y3Jh dGljIGphcmdvbiBpcyBOT1QgYSByZWdpb25hbCB2YXJpYXRpb247IGFzIEZyYW5rIHNhaWQsIGE8 YnI+Jmd0OyB2YXJpYW50IHdvdWxkIGJlIGJldHRlciBzdWl0ZWQgdG8gdGhpcy4gJm5ic3A7RXZl biBNaWNoYWVsIEV2ZXJzb24mIzM5O3MgZmFtb3VzPGJyPiZndDsgY3J1c2FkZSBhZ2FpbnN0IHVz ZSBvZiAmcXVvdDtldXJvJnF1b3Q7IGFzIGEgcGx1cmFsIHdhcyBOT1QgYW4gaW5zdGFuY2Ugb2Yg JnF1b3Q7RVUKPGJyPiZndDsgdXNhZ2UsJnF1b3Q7IGJ1dCByYXRoZXIgYSBtaXNpbnRlcnByZXRh dGlvbiBvZiBhbiBFVSBkaXJlY3RpdmUgYnkgbG9jYWwgSXJpc2g8YnI+Jmd0OyBvZmZpY2lhbHMg YW5kIGpvdXJuYWxpc3RzLjxicj4mZ3Q7PGJyPjxicj48YnI+LS08YnI+PC9kaXY+PC9kaXY+QWRk aXNvbiBQaGlsbGlwczxicj5HbG9iYWxpemF0aW9uIEFyY2hpdGVjdCAtLSBZYWhvbyEgSW5jLjxi cj4KCkNoYWlyIC0tIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdHPGJyPjxicj5JbnRl cm5hdGlvbmFsaXphdGlvbiBpcyBhbiBhcmNoaXRlY3R1cmUuPGJyPkl0IGlzIG5vdCBhIGZlYXR1 cmUuPGJyPjxkaXY+PGRpdj48L2Rpdj48ZGl2Pjxicj48YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+THRydSBtYWlsaW5nIGxpc3QKPGJyPjxhIGhy ZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+THRydUBpZXRmLm9yZzwv YT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRy dSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2x0cnU8L2E+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj4KPGJyPjxiciBjbGVh cj0iYWxsIj4KPGJyPi0tIDxicj5NYXJrCg== ------=_Part_11636_10808144.1195006030317-- --===============0450760346== 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 --===============0450760346==-- From ltru-bounces@ietf.org Tue Nov 13 23:15: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 1Is9fA-0005Q3-WE; Tue, 13 Nov 2007 23:15:41 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Is9fA-0005PI-Ig for ltru-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 23:15:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9fA-0005PA-8Z for ltru@ietf.org; Tue, 13 Nov 2007 23:15:40 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is9f9-0001NL-Re for ltru@ietf.org; Tue, 13 Nov 2007 23:15:40 -0500 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 <20071114041538.ECYS14274.mta13.adelphia.net@DGBP7M81> for ; Tue, 13 Nov 2007 23:15:38 -0500 Message-ID: <001a01c82675$03a25ae0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 13 Nov 2007 20:15:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 mumbled: > and all of their dependencies, but NOT neighboring countries such > as Iceland, Norway, Switzerland, or the Baltics. Balkans. Drink tea first, then write. -- 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 Nov 14 04:15: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 1IsELC-0001Xl-Ac; Wed, 14 Nov 2007 04:15:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsELB-0001WV-6V for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 04:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsELA-0001W0-SJ for ltru@lists.ietf.org; Wed, 14 Nov 2007 04:15:20 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEL5-0002db-MX for ltru@lists.ietf.org; Wed, 14 Nov 2007 04:15:20 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsEKx-0006Jw-La for ltru@lists.ietf.org; Wed, 14 Nov 2007 09:15:07 +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 ; Wed, 14 Nov 2007 09:15:07 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 09:15:07 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 14 Nov 2007 10:11:28 +0100 Lines: 15 Message-ID: References: <002501c82608$beecc140$6601a8c0@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: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: > NOT neighboring countries such as Iceland, Norway, Switzerland, > or the Baltics. s/or the Baltics/Andorra, Foroyar, Holy See, Liechtenstein, Monaco, or = San Marino/. > And the list of EU countries changes with some regularity Yep, the EU might soon get Kosovo, Kroatia, and Montenegro as new = members. Of course the LSTR will get a code for Kosovo first... ;-) Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 04:20: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 1IsEQB-0007Nk-Bj; Wed, 14 Nov 2007 04:20:31 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsEQA-0007HN-4P for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 04:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEQ9-0007Ex-PO for ltru@lists.ietf.org; Wed, 14 Nov 2007 04:20:29 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEQ5-0002lg-BL for ltru@lists.ietf.org; Wed, 14 Nov 2007 04:20:29 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsEPr-00074n-Um for ltru@lists.ietf.org; Wed, 14 Nov 2007 09:20: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 ; Wed, 14 Nov 2007 09:20:11 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 09:20:11 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 14 Nov 2007 10:16:37 +0100 Lines: 6 Message-ID: References: <001a01c82675$03a25ae0$6601a8c0@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: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Ltru] Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: > Balkans. Drink tea first, then write. Sorry, I missed that update, for me it's "read first, then write". _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 05:51: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 1IsFqI-0001CD-99; Wed, 14 Nov 2007 05:51:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsFqG-0001A4-KR for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 05:51:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFqG-00019r-73 for ltru@ietf.org; Wed, 14 Nov 2007 05:51:32 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFqF-0004B7-6j for ltru@ietf.org; Wed, 14 Nov 2007 05:51:32 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007458372.msg for ; Wed, 14 Nov 2007 10:55:54 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Nov 2007 10:51:25 +0000 From: "Debbie Garside" To: References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> Subject: RE: [Ltru] Re: The "QU" territory/region code Date: Wed, 14 Nov 2007 10:50:37 -0000 Message-ID: <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4739E608.2080005@yahoo-inc.com> Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Wed, 14 Nov 2007 10:55:54 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1838036605=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, 14 Nov 2007 10:55:55 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 'LTRU Working Group' 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 I am attending the next meeting of the ISO 3166-1 MA on the 31st of January 2008 on behalf of the BSI. If it would help to have this code allocated within ISO 3166-1 I would be happy to put forward a proposal to the other MA members. When writing any proposal please be mindful of the criteria for inclusion within ISO 3166-1. If you can make the proposal fit the inclusion criteria I will present and support it. Best regards Debbie Garside > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 13 November 2007 18:00 > To: Doug Ewell > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: The "QU" territory/region code > > What follows is a bit of a rant, albeit with a textual > propose for our draft (remember our draft?). Pardon my dust. :-) > > Okay, here's my concern: there was, at one time, a very long > and not-very-friendly thread on ietf-languages in which folks > mostly from the software industry attempted (and failed) to > register "es-americas" > to identify some kind of Latin American or mid-Atlantic > Spanish. The argument against this (basically) was that there > was no such "real" > language, as in "a language recognized by linguistic > scholars". There were, however, some who thought they had a > quite real need to identify an artificially created > linguistic variant. > > In RFC 4646 we explicitly acknowledged the potential for use of the UN > M.49 code "419" for this purpose. > > I agree with Doug that one of the UN M.49 codes could be used > to identify an artificial linguistic variant for the EU. > However, I would be unsurprised if, for example, the EC were > to adopt specially controlled language variations for > translating EU "stuff" without having to choose particular > local variants (or translate into all of them). > Thus I can imagine an "fr-EU" or "de-EU" which is both "not a > real language" and also not "fr-FR" or "de-DE". This could > also be addressed as "fr-x-euro" or "de-eunion" or some-such. > > What bothers me is the sense that "we" (there is no "we") > know better than the users making the request about their > application's needs. I tend to be a little more promiscuous > about supporting variants as a result. There are cases where > the thing being requested isn't well thought out. But I am > not altogether happy with the notion that there is only one > way to use language tags or that "there is no such language > as X hence no use for this subtag in language tags". We don't > actually know that. > > So: I think it would be just grand if 'EU' were actually > assigned by ISO > 3166 and not just reserved. Further, I would support our > acknowledging the "exceptional reservation" as "an > assignment" in 4646bis. To that end, I'd propose changing > Section 2.2.4, item 2 in the list to read: > > -- > All two-character subtags following the primary subtag, with one > exception, were defined in the IANA registry according to the > assignments found in [ISO3166-1] (International Organization for > Standardization, "ISO 3166-1:1997. Codes for the > representation of names > of countries and their subdivisions -- Part 1: Country codes," 1997.) > ("Codes for the representation of names of countries and their > subdivisions -- Part 1: Country codes") using the list of alpha-2 > country codes, or using assignments subsequently made by the ISO 3166 > maintenance agency or governing standardization bodies. The one > exception is the code 'EU' (European Union), which is "exceptionally > reserved" for that purpose (but not "assigned") by ISO 3166. > This code > is assigned in the registry and is subject to the same > constraints that > appear elsewhere in this document as if it were actually > assigned by ISO > 3166. > -- > > Regards, > > Addison > > Doug Ewell wrote: > > Martin Duerst wrote: > > > >> What I'm a bit worried about, and would like to see some > confirmation, > >> is the following scenario. Assume for one reason or > another, some EU > >> variant of a language develops, is defined, or what not. > > > > Back to this in a moment. > > > >> Obviously at least to me, the region subtag 'EU' would be > most suited > >> in this case. Is it possible that the ietf-languages list > just adds > >> this subtag to the registry, or would we have to convene a WG and > >> write another version of what's currently RFC 4646? If the > later is > >> the case, my preference would be to carefully tweak our > texts so that > >> we can avoid rechartering just for the potential scenario > described > >> above. > > > > Both RFC 4646 and draft-4646bis is that they refer to code elements > > "assigned" in ISO 3166-1. RFC 4645 uses the terms "valid" and > > "assigned" in populating the initial LSR. Exceptionally > reserved code > > elements are not "assigned" according to the ISO 3166/MA > definition, and > > thus they don't qualify to have region subtags derived from them > > according to our definition. We would need to change the > requirements > > in 4646bis, and possibly in 4645bis, or else recharter the > group to do > > this in the future. > > > > As Addison said, if we really need a region subtag EU, > someone needs to > > petition ISO 3166/MA to assign the code element. > > > > This discussion, however, continues to presume a > (potential) need for a > > region subtag to describe language usage in exactly these > countries (as > > of 2007-11-03): > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > IT, LT, LU, > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > and all of their dependencies, but NOT neighboring > countries such as > > Iceland, Norway, Switzerland, or the Baltics. And the list of EU > > countries changes with some regularity -- there are currently three > > "official candidate states" and four "potential candidates" > -- making > > code instability not merely a possibility, as it is with > all country > > coding systems, but a certainty. > > > > This is not at all (IMHO) like the recent addition of BL > and MF to 3166 > > and the LSR, two countries (if that they are) which don't appear to > > exhibit distinct language usage. In that case, we are > mirroring the > > decisions made by ISO 3166/MA, as we claim to do, without > consideration > > of the linguistic angle. In the case of EU, we are > actively seeking an > > exception to our rules, which implies we must have a pretty > good reason > > to do so. > > > > Thanks to numeric region codes based on UN M.49, we now > have lots of way > > to indicate pan-European usage: 039, 150, 151, 154, 155. This has > > nothing to do with serving the language-tagging needs of Europe. > > > > Bureaucratic jargon is NOT a regional variation; as Frank said, a > > variant would be better suited to this. Even Michael > Everson's famous > > crusade against use of "euro" as a plural was NOT an > instance of "EU > > usage," but rather a misinterpretation of an EU directive > by local Irish > > officials and journalists. > > > > > -- > 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 Nov 14 05:55: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 1IsFtk-0006JG-Vf; Wed, 14 Nov 2007 05:55:08 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsFtk-0006Ia-9r for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 05:55:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFtj-0006HX-UD for ltru@ietf.org; Wed, 14 Nov 2007 05:55:07 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFtj-0004GQ-7t for ltru@ietf.org; Wed, 14 Nov 2007 05:55:07 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAEAt4Jc018540 for ; Wed, 14 Nov 2007 19:55:04 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 038e_0dfe1974_92a0_11dc_9d22_0014221f2a2d; Wed, 14 Nov 2007 19:55:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55424) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 14 Nov 2007 19:51:15 +0900 Message-Id: <6.0.0.20.2.20071114194903.0983b750@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 14 Nov 2007 19:54:05 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <4739E608.2080005@yahoo-inc.com> References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 02:59 07/11/14, Addison Phillips wrote: >So: I think it would be just grand if 'EU' were actually assigned by ISO 3166 and not just reserved. Further, I would support our acknowledging the "exceptional reservation" as "an assignment" in 4646bis. What other codes except for "EU" are there? I'm fine to restrict this to "EU" only, but I just want to cross-check. >To that end, I'd propose changing Section 2.2.4, item 2 in the list to read: > >-- >All two-character subtags following the primary subtag, with one exception, were defined in the IANA registry according to the assignments found in [ISO3166$Bc`A(B] (International Organization for Standardization, $Bc`W*(BSO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,$Bc`Y(B1997.) ("Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes") using the list of alpha-2 country codes, or using assignments subsequently made by the ISO 3166 maintenance agency or governing standardization bodies. The one exception is the code 'EU' (European Union), which is "exceptionally reserved" for that purpose (but not "assigned") by ISO 3166. This code is assigned in the registry and is subject to the same constraints that appear elsewhere in this document as if it were actually assigned by ISO 3166. >-- As a technical contributor, I agree with this text addition for the reasons given by Addison. However, the text has to be fixed to be in pure US-ASCII. Regards, Martin.s #-#-# 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 Nov 14 05:55:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFtp-0006OJ-38; Wed, 14 Nov 2007 05:55:13 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsFto-0006MZ-94 for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 05:55:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFtn-0006MR-Va for ltru@ietf.org; Wed, 14 Nov 2007 05:55:11 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsFti-0004xn-IL for ltru@ietf.org; Wed, 14 Nov 2007 05:55:11 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAEAt2i4018528 for ; Wed, 14 Nov 2007 19:55:03 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0385_0d4b7454_92a0_11dc_9efb_0014221f2a2d; Wed, 14 Nov 2007 19:55:02 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:55424) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 14 Nov 2007 19:51:13 +0900 Message-Id: <6.0.0.20.2.20071114193837.0983c140@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 14 Nov 2007 19:47:02 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] trying again: teleconference??? In-Reply-To: <4739CF8C.3050408@yahoo-inc.com> References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:23 07/11/14, Addison Phillips wrote: >I'm not suggesting we "just announce" something. Previously on this list there was a discussion of possible times. Yes. I'd just hoped that we don't have to start from scratch again. >Normally, it is up to the chair(s) of the group to coordinate scheduling of activities such as this, etc. and make the final announcement. Well, except that the IETF doesn't usually do teleconferences :-(. >In any case, I'm happy to suggest some times (I just did this for W3C-I18N-Core, so I can be eco-friendly and recycle the bits: see below), but you or Randy should take ownership of gathering input and selecting the date/time. Okay, if I take ownership (and assuming that includes participation), then I'll first have to throw out (A) and (C), because in this timeslot, maybe my body could participate, but my brain for sure won't be awake. >Here are some optional *times*. I can do any of these on either Wednesdays or Thursdays. Note that London is currently effectively the same as GMT. >(B) > >14:00 Pacific >22:00 London >09:00 Sydney (next day) >07:00 Tokyo (next day) >17:00 Toronto >(D) > >22:00 Pacific (previous day) >06:00 London >17:00 Sydney >15:00 Tokyo >01:00 Toronto Can everybody please annouce their preferences? You can send mail directly to me if you don't want to bother the whole list. 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 Nov 14 06:16: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 1IsGEO-0004kz-JR; Wed, 14 Nov 2007 06:16:28 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsGEO-0004ks-0U for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 06:16:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGEN-0004kg-K6 for ltru@lists.ietf.org; Wed, 14 Nov 2007 06:16:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsGEJ-0005dz-3g for ltru@lists.ietf.org; Wed, 14 Nov 2007 06:16:27 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsGEG-0004mf-1l for ltru@lists.ietf.org; Wed, 14 Nov 2007 11:16:20 +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 ; Wed, 14 Nov 2007 11:16:20 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 11:16:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 14 Nov 2007 12:12:56 +0100 Lines: 15 Message-ID: References: <002501c82608$beecc140$6601a8c0@DGBP7M81><4739E608.2080005@yahoo-inc.com> <6.0.0.20.2.20071114194903.0983b750@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > What other codes except for "EU" are there? I'm fine to restrict this = to "EU" > only, but I just want to cross-check. Tons of bogus codes, compare http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/= iso_3166-1_decoding_table.html?printable=3Dtrue#AA EU is in the yellow set (exceptionally reserved), like AC, CP, DG, EA, FX, IC, TA, and UK. Opening this can of worms is suicidal. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 08:41: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 1IsIUb-00073q-I3; Wed, 14 Nov 2007 08:41:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsIUZ-00070U-Fv for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 08:41:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIUZ-0006zu-1V for ltru@ietf.org; Wed, 14 Nov 2007 08:41:19 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsIUY-0003Sl-Kn for ltru@ietf.org; Wed, 14 Nov 2007 08:41:18 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IsITJ-0002un-Fc; Wed, 14 Nov 2007 08:40:01 -0500 Date: Wed, 14 Nov 2007 08:40:01 -0500 To: Debbie Garside Subject: Re: [Ltru] Re: The "QU" territory/region code Message-ID: <20071114134001.GI13650@mercury.ccil.org> References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> 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 Debbie Garside scripsit: > I am attending the next meeting of the ISO 3166-1 MA on the 31st of January > 2008 on behalf of the BSI. If it would help to have this code allocated > within ISO 3166-1 I would be happy to put forward a proposal to the other MA > members. When writing any proposal please be mindful of the criteria for > inclusion within ISO 3166-1. If you can make the proposal fit the inclusion > criteria I will present and support it. I think it's impossible for the MA to call the European Union a nation, particularly since their assigned codes are slaved to M.49, which has no code for it. -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.ccil.org/~cowan but it pours? cowan@ccil.org --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 08:59: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 1IsImA-0002A7-RR; Wed, 14 Nov 2007 08:59:30 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsIm9-00029U-Sj for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 08:59:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIm9-00029L-Ia for ltru@lists.ietf.org; Wed, 14 Nov 2007 08:59:29 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsIm6-0004K6-PE for ltru@lists.ietf.org; Wed, 14 Nov 2007 08:59:29 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IsIm6-0004i9-Dq; Wed, 14 Nov 2007 08:59:26 -0500 Date: Wed, 14 Nov 2007 08:59:26 -0500 To: Frank Ellermann Subject: Re: [Ltru] Re: The "QU" territory/region code Message-ID: <20071114135926.GJ13650@mercury.ccil.org> References: <6.0.0.20.2.20071114194903.0983b750@localhost> 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > > What other codes except for "EU" are there? I'm fine to restrict this to "EU" > > only, but I just want to cross-check. > > Tons of bogus codes, compare > > http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA > > EU is in the yellow set (exceptionally reserved), like AC, CP, DG, > EA, FX, IC, TA, and UK. That is to say, Ascension Island, Clipperton Island, Diego Garcia, Ceuta and Melilla, France without the overseas territories, the Canary Islands, Tristan da Cunha, and the U.K. Of these, only the last code is really bogus, poison, or wormy. I think we could easily live with the others: indeed, en-TA is a recognized variety of English. So I'd be happy to see the exceptionally reserved codes available with the exception of UK. -- The Unicode Standard does not encode John Cowan idiosyncratic, personal, novel, or private http://www.ccil.org/~cowan use characters, nor does it encode logos or graphics. cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 09:06: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 1IsIt2-0002ba-Tr; Wed, 14 Nov 2007 09:06:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsIt2-0002bP-4l for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 09:06:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIt0-0002aN-7u for ltru@ietf.org; Wed, 14 Nov 2007 09:06:34 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsIsx-0004vs-0m for ltru@ietf.org; Wed, 14 Nov 2007 09:06:34 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IsIsr-0005aF-Rt; Wed, 14 Nov 2007 09:06:25 -0500 Date: Wed, 14 Nov 2007 09:06:25 -0500 To: Addison Phillips Subject: Re: [Ltru] Re: The "QU" territory/region code Message-ID: <20071114140625.GK13650@mercury.ccil.org> References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4739E608.2080005@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: 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 Addison Phillips scripsit: > So: I think it would be just grand if 'EU' were actually assigned by ISO > 3166 and not just reserved. As I said, I don't think that's practical. > I'd propose changing Section 2.2.4, item 2 in the list to read: Here's my proposed version: All two-character subtags following the primary subtag were defined in the IANA registry according to the assignments found in [ISO3166‑1] (International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” 1997.) ("Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes") using the list of alpha-2 country codes, or using assignments subsequently made by the ISO 3166 maintenance agency or governing standardization bodies. In addition, the codes that are "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 were also defined in the registry, with the exception of 'UK', which is an exact synonym for the assigned code 'GB'. It would only be confusing to allow 'UK', so it is excluded. Yeah, it's cherry-picking, but this particular cherry has a worm in it. -- John Cowan http://ccil.org/~cowan cowan@ccil.org All "isms" should be "wasms". --Abbie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 09:28: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 1IsJDq-00043q-Qg; Wed, 14 Nov 2007 09:28:06 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsJDq-00042b-11 for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 09:28:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJDp-00041S-Gi for ltru@ietf.org; Wed, 14 Nov 2007 09:28:05 -0500 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound8-blu-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJDp-0007nC-14 for ltru@ietf.org; Wed, 14 Nov 2007 09:28:05 -0500 Received: from outbound8-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound8-blu-R.bigfish.com (Postfix) with ESMTP id C7DED9DCCB3 for ; Wed, 14 Nov 2007 14:28:02 +0000 (UTC) Received: from mail150-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound8-blu.bigfish.com (Postfix) with ESMTP id B2B6560005E for ; Wed, 14 Nov 2007 14:28:02 +0000 (UTC) Received: from mail150-blu (localhost.localdomain [127.0.0.1]) by mail150-blu-R.bigfish.com (Postfix) with ESMTP id 7B2FEBF8244 for ; Wed, 14 Nov 2007 14:28:02 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 192.165.213.23; Service: EHS Received: by mail150-blu (MessageSwitch) id 1195050481802806_15981; Wed, 14 Nov 2007 14:28:01 +0000 (UCT) Received: from lonsmime04.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mail150-blu.bigfish.com (Postfix) with ESMTP id 64BCE978062 for ; Wed, 14 Nov 2007 14:28:01 +0000 (UTC) Received: from eupig2 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Wed, 14 Nov 2007 14:28:01 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31408) with ESMTP id <0JRI00H142UOK7@eupig2.dtc.lon.ime.reuters.com>; Wed, 14 Nov 2007 14:28:00 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.1830); Wed, 14 Nov 2007 14:28:00 +0000 Date: Wed, 14 Nov 2007 14:23:03 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: The "QU" territory/region code In-reply-to: <20071114140625.GK13650@mercury.ccil.org> To: John Cowan , LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: Acgmx5R4aCRakLV8Q5qWm0ZlnFCu5gAAet8Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 14 Nov 2007 14:28:00.0762 (UTC) FILETIME=[8F305DA0:01C826CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1974730775==" Errors-To: ltru-bounces@ietf.org --===============1974730775== Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 Content-class: urn:content-classes:message SSB3b3VsZCBtYWtlIHRoZSBzdGF0ZW1lbnQgYWJvdXQgZXhjbHVkaW5nICdVSycgc3Ryb25nZXIu ICBJIGNhbid0IA0KcHJvcG9zZSBzcGVjaWZpYyB3b3JkcywgYnV0IHRoZSBpbmNsdXNpb24gb2Yg J1VLJyB3b3VsZCBicmVhayANCm1hdGNoaW5nLCBzbyBxdWFsaWZpZXMgZm9yIHN0cm9uZ2VyIGxh bmd1YWdlIHRoYW4ganVzdCAiY29uZnVzaW5nIi4NCg0KTWlzaGENCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBDb3dhbiBbbWFpbHRvOmNvd2FuQGNjaWwub3JnXSAN ClNlbnQ6IDE0IE5vdmVtYmVyIDIwMDcgMTQ6MDYNClRvOiBBZGRpc29uIFBoaWxsaXBzDQpDYzog RG91ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwDQpTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBU aGUgIlFVIiB0ZXJyaXRvcnkvcmVnaW9uIGNvZGUNCg0KQWRkaXNvbiBQaGlsbGlwcyBzY3JpcHNp dDoNCg0KPiBTbzogSSB0aGluayBpdCB3b3VsZCBiZSBqdXN0IGdyYW5kIGlmICdFVScgd2VyZSBh Y3R1YWxseSBhc3NpZ25lZCBieSBJU08gDQo+IDMxNjYgYW5kIG5vdCBqdXN0IHJlc2VydmVkLiAN Cg0KQXMgSSBzYWlkLCBJIGRvbid0IHRoaW5rIHRoYXQncyBwcmFjdGljYWwuDQoNCj4gSSdkIHBy b3Bvc2UgY2hhbmdpbmcgU2VjdGlvbiAyLjIuNCwgaXRlbSAyIGluIHRoZSBsaXN0IHRvIHJlYWQ6 DQoNCkhlcmUncyBteSBwcm9wb3NlZCB2ZXJzaW9uOg0KDQpBbGwgdHdvLWNoYXJhY3RlciBzdWJ0 YWdzIGZvbGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcgd2VyZSBkZWZpbmVkIGluDQp0aGUgSUFO QSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIFtJU08zMTY2 4oCRMV0NCihJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCDi gJxJU08gMzE2Ni0xOjE5OTcuIENvZGVzDQpmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVz IG9mIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tDQpQYXJ0IDE6IENvdW50cnkg Y29kZXMs4oCdIDE5OTcuKSAgKCJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVz DQpvZiBjb3VudHJpZXMgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtLSBQYXJ0IDE6IENvdW50cnkg Y29kZXMiKSB1c2luZyB0aGUNCmxpc3Qgb2YgYWxwaGEtMiBjb3VudHJ5IGNvZGVzLCBvciB1c2lu ZyBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFkZSBieQ0KdGhlIElTTyAzMTY2IG1haW50ZW5h bmNlIGFnZW5jeSBvciBnb3Zlcm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4gSW4NCmFkZGl0 aW9uLCB0aGUgY29kZXMgdGhhdCBhcmUgImV4Y2VwdGlvbmFsbHkgcmVzZXJ2ZWQiIChhcyBvcHBv c2VkIHRvDQoiYXNzaWduZWQiKSBpbiBJU08gMzE2Ni0xIHdlcmUgYWxzbyBkZWZpbmVkIGluIHRo ZSByZWdpc3RyeSwgd2l0aCB0aGUNCmV4Y2VwdGlvbiBvZiAnVUsnLCB3aGljaCBpcyBhbiBleGFj dCBzeW5vbnltIGZvciB0aGUgYXNzaWduZWQgY29kZQ0KJ0dCJy4gIEl0IHdvdWxkIG9ubHkgYmUg Y29uZnVzaW5nIHRvIGFsbG93ICdVSycsIHNvIGl0IGlzIGV4Y2x1ZGVkLg0KDQpZZWFoLCBpdCdz IGNoZXJyeS1waWNraW5nLCBidXQgdGhpcyBwYXJ0aWN1bGFyIGNoZXJyeSBoYXMgYSB3b3JtIGlu IGl0Lg0KDQotLSANCkpvaG4gQ293YW4gIGh0dHA6Ly9jY2lsLm9yZy9+Y293YW4gIGNvd2FuQGNj aWwub3JnDQpBbGwgImlzbXMiIHNob3VsZCBiZSAid2FzbXMiLiAgIC0tQWJiaWUNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHRydSBtYWlsaW5n IGxpc3QNCkx0cnVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2x0cnUNCg0KClRoaXMgZW1haWwgd2FzIHNlbnQgdG8geW91IGJ5IFJldXRlcnMsIHRoZSBn bG9iYWwgbmV3cyBhbmQgaW5mb3JtYXRpb24gY29tcGFueS4gClRvIGZpbmQgb3V0IG1vcmUgYWJv dXQgUmV1dGVycyB2aXNpdCB3d3cuYWJvdXQucmV1dGVycy5jb20KCkFueSB2aWV3cyBleHByZXNz ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIsIApl eGNlcHQgd2hlcmUgdGhlIHNlbmRlciBzcGVjaWZpY2FsbHkgc3RhdGVzIHRoZW0gdG8gYmUgdGhl IHZpZXdzIG9mIFJldXRlcnMgTGltaXRlZC4KClJldXRlcnMgTGltaXRlZCBpcyBwYXJ0IG9mIHRo ZSBSZXV0ZXJzIEdyb3VwIG9mIGNvbXBhbmllcywgb2Ygd2hpY2ggUmV1dGVycyBHcm91cCBQTEMg aXMgdGhlIHVsdGltYXRlIHBhcmVudCBjb21wYW55LgpSZXV0ZXJzIEdyb3VwIFBMQyAtIFJlZ2lz dGVyZWQgb2ZmaWNlIGFkZHJlc3M6IFRoZSBSZXV0ZXJzIEJ1aWxkaW5nLCBTb3V0aCBDb2xvbm5h ZGUsIENhbmFyeSBXaGFyZiwgTG9uZG9uIEUxNCA1RVAsIFVuaXRlZCBLaW5nZG9tClJlZ2lzdGVy ZWQgTm86IDMyOTYzNzUKUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcwo= --===============1974730775== 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 --===============1974730775==-- From ltru-bounces@ietf.org Wed Nov 14 10:38: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 1IsKKI-0006Du-1M; Wed, 14 Nov 2007 10:38:50 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKKH-0006D3-Ez for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKKH-0006Ca-4s for ltru@ietf.org; Wed, 14 Nov 2007 10:38:49 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKKE-0006ds-Rc for ltru@ietf.org; Wed, 14 Nov 2007 10:38:49 -0500 Received: from [10.72.73.107] (snvvpn1-10-72-73-c107.corp.yahoo.com [10.72.73.107]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAEFcL4i055209; Wed, 14 Nov 2007 07:38:21 -0800 (PST) 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=WXuCCiVFd7jZH2TJSReHoGZdTLNzcf2hxJJwtHAzFaNdC2UO8GLACnLS8paGeDc4 Message-ID: <473B166C.6090208@yahoo-inc.com> Date: Wed, 14 Nov 2007 07:38:20 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Misha Wolf Subject: Re: [Ltru] Re: The "QU" territory/region code References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id lAEFcL4i055209 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with John's proposed wording. I agree with Misha's note too. We could just omit John's last sentence=20 (the explanation is sufficiently grave on its own). I kind of like the fact that we point out somewhere that 'UK' is not the=20 right code to use for the UK in a language tag. Addison Misha Wolf wrote: > I would make the statement about excluding 'UK' stronger. I can't=20 > propose specific words, but the inclusion of 'UK' would break=20 > matching, so qualifies for stronger language than just "confusing". >=20 > Misha >=20 >=20 > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org]=20 > Sent: 14 November 2007 14:06 > To: Addison Phillips > Cc: Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] Re: The "QU" territory/region code >=20 > Addison Phillips scripsit: >=20 >> So: I think it would be just grand if 'EU' were actually assigned by I= SO=20 >> 3166 and not just reserved.=20 >=20 > As I said, I don't think that's practical. >=20 >> I'd propose changing Section 2.2.4, item 2 in the list to read: >=20 > Here's my proposed version: >=20 > All two-character subtags following the primary subtag were defined in > the IANA registry according to the assignments found in [ISO3166=E2=80=91= 1] > (International Organization for Standardization, =E2=80=9CISO 3166-1:19= 97. Codes > for the representation of names of countries and their subdivisions -- > Part 1: Country codes,=E2=80=9D 1997.) ("Codes for the representation = of names > of countries and their subdivisions -- Part 1: Country codes") using th= e > list of alpha-2 country codes, or using assignments subsequently made b= y > the ISO 3166 maintenance agency or governing standardization bodies. In > addition, the codes that are "exceptionally reserved" (as opposed to > "assigned") in ISO 3166-1 were also defined in the registry, with the > exception of 'UK', which is an exact synonym for the assigned code > 'GB'. It would only be confusing to allow 'UK', so it is excluded. >=20 > Yeah, it's cherry-picking, but this particular cherry has a worm in it. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=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 Wed Nov 14 10:42: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 1IsKO6-0002rt-Bs; Wed, 14 Nov 2007 10:42:46 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKO4-0002m1-LX for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKO4-0002lJ-BX for ltru@ietf.org; Wed, 14 Nov 2007 10:42:44 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKO0-00072l-AI for ltru@ietf.org; Wed, 14 Nov 2007 10:42:44 -0500 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.222.3; Wed, 14 Nov 2007 07:42:22 -0800 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; Wed, 14 Nov 2007 07:42:39 -0800 From: Peter Constable To: "debbie@ictmarketing.co.uk" , "addison@yahoo-inc.com" Date: Wed, 14 Nov 2007 07:42:35 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZA= Message-ID: References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> In-Reply-To: <0a5701c826ac$3100b720$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: f2728948111f2edaaf8980b5b9de55af 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 Debbie: I think it might help for the MA to consider the entire issue of exceptiona= l reservations. It is effectively providing something for use in public int= erchange without fully endorsing it: that's just going to leave people deal= ing with consuming standards in a quandary, just as we're facing now: they = need to interoperate with the publicly-encountered identifier, but they als= o need to make normative reference to the standard. With exceptional reserv= ations, they end up stuck in a hole with no good way out. Peter > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: Wednesday, November 14, 2007 2:51 AM > To: addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > Hi Addison > > I am attending the next meeting of the ISO 3166-1 MA on the 31st of > January > 2008 on behalf of the BSI. If it would help to have this code > allocated > within ISO 3166-1 I would be happy to put forward a proposal to the > other MA > members. When writing any proposal please be mindful of the criteria > for > inclusion within ISO 3166-1. If you can make the proposal fit the > inclusion > criteria I will present and support it. > > Best regards > > Debbie Garside > > > > -----Original Message----- > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > Sent: 13 November 2007 18:00 > > To: Doug Ewell > > Cc: LTRU Working Group > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > What follows is a bit of a rant, albeit with a textual > > propose for our draft (remember our draft?). Pardon my dust. :-) > > > > Okay, here's my concern: there was, at one time, a very long > > and not-very-friendly thread on ietf-languages in which folks > > mostly from the software industry attempted (and failed) to > > register "es-americas" > > to identify some kind of Latin American or mid-Atlantic > > Spanish. The argument against this (basically) was that there > > was no such "real" > > language, as in "a language recognized by linguistic > > scholars". There were, however, some who thought they had a > > quite real need to identify an artificially created > > linguistic variant. > > > > In RFC 4646 we explicitly acknowledged the potential for use of the > UN > > M.49 code "419" for this purpose. > > > > I agree with Doug that one of the UN M.49 codes could be used > > to identify an artificial linguistic variant for the EU. > > However, I would be unsurprised if, for example, the EC were > > to adopt specially controlled language variations for > > translating EU "stuff" without having to choose particular > > local variants (or translate into all of them). > > Thus I can imagine an "fr-EU" or "de-EU" which is both "not a > > real language" and also not "fr-FR" or "de-DE". This could > > also be addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > What bothers me is the sense that "we" (there is no "we") > > know better than the users making the request about their > > application's needs. I tend to be a little more promiscuous > > about supporting variants as a result. There are cases where > > the thing being requested isn't well thought out. But I am > > not altogether happy with the notion that there is only one > > way to use language tags or that "there is no such language > > as X hence no use for this subtag in language tags". We don't > > actually know that. > > > > So: I think it would be just grand if 'EU' were actually > > assigned by ISO > > 3166 and not just reserved. Further, I would support our > > acknowledging the "exceptional reservation" as "an > > assignment" in 4646bis. To that end, I'd propose changing > > Section 2.2.4, item 2 in the list to read: > > > > -- > > All two-character subtags following the primary subtag, with one > > exception, were defined in the IANA registry according to the > > assignments found in [ISO3166-1] (International Organization for > > Standardization, "ISO 3166-1:1997. Codes for the > > representation of names > > of countries and their subdivisions -- Part 1: Country codes," 1997.) > > ("Codes for the representation of names of countries and their > > subdivisions -- Part 1: Country codes") using the list of alpha-2 > > country codes, or using assignments subsequently made by the ISO 3166 > > maintenance agency or governing standardization bodies. The one > > exception is the code 'EU' (European Union), which is "exceptionally > > reserved" for that purpose (but not "assigned") by ISO 3166. > > This code > > is assigned in the registry and is subject to the same > > constraints that > > appear elsewhere in this document as if it were actually > > assigned by ISO > > 3166. > > -- > > > > Regards, > > > > Addison > > > > Doug Ewell wrote: > > > Martin Duerst wrote: > > > > > >> What I'm a bit worried about, and would like to see some > > confirmation, > > >> is the following scenario. Assume for one reason or > > another, some EU > > >> variant of a language develops, is defined, or what not. > > > > > > Back to this in a moment. > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > most suited > > >> in this case. Is it possible that the ietf-languages list > > just adds > > >> this subtag to the registry, or would we have to convene a WG and > > >> write another version of what's currently RFC 4646? If the > > later is > > >> the case, my preference would be to carefully tweak our > > texts so that > > >> we can avoid rechartering just for the potential scenario > > described > > >> above. > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code elements > > > "assigned" in ISO 3166-1. RFC 4645 uses the terms "valid" and > > > "assigned" in populating the initial LSR. Exceptionally > > reserved code > > > elements are not "assigned" according to the ISO 3166/MA > > definition, and > > > thus they don't qualify to have region subtags derived from them > > > according to our definition. We would need to change the > > requirements > > > in 4646bis, and possibly in 4645bis, or else recharter the > > group to do > > > this in the future. > > > > > > As Addison said, if we really need a region subtag EU, > > someone needs to > > > petition ISO 3166/MA to assign the code element. > > > > > > This discussion, however, continues to presume a > > (potential) need for a > > > region subtag to describe language usage in exactly these > > countries (as > > > of 2007-11-03): > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > IT, LT, LU, > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > and all of their dependencies, but NOT neighboring > > countries such as > > > Iceland, Norway, Switzerland, or the Baltics. And the list of EU > > > countries changes with some regularity -- there are currently three > > > "official candidate states" and four "potential candidates" > > -- making > > > code instability not merely a possibility, as it is with > > all country > > > coding systems, but a certainty. > > > > > > This is not at all (IMHO) like the recent addition of BL > > and MF to 3166 > > > and the LSR, two countries (if that they are) which don't appear to > > > exhibit distinct language usage. In that case, we are > > mirroring the > > > decisions made by ISO 3166/MA, as we claim to do, without > > consideration > > > of the linguistic angle. In the case of EU, we are > > actively seeking an > > > exception to our rules, which implies we must have a pretty > > good reason > > > to do so. > > > > > > Thanks to numeric region codes based on UN M.49, we now > > have lots of way > > > to indicate pan-European usage: 039, 150, 151, 154, 155. This has > > > nothing to do with serving the language-tagging needs of Europe. > > > > > > Bureaucratic jargon is NOT a regional variation; as Frank said, a > > > variant would be better suited to this. Even Michael > > Everson's famous > > > crusade against use of "euro" as a plural was NOT an > > instance of "EU > > > usage," but rather a misinterpretation of an EU directive > > by local Irish > > > officials and journalists. > > > > > > > > > -- > > 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 Nov 14 10:46: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 1IsKRL-0000ix-5r; Wed, 14 Nov 2007 10:46:07 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKRJ-0000ep-Ql for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKRJ-0000dp-DI for ltru@ietf.org; Wed, 14 Nov 2007 10:46:05 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKRF-0007RZ-NH for ltru@ietf.org; Wed, 14 Nov 2007 10:46:05 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 14 Nov 2007 07:45:44 -0800 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; Wed, 14 Nov 2007 07:46:00 -0800 From: Peter Constable To: Martin Duerst , Addison Phillips Date: Wed, 14 Nov 2007 07:45:54 -0800 Subject: RE: [Ltru] trying again: teleconference??? Thread-Topic: [Ltru] trying again: teleconference??? Thread-Index: AcgmrNZT1FpRJtWWTE+hdr6Yq2UFrgAKISLg Message-ID: References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> <6.0.0.20.2.20071114193837.0983c140@localhost> In-Reply-To: <6.0.0.20.2.20071114193837.0983c140@localhost> 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: fb6060cb60c0cea16e3f7219e40a0a81 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 B (1400 Pacific) Wed or Thur is OK with me. Slot D (2200 Pacific) is not.) Peter > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Wednesday, November 14, 2007 2:47 AM > To: Addison Phillips > Cc: 'LTRU Working Group' > Subject: Re: [Ltru] trying again: teleconference??? > > At 01:23 07/11/14, Addison Phillips wrote: > >I'm not suggesting we "just announce" something. Previously on this > list there was a discussion of possible times. > > Yes. I'd just hoped that we don't have to start from scratch again. > > >Normally, it is up to the chair(s) of the group to coordinate > scheduling of activities such as this, etc. and make the final > announcement. > > Well, except that the IETF doesn't usually do teleconferences :-(. > > >In any case, I'm happy to suggest some times (I just did this for W3C- > I18N-Core, so I can be eco-friendly and recycle the bits: see below), > but you or Randy should take ownership of gathering input and selecting > the date/time. > > Okay, if I take ownership (and assuming that includes participation), > then I'll first have to throw out (A) and (C), because in this timeslot, > maybe my body could participate, but my brain for sure won't be awake. > > > >Here are some optional *times*. I can do any of these on either > Wednesdays or Thursdays. Note that London is currently effectively the > same as GMT. > > > >(B) > > > >14:00 Pacific > >22:00 London > >09:00 Sydney (next day) > >07:00 Tokyo (next day) > >17:00 Toronto > > >(D) > > > >22:00 Pacific (previous day) > >06:00 London > >17:00 Sydney > >15:00 Tokyo > >01:00 Toronto > > Can everybody please annouce their preferences? You can send mail > directly to me > if you don't want to bother the whole list. > > 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 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 10:48: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 1IsKTt-0004E5-BU; Wed, 14 Nov 2007 10:48:45 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKTs-0004De-8a for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:48:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKTr-0004DU-VF for ltru@lists.ietf.org; Wed, 14 Nov 2007 10:48:43 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKTo-0007hb-Np for ltru@lists.ietf.org; Wed, 14 Nov 2007 10:48:43 -0500 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.222.3; Wed, 14 Nov 2007 07:48:23 -0800 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; Wed, 14 Nov 2007 07:48:40 -0800 From: Peter Constable To: John Cowan , Frank Ellermann Date: Wed, 14 Nov 2007 07:48:36 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgmxpWY+33rv57GQdKiem+vOJlQRAADwFsw Message-ID: References: <6.0.0.20.2.20071114194903.0983b750@localhost> <20071114135926.GJ13650@mercury.ccil.org> In-Reply-To: <20071114135926.GJ13650@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 From: John Cowan [mailto:cowan@ccil.org] > So I'd be happy to see the exceptionally reserved codes available > with the exception of UK. Ditto. I'm OK with cherry picking if there's a good reason to, but I don't = see this case as having a good reason. And I thought everyone else here wan= ted to avoid cherry picking altogether. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 10:49: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 1IsKUB-0004KC-JK; Wed, 14 Nov 2007 10:49:03 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKUA-0004Js-1R for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:49:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKU9-0004JO-LQ for ltru@ietf.org; Wed, 14 Nov 2007 10:49:01 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKU8-0000UZ-Hb for ltru@ietf.org; Wed, 14 Nov 2007 10:49:01 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007459964.msg for ; Wed, 14 Nov 2007 15:53:22 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Nov 2007 15:48:55 +0000 From: "Debbie Garside" To: , References: <002501c82608$beecc140$6601a8c0@DGBP7M81><4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] Re: The "QU" territory/region code Date: Wed, 14 Nov 2007 15:48:06 -0000 Message-ID: <0b0a01c826d5$bfbb45b0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZAAAGLG4A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Wed, 14 Nov 2007 15:53:22 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1838036605=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, 14 Nov 2007 15:53:24 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: 'LTRU Working Group' 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 Peter I agree. I have broached the subject with ISO Central Secretariat today and will let you (and LTRU) know of any relevant outcomes. Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 14 November 2007 15:43 > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > Debbie: > > I think it might help for the MA to consider the entire issue > of exceptional reservations. It is effectively providing > something for use in public interchange without fully > endorsing it: that's just going to leave people dealing with > consuming standards in a quandary, just as we're facing now: > they need to interoperate with the publicly-encountered > identifier, but they also need to make normative reference to > the standard. With exceptional reservations, they end up > stuck in a hole with no good way out. > > > Peter > > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: Wednesday, November 14, 2007 2:51 AM > > To: addison@yahoo-inc.com > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > Hi Addison > > > > I am attending the next meeting of the ISO 3166-1 MA on the 31st of > > January > > 2008 on behalf of the BSI. If it would help to have this code > > allocated > > within ISO 3166-1 I would be happy to put forward a proposal to the > > other MA members. When writing any proposal please be > mindful of the > > criteria for inclusion within ISO 3166-1. If you can make the > > proposal fit the inclusion criteria I will present and support it. > > > > Best regards > > > > Debbie Garside > > > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > Sent: 13 November 2007 18:00 > > > To: Doug Ewell > > > Cc: LTRU Working Group > > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > > > What follows is a bit of a rant, albeit with a textual > propose for > > > our draft (remember our draft?). Pardon my dust. :-) > > > > > > Okay, here's my concern: there was, at one time, a very long and > > > not-very-friendly thread on ietf-languages in which folks mostly > > > from the software industry attempted (and failed) to register > > > "es-americas" > > > to identify some kind of Latin American or mid-Atlantic > Spanish. The > > > argument against this (basically) was that there was no > such "real" > > > language, as in "a language recognized by linguistic scholars". > > > There were, however, some who thought they had a quite > real need to > > > identify an artificially created linguistic variant. > > > > > > In RFC 4646 we explicitly acknowledged the potential for > use of the > > UN > > > M.49 code "419" for this purpose. > > > > > > I agree with Doug that one of the UN M.49 codes could be used to > > > identify an artificial linguistic variant for the EU. > > > However, I would be unsurprised if, for example, the EC were to > > > adopt specially controlled language variations for translating EU > > > "stuff" without having to choose particular local variants (or > > > translate into all of them). > > > Thus I can imagine an "fr-EU" or "de-EU" which is both > "not a real > > > language" and also not "fr-FR" or "de-DE". This could also be > > > addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > > > What bothers me is the sense that "we" (there is no "we") know > > > better than the users making the request about their > application's > > > needs. I tend to be a little more promiscuous about supporting > > > variants as a result. There are cases where the thing being > > > requested isn't well thought out. But I am not altogether > happy with > > > the notion that there is only one way to use language > tags or that > > > "there is no such language as X hence no use for this subtag in > > > language tags". We don't actually know that. > > > > > > So: I think it would be just grand if 'EU' were actually > assigned by > > > ISO > > > 3166 and not just reserved. Further, I would support our > > > acknowledging the "exceptional reservation" as "an assignment" in > > > 4646bis. To that end, I'd propose changing Section 2.2.4, > item 2 in > > > the list to read: > > > > > > -- > > > All two-character subtags following the primary subtag, with one > > > exception, were defined in the IANA registry according to the > > > assignments found in [ISO3166-1] (International Organization for > > > Standardization, "ISO 3166-1:1997. Codes for the > representation of > > > names of countries and their subdivisions -- Part 1: > Country codes," > > > 1997.) ("Codes for the representation of names of countries and > > > their subdivisions -- Part 1: Country codes") using the list of > > > alpha-2 country codes, or using assignments subsequently > made by the > > > ISO 3166 maintenance agency or governing standardization > bodies. The > > > one exception is the code 'EU' (European Union), which is > > > "exceptionally reserved" for that purpose (but not "assigned") by > > > ISO 3166. > > > This code > > > is assigned in the registry and is subject to the same > constraints > > > that appear elsewhere in this document as if it were actually > > > assigned by ISO 3166. > > > -- > > > > > > Regards, > > > > > > Addison > > > > > > Doug Ewell wrote: > > > > Martin Duerst wrote: > > > > > > > >> What I'm a bit worried about, and would like to see some > > > confirmation, > > > >> is the following scenario. Assume for one reason or > > > another, some EU > > > >> variant of a language develops, is defined, or what not. > > > > > > > > Back to this in a moment. > > > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > > most suited > > > >> in this case. Is it possible that the ietf-languages list > > > just adds > > > >> this subtag to the registry, or would we have to > convene a WG and > > > >> write another version of what's currently RFC 4646? If the > > > later is > > > >> the case, my preference would be to carefully tweak our > > > texts so that > > > >> we can avoid rechartering just for the potential scenario > > > described > > > >> above. > > > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code > > > > elements "assigned" in ISO 3166-1. RFC 4645 uses the terms > > > > "valid" and "assigned" in populating the initial LSR. > > > > Exceptionally > > > reserved code > > > > elements are not "assigned" according to the ISO 3166/MA > > > definition, and > > > > thus they don't qualify to have region subtags derived > from them > > > > according to our definition. We would need to change the > > > requirements > > > > in 4646bis, and possibly in 4645bis, or else recharter the > > > group to do > > > > this in the future. > > > > > > > > As Addison said, if we really need a region subtag EU, > > > someone needs to > > > > petition ISO 3166/MA to assign the code element. > > > > > > > > This discussion, however, continues to presume a > > > (potential) need for a > > > > region subtag to describe language usage in exactly these > > > countries (as > > > > of 2007-11-03): > > > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > > IT, LT, LU, > > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > > > and all of their dependencies, but NOT neighboring > > > countries such as > > > > Iceland, Norway, Switzerland, or the Baltics. And the > list of EU > > > > countries changes with some regularity -- there are currently > > > > three "official candidate states" and four "potential > candidates" > > > -- making > > > > code instability not merely a possibility, as it is with > > > all country > > > > coding systems, but a certainty. > > > > > > > > This is not at all (IMHO) like the recent addition of BL > > > and MF to 3166 > > > > and the LSR, two countries (if that they are) which > don't appear > > > > to exhibit distinct language usage. In that case, we are > > > mirroring the > > > > decisions made by ISO 3166/MA, as we claim to do, without > > > consideration > > > > of the linguistic angle. In the case of EU, we are > > > actively seeking an > > > > exception to our rules, which implies we must have a pretty > > > good reason > > > > to do so. > > > > > > > > Thanks to numeric region codes based on UN M.49, we now > > > have lots of way > > > > to indicate pan-European usage: 039, 150, 151, 154, > 155. This has > > > > nothing to do with serving the language-tagging needs of Europe. > > > > > > > > Bureaucratic jargon is NOT a regional variation; as > Frank said, a > > > > variant would be better suited to this. Even Michael > > > Everson's famous > > > > crusade against use of "euro" as a plural was NOT an > > > instance of "EU > > > > usage," but rather a misinterpretation of an EU directive > > > by local Irish > > > > officials and journalists. > > > > > > > > > > > > > -- > > > 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 Nov 14 10:53: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 1IsKYe-0002uF-L8; Wed, 14 Nov 2007 10:53:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKYd-0002tw-Fd for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKYd-0002su-5Q for ltru@ietf.org; Wed, 14 Nov 2007 10:53:39 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKYZ-0008D7-TC for ltru@ietf.org; Wed, 14 Nov 2007 10:53:39 -0500 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.222.3; Wed, 14 Nov 2007 07:53:18 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Wed, 14 Nov 2007 07:53:35 -0800 From: Peter Constable To: John Cowan , Addison Phillips Date: Wed, 14 Nov 2007 07:53:30 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: Acgmx5Q3Bt8Z74QPTrutelMAKyv78QADlilw Message-ID: References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> <20071114140625.GK13650@mercury.ccil.org> In-Reply-To: <20071114140625.GK13650@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: -8.0 (--------) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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="===============2043499910==" Errors-To: ltru-bounces@ietf.org --===============2043499910== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBKb2huIENvd2FuIFttYWlsdG86Y293YW5AY2NpbC5vcmddDQoNCj4gLi4uIHdpdGgg dGhlDQo+IGV4Y2VwdGlvbiBvZiAnVUsnLCB3aGljaCBpcyBhbiBleGFjdCBzeW5vbnltIGZvciB0 aGUgYXNzaWduZWQgY29kZQ0KPiAnR0InLiAgSXQgd291bGQgb25seSBiZSBjb25mdXNpbmcgdG8g YWxsb3cgJ1VLJywgc28gaXQgaXMgZXhjbHVkZWQuDQo+DQo+IFllYWgsIGl0J3MgY2hlcnJ5LXBp Y2tpbmcsIGJ1dCB0aGlzIHBhcnRpY3VsYXIgY2hlcnJ5IGhhcyBhIHdvcm0gaW4gaXQuDQoNCkFj dHVhbGx5LCBpdCdzIG5vdCBjaGVycnkgcGlja2luZzogaXQncyBjb25zaXN0ZW50IHdpdGggdGhl IHB1cnBvc2Ugb2Ygc2VjdGlvbiAzLjQuDQoNCg0KUGV0ZXINCg== --===============2043499910== 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 --===============2043499910==-- From ltru-bounces@ietf.org Wed Nov 14 10:56: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 1IsKb1-0005i4-6Z; Wed, 14 Nov 2007 10:56:07 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKaz-0005hj-J1 for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:56:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKaz-0005hb-9H for ltru@ietf.org; Wed, 14 Nov 2007 10:56:05 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKat-0008Se-I9 for ltru@ietf.org; Wed, 14 Nov 2007 10:56:05 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007460009.msg for ; Wed, 14 Nov 2007 16:00:20 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 14 Nov 2007 15:55:51 +0000 From: "Debbie Garside" To: , References: <002501c82608$beecc140$6601a8c0@DGBP7M81><4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] Re: The "QU" territory/region code Date: Wed, 14 Nov 2007 15:55:02 -0000 Message-ID: <0b0e01c826d6$b7bec9d0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZAAAImWIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Wed, 14 Nov 2007 16:00:20 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=1838036605=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, 14 Nov 2007 16:00:22 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I would find it useful if anyone has any ideas as to how the MA for ISO 3166-1 could change the way they designate some/all exceptionally reserved codes. Obviously, there is a big difference between the reasons for reserving EU and UK, should we ask the MA to differentiate and would this help LTRU in devising this standard? If this is not considered relevant to this forum (co-chairs?) perhaps members could respond offlist with any ideas that could be presented to the MA for consideration. Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 14 November 2007 15:43 > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > Debbie: > > I think it might help for the MA to consider the entire issue > of exceptional reservations. It is effectively providing > something for use in public interchange without fully > endorsing it: that's just going to leave people dealing with > consuming standards in a quandary, just as we're facing now: > they need to interoperate with the publicly-encountered > identifier, but they also need to make normative reference to > the standard. With exceptional reservations, they end up > stuck in a hole with no good way out. > > > Peter > > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: Wednesday, November 14, 2007 2:51 AM > > To: addison@yahoo-inc.com > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > Hi Addison > > > > I am attending the next meeting of the ISO 3166-1 MA on the 31st of > > January > > 2008 on behalf of the BSI. If it would help to have this code > > allocated > > within ISO 3166-1 I would be happy to put forward a proposal to the > > other MA members. When writing any proposal please be > mindful of the > > criteria for inclusion within ISO 3166-1. If you can make the > > proposal fit the inclusion criteria I will present and support it. > > > > Best regards > > > > Debbie Garside > > > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > Sent: 13 November 2007 18:00 > > > To: Doug Ewell > > > Cc: LTRU Working Group > > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > > > What follows is a bit of a rant, albeit with a textual > propose for > > > our draft (remember our draft?). Pardon my dust. :-) > > > > > > Okay, here's my concern: there was, at one time, a very long and > > > not-very-friendly thread on ietf-languages in which folks mostly > > > from the software industry attempted (and failed) to register > > > "es-americas" > > > to identify some kind of Latin American or mid-Atlantic > Spanish. The > > > argument against this (basically) was that there was no > such "real" > > > language, as in "a language recognized by linguistic scholars". > > > There were, however, some who thought they had a quite > real need to > > > identify an artificially created linguistic variant. > > > > > > In RFC 4646 we explicitly acknowledged the potential for > use of the > > UN > > > M.49 code "419" for this purpose. > > > > > > I agree with Doug that one of the UN M.49 codes could be used to > > > identify an artificial linguistic variant for the EU. > > > However, I would be unsurprised if, for example, the EC were to > > > adopt specially controlled language variations for translating EU > > > "stuff" without having to choose particular local variants (or > > > translate into all of them). > > > Thus I can imagine an "fr-EU" or "de-EU" which is both > "not a real > > > language" and also not "fr-FR" or "de-DE". This could also be > > > addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > > > What bothers me is the sense that "we" (there is no "we") know > > > better than the users making the request about their > application's > > > needs. I tend to be a little more promiscuous about supporting > > > variants as a result. There are cases where the thing being > > > requested isn't well thought out. But I am not altogether > happy with > > > the notion that there is only one way to use language > tags or that > > > "there is no such language as X hence no use for this subtag in > > > language tags". We don't actually know that. > > > > > > So: I think it would be just grand if 'EU' were actually > assigned by > > > ISO > > > 3166 and not just reserved. Further, I would support our > > > acknowledging the "exceptional reservation" as "an assignment" in > > > 4646bis. To that end, I'd propose changing Section 2.2.4, > item 2 in > > > the list to read: > > > > > > -- > > > All two-character subtags following the primary subtag, with one > > > exception, were defined in the IANA registry according to the > > > assignments found in [ISO3166-1] (International Organization for > > > Standardization, "ISO 3166-1:1997. Codes for the > representation of > > > names of countries and their subdivisions -- Part 1: > Country codes," > > > 1997.) ("Codes for the representation of names of countries and > > > their subdivisions -- Part 1: Country codes") using the list of > > > alpha-2 country codes, or using assignments subsequently > made by the > > > ISO 3166 maintenance agency or governing standardization > bodies. The > > > one exception is the code 'EU' (European Union), which is > > > "exceptionally reserved" for that purpose (but not "assigned") by > > > ISO 3166. > > > This code > > > is assigned in the registry and is subject to the same > constraints > > > that appear elsewhere in this document as if it were actually > > > assigned by ISO 3166. > > > -- > > > > > > Regards, > > > > > > Addison > > > > > > Doug Ewell wrote: > > > > Martin Duerst wrote: > > > > > > > >> What I'm a bit worried about, and would like to see some > > > confirmation, > > > >> is the following scenario. Assume for one reason or > > > another, some EU > > > >> variant of a language develops, is defined, or what not. > > > > > > > > Back to this in a moment. > > > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > > most suited > > > >> in this case. Is it possible that the ietf-languages list > > > just adds > > > >> this subtag to the registry, or would we have to > convene a WG and > > > >> write another version of what's currently RFC 4646? If the > > > later is > > > >> the case, my preference would be to carefully tweak our > > > texts so that > > > >> we can avoid rechartering just for the potential scenario > > > described > > > >> above. > > > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code > > > > elements "assigned" in ISO 3166-1. RFC 4645 uses the terms > > > > "valid" and "assigned" in populating the initial LSR. > > > > Exceptionally > > > reserved code > > > > elements are not "assigned" according to the ISO 3166/MA > > > definition, and > > > > thus they don't qualify to have region subtags derived > from them > > > > according to our definition. We would need to change the > > > requirements > > > > in 4646bis, and possibly in 4645bis, or else recharter the > > > group to do > > > > this in the future. > > > > > > > > As Addison said, if we really need a region subtag EU, > > > someone needs to > > > > petition ISO 3166/MA to assign the code element. > > > > > > > > This discussion, however, continues to presume a > > > (potential) need for a > > > > region subtag to describe language usage in exactly these > > > countries (as > > > > of 2007-11-03): > > > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > > IT, LT, LU, > > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > > > and all of their dependencies, but NOT neighboring > > > countries such as > > > > Iceland, Norway, Switzerland, or the Baltics. And the > list of EU > > > > countries changes with some regularity -- there are currently > > > > three "official candidate states" and four "potential > candidates" > > > -- making > > > > code instability not merely a possibility, as it is with > > > all country > > > > coding systems, but a certainty. > > > > > > > > This is not at all (IMHO) like the recent addition of BL > > > and MF to 3166 > > > > and the LSR, two countries (if that they are) which > don't appear > > > > to exhibit distinct language usage. In that case, we are > > > mirroring the > > > > decisions made by ISO 3166/MA, as we claim to do, without > > > consideration > > > > of the linguistic angle. In the case of EU, we are > > > actively seeking an > > > > exception to our rules, which implies we must have a pretty > > > good reason > > > > to do so. > > > > > > > > Thanks to numeric region codes based on UN M.49, we now > > > have lots of way > > > > to indicate pan-European usage: 039, 150, 151, 154, > 155. This has > > > > nothing to do with serving the language-tagging needs of Europe. > > > > > > > > Bureaucratic jargon is NOT a regional variation; as > Frank said, a > > > > variant would be better suited to this. Even Michael > > > Everson's famous > > > > crusade against use of "euro" as a plural was NOT an > > > instance of "EU > > > > usage," but rather a misinterpretation of an EU directive > > > by local Irish > > > > officials and journalists. > > > > > > > > > > > > > -- > > > 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 Nov 14 11:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKjv-0003aP-CA; Wed, 14 Nov 2007 11:05:19 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsKju-0003Yv-Dr for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:05:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKju-0003Yf-1b for ltru@ietf.org; Wed, 14 Nov 2007 11:05:18 -0500 Received: from outbound-va3.frontbridge.com ([216.32.180.16] helo=outbound6-va3-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKjs-0002bf-SW for ltru@ietf.org; Wed, 14 Nov 2007 11:05:17 -0500 Received: from outbound6-va3.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound6-va3-R.bigfish.com (Postfix) with ESMTP id 6868D5D8506 for ; Wed, 14 Nov 2007 15:53:46 +0000 (UTC) Received: from mail54-va3-R.bigfish.com (si1-va3 [10.7.14.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound6-va3.bigfish.com (Postfix) with ESMTP id 5CE7D1B5004D for ; Wed, 14 Nov 2007 15:53:46 +0000 (UTC) Received: from mail54-va3 (localhost.localdomain [127.0.0.1]) by mail54-va3-R.bigfish.com (Postfix) with ESMTP id 19ABE1D10828 for ; Wed, 14 Nov 2007 16:02:36 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 192.165.213.23; Service: EHS Received: by mail54-va3 (MessageSwitch) id 119505615644731_24696; Wed, 14 Nov 2007 16:02:36 +0000 (UCT) Received: from lonsmime04.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mail54-va3.bigfish.com (Postfix) with ESMTP id B25BA19D005D for ; Wed, 14 Nov 2007 16:02:35 +0000 (UTC) Received: from eupig2 (unverified [129.1.30.40]) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Wed, 14 Nov 2007 16:02:34 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31408) with ESMTP id <0JRI004BX78AC6@eupig2.dtc.lon.ime.reuters.com>; Wed, 14 Nov 2007 16:02:34 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.1830); Wed, 14 Nov 2007 16:02:32 +0000 Date: Wed, 14 Nov 2007 15:57:34 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: The "QU" territory/region code In-reply-to: <0b0e01c826d6$b7bec9d0$0d00a8c0@CPQ86763045110> To: debbie@ictmarketing.co.uk, petercon@microsoft.com, addison@yahoo-inc.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZAAAImWIAAALs5g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 14 Nov 2007 16:02:32.0749 (UTC) FILETIME=[C3F4E5D0:01C826D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f 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 Indeed, ISO 3166 could create a table of codes which are not = to be assigned because they are widely used synonyms for = assigned codes. This table could start with the entry 'UK'. Misha -----Original Message----- From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] = Sent: 14 November 2007 15:55 To: petercon@microsoft.com; addison@yahoo-inc.com Cc: 'LTRU Working Group' Subject: RE: [Ltru] Re: The "QU" territory/region code I would find it useful if anyone has any ideas as to how the MA for ISO 3166-1 could change the way they designate some/all exceptionally reserved codes. Obviously, there is a big difference between the reasons for reserving EU and UK, should we ask the MA to differentiate and would this help LTRU in devising this standard? If this is not considered relevant to this forum (co-chairs?) perhaps members could respond offlist with any ideas that could be presented to the MA for consideration. Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 14 November 2007 15:43 > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > Debbie: > > I think it might help for the MA to consider the entire issue > of exceptional reservations. It is effectively providing > something for use in public interchange without fully > endorsing it: that's just going to leave people dealing with > consuming standards in a quandary, just as we're facing now: > they need to interoperate with the publicly-encountered > identifier, but they also need to make normative reference to > the standard. With exceptional reservations, they end up > stuck in a hole with no good way out. > > > Peter > > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: Wednesday, November 14, 2007 2:51 AM > > To: addison@yahoo-inc.com > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > Hi Addison > > > > I am attending the next meeting of the ISO 3166-1 MA on the 31st of > > January > > 2008 on behalf of the BSI. If it would help to have this code > > allocated > > within ISO 3166-1 I would be happy to put forward a proposal to the > > other MA members. When writing any proposal please be > mindful of the > > criteria for inclusion within ISO 3166-1. If you can make the > > proposal fit the inclusion criteria I will present and support it. > > > > Best regards > > > > Debbie Garside > > > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > Sent: 13 November 2007 18:00 > > > To: Doug Ewell > > > Cc: LTRU Working Group > > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > > > What follows is a bit of a rant, albeit with a textual > propose for > > > our draft (remember our draft?). Pardon my dust. :-) > > > > > > Okay, here's my concern: there was, at one time, a very long and > > > not-very-friendly thread on ietf-languages in which folks mostly > > > from the software industry attempted (and failed) to register > > > "es-americas" > > > to identify some kind of Latin American or mid-Atlantic > Spanish. The > > > argument against this (basically) was that there was no > such "real" > > > language, as in "a language recognized by linguistic scholars". > > > There were, however, some who thought they had a quite > real need to > > > identify an artificially created linguistic variant. > > > > > > In RFC 4646 we explicitly acknowledged the potential for > use of the > > UN > > > M.49 code "419" for this purpose. > > > > > > I agree with Doug that one of the UN M.49 codes could be used to > > > identify an artificial linguistic variant for the EU. > > > However, I would be unsurprised if, for example, the EC were to > > > adopt specially controlled language variations for translating EU > > > "stuff" without having to choose particular local variants (or > > > translate into all of them). > > > Thus I can imagine an "fr-EU" or "de-EU" which is both > "not a real > > > language" and also not "fr-FR" or "de-DE". This could also be > > > addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > > > What bothers me is the sense that "we" (there is no "we") know > > > better than the users making the request about their > application's > > > needs. I tend to be a little more promiscuous about supporting > > > variants as a result. There are cases where the thing being > > > requested isn't well thought out. But I am not altogether > happy with > > > the notion that there is only one way to use language > tags or that > > > "there is no such language as X hence no use for this subtag in > > > language tags". We don't actually know that. > > > > > > So: I think it would be just grand if 'EU' were actually > assigned by > > > ISO > > > 3166 and not just reserved. Further, I would support our > > > acknowledging the "exceptional reservation" as "an assignment" in > > > 4646bis. To that end, I'd propose changing Section 2.2.4, > item 2 in > > > the list to read: > > > > > > -- > > > All two-character subtags following the primary subtag, with one > > > exception, were defined in the IANA registry according to the > > > assignments found in [ISO3166-1] (International Organization for > > > Standardization, "ISO 3166-1:1997. Codes for the > representation of > > > names of countries and their subdivisions -- Part 1: > Country codes," > > > 1997.) ("Codes for the representation of names of countries and > > > their subdivisions -- Part 1: Country codes") using the list of > > > alpha-2 country codes, or using assignments subsequently > made by the > > > ISO 3166 maintenance agency or governing standardization > bodies. The > > > one exception is the code 'EU' (European Union), which is > > > "exceptionally reserved" for that purpose (but not "assigned") by > > > ISO 3166. > > > This code > > > is assigned in the registry and is subject to the same > constraints > > > that appear elsewhere in this document as if it were actually > > > assigned by ISO 3166. > > > -- > > > > > > Regards, > > > > > > Addison > > > > > > Doug Ewell wrote: > > > > Martin Duerst wrote: > > > > > > > >> What I'm a bit worried about, and would like to see some > > > confirmation, > > > >> is the following scenario. Assume for one reason or > > > another, some EU > > > >> variant of a language develops, is defined, or what not. > > > > > > > > Back to this in a moment. > > > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > > most suited > > > >> in this case. Is it possible that the ietf-languages list > > > just adds > > > >> this subtag to the registry, or would we have to > convene a WG and > > > >> write another version of what's currently RFC 4646? If the > > > later is > > > >> the case, my preference would be to carefully tweak our > > > texts so that > > > >> we can avoid rechartering just for the potential scenario > > > described > > > >> above. > > > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code > > > > elements "assigned" in ISO 3166-1. RFC 4645 uses the terms > > > > "valid" and "assigned" in populating the initial LSR. > > > > Exceptionally > > > reserved code > > > > elements are not "assigned" according to the ISO 3166/MA > > > definition, and > > > > thus they don't qualify to have region subtags derived > from them > > > > according to our definition. We would need to change the > > > requirements > > > > in 4646bis, and possibly in 4645bis, or else recharter the > > > group to do > > > > this in the future. > > > > > > > > As Addison said, if we really need a region subtag EU, > > > someone needs to > > > > petition ISO 3166/MA to assign the code element. > > > > > > > > This discussion, however, continues to presume a > > > (potential) need for a > > > > region subtag to describe language usage in exactly these > > > countries (as > > > > of 2007-11-03): > > > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > > IT, LT, LU, > > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > > > and all of their dependencies, but NOT neighboring > > > countries such as > > > > Iceland, Norway, Switzerland, or the Baltics. And the > list of EU > > > > countries changes with some regularity -- there are currently > > > > three "official candidate states" and four "potential > candidates" > > > -- making > > > > code instability not merely a possibility, as it is with > > > all country > > > > coding systems, but a certainty. > > > > > > > > This is not at all (IMHO) like the recent addition of BL > > > and MF to 3166 > > > > and the LSR, two countries (if that they are) which > don't appear > > > > to exhibit distinct language usage. In that case, we are > > > mirroring the > > > > decisions made by ISO 3166/MA, as we claim to do, without > > > consideration > > > > of the linguistic angle. In the case of EU, we are > > > actively seeking an > > > > exception to our rules, which implies we must have a pretty > > > good reason > > > > to do so. > > > > > > > > Thanks to numeric region codes based on UN M.49, we now > > > have lots of way > > > > to indicate pan-European usage: 039, 150, 151, 154, > 155. This has > > > > nothing to do with serving the language-tagging needs of Europe. > > > > > > > > Bureaucratic jargon is NOT a regional variation; as > Frank said, a > > > > variant would be better suited to this. Even Michael > > > Everson's famous > > > > crusade against use of "euro" as a plural was NOT an > > > instance of "EU > > > > usage," but rather a misinterpretation of an EU directive > > > by local Irish > > > > officials and journalists. > > > > > > > > > > > > > -- > > > 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 This email was sent to you by Reuters, the global news and information comp= any. = To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, = except where the sender specifically states them to be the views of Reuters= Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters= Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South = Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 11:34: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 1IsLC1-0000mR-Pc; Wed, 14 Nov 2007 11:34:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsLC1-0000mB-9F for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:34:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLC0-0000jr-T4 for ltru@ietf.org; Wed, 14 Nov 2007 11:34:20 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsLC0-0006Sp-Jw for ltru@ietf.org; Wed, 14 Nov 2007 11:34:20 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IsLBv-0000jO-ND; Wed, 14 Nov 2007 11:34:15 -0500 Date: Wed, 14 Nov 2007 11:34:15 -0500 To: Peter Constable Subject: Re: [Ltru] trying again: teleconference??? Message-ID: <20071114163415.GN13650@mercury.ccil.org> References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> <6.0.0.20.2.20071114193837.0983c140@localhost> 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: 7bac9cb154eb5790ae3b2913587a40de 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: > B (1400 Pacific) Wed or Thur is OK with me. Slot D (2200 Pacific) is not.) c I can live with B (1700 America/New_York) on Wednesdays. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 13:04: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 1IsMan-0008R0-7G; Wed, 14 Nov 2007 13:04:01 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsMam-0008NO-Cv for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 13:04:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMam-0008M8-12 for ltru@ietf.org; Wed, 14 Nov 2007 13:04:00 -0500 Received: from outbound-va3.frontbridge.com ([216.32.180.16] helo=outbound3-va3-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMal-0008RV-Nx for ltru@ietf.org; Wed, 14 Nov 2007 13:03:59 -0500 Received: from outbound3-va3.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-va3-R.bigfish.com (Postfix) with ESMTP id E80DDE596DD for ; Wed, 14 Nov 2007 17:55:16 +0000 (UTC) Received: from mail34-va3-R.bigfish.com (si1-va3 [10.7.14.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound3-va3.bigfish.com (Postfix) with ESMTP id E6B0F40049 for ; Wed, 14 Nov 2007 17:55:16 +0000 (UTC) Received: from mail34-va3 (localhost.localdomain [127.0.0.1]) by mail34-va3-R.bigfish.com (Postfix) with ESMTP id 1B38BF487C5 for ; Wed, 14 Nov 2007 18:03:59 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail34-va3 (MessageSwitch) id 1195063438324015_23200; Wed, 14 Nov 2007 18:03:58 +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 mail34-va3.bigfish.com (Postfix) with ESMTP id 3C9DE1B5804E for ; Wed, 14 Nov 2007 18:03:58 +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 2007111410035604-375420 ; Wed, 14 Nov 2007 10:03:56 -0800 In-Reply-To: <20071114163415.GN13650@mercury.ccil.org> To: 'LTRU Working Group' Subject: Re: [Ltru] trying again: teleconference??? 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, 14 Nov 2007 10:01:24 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/14/2007 10:01:24, Serialize complete at 11/14/2007 10:01:24, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/14/2007 10:03:56 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/14/2007 10:03:58 AM, Serialize complete at 11/14/2007 10:03:58 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'd like to listen in. B or D would work for me, with a preference for B. Karen Broome John Cowan 11/14/2007 08:34 AM To Peter Constable cc 'LTRU Working Group' Subject Re: [Ltru] trying again: teleconference??? Peter Constable scripsit: > B (1400 Pacific) Wed or Thur is OK with me. Slot D (2200 Pacific) is not.) c I can live with B (1700 America/New_York) on Wednesdays. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 13:13: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 1IsMk2-0005wy-4K; Wed, 14 Nov 2007 13:13:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsMk0-0005wR-2f for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 13:13:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMjz-0005wH-Ow for ltru@ietf.org; Wed, 14 Nov 2007 13:13:31 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsMjw-000753-SJ for ltru@ietf.org; Wed, 14 Nov 2007 13:13:31 -0500 Received: by wa-out-1112.google.com with SMTP id k40so441904wah for ; Wed, 14 Nov 2007 10:13:28 -0800 (PST) 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=vFVUUQzxwkaqNvM86jBycbzeCDG4qXlmipXX3nOAjPY=; b=D6wR4Oqx8HKSUN1JZlCwcM9ZAwRkdGqJgrh+ISz24lHIz8eE2t/w+5ha+EJdMFzMA8fa3tLlplLTd7GgvDtCcvjoEMGrkeOy1VRztkcOEKbuD/MENgkfhaHZPzRkgiX5ACvNJt6sJjMp2L6n6EttBpF/DY/k6L+DvPuzs+ofkiY= 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=YdiW0ZDyNrpYNjc5EjlZ+j/2NIDehAnSq35YzY7d35cL3s5rv2X+sI8U4zj/PLeCp+49pYluSgxHFMGlHcKnazbfBzIlVDM6w45GzuakiL2p2Um+L1pfAnF89Qf2Pxa917Q/4rYhXH08DikfnkpFIwlLhDuyWDCKonVqbrbE4Mo= Received: by 10.114.107.19 with SMTP id f19mr371093wac.1195064008129; Wed, 14 Nov 2007 10:13:28 -0800 (PST) Received: by 10.114.192.9 with HTTP; Wed, 14 Nov 2007 10:13:28 -0800 (PST) Message-ID: <30b660a20711141013x3ff587ebp824a1d6ce7b112ea@mail.gmail.com> Date: Wed, 14 Nov 2007 10:13:28 -0800 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <473B166C.6090208@yahoo-inc.com> MIME-Version: 1.0 References: <473B166C.6090208@yahoo-inc.com> X-Google-Sender-Auth: 2dd077c3726ce8a6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Misha Wolf , 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="===============1969302245==" Errors-To: ltru-bounces@ietf.org --===============1969302245== Content-Type: multipart/alternative; boundary="----=_Part_2369_26058062.1195064008099" ------=_Part_2369_26058062.1195064008099 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIEpvaG4gYXMgd2VsbCwgYW5kIEFkZGlzb24ncyBmdXJ0aGVyIGNvbW1lbnRz LgoKTWFyawoKT24gTm92IDE0LCAyMDA3IDc6MzggQU0sIEFkZGlzb24gUGhpbGxpcHMgPGFkZGlz b25AeWFob28taW5jLmNvbT4gd3JvdGU6Cgo+IEkgYWdyZWUgd2l0aCBKb2huJ3MgcHJvcG9zZWQg d29yZGluZy4KPgo+IEkgYWdyZWUgd2l0aCBNaXNoYSdzIG5vdGUgdG9vLiBXZSBjb3VsZCBqdXN0 IG9taXQgSm9obidzIGxhc3Qgc2VudGVuY2UKPiAodGhlIGV4cGxhbmF0aW9uIGlzIHN1ZmZpY2ll bnRseSBncmF2ZSBvbiBpdHMgb3duKS4KPgo+IEkga2luZCBvZiBsaWtlIHRoZSBmYWN0IHRoYXQg d2UgcG9pbnQgb3V0IHNvbWV3aGVyZSB0aGF0ICdVSycgaXMgbm90IHRoZQo+IHJpZ2h0IGNvZGUg dG8gdXNlIGZvciB0aGUgVUsgaW4gYSBsYW5ndWFnZSB0YWcuCj4KPiBBZGRpc29uCj4KPiBNaXNo YSBXb2xmIHdyb3RlOgo+ID4gSSB3b3VsZCBtYWtlIHRoZSBzdGF0ZW1lbnQgYWJvdXQgZXhjbHVk aW5nICdVSycgc3Ryb25nZXIuICBJIGNhbid0Cj4gPiBwcm9wb3NlIHNwZWNpZmljIHdvcmRzLCBi dXQgdGhlIGluY2x1c2lvbiBvZiAnVUsnIHdvdWxkIGJyZWFrCj4gPiBtYXRjaGluZywgc28gcXVh bGlmaWVzIGZvciBzdHJvbmdlciBsYW5ndWFnZSB0aGFuIGp1c3QgImNvbmZ1c2luZyIuCj4gPgo+ ID4gTWlzaGEKPiA+Cj4gPgo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+IEZyb206 IEpvaG4gQ293YW4gW21haWx0bzpjb3dhbkBjY2lsLm9yZ10KPiA+IFNlbnQ6IDE0IE5vdmVtYmVy IDIwMDcgMTQ6MDYKPiA+IFRvOiBBZGRpc29uIFBoaWxsaXBzCj4gPiBDYzogRG91ZyBFd2VsbDsg TFRSVSBXb3JraW5nIEdyb3VwCj4gPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBUaGUgIlFVIiB0 ZXJyaXRvcnkvcmVnaW9uIGNvZGUKPiA+Cj4gPiBBZGRpc29uIFBoaWxsaXBzIHNjcmlwc2l0Ogo+ ID4KPiA+PiBTbzogSSB0aGluayBpdCB3b3VsZCBiZSBqdXN0IGdyYW5kIGlmICdFVScgd2VyZSBh Y3R1YWxseSBhc3NpZ25lZCBieQo+IElTTwo+ID4+IDMxNjYgYW5kIG5vdCBqdXN0IHJlc2VydmVk Lgo+ID4KPiA+IEFzIEkgc2FpZCwgSSBkb24ndCB0aGluayB0aGF0J3MgcHJhY3RpY2FsLgo+ID4K PiA+PiBJJ2QgcHJvcG9zZSBjaGFuZ2luZyBTZWN0aW9uIDIuMi40LCBpdGVtIDIgaW4gdGhlIGxp c3QgdG8gcmVhZDoKPiA+Cj4gPiBIZXJlJ3MgbXkgcHJvcG9zZWQgdmVyc2lvbjoKPiA+Cj4gPiBB bGwgdHdvLWNoYXJhY3RlciBzdWJ0YWdzIGZvbGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcgd2Vy ZSBkZWZpbmVkIGluCj4gPiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2ln bm1lbnRzIGZvdW5kIGluIFtJU08zMTY24oCRMV0KPiA+IChJbnRlcm5hdGlvbmFsIE9yZ2FuaXph dGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPIDMxNjYtMToxOTk3LiBDb2Rlcwo+ID4gZm9y IHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBjb3VudHJpZXMgYW5kIHRoZWlyIHN1YmRp dmlzaW9ucyAtLQo+ID4gUGFydCAxOiBDb3VudHJ5IGNvZGVzLCIgMTk5Ny4pICAoIkNvZGVzIGZv ciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMKPiA+IG9mIGNvdW50cmllcyBhbmQgdGhlaXIg c3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeSBjb2RlcyIpIHVzaW5nIHRoZQo+ID4gbGlz dCBvZiBhbHBoYS0yIGNvdW50cnkgY29kZXMsIG9yIHVzaW5nIGFzc2lnbm1lbnRzIHN1YnNlcXVl bnRseSBtYWRlIGJ5Cj4gPiB0aGUgSVNPIDMxNjYgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVy bmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLiBJbgo+ID4gYWRkaXRpb24sIHRoZSBjb2RlcyB0 aGF0IGFyZSAiZXhjZXB0aW9uYWxseSByZXNlcnZlZCIgKGFzIG9wcG9zZWQgdG8KPiA+ICJhc3Np Z25lZCIpIGluIElTTyAzMTY2LTEgd2VyZSBhbHNvIGRlZmluZWQgaW4gdGhlIHJlZ2lzdHJ5LCB3 aXRoIHRoZQo+ID4gZXhjZXB0aW9uIG9mICdVSycsIHdoaWNoIGlzIGFuIGV4YWN0IHN5bm9ueW0g Zm9yIHRoZSBhc3NpZ25lZCBjb2RlCj4gPiAnR0InLiAgSXQgd291bGQgb25seSBiZSBjb25mdXNp bmcgdG8gYWxsb3cgJ1VLJywgc28gaXQgaXMgZXhjbHVkZWQuCj4gPgo+ID4gWWVhaCwgaXQncyBj aGVycnktcGlja2luZywgYnV0IHRoaXMgcGFydGljdWxhciBjaGVycnkgaGFzIGEgd29ybSBpbiBp dC4KPiA+Cj4gPgo+ID4KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBMdHJ1IG1haWxpbmcgbGlzdAo+ ID4gTHRydUBpZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHRydQo+Cj4KPiAtLQo+IEFkZGlzb24gUGhpbGxpcHMKPiBHbG9iYWxpemF0aW9uIEFyY2hp dGVjdCAtLSBZYWhvbyEgSW5jLgo+IENoYWlyIC0tIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBD b3JlIFdHCj4KPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBhbiBhcmNoaXRlY3R1cmUuCj4gSXQg aXMgbm90IGEgZmVhdHVyZS4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiBMdHJ1IG1haWxpbmcgbGlzdAo+IEx0cnVAaWV0Zi5vcmcKPiBodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1Cj4KCgoKLS0gCk1hcmsK ------=_Part_2369_26058062.1195064008099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIEpvaG4gYXMgd2VsbCwgYW5kIEFkZGlzb24mIzM5O3MgZnVydGhlciBjb21t ZW50cy48YnI+PGJyPk1hcms8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBOb3Yg MTQsIDIwMDcgNzozOCBBTSwgQWRkaXNvbiBQaGlsbGlwcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFk ZGlzb25AeWFob28taW5jLmNvbSI+YWRkaXNvbkB5YWhvby1pbmMuY29tPC9hPiZndDsgd3JvdGU6 Cjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDog MXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsg cGFkZGluZy1sZWZ0OiAxZXg7Ij5JIGFncmVlIHdpdGggSm9obiYjMzk7cyBwcm9wb3NlZCB3b3Jk aW5nLjxicj48YnI+SSBhZ3JlZSB3aXRoIE1pc2hhJiMzOTtzIG5vdGUgdG9vLiBXZSBjb3VsZCBq dXN0IG9taXQgSm9obiYjMzk7cyBsYXN0IHNlbnRlbmNlCjxicj4odGhlIGV4cGxhbmF0aW9uIGlz IHN1ZmZpY2llbnRseSBncmF2ZSBvbiBpdHMgb3duKS48YnI+PGJyPkkga2luZCBvZiBsaWtlIHRo ZSBmYWN0IHRoYXQgd2UgcG9pbnQgb3V0IHNvbWV3aGVyZSB0aGF0ICYjMzk7VUsmIzM5OyBpcyBu b3QgdGhlPGJyPnJpZ2h0IGNvZGUgdG8gdXNlIGZvciB0aGUgVUsgaW4gYSBsYW5ndWFnZSB0YWcu PGJyPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+CkFkZGlzb248YnI+PC9mb250PjxkaXY+PGRp dj48L2Rpdj48ZGl2IGNsYXNzPSJXajNDN2MiPjxicj5NaXNoYSBXb2xmIHdyb3RlOjxicj4mZ3Q7 IEkgd291bGQgbWFrZSB0aGUgc3RhdGVtZW50IGFib3V0IGV4Y2x1ZGluZyAmIzM5O1VLJiMzOTsg c3Ryb25nZXIuICZuYnNwO0kgY2FuJiMzOTt0PGJyPiZndDsgcHJvcG9zZSBzcGVjaWZpYyB3b3Jk cywgYnV0IHRoZSBpbmNsdXNpb24gb2YgJiMzOTtVSyYjMzk7IHdvdWxkIGJyZWFrCjxicj4mZ3Q7 IG1hdGNoaW5nLCBzbyBxdWFsaWZpZXMgZm9yIHN0cm9uZ2VyIGxhbmd1YWdlIHRoYW4ganVzdCAm cXVvdDtjb25mdXNpbmcmcXVvdDsuPGJyPiZndDs8YnI+Jmd0OyBNaXNoYTxicj4mZ3Q7PGJyPiZn dDs8YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IEpvaG4g Q293YW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86Y293YW5AY2NpbC5vcmciPgpjb3dhbkBjY2ls Lm9yZzwvYT5dPGJyPiZndDsgU2VudDogMTQgTm92ZW1iZXIgMjAwNyAxNDowNjxicj4mZ3Q7IFRv OiBBZGRpc29uIFBoaWxsaXBzPGJyPiZndDsgQ2M6IERvdWcgRXdlbGw7IExUUlUgV29ya2luZyBH cm91cDxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbTHRydV0gUmU6IFRoZSAmcXVvdDtRVSZxdW90OyB0 ZXJyaXRvcnkvcmVnaW9uIGNvZGU8YnI+Jmd0Ozxicj4mZ3Q7IEFkZGlzb24gUGhpbGxpcHMgc2Ny aXBzaXQ6Cjxicj4mZ3Q7PGJyPiZndDsmZ3Q7IFNvOiBJIHRoaW5rIGl0IHdvdWxkIGJlIGp1c3Qg Z3JhbmQgaWYgJiMzOTtFVSYjMzk7IHdlcmUgYWN0dWFsbHkgYXNzaWduZWQgYnkgSVNPPGJyPiZn dDsmZ3Q7IDMxNjYgYW5kIG5vdCBqdXN0IHJlc2VydmVkLjxicj4mZ3Q7PGJyPiZndDsgQXMgSSBz YWlkLCBJIGRvbiYjMzk7dCB0aGluayB0aGF0JiMzOTtzIHByYWN0aWNhbC48YnI+Jmd0Ozxicj4m Z3Q7Jmd0OyBJJiMzOTtkIHByb3Bvc2UgY2hhbmdpbmcgU2VjdGlvbiAKMi4yLjQsIGl0ZW0gMiBp biB0aGUgbGlzdCB0byByZWFkOjxicj4mZ3Q7PGJyPiZndDsgSGVyZSYjMzk7cyBteSBwcm9wb3Nl ZCB2ZXJzaW9uOjxicj4mZ3Q7PGJyPiZndDsgQWxsIHR3by1jaGFyYWN0ZXIgc3VidGFncyBmb2xs b3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIHdlcmUgZGVmaW5lZCBpbjxicj4mZ3Q7IHRoZSBJQU5B IHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQgaW4gW0lTTzMxNjbi gJExXQo8YnI+Jmd0OyAoSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXph dGlvbiwgIklTTyAzMTY2LTE6MTk5Ny4gQ29kZXM8YnI+Jmd0OyBmb3IgdGhlIHJlcHJlc2VudGF0 aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcyBhbmQgdGhlaXIgc3ViZGl2aXNpb25zIC0tPGJyPiZn dDsgUGFydCAxOiBDb3VudHJ5IGNvZGVzLCIgMTk5Ny4pICZuYnNwOygmcXVvdDtDb2RlcyBmb3Ig dGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzCjxicj4mZ3Q7IG9mIGNvdW50cmllcyBhbmQgdGhl aXIgc3ViZGl2aXNpb25zIC0tIFBhcnQgMTogQ291bnRyeSBjb2RlcyZxdW90OykgdXNpbmcgdGhl PGJyPiZndDsgbGlzdCBvZiBhbHBoYS0yIGNvdW50cnkgY29kZXMsIG9yIHVzaW5nIGFzc2lnbm1l bnRzIHN1YnNlcXVlbnRseSBtYWRlIGJ5PGJyPiZndDsgdGhlIElTTyAzMTY2IG1haW50ZW5hbmNl IGFnZW5jeSBvciBnb3Zlcm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4gSW4KPGJyPiZndDsg YWRkaXRpb24sIHRoZSBjb2RlcyB0aGF0IGFyZSAmcXVvdDtleGNlcHRpb25hbGx5IHJlc2VydmVk JnF1b3Q7IChhcyBvcHBvc2VkIHRvPGJyPiZndDsgJnF1b3Q7YXNzaWduZWQmcXVvdDspIGluIElT TyAzMTY2LTEgd2VyZSBhbHNvIGRlZmluZWQgaW4gdGhlIHJlZ2lzdHJ5LCB3aXRoIHRoZTxicj4m Z3Q7IGV4Y2VwdGlvbiBvZiAmIzM5O1VLJiMzOTssIHdoaWNoIGlzIGFuIGV4YWN0IHN5bm9ueW0g Zm9yIHRoZSBhc3NpZ25lZCBjb2RlCjxicj4mZ3Q7ICYjMzk7R0ImIzM5Oy4gJm5ic3A7SXQgd291 bGQgb25seSBiZSBjb25mdXNpbmcgdG8gYWxsb3cgJiMzOTtVSyYjMzk7LCBzbyBpdCBpcyBleGNs dWRlZC48YnI+Jmd0Ozxicj4mZ3Q7IFllYWgsIGl0JiMzOTtzIGNoZXJyeS1waWNraW5nLCBidXQg dGhpcyBwYXJ0aWN1bGFyIGNoZXJyeSBoYXMgYSB3b3JtIGluIGl0Ljxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0Ozxicj48L2Rpdj48L2Rpdj4KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+PGRpdiBjbGFz cz0iSWgyRTNkIj4mZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+Jmd0OyBMdHJ1IG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9 Im1haWx0bzpMdHJ1QGlldGYub3JnIj4KTHRydUBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48YnI+ PGJyPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJJaDJFM2QiPi0tPGJyPkFkZGlzb24gUGhpbGxpcHM8 YnI+R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QgLS0gWWFob28hIEluYy4KPGJyPkNoYWlyIC0tIFcz QyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdHPGJyPjxicj5JbnRlcm5hdGlvbmFsaXphdGlv biBpcyBhbiBhcmNoaXRlY3R1cmUuPGJyPkl0IGlzIG5vdCBhIGZlYXR1cmUuPGJyPjxicj48YnI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+PC9kaXY+ PGRpdj48ZGl2PjwvZGl2PjxkaXYgY2xhc3M9IldqM0M3YyI+Ckx0cnUgbWFpbGluZyBsaXN0PGJy PjxhIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnPC9hPjxicj48YSBo cmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydTwvYT48 YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pgo8YnI+PGJyIGNsZWFyPSJhbGwiPjxi cj4tLSA8YnI+TWFyawo= ------=_Part_2369_26058062.1195064008099-- --===============1969302245== 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 --===============1969302245==-- From ltru-bounces@ietf.org Wed Nov 14 13:14: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 1IsMlK-0007mu-7P; Wed, 14 Nov 2007 13:14:54 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsMlI-0007l7-In for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 13:14:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMlI-0007gk-3e for ltru@ietf.org; Wed, 14 Nov 2007 13:14:52 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsMlH-0000fh-8P for ltru@ietf.org; Wed, 14 Nov 2007 13:14:51 -0500 Received: by wa-out-1112.google.com with SMTP id k40so442497wah for ; Wed, 14 Nov 2007 10:14:50 -0800 (PST) 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=kWP0mptNx0FlcCdgR4OUIId37Yc9vyeVf/PIdodR5OQ=; b=RkWLaNBdzO0AecYX+R6PQsSAXmWXct8Y6lOETPw3jHJxE3N0EQFoVI4cHwVrnIO0n8lm3H2Igz+QNDCrmPeaTYtb5neypm8ldGCXnQN1PmvSIpj7Y4F9VnPj50WyEfSB05guXYwn3e+xuLSmMlM9hmMfIbr2vz/dJUAfsXaZWG0= 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=Y9/eoCE+fnXFLOlTC90ZhoylpLCPZAMl53h7Vp/fG2piN8XWmxh4/R6U2iOH2PFpQagiiqo9FI7Ve8ukbRfZ0BtBcaMtcmlv2z1t5WInAlxi5CBabQ+PW8XtgodvKW3kBmQmD+ZlTyc0x5JCtYCJc+6LfTWHX9FhtUtJOVq/svM= Received: by 10.114.134.1 with SMTP id h1mr158255wad.1195064090226; Wed, 14 Nov 2007 10:14:50 -0800 (PST) Received: by 10.114.192.9 with HTTP; Wed, 14 Nov 2007 10:14:50 -0800 (PST) Message-ID: <30b660a20711141014g26870387k1970ae2f27914fc4@mail.gmail.com> Date: Wed, 14 Nov 2007 10:14:50 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] trying again: teleconference??? In-Reply-To: MIME-Version: 1.0 References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> <6.0.0.20.2.20071114193837.0983c140@localhost> X-Google-Sender-Auth: 209ba53a5156b2f9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0388096909==" Errors-To: ltru-bounces@ietf.org --===============0388096909== Content-Type: multipart/alternative; boundary="----=_Part_2389_442191.1195064090186" ------=_Part_2389_442191.1195064090186 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That works for me too. On Nov 14, 2007 7:45 AM, Peter Constable wrote: > B (1400 Pacific) Wed or Thur is OK with me. Slot D (2200 Pacific) is not.) > > > Peter > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: Wednesday, November 14, 2007 2:47 AM > > To: Addison Phillips > > Cc: 'LTRU Working Group' > > Subject: Re: [Ltru] trying again: teleconference??? > > > > At 01:23 07/11/14, Addison Phillips wrote: > > >I'm not suggesting we "just announce" something. Previously on this > > list there was a discussion of possible times. > > > > Yes. I'd just hoped that we don't have to start from scratch again. > > > > >Normally, it is up to the chair(s) of the group to coordinate > > scheduling of activities such as this, etc. and make the final > > announcement. > > > > Well, except that the IETF doesn't usually do teleconferences :-(. > > > > >In any case, I'm happy to suggest some times (I just did this for W3C- > > I18N-Core, so I can be eco-friendly and recycle the bits: see below), > > but you or Randy should take ownership of gathering input and selecting > > the date/time. > > > > Okay, if I take ownership (and assuming that includes participation), > > then I'll first have to throw out (A) and (C), because in this timeslot, > > maybe my body could participate, but my brain for sure won't be awake. > > > > > > >Here are some optional *times*. I can do any of these on either > > Wednesdays or Thursdays. Note that London is currently effectively the > > same as GMT. > > > > > > >(B) > > > > > >14:00 Pacific > > >22:00 London > > >09:00 Sydney (next day) > > >07:00 Tokyo (next day) > > >17:00 Toronto > > > > >(D) > > > > > >22:00 Pacific (previous day) > > >06:00 London > > >17:00 Sydney > > >15:00 Tokyo > > >01:00 Toronto > > > > Can everybody please annouce their preferences? You can send mail > > directly to me > > if you don't want to bother the whole list. > > > > 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 > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_2389_442191.1195064090186 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That works for me too.

On Nov 14, 2007 7:45 AM, Peter Constable <petercon@microsoft.com> wrote:
B (1400 Pacific) Wed or Thur is OK with me. Slot D (2200 Pacific) is not.)


Peter

> -----Original Message-----
> From: Martin Duerst [mailto: duerst@it.aoyama.ac.jp]
> Sent: Wednesday, November 14, 2007 2:47 AM
> To: Addison Phillips
> Cc: 'LTRU Working Group'
> Subject: Re: [Ltru] trying again: teleconference???
>
> At 01:23 07/11/14, Addison Phillips wrote:
> >I'm not suggesting we "just announce" something. Previously on this
> list there was a discussion of possible times.
>
> Yes. I'd just hoped that we don't have to start from scratch again.
>
> >Normally, it is up to the chair(s) of the group to coordinate
> scheduling of activities such as this, etc. and make the final
> announcement.
>
> Well, except that the IETF doesn't usually do teleconferences :-(.
>
> >In any case, I'm happy to suggest some times (I just did this for W3C-
> I18N-Core, so I can be eco-friendly and recycle the bits: see below),
> but you or Randy should take ownership of gathering input and selecting
> the date/time.
>
> Okay, if I take ownership (and assuming that includes participation),
> then I'll first have to throw out (A) and (C), because in this timeslot,
> maybe my body could participate, but my brain for sure won't be awake.
>
>
> >Here are some optional *times*. I can do any of these on either
> Wednesdays or Thursdays. Note that London is currently effectively the
> same as GMT.
>
>
> >(B)
> >
> >14:00 Pacific
> >22:00 London
> >09:00 Sydney (next day)
> >07:00 Tokyo (next day)
> >17:00 Toronto
>
> >(D)
> >
> >22:00 Pacific (previous day)
> >06:00 London
> >17:00 Sydney
> >15:00 Tokyo
> >01:00 Toronto
>
> Can everybody please annouce their preferences? You can send mail
> directly to me
> if you don't want to bother the whole list.
>
> 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


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



--
Mark ------=_Part_2389_442191.1195064090186-- --===============0388096909== 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 --===============0388096909==-- From ltru-bounces@ietf.org Wed Nov 14 16:47: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 1IsQ4w-0006Ov-6E; Wed, 14 Nov 2007 16:47:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsQ4t-0006ME-GX for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:47:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQ4s-0006LN-T5 for ltru@ietf.org; Wed, 14 Nov 2007 16:47:19 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsQ4s-0004Jl-87 for ltru@ietf.org; Wed, 14 Nov 2007 16:47:18 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IsQ4l-00018d-VU; Wed, 14 Nov 2007 16:47:12 -0500 Date: Wed, 14 Nov 2007 16:47:11 -0500 To: Debbie Garside Subject: Re: [Ltru] Re: The "QU" territory/region code Message-ID: <20071114214711.GC12525@mercury.ccil.org> References: <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> <0b0e01c826d6$b7bec9d0$0d00a8c0@CPQ86763045110> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b0e01c826d6$b7bec9d0$0d00a8c0@CPQ86763045110> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > I would find it useful if anyone has any ideas as to how the MA for > ISO 3166-1 could change the way they designate some/all exceptionally > reserved codes. Obviously, there is a big difference between the > reasons for reserving EU and UK, should we ask the MA to differentiate > and would this help LTRU in devising this standard? If this is not > considered relevant to this forum (co-chairs?) perhaps members could > respond offlist with any ideas that could be presented to the MA for > consideration. It's important to realize that ISO has tied the 3166/MA's hands pretty thoroughly -- that's what it means to be a mere Maintenance Agency, rather than a Registration Authority, which is much more autonomous. It can't assign a code element to anything except the entities that UNSD (the United Nations Statistics Division) calls a "country or area". Since UNSD is chiefly concerned with national and supranational economic and social statistics, it simply doesn't care very much about the little islands (okay, Ceuta and Melilla are Spanish "islands" on the mainland of Africa) and isn't likely to assign code elements for them. Nor will it assign two code elements to the U.K. Assigning a code to the E.U. looks plausible except that (as many have pointed out) the composition of the E.U. changes over time, making historical comparisons meaningless. (When the ancestor of the E.U. began in 1951, it had only six members; partial precursors go back to 1948 (three members) and 1921 (two members). Now there are 27, with seven more in candidate or potential-candidate status.) So none of these code elements are going to get "assigned" status. "Exceptionally reserved" is the best we can do, and if we want them we must live with that. The questions are: 1) Can we live without them? 2) Can we live with them? 3) If we are going to live with them, what exceptions are needed? -- De plichten van een docent zijn divers, John Cowan die van het gehoor ook. cowan@ccil.org --Edsger Dijkstra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 18:00: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 1IsRDb-0002Kh-Fb; Wed, 14 Nov 2007 18:00:23 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsRDa-0002IH-MJ for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 18:00:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRDa-0002HL-Bn for ltru@ietf.org; Wed, 14 Nov 2007 18:00:22 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsRDa-00071O-20 for ltru@ietf.org; Wed, 14 Nov 2007 18:00:22 -0500 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.222.3; Wed, 14 Nov 2007 15:00:03 -0800 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; Wed, 14 Nov 2007 15:00:20 -0800 From: Peter Constable To: John Cowan , Debbie Garside Date: Wed, 14 Nov 2007 15:00:19 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgnB+6MEF0NeBN/QUmeRJe9SjbHkgACe4wA Message-ID: References: <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> <0b0e01c826d6$b7bec9d0$0d00a8c0@CPQ86763045110> <20071114214711.GC12525@mercury.ccil.org> In-Reply-To: <20071114214711.GC12525@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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan [mailto:cowan@ccil.org] > It's important to realize that ISO has tied the 3166/MA's hands pretty > thoroughly -- that's what it means to be a mere Maintenance Agency, > rather than a Registration Authority, which is much more autonomous. True, but the MA can still report complaints and issues back to TC46. At le= ast from my experience, trying to get feedback through the US TAG into TC46= is a dead end. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 14 19: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 1IsSIp-0007er-Hb; Wed, 14 Nov 2007 19:09:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsSIo-0007ej-Ki for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 19:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsSIo-0007dt-5m; Wed, 14 Nov 2007 19:09:50 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsSIb-00060I-5Z; Wed, 14 Nov 2007 19:09:50 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAF09Y23002223; Wed, 14 Nov 2007 16:09:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject:content-type; b=1Vw3I7/UxFIkUqONNaoueQiJXmW2DbEfGRReJttTqL8VOp0yUgPIJFlS4sTC+ZjC Message-ID: <473B8E3D.1060209@yahoo-inc.com> Date: Wed, 14 Nov 2007 16:09:33 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="------------030203010202090500000406" X-Spam-Score: -14.7 (--------------) X-Scan-Signature: b61b0f4d0eac8b9fb6e57153c9c61082 Cc: 'LTRU Working Group' Subject: [Ltru] SUBMISSION: draft-ietf-ltru-4646bis-09 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --------------030203010202090500000406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear Editors, Please find attached in text format draft-09 of draft-ietf-ltru-4646bis. Best Regards (for the editors), Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. --------------030203010202090500000406 Content-Type: text/plain; name="draft-ietf-ltru-4646bis-09.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ltru-4646bis-09.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWFob28hIEluYy4NCk9ic29sZXRl czogNDY0NiAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4g RGF2aXMsIEVkLg0KSW50ZW5kZWQgc3RhdHVzOiBCZXN0IEN1cnJlbnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgR29vZ2xlDQpQcmFjdGljZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMTQsIDIwMDcNCkV4 cGlyZXM6IE1heSAxNywgMjAwOA0KDQoNCiAgICAgICAgICAgICAgICAgICAgIFRhZ3MgZm9y IElkZW50aWZ5aW5nIExhbmd1YWdlcw0KICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1p ZXRmLWx0cnUtNDY0NmJpcy0wOQ0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1 Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0 aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3 aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Ns b3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2ls bCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5 Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywg YW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBE cmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRp bWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJh ZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFp ZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFk b3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl IG9uIE1heSAxNywgMjAwOC4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQg KEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAg ICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHN0cnVjdHVyZSwgY29udGVudCwg Y29uc3RydWN0aW9uLCBhbmQNCiAgIHNlbWFudGljcyBvZiBsYW5ndWFnZSB0YWdzIGZvciB1 c2UgaW4gY2FzZXMgd2hlcmUgaXQgaXMgZGVzaXJhYmxlIHRvDQogICBpbmRpY2F0ZSB0aGUg bGFuZ3VhZ2UgdXNlZCBpbiBhbiBpbmZvcm1hdGlvbiBvYmplY3QuICBJdCBhbHNvDQogICBk ZXNjcmliZXMgaG93IHRvIHJlZ2lzdGVyIHZhbHVlcyBmb3IgdXNlIGluIGxhbmd1YWdlIHRh Z3MgYW5kIHRoZQ0KICAgY3JlYXRpb24gb2YgdXNlci1kZWZpbmVkIGV4dGVuc2lvbnMgZm9y IHByaXZhdGUgaW50ZXJjaGFuZ2UuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4g IEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0DQogICAyLiAgVGhlIExhbmd1YWdlIFRhZyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi4xLiAgU3ludGF4IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0K ICAgICAyLjIuICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQgSW50ZXJwcmV0YXRpb24g LiAuIC4gLiAuIC4gLiAuICA4DQogICAgICAgMi4yLjEuICBQcmltYXJ5IExhbmd1YWdlIFN1 YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgICAyLjIuMi4g IEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMQ0KICAgICAgIDIuMi4zLiAgU2NyaXB0IFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgICAgMi4yLjQuICBSZWdpb24gU3VidGFn ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAgICAy LjIuNS4gIFZhcmlhbnQgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNQ0KICAgICAgIDIuMi42LiAgRXh0ZW5zaW9uIFN1YnRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAgICAgMi4yLjcuICBQcml2YXRl IFVzZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAg ICAgICAyLjIuOC4gIEdyYW5kZmF0aGVyZWQgUmVnaXN0cmF0aW9ucyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxOA0KICAgICAgIDIuMi45LiAgQ2xhc3NlcyBvZiBDb25mb3JtYW5j ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAzLiAgUmVnaXN0cnkg Rm9ybWF0IGFuZCBNYWludGVuYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjANCiAgICAgMy4xLiAgRm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdp c3RyeSAgLiAuIC4gLiAuIC4gLiAyMA0KICAgICAgIDMuMS4xLiAgRmlsZSBGb3JtYXQgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICAgICAgMy4x LjIuICBSZWNvcmQgRGVmaW5pdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjENCiAgICAgICAzLjEuMy4gIFN1YnRhZyBhbmQgVGFnIEZpZWxkcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNA0KICAgICAgIDMuMS40LiAgRGVzY3JpcHRp b24gRmllbGQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0DQogICAg ICAgMy4xLjUuICBEZXByZWNhdGVkIEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjUNCiAgICAgICAzLjEuNi4gIFByZWZlcnJlZC1WYWx1ZSBGaWVsZCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0KICAgICAgIDMuMS43LiAgUHJl Zml4IEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2 DQogICAgICAgMy4xLjguICBTdXBwcmVzcy1TY3JpcHQgRmllbGQgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjcNCiAgICAgICAzLjEuOS4gIE1hY3JvbGFuZ3VhZ2UgRmll bGQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNw0KICAgICAgIDMuMS4x MC4gQ29tbWVudHMgRmllbGQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDI4DQogICAgIDMuMi4gIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgICAgMy4zLiAgTWFpbnRlbmFuY2Ugb2Yg dGhlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQ0KICAgICAz LjQuICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI5DQogICAgIDMuNS4gIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUgZm9yIFN1 YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzQNCiAgICAgMy42LiAgUG9zc2liaWxp dGllcyBmb3IgUmVnaXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOA0K ICAgICAzLjcuICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIFJlZ2lzdHJ5IC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDQwDQogICAgIDMuOC4gIFVwZGF0ZSBvZiB0aGUgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDMNCiAgIDQuICBGb3JtYXRp b24gYW5kIFByb2Nlc3Npbmcgb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4g LiA0NA0KICAgICA0LjEuICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0DQogICAgIDQuMi4gIE1lYW5pbmcgb2YgdGhlIExh bmd1YWdlIFRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDgNCiAgICAgNC4z LiAgTGVuZ3RoIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1MA0KICAgICAgIDQuMy4xLiAgV29ya2luZyB3aXRoIExpbWl0ZWQgQnVmZmVy IFNpemVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2Ug Ml0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICAgICA0LjMuMi4gIFRydW5jYXRp b24gb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Mg0KICAg ICA0LjQuICBDYW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDUyDQogICAgIDQuNS4gIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRl IFVzZSBTdWJ0YWdzIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTQNCiAgIDUuICBJQU5BIENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1 Ng0KICAgICA1LjEuICBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDU2DQogICAgIDUuMi4gIEV4dGVuc2lvbnMgUmVnaXN0cnkg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTcNCiAgIDYuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1OA0KICAgNy4gIENoYXJhY3RlciBTZXQgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5DQogICA4LiAgQ2hhbmdlcyBmcm9tIFJGQyA0 NjQ2ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjANCiAgIDku ICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA2NA0KICAgICA5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY0DQogICAgIDkuMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjUN CiAgIEFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA2Nw0KICAgQXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1 YWdlIFRhZ3MgKEluZm9ybWF0aXZlKSAuIC4gLiAuIC4gLiAuIDY4DQogICBBcHBlbmRpeCBD LiAgRXhhbXBsZXMgb2YgUmVnaXN0cmF0aW9uIEZvcm1zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNzENCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3Mw0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFu ZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDc0DQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDgg ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0K MS4gIEludHJvZHVjdGlvbg0KDQogICBIdW1hbiBiZWluZ3Mgb24gb3VyIHBsYW5ldCBoYXZl LCBwYXN0IGFuZCBwcmVzZW50LCB1c2VkIGEgbnVtYmVyIG9mDQogICBsYW5ndWFnZXMuICBU aGVyZSBhcmUgbWFueSByZWFzb25zIHdoeSBvbmUgd291bGQgd2FudCB0byBpZGVudGlmeSB0 aGUNCiAgIGxhbmd1YWdlIHVzZWQgd2hlbiBwcmVzZW50aW5nIG9yIHJlcXVlc3RpbmcgaW5m b3JtYXRpb24uDQoNCiAgIEEgdXNlcidzIGxhbmd1YWdlIHByZWZlcmVuY2VzIG9mdGVuIG5l ZWQgdG8gYmUgaWRlbnRpZmllZCBzbyB0aGF0DQogICBhcHByb3ByaWF0ZSBwcm9jZXNzaW5n IGNhbiBiZSBhcHBsaWVkLiAgRm9yIGV4YW1wbGUsIHRoZSB1c2VyJ3MNCiAgIGxhbmd1YWdl IHByZWZlcmVuY2VzIGluIGEgV2ViIGJyb3dzZXIgY2FuIGJlIHVzZWQgdG8gc2VsZWN0IFdl YiBwYWdlcw0KICAgYXBwcm9wcmlhdGVseS4gIExhbmd1YWdlIHByZWZlcmVuY2VzIGNhbiBh bHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nDQogICB0b29scyAoc3VjaCBhcyBkaWN0aW9u YXJpZXMpIHRvIGFzc2lzdCBpbiB0aGUgcHJvY2Vzc2luZyBvcg0KICAgdW5kZXJzdGFuZGlu ZyBvZiBjb250ZW50IGluIGRpZmZlcmVudCBsYW5ndWFnZXMuDQoNCiAgIEluIGFkZGl0aW9u LCBrbm93bGVkZ2UgYWJvdXQgdGhlIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdXNlZCBieSBzb21l DQogICBwaWVjZSBvZiBpbmZvcm1hdGlvbiBjb250ZW50IG1pZ2h0IGJlIHVzZWZ1bCBvciBl dmVuIHJlcXVpcmVkIGJ5IHNvbWUNCiAgIHR5cGVzIG9mIHByb2Nlc3Npbmc7IGZvciBleGFt cGxlLCBzcGVsbC1jaGVja2luZywgY29tcHV0ZXItDQogICBzeW50aGVzaXplZCBzcGVlY2gs IEJyYWlsbGUgdHJhbnNjcmlwdGlvbiwgb3IgaGlnaC1xdWFsaXR5IHByaW50DQogICByZW5k ZXJpbmdzLg0KDQogICBPbmUgbWVhbnMgb2YgaW5kaWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNl ZCBpcyBieSBsYWJlbGluZyB0aGUNCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhbiBp ZGVudGlmaWVyIG9yICJ0YWciLiAgVGhlc2UgdGFncyBjYW4gYmUNCiAgIHVzZWQgdG8gc3Bl Y2lmeSB1c2VyIHByZWZlcmVuY2VzIHdoZW4gc2VsZWN0aW5nIGluZm9ybWF0aW9uIGNvbnRl bnQsDQogICBvciBmb3IgbGFiZWxpbmcgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRl bnQgYW5kIGFzc29jaWF0ZWQNCiAgIHJlc291cmNlcy4NCg0KICAgVGFncyBjYW4gYWxzbyBi ZSB1c2VkIHRvIGluZGljYXRlIGFkZGl0aW9uYWwgbGFuZ3VhZ2UgYXR0cmlidXRlcyBvZg0K ICAgY29udGVudC4gIEZvciBleGFtcGxlLCBpbmRpY2F0aW5nIHNwZWNpZmljIGluZm9ybWF0 aW9uIGFib3V0IHRoZQ0KICAgZGlhbGVjdCwgd3JpdGluZyBzeXN0ZW0sIG9yIG9ydGhvZ3Jh cGh5IHVzZWQgaW4gYSBkb2N1bWVudCBvcg0KICAgcmVzb3VyY2UgbWF5IGVuYWJsZSB0aGUg dXNlciB0byBvYnRhaW4gaW5mb3JtYXRpb24gaW4gYSBmb3JtIHRoYXQNCiAgIHRoZXkgY2Fu IHVuZGVyc3RhbmQsIG9yIGl0IGNhbiBiZSBpbXBvcnRhbnQgaW4gcHJvY2Vzc2luZyBvcg0K ICAgcmVuZGVyaW5nIHRoZSBnaXZlbiBjb250ZW50IGludG8gYW4gYXBwcm9wcmlhdGUgZm9y bSBvciBzdHlsZS4NCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBwYXJ0aWN1bGFy IGlkZW50aWZpZXIgbWVjaGFuaXNtICh0aGUNCiAgIGxhbmd1YWdlIHRhZykgYW5kIGEgcmVn aXN0cmF0aW9uIGZ1bmN0aW9uIGZvciB2YWx1ZXMgdG8gYmUgdXNlZCB0bw0KICAgZm9ybSB0 YWdzLiAgSXQgYWxzbyBkZWZpbmVzIGEgbWVjaGFuaXNtIGZvciBwcml2YXRlIHVzZSB2YWx1 ZXMgYW5kDQogICBmdXR1cmUgZXh0ZW5zaW9uLg0KDQogICBUaGlzIGRvY3VtZW50IHJlcGxh Y2VzIFtSRkM0NjQ2XSwgd2hpY2ggcmVwbGFjZWQgW1JGQzMwNjZdIGFuZCBpdHMNCiAgIHBy ZWRlY2Vzc29yIFtSRkMxNzY2XS4gIEZvciBhIGxpc3Qgb2YgY2hhbmdlcyBpbiB0aGlzIGRv Y3VtZW50LCBzZWUNCiAgIFNlY3Rpb24gOC4NCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9O QUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjIuICBUaGUgTGFuZ3VhZ2UgVGFnDQoNCiAg IExhbmd1YWdlIHRhZ3MgYXJlIHVzZWQgdG8gaGVscCBpZGVudGlmeSBsYW5ndWFnZXMsIHdo ZXRoZXIgc3Bva2VuLA0KICAgd3JpdHRlbiwgc2lnbmVkLCBvciBvdGhlcndpc2Ugc2lnbmFs ZWQsIGZvciB0aGUgcHVycG9zZSBvZg0KICAgY29tbXVuaWNhdGlvbi4gIFRoaXMgaW5jbHVk ZXMgY29uc3RydWN0ZWQgYW5kIGFydGlmaWNpYWwgbGFuZ3VhZ2VzLA0KICAgYnV0IGV4Y2x1 ZGVzIGxhbmd1YWdlcyBub3QgaW50ZW5kZWQgcHJpbWFyaWx5IGZvciBodW1hbg0KICAgY29t bXVuaWNhdGlvbiwgc3VjaCBhcyBwcm9ncmFtbWluZyBsYW5ndWFnZXMuDQoNCjIuMS4gIFN5 bnRheA0KDQogICBUaGUgbGFuZ3VhZ2UgdGFnIGlzIGNvbXBvc2VkIG9mIG9uZSBvciBtb3Jl IHBhcnRzLCBrbm93biBhcw0KICAgInN1YnRhZ3MiLiAgRWFjaCBzdWJ0YWcgY29uc2lzdHMg b2YgYSBzZXF1ZW5jZSBvZiBhbHBoYW51bWVyaWMNCiAgIGNoYXJhY3RlcnMuICBTdWJ0YWdz IGFyZSBkaXN0aW5ndWlzaGVkIGFuZCBzZXBhcmF0ZWQgZnJvbSBvbmUgYW5vdGhlcg0KICAg YnkgYSBoeXBoZW4gKCItIiwgQUJORiBbUkZDNDIzNF0gJXgyRCkuICBBIGxhbmd1YWdlIHRh ZyBjb25zaXN0cyBvZiBhDQogICAicHJpbWFyeSBsYW5ndWFnZSIgc3VidGFnIGFuZCBhIChw b3NzaWJseSBlbXB0eSkgc2VyaWVzIG9mIHN1YnNlcXVlbnQNCiAgIHN1YnRhZ3MsIGVhY2gg b2Ygd2hpY2ggcmVmaW5lcyBvciBuYXJyb3dzIHRoZSByYW5nZSBvZiBsYW5ndWFnZXMNCiAg IGlkZW50aWZpZWQgYnkgdGhlIG92ZXJhbGwgdGFnLg0KDQogICBVc3VhbGx5LCBlYWNoIHR5 cGUgb2Ygc3VidGFnIGlzIGRpc3Rpbmd1aXNoZWQgYnkgbGVuZ3RoLCBwb3NpdGlvbiBpbg0K ICAgdGhlIHRhZywgYW5kIGNvbnRlbnQ6IHN1YnRhZ3MgY2FuIGJlIHJlY29nbml6ZWQgc29s ZWx5IGJ5IHRoZXNlDQogICBmZWF0dXJlcy4gIFRoZSBvbmx5IGV4Y2VwdGlvbiB0byB0aGlz IGlzIGEgZml4ZWQgbGlzdCBvZg0KICAgZ3JhbmRmYXRoZXJlZCB0YWdzIHJlZ2lzdGVyZWQg dW5kZXIgUkZDIDMwNjYgW1JGQzMwNjZdLiAgVGhpcyBtYWtlcw0KICAgaXQgcG9zc2libGUg dG8gY29uc3RydWN0IGEgcGFyc2VyIHRoYXQgY2FuIGV4dHJhY3QgYW5kIGFzc2lnbiBzb21l DQogICBzZW1hbnRpYyBpbmZvcm1hdGlvbiB0byB0aGUgc3VidGFncywgZXZlbiBpZiB0aGUg c3BlY2lmaWMgc3VidGFnDQogICB2YWx1ZXMgYXJlIG5vdCByZWNvZ25pemVkLiAgVGh1cywg YSBwYXJzZXIgbmVlZCBub3QgaGF2ZSBhbiB1cC10by0NCiAgIGRhdGUgY29weSAob3IgYW55 IGNvcHkgYXQgYWxsKSBvZiB0aGUgc3VidGFnIHJlZ2lzdHJ5IHRvIHBlcmZvcm0gbW9zdA0K ICAgc2VhcmNoaW5nIGFuZCBtYXRjaGluZyBvcGVyYXRpb25zLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBUaGUgc3ludGF4IG9mIHRoZSBsYW5ndWFn ZSB0YWcgaW4gQUJORiBbUkZDNDIzNF0gaXM6DQoNCiAgIExhbmd1YWdlLVRhZyAgPSBsYW5n dGFnDQogICAgICAgICAgICAgICAgIC8gcHJpdmF0ZXVzZSAgICAgICAgICAgICA7IHByaXZh dGUgdXNlIHRhZw0KICAgICAgICAgICAgICAgICAvIGlycmVndWxhciAgICAgICAgICAgICAg OyB0YWdzIGdyYW5kZmF0aGVyZWQgYnkgcnVsZQ0KDQogICBsYW5ndGFnICAgICAgID0gKGxh bmd1YWdlDQogICAgICAgICAgICAgICAgICAgIFsiLSIgc2NyaXB0XQ0KICAgICAgICAgICAg ICAgICAgICBbIi0iIHJlZ2lvbl0NCiAgICAgICAgICAgICAgICAgICAgKigiLSIgdmFyaWFu dCkNCiAgICAgICAgICAgICAgICAgICAgKigiLSIgZXh0ZW5zaW9uKQ0KICAgICAgICAgICAg ICAgICAgICBbIi0iIHByaXZhdGV1c2VdKQ0KDQogICBsYW5ndWFnZSAgICAgID0gKDIqM0FM UEhBIFsgZXh0bGFuZyBdKSA7IHNob3J0ZXN0IElTTyA2MzkgY29kZQ0KICAgICAgICAgICAg ICAgICAvIDRBTFBIQSAgICAgICAgICAgICAgICAgOyByZXNlcnZlZCBmb3IgZnV0dXJlIHVz ZQ0KICAgICAgICAgICAgICAgICAvIDUqOEFMUEhBICAgICAgICAgICAgICAgOyByZWdpc3Rl cmVkIGxhbmd1YWdlIHN1YnRhZw0KDQogICBleHRsYW5nICAgICAgID0gKjMoIi0iIDNBTFBI QSkgICAgICAgICA7IHNwZWNpZmljIElTTyA2MzktMyBjb2Rlcw0KDQogICBzY3JpcHQgICAg ICAgID0gNEFMUEhBICAgICAgICAgICAgICAgICA7IElTTyAxNTkyNCBjb2RlDQoNCiAgIHJl Z2lvbiAgICAgICAgPSAyQUxQSEEgICAgICAgICAgICAgICAgIDsgSVNPIDMxNjYgY29kZQ0K ICAgICAgICAgICAgICAgICAvIDNESUdJVCAgICAgICAgICAgICAgICAgOyBVTiBNLjQ5IGNv ZGUNCg0KICAgdmFyaWFudCAgICAgICA9IDUqOGFscGhhbnVtICAgICAgICAgICAgOyByZWdp c3RlcmVkIHZhcmlhbnRzDQogICAgICAgICAgICAgICAgIC8gKERJR0lUIDNhbHBoYW51bSkN Cg0KICAgZXh0ZW5zaW9uICAgICA9IHNpbmdsZXRvbiAxKigiLSIgKDIqOGFscGhhbnVtKSkN Cg0KICAgc2luZ2xldG9uICAgICA9ICV4NDEtNTcgLyAleDU5LTVBIC8gJXg2MS03NyAvICV4 NzktN0EgLyBESUdJVA0KICAgICAgICAgICAgICAgICA7ICJhIi0idyIgLyAieSItInoiIC8g IkEiLSJXIiAvICJZIi0iWiIgLyAiMCItIjkiDQogICAgICAgICAgICAgICAgIDsgU2luZ2xl IGFscGhhbnVtZXJpY3MNCiAgICAgICAgICAgICAgICAgOyAieCIgaXMgcmVzZXJ2ZWQgZm9y IHByaXZhdGUgdXNlDQoNCiAgIHByaXZhdGV1c2UgICAgPSAieCIgMSooIi0iICgxKjhhbHBo YW51bSkpDQoNCiAgIGlycmVndWxhciAgICAgPSAiZW4tR0Itb2VkIiAvICJpLWFtaSIgLyAi aS1ibm4iIC8gImktZGVmYXVsdCINCiAgICAgICAgICAgICAgICAgLyAiaS1lbm9jaGlhbiIg LyAiaS1oYWsiIC8gImkta2xpbmdvbiIgLyAiaS1sdXgiDQogICAgICAgICAgICAgICAgIC8g ImktbWluZ28iIC8gImktbmF2YWpvIiAvICJpLXB3biIgLyAiaS10YW8iDQogICAgICAgICAg ICAgICAgIC8gImktdGF5IiAvICJpLXRzdSIgLyAic2duLUJFLWZyIiAvICJzZ24tQkUtbmwi DQogICAgICAgICAgICAgICAgIC8gInNnbi1DSC1kZSINCg0KICAgYWxwaGFudW0gICAgICA9 IChBTFBIQSAvIERJR0lUKSAgICAgICA7IGxldHRlcnMgYW5kIG51bWJlcnMNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IExhbmd1YWdlIFRhZyBBQk5GDQoNCiAgIEFs bCBzdWJ0YWdzIGhhdmUgYSBtYXhpbXVtIGxlbmd0aCBvZiBlaWdodCBjaGFyYWN0ZXJzIGFu ZCB3aGl0ZXNwYWNlDQogICBpcyBub3QgcGVybWl0dGVkIGluIGEgbGFuZ3VhZ2UgdGFnLiAg VGhlcmUgaXMgYSBzdWJ0bGV0eSBpbiB0aGUgQUJORg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdl IDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBwcm9kdWN0aW9uICd2YXJpYW50 JzogdmFyaWFudHMgc3RhcnRpbmcgd2l0aCBhIGRpZ2l0IE1BWSBiZSBmb3VyDQogICBjaGFy YWN0ZXJzIGxvbmcsIHdoaWxlIHRob3NlIHN0YXJ0aW5nIHdpdGggYSBsZXR0ZXIgTVVTVCBi ZSBhdCBsZWFzdA0KICAgZml2ZSBjaGFyYWN0ZXJzIGxvbmcuICBGb3IgZXhhbXBsZXMgb2Yg bGFuZ3VhZ2UgdGFncywgc2VlIEFwcGVuZGl4IEIuDQoNCiAgIE5vdGUgV2VsbDogdGhlIEFC TkYgc3ludGF4IGRvZXMgbm90IGRpc3Rpbmd1aXNoIGJldHdlZW4gdXBwZXIgYW5kDQogICBs b3dlcmNhc2UuICBUaGUgYXBwZWFyYW5jZSBvZiB1cHBlciBhbmQgbG93ZXJjYXNlIGxldHRl cnMgaW4gdGhlDQogICB2YXJvdXMgQUJORiBwcm9kdWN0aW9ucyBhYm92ZSBkbyBub3QgYWZm ZWN0IGhvdyBpbXBsZW1lbnRhdGlvbnMNCiAgIGludGVycHJldCB0YWdzLiAgVGhhdCBpcywg dGhlIHRhZyAiSS1BTUkiIG1hdGNoZXMgdGhlIGl0ZW0gImktYW1pIiBpbg0KICAgdGhlICdp cnJlZ3VsYXInIHByb2R1Y3Rpb24uICBBdCBhbGwgdGltZXMsIHRoZSB0YWdzIGFuZCB0aGVp cg0KICAgc3VidGFncywgaW5jbHVkaW5nIHByaXZhdGUgdXNlIGFuZCBleHRlbnNpb25zLCBh cmUgdG8gYmUgdHJlYXRlZCBhcw0KICAgY2FzZSBpbnNlbnNpdGl2ZTogdGhlcmUgZXhpc3Qg Y29udmVudGlvbnMgZm9yIHRoZSBjYXBpdGFsaXphdGlvbiBvZg0KICAgc29tZSBvZiB0aGUg c3VidGFncywgYnV0IHRoZXNlIE1VU1QgTk9UIGJlIHRha2VuIHRvIGNhcnJ5IG1lYW5pbmcu DQoNCiAgIEZvciBleGFtcGxlOg0KDQogICBvICBbSVNPNjM5LTFdIHJlY29tbWVuZHMgdGhh dCBsYW5ndWFnZSBjb2RlcyBiZSB3cml0dGVuIGluIGxvd2VyY2FzZQ0KICAgICAgKCdtbicg TW9uZ29saWFuKS4NCg0KICAgbyAgW0lTTzMxNjYtMV0gcmVjb21tZW5kcyB0aGF0IGNvdW50 cnkgY29kZXMgYmUgY2FwaXRhbGl6ZWQgKCdNTicNCiAgICAgIE1vbmdvbGlhKS4NCg0KICAg byAgW0lTTzE1OTI0XSByZWNvbW1lbmRzIHRoYXQgc2NyaXB0IGNvZGVzIHVzZSBsb3dlcmNh c2Ugd2l0aCB0aGUNCiAgICAgIGluaXRpYWwgbGV0dGVyIGNhcGl0YWxpemVkICgnQ3lybCcg Q3lyaWxsaWMpLg0KDQogICBIb3dldmVyLCBpbiB0aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMg ZG9jdW1lbnQsIHRoZSB1cHBlcmNhc2UgVVMtQVNDSUkNCiAgIGxldHRlcnMgaW4gdGhlIHJh bmdlICdBJyB0aHJvdWdoICdaJyBhcmUgY29uc2lkZXJlZCBlcXVpdmFsZW50IGFuZA0KICAg bWFwcGVkIGRpcmVjdGx5IHRvIHRoZWlyIFVTLUFTQ0lJIGxvd2VyY2FzZSBlcXVpdmFsZW50 cyBpbiB0aGUgcmFuZ2UNCiAgICdhJyB0aHJvdWdoICd6Jy4gIFRodXMsIHRoZSB0YWcgIm1u LUN5cmwtTU4iIGlzIG5vdCBkaXN0aW5jdCBmcm9tDQogICAiTU4tY1lSTC1tbiIgb3IgIm1O LWNZckwtTW4iIChvciBhbnkgb3RoZXIgY29tYmluYXRpb24pLCBhbmQgZWFjaCBvZg0KICAg dGhlc2UgdmFyaWF0aW9ucyBjb252ZXlzIHRoZSBzYW1lIG1lYW5pbmc6IE1vbmdvbGlhbiB3 cml0dGVuIGluIHRoZQ0KICAgQ3lyaWxsaWMgc2NyaXB0IGFzIHVzZWQgaW4gTW9uZ29saWEu DQoNCiAgIEFsdGhvdWdoIGNhc2UgZGlzdGluY3Rpb25zIGRvIG5vdCBjYXJyeSBtZWFuaW5n IGluIGxhbmd1YWdlIHRhZ3MsDQogICBjb25zaXN0ZW50IGZvcm1hdHRpbmcgYW5kIHByZXNl bnRhdGlvbiBvZiB0aGUgdGFncyB3aWxsIGFpZCB1c2Vycy4NCiAgIFRoZSBmb3JtYXQgb2Yg dGhlIHRhZ3MgYW5kIHN1YnRhZ3MgaW4gdGhlIHJlZ2lzdHJ5IGlzIFJFQ09NTUVOREVELg0K ICAgSW4gdGhpcyBmb3JtYXQsIGFsbCBub24taW5pdGlhbCB0d28tbGV0dGVyIHN1YnRhZ3Mg YXJlIHVwcGVyY2FzZSwgYWxsDQogICBub24taW5pdGlhbCBmb3VyLWxldHRlciBzdWJ0YWdz IGFyZSB0aXRsZWNhc2UsIGFuZCBhbGwgb3RoZXIgc3VidGFncw0KICAgYXJlIGxvd2VyY2Fz ZS4NCg0KICAgTm90ZSB0aGF0IGFsdGhvdWdoIFtSRkM0MjM0XSByZWZlcnMgdG8gb2N0ZXRz LCB0aGUgbGFuZ3VhZ2UgdGFncw0KICAgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgYXJl IHNlcXVlbmNlcyBvZiBjaGFyYWN0ZXJzIGZyb20gdGhlIFVTLQ0KICAgQVNDSUkgW0lTTzY0 Nl0gcmVwZXJ0b2lyZS4gIExhbmd1YWdlIHRhZ3MgTUFZIGJlIHVzZWQgaW4gZG9jdW1lbnRz DQogICBhbmQgYXBwbGljYXRpb25zIHRoYXQgdXNlIG90aGVyIGVuY29kaW5ncywgc28gbG9u ZyBhcyB0aGVzZSBlbmNvbXBhc3MNCiAgIHRoZSBVUy1BU0NJSSByZXBlcnRvaXJlLiAgQW4g ZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhNTCBkb2N1bWVudA0KICAgdGhhdCB1c2Vz IHRoZSBVVEYtMTZMRSBbUkZDMjc4MV0gZW5jb2Rpbmcgb2YgW1VuaWNvZGVdLg0KDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAg ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQoy LjIuICBMYW5ndWFnZSBTdWJ0YWcgU291cmNlcyBhbmQgSW50ZXJwcmV0YXRpb24NCg0KICAg VGhlIG5hbWVzcGFjZSBvZiBsYW5ndWFnZSB0YWdzIGFuZCB0aGVpciBzdWJ0YWdzIGlzIGFk bWluaXN0ZXJlZCBieQ0KICAgdGhlIEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMgQXV0aG9y aXR5IChJQU5BKSBbUkZDMjg2MF0gYWNjb3JkaW5nIHRvDQogICB0aGUgcnVsZXMgaW4gU2Vj dGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQuICBUaGUgTGFuZ3VhZ2UgU3VidGFnDQogICBSZWdp c3RyeSBtYWludGFpbmVkIGJ5IElBTkEgaXMgdGhlIHNvdXJjZSBmb3IgdmFsaWQgc3VidGFn czogb3RoZXINCiAgIHN0YW5kYXJkcyByZWZlcmVuY2VkIGluIHRoaXMgc2VjdGlvbiBwcm92 aWRlIHRoZSBzb3VyY2UgbWF0ZXJpYWwgZm9yDQogICB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBU ZXJtaW5vbG9neSB1c2VkIGluIHRoaXMgZG9jdW1lbnQ6DQoNCiAgIG8gIFRhZyBvciB0YWdz IHJlZmVycyB0byBhIGNvbXBsZXRlIGxhbmd1YWdlIHRhZywgc3VjaCBhcw0KICAgICAgInNy LUxhdG4tUlMiIG9yICJhei1BcmFiLUlSIi4gIEV4YW1wbGVzIG9mIHRhZ3MgaW4gdGhpcyBk b2N1bWVudA0KICAgICAgYXJlIGVuY2xvc2VkIGluIGRvdWJsZS1xdW90ZXMgKCJlbi1VUyIp Lg0KDQogICBvICBTdWJ0YWcgcmVmZXJzIHRvIGEgc3BlY2lmaWMgc2VjdGlvbiBvZiBhIHRh ZywgZGVsaW1pdGVkIGJ5IGh5cGhlbiwNCiAgICAgIHN1Y2ggYXMgdGhlIHN1YnRhZyAnSGFu dCcgaW4gInpoLUhhbnQtQ04iLiAgRXhhbXBsZXMgb2Ygc3VidGFncyBpbg0KICAgICAgdGhp cyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4gc2luZ2xlIHF1b3RlcyAoJ0hhbnQnKS4NCg0K ICAgbyAgQ29kZSBvciBjb2RlcyByZWZlcnMgdG8gdmFsdWVzIGRlZmluZWQgaW4gZXh0ZXJu YWwgc3RhbmRhcmRzIChhbmQNCiAgICAgIHdoaWNoIGFyZSB1c2VkIGFzIHN1YnRhZ3MgaW4g dGhpcyBkb2N1bWVudCkuICBGb3IgZXhhbXBsZSwgJ0hhbnQnDQogICAgICBpcyBhbiBbSVNP MTU5MjRdIHNjcmlwdCBjb2RlIHRoYXQgd2FzIHVzZWQgdG8gZGVmaW5lIHRoZSAnSGFudCcN CiAgICAgIHNjcmlwdCBzdWJ0YWcgZm9yIHVzZSBpbiBhIGxhbmd1YWdlIHRhZy4gIEV4YW1w bGVzIG9mIGNvZGVzIGluDQogICAgICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBz aW5nbGUgcXVvdGVzICgnZW4nLCAnSGFudCcpLg0KDQogICBUaGUgZGVmaW5pdGlvbnMgaW4g dGhpcyBzZWN0aW9uIGFwcGx5IHRvIHRoZSB2YXJpb3VzIHN1YnRhZ3Mgd2l0aGluDQogICB0 aGUgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0 aG9zZQ0KICAgImdyYW5kZmF0aGVyZWQiIHRhZ3MgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMi44 Lg0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSBkZXNpZ25lZCBzbyB0aGF0IGVhY2ggc3VidGFn IHR5cGUgaGFzIHVuaXF1ZSBsZW5ndGgNCiAgIGFuZCBjb250ZW50IHJlc3RyaWN0aW9ucy4g IFRoZXNlIG1ha2UgaWRlbnRpZmljYXRpb24gb2YgdGhlIHN1YnRhZydzDQogICB0eXBlIHBv c3NpYmxlLCBldmVuIGlmIHRoZSBjb250ZW50IG9mIHRoZSBzdWJ0YWcgaXRzZWxmIGlzDQog ICB1bnJlY29nbml6ZWQuICBUaGlzIGFsbG93cyB0YWdzIHRvIGJlIHBhcnNlZCBhbmQgcHJv Y2Vzc2VkIHdpdGhvdXQNCiAgIHJlZmVyZW5jZSB0byB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIG9yIHRoZQ0KICAgSUFOQSByZWdpc3RyeSBhbmQg bWFrZXMgdGhlIGFzc29jaWF0ZWQgZXhjZXB0aW9uIGhhbmRsaW5nIHdoZW4NCiAgIHBhcnNp bmcgdGFncyBzaW1wbGVyLg0KDQogICBTdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IHRo YXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1bmRlcmx5aW5nDQogICBzdGFuZGFyZCBjYW4gb25s eSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25zIGluIGEgdGFnLg0KICAgU3BlY2lmaWNh bGx5LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBv ciBhcw0KICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBOb3RlIHRoYXQgc2VxdWVuY2VzIG9m IHByaXZhdGUgdXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBNVVNUIG9jY3VyDQogICBhdCB0 aGUgZW5kIG9mIHRoZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFuZCBNVVNUIE5PVCBiZSBpbnRl cnNwZXJzZWQNCiAgIHdpdGggc3VidGFncyBkZWZpbmVkIGVsc2V3aGVyZSBpbiB0aGlzIGRv Y3VtZW50Lg0KDQogICBTaW5nbGUtbGV0dGVyIGFuZCBzaW5nbGUtZGlnaXQgc3VidGFncyBh cmUgcmVzZXJ2ZWQgZm9yIGN1cnJlbnQgb3INCiAgIGZ1dHVyZSB1c2UuICBUaGVzZSBpbmNs dWRlIHRoZSBmb2xsb3dpbmcgY3VycmVudCB1c2VzOg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdl IDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBvICBUaGUgc2luZ2xlLWxldHRl ciBzdWJ0YWcgJ3gnIGlzIHJlc2VydmVkIHRvIGludHJvZHVjZSBhIHNlcXVlbmNlDQogICAg ICBvZiBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVGhlIGludGVycHJldGF0aW9uIG9mIGFueSBw cml2YXRlIHVzZQ0KICAgICAgc3VidGFncyBpcyBkZWZpbmVkIHNvbGVseSBieSBwcml2YXRl IGFncmVlbWVudCBhbmQgaXMgbm90IGRlZmluZWQNCiAgICAgIGJ5IHRoZSBydWxlcyBpbiB0 aGlzIHNlY3Rpb24gb3IgaW4gYW55IHN0YW5kYXJkIG9yIHJlZ2lzdHJ5DQogICAgICBkZWZp bmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIG8gIEFsbCBvdGhlciBzaW5nbGUtbGV0dGVy IHN1YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGludHJvZHVjZQ0KICAgICAgc3RhbmRhcmRpemVk IGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2VzIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgU2Vj dGlvbiAzLjcuDQoNCiAgIFRoZSBzaW5nbGUtbGV0dGVyIHN1YnRhZyAnaScgaXMgdXNlZCBi eSBzb21lIGdyYW5kZmF0aGVyZWQgdGFncywgc3VjaA0KICAgYXMgImktZGVmYXVsdCIsIHdo ZXJlIGl0IGFsd2F5cyBhcHBlYXJzIGluIHRoZSBmaXJzdCBwb3NpdGlvbiBhbmQNCiAgIGNh bm5vdCBiZSBjb25mdXNlZCB3aXRoIGFuIGV4dGVuc2lvbi4NCg0KMi4yLjEuICBQcmltYXJ5 IExhbmd1YWdlIFN1YnRhZw0KDQogICBUaGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaXMg dGhlIGZpcnN0IHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZw0KICAgKHdpdGggdGhlIGV4Y2Vw dGlvbiBvZiBwcml2YXRlIHVzZSBhbmQgY2VydGFpbiBncmFuZGZhdGhlcmVkIHRhZ3MpDQog ICBhbmQgY2Fubm90IGJlIG9taXR0ZWQuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRv IHRoZSBwcmltYXJ5DQogICBsYW5ndWFnZSBzdWJ0YWc6DQoNCiAgIDEuICBBbGwgdHdvLWNo YXJhY3RlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRoZQ0K ICAgICAgIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3Vu ZCBpbiB0aGUgc3RhbmRhcmQNCiAgICAgICBJU08gNjM5IFBhcnQgMSwgIklTTyA2MzktMToy MDAyLCBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mDQogICAgICAgbmFtZXMgb2Yg bGFuZ3VhZ2VzIC0tIFBhcnQgMTogQWxwaGEtMiBjb2RlIiBbSVNPNjM5LTFdLCBvciB1c2lu Zw0KICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRseSBtYWRlIGJ5IHRoZSBJU08gNjM5 LTEgcmVnaXN0cmF0aW9uDQogICAgICAgYXV0aG9yaXR5IChSQSkgb3IgZ292ZXJuaW5nIHN0 YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDIuICBBbGwgdGhyZWUtY2hhcmFjdGVyIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRlZmluZWQgaW4gdGhlDQogICAgICAgSUFO QSByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIGVpdGhl ciBJU08NCiAgICAgICA2MzkgUGFydCAyLCAiSVNPIDYzOS0yOjE5OTggLSBDb2RlcyBmb3Ig dGhlIHJlcHJlc2VudGF0aW9uIG9mDQogICAgICAgbmFtZXMgb2YgbGFuZ3VhZ2VzIC0tIFBh cnQgMjogQWxwaGEtMyBjb2RlIC0gZWRpdGlvbiAxIg0KICAgICAgIFtJU082MzktMl0sIElT TyA2MzkgUGFydCAzLCAiQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZg0KICAgICAg IG5hbWVzIG9mIGxhbmd1YWdlcyAtLSBQYXJ0IDM6IEFscGhhLTMgY29kZSBmb3IgY29tcHJl aGVuc2l2ZQ0KICAgICAgIGNvdmVyYWdlIG9mIGxhbmd1YWdlcyIgW0lTTzYzOS0zXSwgb3Ig YXNzaWdubWVudHMgc3Vic2VxdWVudGx5DQogICAgICAgbWFkZSBieSB0aGUgcmVsZXZhbnQg SVNPIDYzOSByZWdpc3RyYXRpb24gYXV0aG9yaXRpZXMgb3INCiAgICAgICBnb3Zlcm5pbmcg c3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0KICAgMy4gIFRoZSBzdWJ0YWdzIGluIHRoZSBy YW5nZSAncWFhJyB0aHJvdWdoICdxdHonIGFyZSByZXNlcnZlZCBmb3INCiAgICAgICBwcml2 YXRlIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBjb3JyZXNwb25kIHRv IGNvZGVzDQogICAgICAgcmVzZXJ2ZWQgYnkgSVNPIDYzOS0yIGZvciBwcml2YXRlIHVzZS4g IFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkDQogICAgICAgZm9yIG5vbi1yZWdpc3RlcmVkIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyAoaW5zdGVhZCBvZiB1c2luZw0KICAgICAgIHByaXZh dGUgdXNlIHN1YnRhZ3MgZm9sbG93aW5nICd4LScpLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rp b24gNC41DQogICAgICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3Vi dGFncy4NCg0KICAgNC4gIEFsbCBmb3VyLWNoYXJhY3RlciBsYW5ndWFnZSBzdWJ0YWdzIGFy ZSByZXNlcnZlZCBmb3IgcG9zc2libGUNCiAgICAgICBmdXR1cmUgc3RhbmRhcmRpemF0aW9u Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAy MDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0K DQoNCiAgIDUuICBBbGwgbGFuZ3VhZ2Ugc3VidGFncyBvZiA1IHRvIDggY2hhcmFjdGVycyBp biBsZW5ndGggaW4gdGhlIElBTkENCiAgICAgICByZWdpc3RyeSB3ZXJlIGRlZmluZWQgdmlh IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBpbiBTZWN0aW9uIDMuNQ0KICAgICAgIGFuZCBN QVkgYmUgdXNlZCB0byBmb3JtIHRoZSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZy4gIEF0IHRo ZSB0aW1lDQogICAgICAgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCwgdGhlcmUgd2VyZSBu byBleGFtcGxlcyBvZiB0aGlzIGtpbmQgb2YNCiAgICAgICBzdWJ0YWcgYW5kIGZ1dHVyZSBy ZWdpc3RyYXRpb25zIG9mIHRoaXMgdHlwZSB3aWxsIGJlIGRpc2NvdXJhZ2VkOg0KICAgICAg IHByaW1hcnkgbGFuZ3VhZ2VzIGFyZSBzdHJvbmdseSBSRUNPTU1FTkRFRCBmb3IgcmVnaXN0 cmF0aW9uIHdpdGgNCiAgICAgICBJU08gNjM5LCBhbmQgcHJvcG9zYWxzIHJlamVjdGVkIGJ5 IElTTyA2MzkvUkEtSkFDIHdpbGwgYmUgY2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJl Zm9yZSB0aGV5IGFyZSByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAgNi4gIFRoZSBzaW5n bGUtY2hhcmFjdGVyIHN1YnRhZyAneCcgYXMgdGhlIHByaW1hcnkgc3VidGFnIGluZGljYXRl cw0KICAgICAgIHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkgb2Ygc3Vi dGFncyB3aG9zZSBtZWFuaW5nIGlzDQogICAgICAgZGVmaW5lZCBieSBwcml2YXRlIGFncmVl bWVudC4gIEZvciBleGFtcGxlLCBpbiB0aGUgdGFnICJ4LWZyLUNIIiwNCiAgICAgICB0aGUg c3VidGFncyAnZnInIGFuZCAnQ0gnIFNIT1VMRCBOT1QgYmUgdGFrZW4gdG8gcmVwcmVzZW50 IHRoZQ0KICAgICAgIEZyZW5jaCBsYW5ndWFnZSBvciB0aGUgY291bnRyeSBvZiBTd2l0emVy bGFuZCAob3IgYW55IG90aGVyIHZhbHVlDQogICAgICAgaW4gdGhlIElBTkEgcmVnaXN0cnkp IHVubGVzcyB0aGVyZSBpcyBhIHByaXZhdGUgYWdyZWVtZW50IGluDQogICAgICAgcGxhY2Ug dG8gZG8gc28uICBTZWUgU2VjdGlvbiA0LjUuDQoNCiAgIDcuICBUaGUgc2luZ2xlLWNoYXJh Y3RlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFuZGZhdGhlcmVkDQogICAgICAg dGFncyAoc2VlIFNlY3Rpb24gMi4yLjgpIHN1Y2ggYXMgImkta2xpbmdvbiIgYW5kICJpLWJu biIuICAoT3RoZXINCiAgICAgICBncmFuZGZhdGhlcmVkIHRhZ3MgaGF2ZSBhIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFnIGluIHRoZWlyIGZpcnN0DQogICAgICAgcG9zaXRpb24uKQ0KDQog ICA4LiAgT3RoZXIgdmFsdWVzIE1VU1QgTk9UIGJlIGFzc2lnbmVkIHRvIHRoZSBwcmltYXJ5 IHN1YnRhZyBleGNlcHQgYnkNCiAgICAgICByZXZpc2lvbiBvciB1cGRhdGUgb2YgdGhpcyBk b2N1bWVudC4NCg0KICAgTm90ZTogRm9yIGxhbmd1YWdlcyB0aGF0IGhhdmUgYm90aCBhbiBJ U08gNjM5LTEgdHdvLWNoYXJhY3RlciBjb2RlDQogICBhbmQgYSB0aHJlZSBjaGFyYWN0ZXIg Y29kZSBhc3NpZ25lZCBieSBlaXRoZXIgSVNPIDYzOS0yIG9yIElTTyA2MzktMywNCiAgIG9u bHkgdGhlIElTTyA2MzktMSB0d28tY2hhcmFjdGVyIGNvZGUgaXMgZGVmaW5lZCBpbiB0aGUg SUFOQQ0KICAgcmVnaXN0cnkuDQoNCiAgIE5vdGU6IEZvciBsYW5ndWFnZXMgdGhhdCBoYXZl IG5vIElTTyA2MzktMSB0d28tY2hhcmFjdGVyIGNvZGUgYW5kIGZvcg0KICAgd2hpY2ggdGhl IElTTyA2MzktMi9UIChUZXJtaW5vbG9neSkgY29kZSBhbmQgdGhlIElTTyA2MzktMi9CDQog ICAoQmlibGlvZ3JhcGhpYykgY29kZXMgZGlmZmVyLCBvbmx5IHRoZSBUZXJtaW5vbG9neSBj b2RlIGlzIGRlZmluZWQgaW4NCiAgIHRoZSBJQU5BIHJlZ2lzdHJ5LiAgQXQgdGhlIHRpbWUg dGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCwgYWxsDQogICBsYW5ndWFnZXMgdGhhdCBoYWQg Ym90aCBraW5kcyBvZiB0aHJlZS1jaGFyYWN0ZXIgY29kZSB3ZXJlIGFsc28NCiAgIGFzc2ln bmVkIGEgdHdvLWNoYXJhY3RlciBjb2RlOyBpdCBpcyBleHBlY3RlZCB0aGF0IGZ1dHVyZSBh c3NpZ25tZW50cw0KICAgb2YgdGhpcyBuYXR1cmUgd2lsbCBub3Qgb2NjdXIuDQoNCiAgIE5v dGU6IFRvIGF2b2lkIHByb2JsZW1zIHdpdGggdmVyc2lvbmluZyBhbmQgc3VidGFnIGNob2lj ZSBhcw0KICAgZXhwZXJpZW5jZWQgZHVyaW5nIHRoZSB0cmFuc2l0aW9uIGJldHdlZW4gUkZD IDE3NjYgYW5kIFJGQyAzMDY2LCBhcw0KICAgd2VsbCBhcyB0aGUgY2Fub25pY2FsIG5hdHVy ZSBvZiBzdWJ0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwgdGhlDQogICBJU08gNjM5 IFJlZ2lzdHJhdGlvbiBBdXRob3JpdHkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlIChJU08g NjM5Lw0KICAgUkEtSkFDKSBoYXMgaW5jbHVkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQg aW4gW2lzbzYzOS5wcmluXToNCg0KICAgICAgIkEgbGFuZ3VhZ2UgY29kZSBhbHJlYWR5IGlu IElTTyA2MzktMiBhdCB0aGUgcG9pbnQgb2YgZnJlZXppbmcgSVNPDQogICAgICA2MzktMSBz aGFsbCBub3QgbGF0ZXIgYmUgYWRkZWQgdG8gSVNPIDYzOS0xLiAgVGhpcyBpcyB0byBlbnN1 cmUNCiAgICAgIGNvbnNpc3RlbmN5IGluIHVzYWdlIG92ZXIgdGltZSwgc2luY2UgdXNlcnMg YXJlIGRpcmVjdGVkIGluDQogICAgICBJbnRlcm5ldCBhcHBsaWNhdGlvbnMgdG8gZW1wbG95 IHRoZSBhbHBoYS0zIGNvZGUgd2hlbiBhbiBhbHBoYS0yDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFn ZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3Ry eSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICAgIGNvZGUgZm9yIHRoYXQg bGFuZ3VhZ2UgaXMgbm90IGF2YWlsYWJsZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGlu c3RhYmlsaXR5IGluIHRoZSBjYW5vbmljYWwgZm9ybSBvZiB0YWdzLCBpZiBhDQogICB0d28t Y2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8gSVNPIDYzOS0xIGZvciBhIGxhbmd1YWdlIGZv ciB3aGljaCBhDQogICB0aHJlZS1jaGFyYWN0ZXIgY29kZSB3YXMgYWxyZWFkeSBpbmNsdWRl ZCBpbiBlaXRoZXIgSVNPIDYzOS0yIG9yIElTTw0KICAgNjM5LTMsIHRoZSB0d28tY2hhcmFj dGVyIGNvZGUgTVVTVCBOT1QgYmUgcmVnaXN0ZXJlZC4gIFNlZQ0KICAgU2VjdGlvbiAzLjQu DQoNCiAgIEZvciBleGFtcGxlLCBpZiBzb21lIGNvbnRlbnQgd2VyZSB0YWdnZWQgd2l0aCAn aGF3JyAoSGF3YWlpYW4pLCB3aGljaA0KICAgY3VycmVudGx5IGhhcyBubyB0d28tY2hhcmFj dGVyIGNvZGUsIHRoZSB0YWcgd291bGQgbm90IGJlIGludmFsaWRhdGVkDQogICBpZiBJU08g NjM5LTEgd2VyZSB0byBhc3NpZ24gYSB0d28tY2hhcmFjdGVyIGNvZGUgdG8gdGhlIEhhd2Fp aWFuDQogICBsYW5ndWFnZSBhdCBhIGxhdGVyIGRhdGUuDQoNCiAgIE5vdGU6IEFuIGV4YW1w bGUgb2YgaW5kZXBlbmRlbnQgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cmF0aW9u DQogICBtaWdodCBpbmNsdWRlOiBvbmUgb2YgdGhlIGdyYW5kZmF0aGVyZWQgSUFOQSByZWdp c3RyYXRpb25zIGlzDQogICAiaS1lbm9jaGlhbiIuICBUaGUgc3VidGFnICdlbm9jaGlhbicg Y291bGQgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQQ0KICAgcmVnaXN0cnkgYXMgYSBwcmlt YXJ5IGxhbmd1YWdlIHN1YnRhZyAoYXNzdW1pbmcgdGhhdCBJU08gNjM5IGRvZXMgbm90DQog ICByZWdpc3RlciB0aGlzIGxhbmd1YWdlIGZpcnN0KSwgbWFraW5nIHRhZ3Mgc3VjaCBhcyAi ZW5vY2hpYW4tQVEiIGFuZA0KICAgImVub2NoaWFuLUxhdG4iIHZhbGlkLg0KDQoyLjIuMi4g IEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MNCg0KICAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3Vi dGFncyBhcmUgdXNlZCB0byBpZGVudGlmeSBsYW5ndWFnZXMgdGhhdCBhcmUNCiAgIGVuY29t cGFzc2VkIGJ5IGEgIm1hY3JvbGFuZ3VhZ2UiLiAgSVNPIDYzOS0zIGRlZmluZXMgY2VydGFp bg0KICAgbGFuZ3VhZ2VzIHRvIGJlICJtYWNyb2xhbmd1YWdlcyI7IHRoYXQgaXMsIHRoZXkg YXJlIGdyb3VwcyBvZiB2ZXJ5DQogICBjbG9zZWx5IHJlbGF0ZWQgbGFuZ3VhZ2VzIHdoaWNo IGFyZSB0cmVhdGVkIGFzIGEgc2luZ2xlIGxhbmd1YWdlIGluDQogICBjZXJ0YWluIGNvbnRl eHRzLiAgSW4gb3JkZXIgdG8gaW1wcm92ZSBtYXRjaGluZyBiZWhhdmlvciBhbmQgdGFnZ2lu Zw0KICAgY29uc2lzdGVuY3ksIGVhY2ggbGFuZ3VhZ2UgZW5jb21wYXNzZWQgYnkgYSBJU08g NjM5LTMgbWFjcm9sYW5ndWFnZQ0KICAgaXMgcmVwcmVzZW50ZWQgaW4gdGhlIElBTkEgcmVn aXN0cnkgdXNpbmcgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UNCiAgIHN1YnRhZywgcHJvdmlkZWQg dGhhdCBpdCBpcyBub3QgYWxyZWFkeSByZXByZXNlbnRlZCB1c2luZyBhIGxhbmd1YWdlDQog ICBzdWJ0YWcuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBleHRlbmRlZCBs YW5ndWFnZSBzdWJ0YWdzOg0KDQogICAxLiAgVGhlc2Ugc3VidGFncyB3ZXJlIGRlZmluZWQg aW4gdGhlIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvDQogICAgICAgYXNzaWdubWVudHMg Zm91bmQgaW4gSVNPIDYzOSBQYXJ0IDMuDQoNCiAgIDIuICBBIHNlcXVlbmNlIG9mIHVwIHRv IHRocmVlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MgTUFZIGFwcGVhciBpbg0KICAgICAg IGEgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBzZXF1ZW5jZSBNVVNUIGZvbGxvdyB0aGUgcHJpbWFy eSBsYW5ndWFnZQ0KICAgICAgIHN1YnRhZyBhbmQgcHJlY2VkZSBhbnkgb3RoZXIgc3VidGFn cy4NCg0KICAgMy4gIEVhY2ggZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnIE1VU1Qgb25seSBh cHBlYXIgaW4gYSB0YWcNCiAgICAgICBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIGV4YWN0 IHNlcXVlbmNlIG9mIHN1YnRhZ3MgdGhhdCBhcHBlYXJzDQogICAgICAgaW4gdGhlICdQcmVm aXgnIGZpZWxkIGluIGl0cyByZWdpc3RyeSByZWNvcmQuDQoNCiAgIDQuICBPdGhlciB2YWx1 ZXMgTVVTVCBOT1QgYmUgYXNzaWduZWQgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRh Zw0KICAgICAgIGV4Y2VwdCBieSByZXZpc2lvbiBvciB1cGRhdGUgb2YgdGhpcyBkb2N1bWVu dC4NCg0KICAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnIHJlY29yZHMgTVVTVCBpbmNsdWRl IGV4YWN0bHkgb25lICdQcmVmaXgnDQogICBmaWVsZCBpbmRpY2F0aW5nIGFuIGFwcHJvcHJp YXRlIHN1YnRhZyBvciBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGZvcg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAg W1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICB0aGF0IGV4dGVuZGVk IGxhbmd1YWdlIHN1YnRhZy4NCg0KICAgRm9yIGV4YW1wbGUsIHRoZSAnZ2FuJyBhbmQgJ2Nt bicgc3VidGFncyByZXByZXNlbnQgdGhlIGxhbmd1YWdlcyBHYW4NCiAgIENoaW5lc2UgYW5k IE1hbmRhcmluIENoaW5lc2UuICBFYWNoIGlzIGVuY29tcGFzc2VkIGJ5IHRoZQ0KICAgbWFj cm9sYW5ndWFnZSAnemgnIChDaGluZXNlKS4gIFRoZXJlZm9yZSwgdGhleSBib3RoIGhhdmUg dGhlIHByZWZpeA0KICAgInpoIiBpbiB0aGVpciByZWdpc3RyeSByZWNvcmRzLiAgQ29uc2Vx dWVudGx5LCBHYW4gQ2hpbmVzZSBpcw0KICAgcmVwcmVzZW50ZWQgYXMgInpoLWdhbiIgYW5k IE1hbmRhcmluIENoaW5lc2UgYXMgInpoLWNtbiIuICBUaGUNCiAgIGxhbmd1YWdlIHN1YnRh ZyAnemgnIGNhbiBzdGlsbCBiZSB1c2VkIHdpdGhvdXQgYW4gZXh0ZW5kZWQgbGFuZ3VhZ2UN CiAgIHN1YnRhZyB0byBsYWJlbCBhIHJlc291cmNlIGFzIHNvbWUgdW5zcGVjaWZpZWQgdmFy aWV0eSBvZiBDaGluZXNlDQogICAod2hpY2ggaW4gcHJhY3RpY2Ugd2lsbCB1c3VhbGx5IGJl IE1hbmRhcmluLCB0aGUgZG9taW5hbnQgdmFyaWV0eSBvZg0KICAgQ2hpbmVzZSwgYnV0IG1p Z2h0IGFsc28gYmUgc29tZSBvdGhlciB2YXJpZXR5KS4NCg0KICAgTm93IHN1cHBvc2UgdGhh dCwgaW4gdGhlIGZ1dHVyZSwgdGhlIElTTyA2MzktMyBSZWdpc3RyYXRpb24gQXV0aG9yaXR5 DQogICB3ZXJlIHRvIGRlY2lkZSB0aGF0IEdhbiBDaGluZXNlIGlzIGFjdHVhbGx5IHR3byBk aWZmZXJlbnQgY2xvc2VseQ0KICAgcmVsYXRlZCBsYW5ndWFnZXM6IGl0IG1pZ2h0IHJlY2xh c3NpZnkgJ2dhbicgYXMgYSBtYWNyb2xhbmd1YWdlIGFuZA0KICAgaW50cm9kdWNlIHR3byBu ZXcgY29kZSBlbGVtZW50cy4gIEluIHRoYXQgY2FzZSwgdGhlc2UgY29kZSBlbGVtZW50cw0K ICAgd291bGQgYmUgYWRkZWQgdG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgZXh0ZW5kZWQgbGFu Z3VhZ2Ugc3VidGFncyB3aXRoDQogICBwcmVmaXhlcyBvZiAiemgtZ2FuIi4gIE5vIGNoYW5n ZSB3b3VsZCBiZSBtYWRlIHRvIHRoZSByZWdpc3RyeSByZWNvcmQNCiAgIGZvciAnZ2FuJy4N Cg0KMi4yLjMuICBTY3JpcHQgU3VidGFnDQoNCiAgIFNjcmlwdCBzdWJ0YWdzIGFyZSB1c2Vk IHRvIGluZGljYXRlIHRoZSBzY3JpcHQgb3Igd3JpdGluZyBzeXN0ZW0NCiAgIHZhcmlhdGlv bnMgdGhhdCBkaXN0aW5ndWlzaCB0aGUgd3JpdHRlbiBmb3JtcyBvZiBhIGxhbmd1YWdlIG9y IGl0cw0KICAgZGlhbGVjdHMuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBz Y3JpcHQgc3VidGFnczoNCg0KICAgMS4gIEFsbCBmb3VyLWNoYXJhY3RlciBzdWJ0YWdzIHdl cmUgZGVmaW5lZCBhY2NvcmRpbmcgdG8NCiAgICAgICBbSVNPMTU5MjRdLS0iQ29kZXMgZm9y IHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgbmFtZXMgb2YNCiAgICAgICBzY3JpcHRzIjog YWxwaGEtNCBzY3JpcHQgY29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUN CiAgICAgICBJU08gMTU5MjQgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFu ZGFyZGl6YXRpb24gYm9kaWVzLA0KICAgICAgIGRlbm90aW5nIHRoZSBzY3JpcHQgb3Igd3Jp dGluZyBzeXN0ZW0gdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoDQogICAgICAgdGhpcyBsYW5n dWFnZS4NCg0KICAgMi4gIFNjcmlwdCBzdWJ0YWdzIE1VU1QgaW1tZWRpYXRlbHkgZm9sbG93 IHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgc3VidGFnIGFuZCBhbGwgZXh0ZW5kZWQg bGFuZ3VhZ2Ugc3VidGFncyBhbmQgTVVTVCBvY2N1ciBiZWZvcmUNCiAgICAgICBhbnkgb3Ro ZXIgdHlwZSBvZiBzdWJ0YWcgZGVzY3JpYmVkIGJlbG93Lg0KDQogICAzLiAgVGhlIHNjcmlw dCBzdWJ0YWdzICdRYWFhJyB0aHJvdWdoICdRYWJ4JyBhcmUgcmVzZXJ2ZWQgZm9yIHByaXZh dGUNCiAgICAgICB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MgY29ycmVz cG9uZCB0byBjb2RlcyByZXNlcnZlZA0KICAgICAgIGJ5IElTTyAxNTkyNCBmb3IgcHJpdmF0 ZSB1c2UuICBUaGVzZSBjb2RlcyBNQVkgYmUgdXNlZCBmb3Igbm9uLQ0KICAgICAgIHJlZ2lz dGVyZWQgc2NyaXB0IHZhbHVlcy4gIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDQuNSBmb3Ig bW9yZQ0KICAgICAgIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAg IDQuICBTY3JpcHQgc3VidGFncyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkIHVzaW5nIHRoZSBw cm9jZXNzIGluDQogICAgICAgU2VjdGlvbiAzLjUgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlh bnQgc3VidGFncyBNQVkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24g Zm9yIHRoYXQgcHVycG9zZS4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg IEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIDUuICBUaGVyZSBNVVNUIGJlIGF0IG1vc3Qgb25l IHNjcmlwdCBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0YWcsIGFuZA0KICAgICAgIHRoZSBzY3Jp cHQgc3VidGFnIFNIT1VMRCBiZSBvbWl0dGVkIHdoZW4gaXQgYWRkcyBubw0KICAgICAgIGRp c3Rpbmd1aXNoaW5nIHZhbHVlIHRvIHRoZSB0YWcgb3Igd2hlbiB0aGUgcHJpbWFyeSBsYW5n dWFnZQ0KICAgICAgIHN1YnRhZydzIHJlY29yZCBpbmNsdWRlcyBhIFN1cHByZXNzLVNjcmlw dCBmaWVsZCBsaXN0aW5nIHRoZQ0KICAgICAgIGFwcGxpY2FibGUgc2NyaXB0IHN1YnRhZy4N Cg0KICAgRXhhbXBsZTogInNyLUxhdG4iIHJlcHJlc2VudHMgU2VyYmlhbiB3cml0dGVuIHVz aW5nIHRoZSBMYXRpbiBzY3JpcHQuDQoNCjIuMi40LiAgUmVnaW9uIFN1YnRhZw0KDQogICBS ZWdpb24gc3VidGFncyBhcmUgdXNlZCB0byBpbmRpY2F0ZSBsaW5ndWlzdGljIHZhcmlhdGlv bnMgYXNzb2NpYXRlZA0KICAgd2l0aCBvciBhcHByb3ByaWF0ZSB0byBhIHNwZWNpZmljIGNv dW50cnksIHRlcnJpdG9yeSwgb3IgcmVnaW9uLg0KICAgVHlwaWNhbGx5LCBhIHJlZ2lvbiBz dWJ0YWcgaXMgdXNlZCB0byBpbmRpY2F0ZSByZWdpb25hbCBkaWFsZWN0cyBvcg0KICAgdXNh Z2UsIG9yIHJlZ2lvbi1zcGVjaWZpYyBzcGVsbGluZyBjb252ZW50aW9ucy4gIEEgcmVnaW9u IHN1YnRhZyBjYW4NCiAgIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IGNvbnRlbnQg aXMgZXhwcmVzc2VkIGluIGEgd2F5IHRoYXQgaXMNCiAgIGFwcHJvcHJpYXRlIGZvciB1c2Ug dGhyb3VnaG91dCBhIHJlZ2lvbiwgZm9yIGluc3RhbmNlLCBTcGFuaXNoDQogICBjb250ZW50 IHRhaWxvcmVkIHRvIGJlIHVzZWZ1bCB0aHJvdWdob3V0IExhdGluIEFtZXJpY2EuDQoNCiAg IFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIHJlZ2lvbiBzdWJ0YWdzOg0KDQog ICAxLiAgUmVnaW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRl ZCBsYW5ndWFnZSwgb3INCiAgICAgICBzY3JpcHQgc3VidGFncyBhbmQgTVVTVCBwcmVjZWRl IGFsbCBvdGhlciBzdWJ0YWdzLg0KDQogICAyLiAgQWxsIHR3by1jaGFyYWN0ZXIgc3VidGFn cyBmb2xsb3dpbmcgdGhlIHByaW1hcnkgc3VidGFnIHdlcmUNCiAgICAgICBkZWZpbmVkIGlu IHRoZSBJQU5BIHJlZ2lzdHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQN CiAgICAgICBpbiBbSVNPMzE2Ni0xXSAoIkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24g b2YgbmFtZXMgb2YNCiAgICAgICBjb3VudHJpZXMgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAt LSBQYXJ0IDE6IENvdW50cnkgY29kZXMiKSB1c2luZw0KICAgICAgIHRoZSBsaXN0IG9mIGFs cGhhLTIgY291bnRyeSBjb2Rlcywgb3IgdXNpbmcgYXNzaWdubWVudHMNCiAgICAgICBzdWJz ZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDMxNjYgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdv dmVybmluZw0KICAgICAgIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuICBJbiBhZGRpdGlvbiwg dGhlIGNvZGVzIHRoYXQgYXJlDQogICAgICAgImV4Y2VwdGlvbmFsbHkgcmVzZXJ2ZWQiIChh cyBvcHBvc2VkIHRvICJhc3NpZ25lZCIpIGluIElTTyAzMTY2LTENCiAgICAgICB3ZXJlIGFs c28gZGVmaW5lZCBpbiB0aGUgcmVnaXN0cnksIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiAnVUsn LA0KICAgICAgIHdoaWNoIGlzIGFuIGV4YWN0IHN5bm9ueW0gZm9yIHRoZSBhc3NpZ25lZCBj b2RlICdHQicuDQoNCiAgIDMuICBBbGwgdGhyZWUtY2hhcmFjdGVyIHN1YnRhZ3MgY29uc2lz dGluZyBvZiBkaWdpdCAobnVtZXJpYykNCiAgICAgICBjaGFyYWN0ZXJzIGZvbGxvd2luZyB0 aGUgcHJpbWFyeSBzdWJ0YWcgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVn aXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBVTiBTdGFuZGFy ZA0KICAgICAgIENvdW50cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIFtV Tl9NLjQ5XSBvcg0KICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRseSBtYWRlIGJ5IHRo ZSBnb3Zlcm5pbmcgc3RhbmRhcmRzIGJvZHkuDQogICAgICAgTm90ZSB0aGF0IG5vdCBhbGwg b2YgdGhlIFVOIE0uNDkgY29kZXMgYXJlIGRlZmluZWQgaW4gdGhlIElBTkENCiAgICAgICBy ZWdpc3RyeS4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgZGVmaW5lIHdoaWNoIGNvZGVzIGFyZSBl bnRlcmVkDQogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFsaWQgc3VidGFnczoNCg0K ICAgICAgIEEuICBVTiBudW1lcmljIGNvZGVzIGFzc2lnbmVkIHRvICdtYWNyby1nZW9ncmFw aGljYWwNCiAgICAgICAgICAgKGNvbnRpbmVudGFsKScgb3Igc3ViLXJlZ2lvbnMgTVVTVCBi ZSByZWdpc3RlcmVkIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeS4gIFRoZXNlIGNvZGVz IGFyZSBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElTTyAz MTY2IGFscGhhLTIgY29kZSBhbmQgcmVwcmVzZW50IHN1cHJhLW5hdGlvbmFsIGFyZWFzLA0K ICAgICAgICAgICB1c3VhbGx5IGNvdmVyaW5nIG1vcmUgdGhhbiBvbmUgbmF0aW9uLCBzdGF0 ZSwgcHJvdmluY2UsIG9yDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGly ZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwNw0KDQoNCiAgICAgICAgICAgdGVycml0b3J5Lg0KDQogICAgICAgQi4gIFVO IG51bWVyaWMgY29kZXMgZm9yICdlY29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlcg0KICAg ICAgICAgICBncm91cGluZ3MnIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkEg cmVnaXN0cnkgYW5kDQogICAgICAgICAgIE1VU1QgTk9UIGJlIHVzZWQgdG8gZm9ybSBsYW5n dWFnZSB0YWdzLg0KDQogICAgICAgQy4gIFVOIG51bWVyaWMgY29kZXMgZm9yIGNvdW50cmll cyBvciBhcmVhcyB3aXRoIGFtYmlndW91cyBJU08NCiAgICAgICAgICAgMzE2NiBhbHBoYS0y IGNvZGVzLCB3aGVuIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnksIE1VU1QgYmUNCiAgICAg ICAgICAgZGVmaW5lZCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIFNlY3Rpb24gMy40IGFu ZCBNVVNUIGJlDQogICAgICAgICAgIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHRoYXQg cmVwcmVzZW50IHRoZSBjb3VudHJ5IG9yDQogICAgICAgICAgIHJlZ2lvbiBmb3Igd2hpY2gg dGhleSBhcmUgZGVmaW5lZC4NCg0KICAgICAgIEQuICBVTiBudW1lcmljIGNvZGVzIGZvciBj b3VudHJpZXMgb3IgYXJlYXMgZm9yIHdoaWNoIHRoZXJlIGlzIGFuDQogICAgICAgICAgIGFz c29jaWF0ZWQgSVNPIDMxNjYgYWxwaGEtMiBjb2RlIGluIHRoZSByZWdpc3RyeSBNVVNUIE5P VCBiZQ0KICAgICAgICAgICBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBNVVNUIE5P VCBiZSB1c2VkIHRvIGZvcm0NCiAgICAgICAgICAgbGFuZ3VhZ2UgdGFncy4gIE5vdGUgdGhh dCB0aGUgSVNPIDMxNjYtYmFzZWQgc3VidGFnIGluIHRoZQ0KICAgICAgICAgICByZWdpc3Ry eSBNVVNUIGFjdHVhbGx5IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgVU4gTS40OSBjb2RlIGlu DQogICAgICAgICAgIHF1ZXN0aW9uLg0KDQogICAgICAgRS4gIFVOIG51bWVyaWMgY29kZXMg YW5kIElTTyAzMTY2IGFscGhhLTIgY29kZXMgZm9yIGNvdW50cmllcyBvcg0KICAgICAgICAg ICBhcmVhcyBsaXN0ZWQgYXMgZWxpZ2libGUgZm9yIHJlZ2lzdHJhdGlvbiBpbiBbUkZDNDY0 NV0gYnV0DQogICAgICAgICAgIG5vdCBwcmVzZW50bHkgcmVnaXN0ZXJlZCBNQVkgYmUgZW50 ZXJlZCBpbnRvIHRoZSBJQU5BDQogICAgICAgICAgIHJlZ2lzdHJ5IHZpYSB0aGUgcHJvY2Vz cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUuICBPbmNlDQogICAgICAgICAgIHJlZ2lzdGVy ZWQsIHRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0K ICAgICAgIEYuICBBbGwgb3RoZXIgVU4gbnVtZXJpYyBjb2RlcyBmb3IgY291bnRyaWVzIG9y IGFyZWFzIHRoYXQgZG8gbm90DQogICAgICAgICAgIGhhdmUgYW4gYXNzb2NpYXRlZCBJU08g MzE2NiBhbHBoYS0yIGNvZGUgTVVTVCBOT1QgYmUgZW50ZXJlZA0KICAgICAgICAgICBpbnRv IHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRh Z3MuDQogICAgICAgICAgIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZXNlIGNvZGVz LCBzZWUgU2VjdGlvbiAzLjQuDQoNCiAgIDQuICBOb3RlOiBUaGUgYWxwaGFudW1lcmljIGNv ZGVzIGluIEFwcGVuZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50DQogICAgICAgTVVTVCBOT1Qg YmUgZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhbmQgTVVTVCBOT1QgYmUgdXNlZCB0bw0K ICAgICAgIGZvcm0gbGFuZ3VhZ2UgdGFncy4gIChBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50 IHdhcyBjcmVhdGVkLA0KICAgICAgIHRoZXNlIHZhbHVlcyBtYXRjaGVkIHRoZSBJU08gMzE2 NiBhbHBoYS0yIGNvZGVzLikNCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9zdCBvbmUg cmVnaW9uIHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgcmVnaW9u IHN1YnRhZyBNQVkgYmUgb21pdHRlZCwgYXMgd2hlbiBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNo aW5nDQogICAgICAgdmFsdWUgdG8gdGhlIHRhZy4NCg0KICAgNi4gIFRoZSByZWdpb24gc3Vi dGFncyAnQUEnLCAnUU0nLSdRWicsICdYQSctJ1haJywgYW5kICdaWicgYXJlDQogICAgICAg cmVzZXJ2ZWQgZm9yIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0 YWdzDQogICAgICAgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZCBieSBJU08gMzE2NiBm b3IgcHJpdmF0ZSB1c2UuICBUaGVzZQ0KICAgICAgIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBw cml2YXRlIHVzZSByZWdpb24gc3VidGFncyAoaW5zdGVhZCBvZg0KICAgICAgIHVzaW5nIGEg cHJpdmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNlKS4gIFBsZWFzZSByZWZlciB0bw0KICAgICAg IFNlY3Rpb24gNC41IGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRh Z3MuDQoNCiAgICJkZS1DSCIgcmVwcmVzZW50cyBHZXJtYW4gKCdkZScpIGFzIHVzZWQgaW4g U3dpdHplcmxhbmQgKCdDSCcpLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAg IEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICJzci1MYXRuLVJTIiByZXByZXNlbnRzIFNlcmJp YW4gKCdzcicpIHdyaXR0ZW4gdXNpbmcgTGF0aW4gc2NyaXB0DQogICAoJ0xhdG4nKSBhcyB1 c2VkIGluIFNlcmJpYSAoJ1JTJykuDQoNCiAgICJlcy00MTkiIHJlcHJlc2VudHMgU3Bhbmlz aCAoJ2VzJykgYXBwcm9wcmlhdGUgdG8gdGhlIFVOLWRlZmluZWQNCiAgIExhdGluIEFtZXJp Y2EgYW5kIENhcmliYmVhbiByZWdpb24gKCc0MTknKS4NCg0KMi4yLjUuICBWYXJpYW50IFN1 YnRhZ3MNCg0KICAgVmFyaWFudCBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIGFkZGl0 aW9uYWwsIHdlbGwtcmVjb2duaXplZA0KICAgdmFyaWF0aW9ucyB0aGF0IGRlZmluZSBhIGxh bmd1YWdlIG9yIGl0cyBkaWFsZWN0cyB0aGF0IGFyZSBub3QNCiAgIGNvdmVyZWQgYnkgb3Ro ZXIgYXZhaWxhYmxlIHN1YnRhZ3MuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRo ZQ0KICAgdmFyaWFudCBzdWJ0YWdzOg0KDQogICAxLiAgVmFyaWFudCBzdWJ0YWdzIGFyZSBu b3QgYXNzb2NpYXRlZCB3aXRoIGFueSBleHRlcm5hbCBzdGFuZGFyZC4NCiAgICAgICBWYXJp YW50IHN1YnRhZ3MgYW5kIHRoZWlyIG1lYW5pbmdzIGFyZSBkZWZpbmVkIGJ5IHRoZQ0KICAg ICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjUuDQoNCiAg IDIuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxsIG9mIHRoZSBvdGhlciBkZWZp bmVkIHN1YnRhZ3MsIGJ1dA0KICAgICAgIHByZWNlZGUgYW55IGV4dGVuc2lvbiBvciBwcml2 YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAzLiAgTW9yZSB0aGFuIG9uZSB2YXJp YW50IE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIGxhbmd1YWdlIHRhZy4NCg0KICAgNC4gIFZh cmlhbnQgc3VidGFncyBNVVNUIGJlIHJlZ2lzdGVyZWQgd2l0aCBJQU5BIGFjY29yZGluZyB0 byB0aGUNCiAgICAgICBydWxlcyBpbiBTZWN0aW9uIDMuNSBvZiB0aGlzIGRvY3VtZW50IGJl Zm9yZSBiZWluZyB1c2VkIHRvIGZvcm0NCiAgICAgICBsYW5ndWFnZSB0YWdzLiAgSW4gb3Jk ZXIgdG8gZGlzdGluZ3Vpc2ggdmFyaWFudHMgZnJvbSBvdGhlciB0eXBlcw0KICAgICAgIG9m IHN1YnRhZ3MsIHJlZ2lzdHJhdGlvbnMgTVVTVCBtZWV0IHRoZSBmb2xsb3dpbmcgbGVuZ3Ro IGFuZA0KICAgICAgIGNvbnRlbnQgcmVzdHJpY3Rpb25zOg0KDQogICAgICAgMS4gIFZhcmlh bnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBsZXR0ZXIgKGEteiwgQS1aKSBNVVNUIGJl DQogICAgICAgICAgIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQogICAgICAg Mi4gIFZhcmlhbnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBkaWdpdCAoMC05KSBNVVNU IGJlIGF0DQogICAgICAgICAgIGxlYXN0IGZvdXIgY2hhcmFjdGVycyBsb25nLg0KDQogICBW YXJpYW50IHN1YnRhZyByZWNvcmRzIGluIHRoZSBsYW5ndWFnZSBzdWJ0YWcgcmVnaXN0cnkg TUFZIGluY2x1ZGUNCiAgIG9uZSBvciBtb3JlICdQcmVmaXgnIGZpZWxkcy4gIFRoZSAnUHJl Zml4JyBpbmRpY2F0ZXMgdGhlIGxhbmd1YWdlIHRhZw0KICAgb3IgdGFncyB0aGF0IHdvdWxk IG1ha2UgYSBzdWl0YWJsZSBwcmVmaXggKHdpdGggb3RoZXIgc3VidGFncywgYXMNCiAgIGFw cHJvcHJpYXRlKSBpbiBmb3JtaW5nIGEgbGFuZ3VhZ2UgdGFnIHdpdGggdGhlIHZhcmlhbnQu ICBUaGF0IGlzLA0KICAgZWFjaCBvZiB0aGUgc3VidGFncyBpbiB0aGUgcHJlZml4IFNIT1VM RCBhcHBlYXIgYmVmb3JlIHRoZSB2YXJpYW50Lg0KICAgRm9yIGV4YW1wbGUsIHRoZSBzdWJ0 YWcgJ25lZGlzJyBoYXMgYSBQcmVmaXggb2YgInNsIiwgbWFraW5nIGl0DQogICBzdWl0YWJs ZSB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgc3VjaCBhcyAic2wtbmVkaXMiIGFuZCAic2wtSVQt bmVkaXMiLA0KICAgYnV0IG5vdCBzdWl0YWJsZSBmb3IgdXNlIGluIGEgdGFnIHN1Y2ggYXMg InpoLW5lZGlzIiBvciAiaXQtSVQtDQogICBuZWRpcyIuDQoNCiAgICJzbC1uZWRpcyIgcmVw cmVzZW50cyB0aGUgTmF0aXNvbmUgb3IgTmFkaXphIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLg0K DQogICAiZGUtQ0gtMTk5NiIgcmVwcmVzZW50cyBHZXJtYW4gYXMgdXNlZCBpbiBTd2l0emVy bGFuZCBhbmQgYXMgd3JpdHRlbg0KICAgdXNpbmcgdGhlIHNwZWxsaW5nIHJlZm9ybSBiZWdp bm5pbmcgaW4gdGhlIHllYXIgMTk5NiBDLkUuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxNV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIE1vc3QgdmFyaWFudHMgdGhhdCBzaGFy ZSBhIHByZWZpeCBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiAgRm9yDQogICBleGFtcGxlLCB0 aGUgR2VybWFuIG9ydGhvZ3JhcGhpYyB2YXJpYXRpb25zICcxOTk2JyBhbmQgJzE5MDEnIFNI T1VMRA0KICAgTk9UIGJlIHVzZWQgaW4gdGhlIHNhbWUgdGFnLCBhcyB0aGV5IHJlcHJlc2Vu dCB0aGUgZGF0ZXMgb2YgZGlmZmVyZW50DQogICBzcGVsbGluZyByZWZvcm1zLiAgQSB2YXJp YW50IHRoYXQgY2FuIG1lYW5pbmdmdWxseSBiZSB1c2VkIGluDQogICBjb21iaW5hdGlvbiB3 aXRoIGFub3RoZXIgdmFyaWFudCBTSE9VTEQgaW5jbHVkZSBhICdQcmVmaXgnIGZpZWxkIGlu DQogICBpdHMgcmVnaXN0cnkgcmVjb3JkIHRoYXQgbGlzdHMgdGhhdCBvdGhlciB2YXJpYW50 LiAgRm9yIGV4YW1wbGUsIGlmDQogICBhbm90aGVyIEdlcm1hbiB2YXJpYW50ICdleGFtcGxl JyB3ZXJlIGNyZWF0ZWQgdGhhdCBtYWRlIHNlbnNlIHRvIHVzZQ0KICAgd2l0aCAnMTk5Nics IHRoZW4gJ2V4YW1wbGUnIHNob3VsZCBpbmNsdWRlIHR3byBQcmVmaXggZmllbGRzOiAiZGUi DQogICBhbmQgImRlLTE5OTYiLg0KDQoyLjIuNi4gIEV4dGVuc2lvbiBTdWJ0YWdzDQoNCiAg IEV4dGVuc2lvbnMgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgZXh0ZW5kaW5nIGxhbmd1YWdl IHRhZ3MgZm9yIHVzZSBpbg0KICAgdmFyaW91cyBhcHBsaWNhdGlvbnMuICBTZWUgU2VjdGlv biAzLjcuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvDQogICBleHRlbnNpb25zOg0K DQogICAxLiAgIEV4dGVuc2lvbiBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3Ro ZXIgc3VidGFncyBkZWZpbmVkDQogICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5n bGUtY2hhcmFjdGVyIHN1YnRhZyAoInNpbmdsZXRvbiIpLg0KICAgICAgICBUaGUgc2luZ2xl dG9uIE1VU1QgYmUgb25lIGFsbG9jYXRlZCB0byBhIHJlZ2lzdHJhdGlvbiBhdXRob3JpdHkN CiAgICAgICAgdmlhIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gMy43IGFu ZCBNVVNUIE5PVCBiZSB0aGUNCiAgICAgICAgbGV0dGVyICd4Jywgd2hpY2ggaXMgcmVzZXJ2 ZWQgZm9yIHByaXZhdGUgdXNlIHN1YnRhZyBzZXF1ZW5jZXMuDQoNCiAgIDIuICAgTm90ZTog UHJpdmF0ZSB1c2Ugc3VidGFnIHNlcXVlbmNlcyBzdGFydGluZyB3aXRoIHRoZSBzaW5nbGV0 b24NCiAgICAgICAgc3VidGFnICd4JyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4yLjcg YmVsb3cuDQoNCiAgIDMuICAgQW4gZXh0ZW5zaW9uIE1VU1QgZm9sbG93IGF0IGxlYXN0IGEg cHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcuDQogICAgICAgIFRoYXQgaXMsIGEgbGFuZ3VhZ2Ug dGFnIGNhbm5vdCBiZWdpbiB3aXRoIGFuIGV4dGVuc2lvbi4NCiAgICAgICAgRXh0ZW5zaW9u cyBleHRlbmQgbGFuZ3VhZ2UgdGFncywgdGhleSBkbyBub3Qgb3ZlcnJpZGUgb3IgcmVwbGFj ZQ0KICAgICAgICB0aGVtLiAgRm9yIGV4YW1wbGUsICJhLXZhbHVlIiBpcyBub3QgYSB3ZWxs LWZvcm1lZCBsYW5ndWFnZSB0YWcsDQogICAgICAgIHdoaWxlICJkZS1hLXZhbHVlIiBpcy4N Cg0KICAgNC4gICBFYWNoIHNpbmdsZXRvbiBzdWJ0YWcgTVVTVCBhcHBlYXIgYXQgbW9zdCBv bmUgdGltZSBpbiBlYWNoIHRhZw0KICAgICAgICAob3RoZXIgdGhhbiBhcyBhIHByaXZhdGUg dXNlIHN1YnRhZykuICBUaGF0IGlzLCBzaW5nbGV0b24NCiAgICAgICAgc3VidGFncyBNVVNU IE5PVCBiZSByZXBlYXRlZC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJlbi1hLWJiYi1hLQ0K ICAgICAgICBjY2MiIGlzIGludmFsaWQgYmVjYXVzZSB0aGUgc3VidGFnICdhJyBhcHBlYXJz IHR3aWNlLiAgTm90ZSB0aGF0DQogICAgICAgIHRoZSB0YWcgImVuLWEtYmJiLXgtYS1jY2Mi IGlzIHZhbGlkIGJlY2F1c2UgdGhlIHNlY29uZA0KICAgICAgICBhcHBlYXJhbmNlIG9mIHRo ZSBzaW5nbGV0b24gJ2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ugc2VxdWVuY2UuDQoNCiAgIDUu ICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IGFsbCBvZiB0aGUgcmVxdWlyZW1lbnRz IGZvciB0aGUNCiAgICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICA2LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1Qg bWVldCB3aGF0ZXZlciByZXF1aXJlbWVudHMgYXJlIHNldCBieSB0aGUNCiAgICAgICAgZG9j dW1lbnQgdGhhdCBkZWZpbmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVy DQogICAgICAgIHJlcXVpcmVtZW50cyBhcmUgcHJvdmlkZWQgYnkgdGhlIG1haW50YWluaW5n IGF1dGhvcml0eS4NCg0KICAgNy4gICBFYWNoIGV4dGVuc2lvbiBzdWJ0YWcgTVVTVCBiZSBm cm9tIHR3byB0byBlaWdodCBjaGFyYWN0ZXJzIGxvbmcNCiAgICAgICAgYW5kIGNvbnNpc3Qg c29sZWx5IG9mIGxldHRlcnMgb3IgZGlnaXRzLCB3aXRoIGVhY2ggc3VidGFnDQogICAgICAg IHNlcGFyYXRlZCBieSBhIHNpbmdsZSAnLScuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxNl0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIDguICAgRWFjaCBzaW5nbGV0b24gTVVT VCBiZSBmb2xsb3dlZCBieSBhdCBsZWFzdCBvbmUgZXh0ZW5zaW9uDQogICAgICAgIHN1YnRh Zy4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJ0bGgtYS1iLWZvbyIgaXMgaW52YWxpZCBiZWNh dXNlDQogICAgICAgIHRoZSBmaXJzdCBzaW5nbGV0b24gJ2EnIGlzIGZvbGxvd2VkIGltbWVk aWF0ZWx5IGJ5IGFub3RoZXINCiAgICAgICAgc2luZ2xldG9uICdiJy4NCg0KICAgOS4gICBF eHRlbnNpb24gc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxh bmd1YWdlLA0KICAgICAgICBzY3JpcHQsIHJlZ2lvbiwgYW5kIHZhcmlhbnQgc3VidGFncyBp biBhIHRhZy4NCg0KICAgMTAuICBBbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlIHNpbmdsZXRv biBhbmQgYmVmb3JlIGFub3RoZXIgc2luZ2xldG9uDQogICAgICAgIGFyZSBwYXJ0IG9mIHRo ZSBleHRlbnNpb24uICBFeGFtcGxlOiBJbiB0aGUgdGFnICJmci1hLUxhdG4iLCB0aGUNCiAg ICAgICAgc3VidGFnICdMYXRuJyBkb2VzIG5vdCByZXByZXNlbnQgdGhlIHNjcmlwdCBzdWJ0 YWcgJ0xhdG4nDQogICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFn IFJlZ2lzdHJ5LiAgSXRzIG1lYW5pbmcgaXMNCiAgICAgICAgZGVmaW5lZCBieSB0aGUgZXh0 ZW5zaW9uICdhJy4NCg0KICAgMTEuICBJbiB0aGUgZXZlbnQgdGhhdCBtb3JlIHRoYW4gb25l IGV4dGVuc2lvbiBhcHBlYXJzIGluIGEgc2luZ2xlDQogICAgICAgIHRhZywgdGhlIHRhZyBT SE9VTEQgYmUgY2Fub25pY2FsaXplZCBhcyBkZXNjcmliZWQgaW4NCiAgICAgICAgU2VjdGlv biA0LjQuDQoNCiAgIEZvciBleGFtcGxlLCBpZiB0aGUgcHJlZml4IHNpbmdsZXRvbiAncicg YW5kIHRoZSBzaG93biBzdWJ0YWdzIHdlcmUNCiAgIGRlZmluZWQsIHRoZW4gdGhlIGZvbGxv d2luZyB0YWcgd291bGQgYmUgYSB2YWxpZCBleGFtcGxlOiAiZW4tTGF0bi0NCiAgIEdCLWJv b250LXItZXh0ZW5kZWQtc2VxdWVuY2UteC1wcml2YXRlIg0KDQoyLjIuNy4gIFByaXZhdGUg VXNlIFN1YnRhZ3MNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUgdXNlZCB0byBpbmRp Y2F0ZSBkaXN0aW5jdGlvbnMgaW4gbGFuZ3VhZ2UNCiAgIGltcG9ydGFudCBpbiBhIGdpdmVu IGNvbnRleHQgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQuICBUaGUgZm9sbG93aW5nDQogICBydWxl cyBhcHBseSB0byBwcml2YXRlIHVzZSBzdWJ0YWdzOg0KDQogICAxLiAgUHJpdmF0ZSB1c2Ug c3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0K ICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHJlc2VydmVkIHNpbmdsZS1jaGFyYWN0 ZXIgc3VidGFnICd4Jy4NCg0KICAgMi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgTVVTVCBjb25m b3JtIHRvIHRoZSBmb3JtYXQgYW5kIGNvbnRlbnQNCiAgICAgICBjb25zdHJhaW50cyBkZWZp bmVkIGluIHRoZSBBQk5GIGZvciBhbGwgc3VidGFncy4NCg0KICAgMy4gIFByaXZhdGUgdXNl IHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwN CiAgICAgICBzY3JpcHQsIHJlZ2lvbiwgdmFyaWFudCwgYW5kIGV4dGVuc2lvbiBzdWJ0YWdz IGluIHRoZSB0YWcuDQogICAgICAgQW5vdGhlciB3YXkgb2Ygc2F5aW5nIHRoaXMgaXMgdGhh dCBhbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlDQogICAgICAgc2luZ2xldG9uICd4JyBNVVNU IGJlIGNvbnNpZGVyZWQgcHJpdmF0ZSB1c2UuICBFeGFtcGxlOiBUaGUNCiAgICAgICBzdWJ0 YWcgJ1VTJyBpbiB0aGUgdGFnICJlbi14LVVTIiBpcyBhIHByaXZhdGUgdXNlIHN1YnRhZy4N Cg0KICAgNC4gIEEgdGFnIE1BWSBjb25zaXN0IGVudGlyZWx5IG9mIHByaXZhdGUgdXNlIHN1 YnRhZ3MuDQoNCiAgIDUuICBObyBzb3VyY2UgaXMgZGVmaW5lZCBmb3IgcHJpdmF0ZSB1c2Ug c3VidGFncy4gIFVzZSBvZiBwcml2YXRlIHVzZQ0KICAgICAgIHN1YnRhZ3MgaXMgYnkgcHJp dmF0ZSBhZ3JlZW1lbnQgb25seS4NCg0KICAgNi4gIFByaXZhdGUgdXNlIHN1YnRhZ3MgYXJl IE5PVCBSRUNPTU1FTkRFRCB3aGVyZSBhbHRlcm5hdGl2ZXMgZXhpc3QNCiAgICAgICBvciBm b3IgZ2VuZXJhbCBpbnRlcmNoYW5nZS4gIFNlZSBTZWN0aW9uIDQuNSBmb3IgbW9yZSBpbmZv cm1hdGlvbg0KICAgICAgIG9uIHByaXZhdGUgdXNlIHN1YnRhZyBjaG9pY2UuDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAg ICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIEZvciBl eGFtcGxlOiBVc2VycyB3aG8gd2lzaGVkIHRvIHV0aWxpemUgY29kZXMgZnJvbSB0aGUgRXRo bm9sb2d1ZQ0KICAgcHVibGljYXRpb24gb2YgU0lMIEludGVybmF0aW9uYWwgZm9yIGxhbmd1 YWdlIGlkZW50aWZpY2F0aW9uIG1pZ2h0DQogICBhZ3JlZSB0byBleGNoYW5nZSB0YWdzIHN1 Y2ggYXMgImF6LUFyYWIteC1BWkUtZGVyYmVuZCIuICBUaGlzIGV4YW1wbGUNCiAgIGNvbnRh aW5zIHR3byBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVGhlIGZpcnN0IGlzICdBWkUnIGFuZCB0 aGUgc2Vjb25kDQogICBpcyAnZGVyYmVuZCcuDQoNCjIuMi44LiAgR3JhbmRmYXRoZXJlZCBS ZWdpc3RyYXRpb25zDQoNCiAgIFByaW9yIHRvIFJGQyA0NjQ2LCB3aG9sZSBsYW5ndWFnZSB0 YWdzIHdlcmUgcmVnaXN0ZXJlZCBhY2NvcmRpbmcgdG8NCiAgIHRoZSBydWxlcyBpbiBSRkMg MTc2NiBhbmQvb3IgUkZDIDMwNjYuICBUaGVzZSByZWdpc3RlcmVkIHRhZ3MNCiAgIG1haW50 YWluIHRoZWlyIHZhbGlkaXR5LiAgT2YgdGhvc2UgdGFncywgdGhvc2UgdGhhdCB3ZXJlIG1h ZGUNCiAgIG9ic29sZXRlIG9yIHJlZHVuZGFudCBieSB0aGUgYWR2ZW50IG9mIFJGQyA0NjQ2 LCBieSB0aGlzIGRvY3VtZW50LCBvcg0KICAgYnkgc3Vic2VxdWVudCByZWdpc3RyYXRpb24g b2Ygc3VidGFncyBhcmUgbWFpbnRhaW5lZCBpbiB0aGUgcmVnaXN0cnkNCiAgIGluIHJlY29y ZHMgYXMgInJlZHVuZGFudCIgcmVjb3Jkcy4gIFRob3NlIHRhZ3MgdGhhdCBkbyBub3QgbWF0 Y2ggdGhlDQogICAnbGFuZ3RhZycgcHJvZHVjdGlvbiBpbiB0aGUgQUJORiBpbiB0aGlzIGRv Y3VtZW50IG9yIHRoYXQgY29udGFpbg0KICAgc3VidGFncyB0aGF0IGRvIG5vdCBpbmRpdmlk dWFsbHkgYXBwZWFyIGluIHRoZSByZWdpc3RyeSBhcmUNCiAgIG1haW50YWluZWQgaW4gdGhl IHJlZ2lzdHJ5IGluIHJlY29yZHMgb2YgdGhlICJncmFuZGZhdGhlcmVkIiB0eXBlLg0KDQog ICBHcmFuZGZhdGhlcmVkIHRhZ3MgY29udGFpbiBvbmUgb3IgbW9yZSBzdWJ0YWdzIHRoYXQg YXJlIG5vdCBkZWZpbmVkDQogICBpbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IChz ZWUgU2VjdGlvbiAzKS4gIFJlZHVuZGFudCB0YWdzDQogICBjb25zaXN0IGVudGlyZWx5IG9m IHN1YnRhZ3MgZGVmaW5lZCBhYm92ZSBhbmQgd2hvc2UgaW5kZXBlbmRlbnQNCiAgIHJlZ2lz dHJhdGlvbiB3YXMgc3VwZXJzZWRlZCBieSBbUkZDNDY0Nl0uICBGb3IgbW9yZSBpbmZvcm1h dGlvbiBzZWUNCiAgIFNlY3Rpb24gMy44Lg0KDQogICBTb21lIGdyYW5kZmF0aGVyZWQgdGFn cyBhcmUgInJlZ3VsYXIiIGluIHRoYXQgdGhleSBtYXRjaCB0aGUNCiAgICdsYW5ndGFnJyBw cm9kdWN0aW9uIGluIEZpZ3VyZSAxLiAgSW4gc29tZSBjYXNlcywgdGhlc2UgdGFncyBjb3Vs ZA0KICAgYmVjb21lIHJlZHVuZGFudCBpZiB0aGVpciAoY3VycmVudCB1bnJlZ2lzdGVyZWQp IHN1YnRhZ3Mgd2VyZSB0byBiZQ0KICAgcmVnaXN0ZXJlZCAoYXMgdmFyaWFudHMsIGZvciBl eGFtcGxlKS4gIEluIG90aGVyIGNhc2VzLCBhbHRob3VnaCB0aGUNCiAgIHN1YnRhZ3MgbWF0 Y2ggdGhlIGxhbmd1YWdlIHRhZyBwYXR0ZXJuLCB0aGUgbWVhbmluZyBhc3NpZ25lZCB0byB0 aGUNCiAgIHZhcmlvdXMgc3VidGFncyBpcyBwcm9oaWJpdGVkIGJ5IHJ1bGVzIGVsc2V3aGVy ZSBpbiB0aGlzIGRvY3VtZW50Lg0KICAgVGhvc2UgdGFncyBjYW4gbmV2ZXIgYmVjb21lIHJl ZHVuZGFudC4NCg0KICAgVGhlIHJlbWFpbmluZyBncmFuZGZhdGhlcmVkIHRhZ3MgYXJlICJp cnJlZ3VsYXIiIGFuZCBkbyBub3QgbWF0Y2ggdGhlDQogICAnbGFuZ3RhZycgcHJvZHVjdGlv bi4gIFRoZXNlIGFyZSBsaXN0ZWQgaW4gdGhlICdpcnJlZ3VsYXInIHByb2R1Y3Rpb24NCiAg IGluIEZpZ3VyZSAxLiAgVGhlc2UgZ3JhbmRmYXRoZXJlZCB0YWdzIGNhbiBuZXZlciBiZWNv bWUgcmVkdW5kYW50Lg0KICAgTWFueSBvZiB0aGVzZSB0YWdzIGhhdmUgYmVlbiBzdXBlcnNl ZGVkIGJ5IG90aGVyIHJlZ2lzdHJhdGlvbnM6IHRoZWlyDQogICByZWNvcmQgY29udGFpbnMg YSBQcmVmZXJyZWQtVmFsdWUgZmllbGQgdGhhdCByZWFsbHkgb3VnaHQgdG8gYmUgdXNlZA0K ICAgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHJlcHJlc2VudGluZyB0aGF0IHZhbHVlLg0KDQoy LjIuOS4gIENsYXNzZXMgb2YgQ29uZm9ybWFuY2UNCg0KICAgSW1wbGVtZW50YXRpb25zIHNv bWV0aW1lcyBuZWVkIHRvIGRlc2NyaWJlIHRoZWlyIGNhcGFiaWxpdGllcyB3aXRoDQogICBy ZWdhcmQgdG8gdGhlIHJ1bGVzIGFuZCBwcmFjdGljZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQuICBUYWdzDQogICBjYW4gYmUgY2hlY2tlZCBvciB2ZXJpZmllZCBpbiBhIG51bWJl ciBvZiB3YXlzLCBidXQgdHdvIHBhcnRpY3VsYXINCiAgIGNsYXNzZXMgb2YgdGFnIGNvbmZv cm1hbmNlIGFyZSBmb3JtYWxseSBkZWZpbmVkIGhlcmUuDQoNCiAgIEEgdGFnIGlzIGNvbnNp ZGVyZWQgIndlbGwtZm9ybWVkIiBpZiBpdCBjb25mb3JtcyB0byB0aGUgQUJORg0KICAgKFNl Y3Rpb24gMi4xKS4gIE5vdGUgdGhhdCBpcnJlZ3VsYXIgZ3JhbmRmYXRoZXJlZCB0YWdzIGFy ZSBub3cgbGlzdGVkDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMg TWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwNw0KDQoNCiAgIGluIHRoZSAnaXJyZWd1bGFyJyBwcm9kdWN0aW9uLg0KDQogICBB IHRhZyBpcyBjb25zaWRlcmVkICJ2YWxpZCIgaWYgaXQgd2VsbC1mb3JtZWQgYW5kIGl0IGFs c28gc2F0aXNmaWVzDQogICB0aGVzZSBjb25kaXRpb25zOg0KDQogICBvICBUaGUgdGFnIGlz IGVpdGhlciBhIGdyYW5kZmF0aGVyZWQgdGFnLCBvciBhbGwgb2YgaXRzIGxhbmd1YWdlLA0K ICAgICAgZXh0ZW5kZWQgbGFuZ3VhZ2UsIHNjcmlwdCwgcmVnaW9uLCBhbmQgdmFyaWFudCBz dWJ0YWdzIGFwcGVhciBpbg0KICAgICAgdGhlIElBTkEgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lz dHJ5IGFzIG9mIHRoZSBwYXJ0aWN1bGFyIHJlZ2lzdHJ5DQogICAgICBkYXRlLg0KDQogICBv ICBUaGVyZSBhcmUgbm8gZHVwbGljYXRlIHNpbmdsZXRvbiAoZXh0ZW5zaW9uKSBzdWJ0YWdz IGFuZCBubw0KICAgICAgZHVwbGljYXRlIHZhcmlhbnQgc3VidGFncy4NCg0KICAgbyAgRm9y IGVhY2ggc3VidGFnIHRoYXQgaGFzIGEgJ1ByZWZpeCcgZmllbGQgaW4gdGhlIHJlZ2lzdHJ5 LCB0aGUNCiAgICAgIFByZWZpeCBtYXRjaGVzIHRoZSBsYW5ndWFnZSB0YWcgdXNpbmcgRXh0 ZW5kZWQgRmlsdGVyaW5nDQogICAgICBbUkZDNDY0N10uICBUaGF0IGlzLCBlYWNoIHN1YnRh ZyBpbiB0aGUgUHJlZml4IGlzIHByZXNlbnQgaW4gdGhlDQogICAgICB0YWcgYW5kIGluIHRo ZSBzYW1lIG9yZGVyLiAgRnVydGhlcm1vcmUsIGFsbCBvZiB0aGUgUHJlZml4J3MNCiAgICAg IHN1YnRhZ3MgTVVTVCBhcHBlYXIgYmVmb3JlIHRoZSBzdWJ0YWcuICBGb3IgZXhhbXBsZSwg dGhlIFByZWZpeA0KICAgICAgInpoLVRXIiBtYXRjaGVzIHRoZSB0YWcgInpoLUhhbnQtVFci Lg0KDQogICBOb3RlIHRoYXQgYSB0YWcncyB2YWxpZGl0eSBkZXBlbmRzIG9uIHRoZSBkYXRl IG9mIHRoZSByZWdpc3RyeSB1c2VkDQogICB0byB2YWxpZGF0ZSB0aGUgdGFnLiAgQSBtb3Jl LXJlY2VudCBjb3B5IG9mIHRoZSByZWdpc3RyeSBtaWdodA0KICAgY29udGFpbiBhIHN1YnRh ZyB0aGF0IGFuIG9sZGVyIHZlcnNpb24gZG9lcyBub3QuDQoNCiAgIEEgdGFnIGlzIGNvbnNp ZGVyZWQgInZhbGlkIiBmb3IgYSBnaXZlbiBleHRlbnNpb24gKFNlY3Rpb24gMy43KSAoYXMN CiAgIG9mIGEgcGFydGljdWxhciB2ZXJzaW9uLCByZXZpc2lvbiwgYW5kIGRhdGUpIGlmIGl0 IG1lZXRzIHRoZSBjcml0ZXJpYQ0KICAgZm9yICJ2YWxpZCIgYWJvdmUgYW5kIGFsc28gc2F0 aXNmaWVzIHRoaXMgY29uZGl0aW9uOg0KDQogICAgICBFYWNoIHN1YnRhZyB1c2VkIGluIHRo ZSBleHRlbnNpb24gcGFydCBvZiB0aGUgdGFnIGlzIHZhbGlkDQogICAgICBhY2NvcmRpbmcg dG8gdGhlIGV4dGVuc2lvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDgg ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0K My4gIFJlZ2lzdHJ5IEZvcm1hdCBhbmQgTWFpbnRlbmFuY2UNCg0KICAgVGhpcyBzZWN0aW9u IGRlZmluZXMgdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBhbmQgdGhlIG1haW50ZW5h bmNlDQogICBhbmQgdXBkYXRlIHByb2NlZHVyZXMgYXNzb2NpYXRlZCB3aXRoIGl0LCBhcyB3 ZWxsIGFzIGEgcmVnaXN0cnkgZm9yDQogICBleHRlbnNpb25zIHRvIGxhbmd1YWdlIHRhZ3Mg KFNlY3Rpb24gMy43KS4NCg0KICAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSBjb250 YWlucyBhIGNvbXByZWhlbnNpdmUgbGlzdCBvZiBhbGwgb2YNCiAgIHRoZSBzdWJ0YWdzIHZh bGlkIGluIGxhbmd1YWdlIHRhZ3MuICBUaGlzIGFsbG93cyBpbXBsZW1lbnRlcnMgYQ0KICAg c3RyYWlnaHRmb3J3YXJkIGFuZCByZWxpYWJsZSB3YXkgdG8gdmFsaWRhdGUgbGFuZ3VhZ2Ug dGFncy4gIFRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IHdpbGwgYmUgbWFpbnRh aW5lZCBzbyB0aGF0LCBleGNlcHQgZm9yDQogICBleHRlbnNpb24gc3VidGFncywgaXQgaXMg cG9zc2libGUgdG8gdmFsaWRhdGUgYWxsIG9mIHRoZSBzdWJ0YWdzIHRoYXQNCiAgIGFwcGVh ciBpbiBhIGxhbmd1YWdlIHRhZyB1bmRlciB0aGUgcHJvdmlzaW9ucyBvZiB0aGlzIGRvY3Vt ZW50IG9yIGl0cw0KICAgcmV2aXNpb25zIG9yIHN1Y2Nlc3NvcnMuICBJbiBhZGRpdGlvbiwg dGhlIG1lYW5pbmcgb2YgdGhlIHZhcmlvdXMNCiAgIHN1YnRhZ3Mgd2lsbCBiZSB1bmFtYmln dW91cyBhbmQgc3RhYmxlIG92ZXIgdGltZS4gIChUaGUgbWVhbmluZyBvZg0KICAgcHJpdmF0 ZSB1c2Ugc3VidGFncywgb2YgY291cnNlLCBpcyBub3QgZGVmaW5lZCBieSB0aGUgSUFOQSBy ZWdpc3RyeS4pDQoNCjMuMS4gIEZvcm1hdCBvZiB0aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcg UmVnaXN0cnkNCg0KICAgVGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5ICgidGhl IHJlZ2lzdHJ5IikgaXMgYSBtYWNoaW5lLQ0KICAgcmVhZGFibGUgZmlsZSBpbiB0aGUgZm9y bWF0IGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24sIHBsdXMgY29waWVzIG9mDQogICB0aGUg cmVnaXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcHJv Y2Vzcw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LiAgVGhlIGV4aXN0aW5nIHJlZ2lz dHJhdGlvbiBmb3JtcyBmb3INCiAgIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdz IHRha2VuIGZyb20gUkZDIDMwNjYgd2lsbCBiZQ0KICAgbWFpbnRhaW5lZCBhcyBwYXJ0IG9m IHRoZSBvYnNvbGV0ZSBSRkMgMzA2NiByZWdpc3RyeS4gIFRoZSByZW1haW5pbmcNCiAgIHNl dCBvZiBzdWJ0YWdzIGNyZWF0ZWQgYnkgZWl0aGVyIFtSRkM0NjQ1XSBvciBbcmVnaXN0cnkt dXBkYXRlXSB3aWxsDQogICBub3QgaGF2ZSByZWdpc3RyYXRpb24gZm9ybXMgY3JlYXRlZCBm b3IgdGhlbS4NCg0KMy4xLjEuICBGaWxlIEZvcm1hdA0KDQogICBUaGUgcmVnaXN0cnkgY29u c2lzdHMgb2YgYSBzZXJpZXMgb2YgcmVjb3JkcyBzdG9yZWQgaW4gdGhlIHJlY29yZC1qYXIN CiAgIGZvcm1hdCAoZGVzY3JpYmVkIGluIFtyZWNvcmQtamFyXSkuICBFYWNoIHJlY29yZCwg aW4gdHVybiwgY29uc2lzdHMNCiAgIG9mIGEgc2VyaWVzIG9mIGZpZWxkcyB0aGF0IGRlc2Ny aWJlIHRoZSB2YXJpb3VzIHN1YnRhZ3MgYW5kIHRhZ3MuDQogICBUaGUgcmVnaXN0cnkgaXMg YSBVbmljb2RlIFtVbmljb2RlXSB0ZXh0IGZpbGUsIHVzaW5nIHRoZSBVVEYtOA0KICAgW1JG QzM2MjldIGNoYXJhY3RlciBlbmNvZGluZy4NCg0KICAgRWFjaCBmaWVsZCBjYW4gYmUgY29u c2lkZXJlZCBhIHNpbmdsZSwgbG9naWNhbCBsaW5lIG9mIFVuaWNvZGUNCiAgIFtVbmljb2Rl XSBjaGFyYWN0ZXJzLCBjb21wcmlzaW5nIGEgZmllbGQtbmFtZSBhbmQgYSBmaWVsZC1ib2R5 DQogICBzZXBhcmF0ZWQgYnkgYSBDT0xPTiBjaGFyYWN0ZXIgKCV4M0EpLiAgRWFjaCBmaWVs ZCBpcyB0ZXJtaW5hdGVkIGJ5DQogICB0aGUgbmV3bGluZSBzZXF1ZW5jZSBDUkxGLiAgVGhl IHRleHQgaW4gZWFjaCBmaWVsZCBNVVNUIGJlIGluIFVuaWNvZGUNCiAgIE5vcm1hbGl6YXRp b24gRm9ybSBDIChORkMpLg0KDQogICBBIGNvbGxlY3Rpb24gb2YgZmllbGRzIGZvcm1zIGEg J3JlY29yZCcuICBSZWNvcmRzIGFyZSBzZXBhcmF0ZWQgYnkNCiAgIGxpbmVzIGNvbnRhaW5p bmcgb25seSB0aGUgc2VxdWVuY2UgIiUlIiAoJXgyNS4yNSkuDQoNCiAgIEFsdGhvdWdoIGZp ZWxkcyBhcmUgbG9naWNhbGx5IGEgc2luZ2xlIGxpbmUgb2YgdGV4dCwgZWFjaCBsaW5lIG9m DQogICB0ZXh0IGluIHRoZSBmaWxlIGZvcm1hdCBpcyBsaW1pdGVkIHRvIDcyIGJ5dGVzIGlu IGxlbmd0aC4gIFRvDQogICBhY2NvbW1vZGF0ZSB0aGlzLCB0aGUgZmllbGQtYm9keSBjYW4g YmUgc3BsaXQgaW50byBhIG11bHRpcGxlLWxpbmUNCiAgIHJlcHJlc2VudGF0aW9uOyB0aGlz IGlzIGNhbGxlZCAiZm9sZGluZyIuICBGb2xkaW5nIGlzIGFsd2F5cyBkb25lIG9uDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAg ICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIFVu aWNvZGUgY29kZSBwb2ludCBib3VuZGFyaWVzIChuZXZlciBpbiB0aGUgbWlkZGxlIG9mIGEg bXVsdGlieXRlDQogICBVVEYtOCBzZXF1ZW5jZSkgYW5kIE1VU1QgTk9UIG9jY3VyIGp1c3Qg cHJpb3IgdG8gYSBjb21iaW5pbmcgbWFyay4NCg0KICAgQWx0aG91Z2ggdGhlIGZpbGUgZm9y bWF0IHVzZXMgdGhlIFVURi04IGVuY29kaW5nLCB1bmxlc3Mgb3RoZXJ3aXNlDQogICBpbmRp Y2F0ZWQsIGZpZWxkcyBhcmUgcmVzdHJpY3RlZCB0byB0aGUgcHJpbnRhYmxlIGNoYXJhY3Rl cnMgZnJvbSB0aGUNCiAgIFVTLUFTQ0lJIFtJU082NDZdIHJlcGVydG9pcmUuDQoNCiAgIFRo ZSBmb3JtYXQgb2YgdGhlIHJlZ2lzdHJ5IGlzIGRlc2NyaWJlZCBieSB0aGUgZm9sbG93aW5n IEFCTkYgKHBlcg0KICAgW1JGQzQyMzRdKToNCg0KICAgcmVnaXN0cnkgICA9IHJlY29yZCAq KCIlJSIgQ1JMRiByZWNvcmQpDQogICByZWNvcmQgICAgID0gMSooIGZpZWxkLW5hbWUgKlNQ ICI6IiAqU1AgZmllbGQtYm9keSBDUkxGICkNCiAgIGZpZWxkLW5hbWUgPSAoQUxQSEEgLyBE SUdJVCkgWyooQUxQSEEgLyBESUdJVCAvICItIikgKEFMUEhBIC8gRElHSVQpXQ0KICAgZmll bGQtYm9keSA9ICooW1sqU1AgQ1JMRl0gMSpTUF0gMSpDSEFSUykNCiAgIENIQVJTICAgICAg PSAoJXgyMS0xMEZGRkYpICAgICAgOyBVbmljb2RlIGNvZGUgcG9pbnRzDQoNCiAgICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgMjogUmVnaXN0cnkgRm9ybWF0IEFCTkYNCg0KICAgVGhl IHNlcXVlbmNlICcuLicgKCV4MkUuMkUpIGluIGEgZmllbGQtYm9keSBkZW5vdGVzIGEgcmFu Z2Ugb2YNCiAgIHZhbHVlcy4gIFN1Y2ggYSByYW5nZSByZXByZXNlbnRzIGFsbCBzdWJ0YWdz IG9mIHRoZSBzYW1lIGxlbmd0aCB0aGF0DQogICBhcmUgaW4gYWxwaGFiZXRpYyBvciBudW1l cmljIG9yZGVyIHdpdGhpbiB0aGF0IHJhbmdlLCBpbmNsdWRpbmcgdGhlDQogICB2YWx1ZXMg ZXhwbGljaXRseSBtZW50aW9uZWQuICBGb3IgZXhhbXBsZSAnYS4uYycgZGVub3RlcyB0aGUg dmFsdWVzDQogICAnYScsICdiJywgYW5kICdjJyBhbmQgJzExLi4xMycgZGVub3RlcyB0aGUg dmFsdWVzICcxMScsICcxMicsIGFuZA0KICAgJzEzJy4NCg0KICAgQWxsIGZpZWxkcyB3aG9z ZSBmaWVsZC1ib2R5IGNvbnRhaW5zIGEgZGF0ZSB2YWx1ZSB1c2UgdGhlICJmdWxsLWRhdGUi DQogICBmb3JtYXQgc3BlY2lmaWVkIGluIFtSRkMzMzM5XS4gIEZvciBleGFtcGxlOiAiMjAw NC0wNi0yOCIgcmVwcmVzZW50cw0KICAgSnVuZSAyOCwgMjAwNCwgaW4gdGhlIEdyZWdvcmlh biBjYWxlbmRhci4NCg0KMy4xLjIuICBSZWNvcmQgRGVmaW5pdGlvbnMNCg0KICAgVGhlcmUg YXJlIHRocmVlIHR5cGVzIG9mIHJlY29yZHMgaW4gdGhlIHJlZ2lzdHJ5OiAiRmlsZS1EYXRl IiwNCiAgICJTdWJ0YWciLCBhbmQgIlRhZyIgcmVjb3Jkcy4NCg0KICAgVGhlIGZpcnN0IHJl Y29yZCBpbiB0aGUgcmVnaXN0cnkgaXMgYSAiRmlsZS1EYXRlIiByZWNvcmQuICBUaGlzDQog ICByZWNvcmQgY29udGFpbnMgdGhlIHNpbmdsZSBmaWVsZCB3aG9zZSBmaWVsZC1uYW1lIGlz ICJGaWxlLURhdGUiIChzZWUNCiAgIEZpZ3VyZSAyKS4gIFRoZSBmaWVsZC1ib2R5IG9mIHRo aXMgcmVjb3JkIGNvbnRhaW5zIHRoZSBsYXN0DQogICBtb2RpZmljYXRpb24gZGF0ZSBvZiB0 aGlzIGNvcHkgb2YgdGhlIHJlZ2lzdHJ5LCBtYWtpbmcgaXQgcG9zc2libGUgdG8NCiAgIGNv bXBhcmUgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZSByZWdpc3RyeS4gIFRoZSByZWdpc3Ry eSBvbiB0aGUgSUFOQQ0KICAgd2Vic2l0ZSBpcyB0aGUgbW9zdCBjdXJyZW50LiAgVmVyc2lv bnMgd2l0aCBhbiBvbGRlciBkYXRlIHRoYW4gdGhhdA0KICAgb25lIGFyZSBub3QgdXAtdG8t ZGF0ZS4NCg0KICAgRmlsZS1EYXRlOiAyMDA0LTA2LTI4DQogICAlJQ0KDQogICAgICAgICAg ICAgICAgIEZpZ3VyZSAzOiBFeGFtcGxlIG9mIHRoZSBGaWxlLURhdGUgUmVjb3JkDQoNCiAg IFN1YnNlcXVlbnQgcmVjb3JkcyByZXByZXNlbnQgZWl0aGVyIHN1YnRhZ3Mgb3IgdGFncyBp biB0aGUgcmVnaXN0cnkuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGly ZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwNw0KDQoNCiAgICJTdWJ0YWciIHJlY29yZHMgY29udGFpbiBhIGZpZWxkIHdp dGggYSBmaWVsZC1uYW1lIG9mICJTdWJ0YWciLA0KICAgd2hpbGUsIHVuc3VycHJpc2luZ2x5 LCAiVGFnIiByZWNvcmRzIGNvbnRhaW4gYSBmaWVsZCB3aXRoIGEgZmllbGQtDQogICBuYW1l IG9mICJUYWciLiAgRWFjaCBvZiB0aGUgZmllbGRzIGluIGVhY2ggcmVjb3JkIE1VU1Qgb2Nj dXIgbm8gbW9yZQ0KICAgdGhhbiBvbmNlLCB1bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkIGJlbG93 LiAgRWFjaCByZWNvcmQgTVVTVCBjb250YWluDQogICB0aGUgZm9sbG93aW5nIGZpZWxkczoN Cg0KICAgbyAgJ1R5cGUnDQoNCiAgICAgICogIFR5cGUncyBmaWVsZC1ib2R5IE1VU1QgY29u c2lzdCBvZiBvbmUgb2YgdGhlIGZvbGxvd2luZyBzdHJpbmdzOg0KICAgICAgICAgImxhbmd1 YWdlIiwgImV4dGxhbmciLCAic2NyaXB0IiwgInJlZ2lvbiIsICJ2YXJpYW50IiwNCiAgICAg ICAgICJncmFuZGZhdGhlcmVkIiwgYW5kICJyZWR1bmRhbnQiIGFuZCBkZW5vdGVzIHRoZSB0 eXBlIG9mIHRhZyBvcg0KICAgICAgICAgc3VidGFnLg0KDQogICBvICBFaXRoZXIgJ1N1YnRh Zycgb3IgJ1RhZycNCg0KICAgICAgKiAgU3VidGFnJ3MgZmllbGQtYm9keSBjb250YWlucyB0 aGUgc3VidGFnIGJlaW5nIGRlZmluZWQuICBUaGlzDQogICAgICAgICBmaWVsZCBNVVNUIG9u bHkgYXBwZWFyIGluIHJlY29yZHMgb2Ygd2hvc2UgJ1R5cGUnIGhhcyBvbmUgb2YNCiAgICAg ICAgIHRoZXNlIHZhbHVlczogImxhbmd1YWdlIiwgImV4dGxhbmciLCAic2NyaXB0IiwgInJl Z2lvbiIsIG9yDQogICAgICAgICAidmFyaWFudCIuDQoNCiAgICAgICogIFRhZydzIGZpZWxk LWJvZHkgY29udGFpbnMgYSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcuICBUaGlzIGZpZWxkDQog ICAgICAgICBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgd2hvc2UgJ1R5cGUnIGhhcyBv bmUgb2YgdGhlc2UNCiAgICAgICAgIHZhbHVlczogImdyYW5kZmF0aGVyZWQiIG9yICJyZWR1 bmRhbnQiLiAgTm90ZSB0aGF0IHRoZSBmaWVsZC0NCiAgICAgICAgIGJvZHkgd2lsbCBhbHdh eXMgZm9sbG93IHRoZSAnZ3JhbmRmYXRoZXJlZCcgcHJvZHVjdGlvbiBpbiB0aGUNCiAgICAg ICAgIEFCTkYgaW4gU2VjdGlvbiAyLjENCg0KICAgbyAgRGVzY3JpcHRpb24NCg0KICAgICAg KiAgRGVzY3JpcHRpb24ncyBmaWVsZC1ib2R5IGNvbnRhaW5zIGEgbm9uLW5vcm1hdGl2ZSBk ZXNjcmlwdGlvbg0KICAgICAgICAgb2YgdGhlIHN1YnRhZyBvciB0YWcuDQoNCiAgIG8gIEFk ZGVkDQoNCiAgICAgICogIEFkZGVkJ3MgZmllbGQtYm9keSBjb250YWlucyB0aGUgZGF0ZSB0 aGUgcmVjb3JkIHdhcyBhZGRlZCB0bw0KICAgICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBF YWNoIHJlY29yZCBNQVkgYWxzbyBjb250YWluIHRoZSBmb2xsb3dpbmcgZmllbGRzOg0KDQog ICBvICBQcmVmZXJyZWQtVmFsdWUNCg0KICAgICAgKiAgRm9yIGZpZWxkcyBvZiB0eXBlICdz Y3JpcHQnLCAncmVnaW9uJywgYW5kICd2YXJpYW50JywNCiAgICAgICAgICdQcmVmZXJyZWQt VmFsdWUnIGNvbnRhaW5zIHRoZSBzdWJ0YWcgb2YgdGhlIHNhbWUgJ1R5cGUnIHRoYXQNCiAg ICAgICAgIGlzIHByZWZlcnJlZCBmb3IgZm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQog ICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2xhbmd1YWdlJyBhbmQgJ2V4dGxhbmcnLCAn UHJlZmVycmVkLVZhbHVlJw0KICAgICAgICAgY29udGFpbnMgdGhlIGxhbmd1YWdlIHByb2R1 Y3Rpb24gKHNlZSBGaWd1cmUgMSkgdGhhdCBpcw0KICAgICAgICAgcHJlZmVycmVkIHdoZW4g Zm9ybWluZyB0aGUgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBjYW4gYmUgc2ltcGx5IGENCiAgICAg ICAgICdsYW5ndWFnZScgc3VidGFnLCBvciBpdCBjYW4gYmUgYSAnbGFuZ3VhZ2UnIHN1YnRh ZyBmb2xsb3dlZCBieQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVz IE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVt YmVyIDIwMDcNCg0KDQogICAgICAgICBhbiBleHRlbmRlZCBsYW5ndWFnZSBzZXF1ZW5jZS4N Cg0KICAgICAgKiAgRm9yIGZpZWxkcyBvZiB0eXBlICdncmFuZGZhdGhlcmVkJyBhbmQgJ3Jl ZHVuZGFudCcsIGEgY2Fub25pY2FsDQogICAgICAgICBtYXBwaW5nIHRvIGEgY29tcGxldGUg bGFuZ3VhZ2UgdGFnLg0KDQogICBvICBEZXByZWNhdGVkDQoNCiAgICAgICogIERlcHJlY2F0 ZWQncyBmaWVsZC1ib2R5IGNvbnRhaW5zIHRoZSBkYXRlIHRoZSByZWNvcmQgd2FzDQogICAg ICAgICBkZXByZWNhdGVkLg0KDQogICBvICBQcmVmaXgNCg0KICAgICAgKiAgUHJlZml4J3Mg ZmllbGQtYm9keSBjb250YWlucyBhIGxhbmd1YWdlIHRhZyB3aXRoIHdoaWNoIHRoaXMNCiAg ICAgICAgIHN1YnRhZyBNQVkgYmUgdXNlZCB0byBmb3JtIGEgbmV3IGxhbmd1YWdlIHRhZywg cGVyaGFwcyB3aXRoDQogICAgICAgICBvdGhlciBzdWJ0YWdzIGFzIHdlbGwuICBUaGUgUHJl Zml4J3Mgc3VidGFncyBhcHBlYXIgYmVmb3JlIHRoZQ0KICAgICAgICAgc3VidGFnLiAgVGhp cyBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgd2hvc2UgJ1R5cGUnDQogICAg ICAgICBmaWVsZC1ib2R5IGlzICd2YXJpYW50JyBvciAnZXh0bGFuZycuICBGb3IgZXhhbXBs ZSwgdGhlDQogICAgICAgICAnUHJlZml4JyBmb3IgdGhlIHZhcmlhbnQgJ25lZGlzJyBpcyAn c2wnLCBtZWFuaW5nIHRoYXQgdGhlIHRhZ3MNCiAgICAgICAgICJzbC1uZWRpcyIgYW5kICJz bC1JVC1uZWRpcyIgbWlnaHQgYmUgYXBwcm9wcmlhdGUgd2hpbGUgdGhlIHRhZw0KICAgICAg ICAgImlzLW5lZGlzIiBpcyBub3QuDQoNCiAgIG8gIENvbW1lbnRzDQoNCiAgICAgICogIENv bW1lbnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN1YnRh ZywgYXMNCiAgICAgICAgIGRlZW1lZCBhcHByb3ByaWF0ZSBmb3IgdW5kZXJzdGFuZGluZyB0 aGUgcmVnaXN0cnkgYW5kDQogICAgICAgICBpbXBsZW1lbnRpbmcgbGFuZ3VhZ2UgdGFncyB1 c2luZyB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgU3VwcHJlc3MtU2NyaXB0DQoNCiAg ICAgICogIFN1cHByZXNzLVNjcmlwdCBjb250YWlucyBhIHNjcmlwdCBzdWJ0YWcgdGhhdCBT SE9VTEQgTk9UIGJlDQogICAgICAgICB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB3aXRo IHRoZSBhc3NvY2lhdGVkIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICAgIHN1YnRhZy4gIFRo aXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAg ICAgICAgZmllbGQtYm9keSBpcyAnbGFuZ3VhZ2UnLiAgU2VlIFNlY3Rpb24gNC4xLg0KDQog ICBvICBNYWNyb2xhbmd1YWdlDQoNCiAgICAgICogIE1hY3JvbGFuZ3VhZ2UgY29udGFpbnMg YSBwcmltYXJ5IG9yIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZw0KICAgICAgICAgZGVmaW5l ZCBieSBJU08gNjM5IGFzIGEgIm1hY3JvbGFuZ3VhZ2UiIHRoYXQgZW5jb21wYXNzZXMgdGhp cw0KICAgICAgICAgbGFuZ3VhZ2Ugc3VidGFnLiAgVGhpcyBmaWVsZCBNVVNUIG9ubHkgYXBw ZWFyIGluIHJlY29yZHMgd2hvc2UNCiAgICAgICAgICdUeXBlJyBmaWVsZC1ib2R5IGlzICds YW5ndWFnZScgb3IgJ2V4dGxhbmcnLg0KDQogICBGdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBk b2N1bWVudCBtaWdodCBhZGQgYWRkaXRpb25hbCBmaWVsZHMgdG8gdGhlDQogICByZWdpc3Ry eSwgc28gaW1wbGVtZW50YXRpb25zIFNIT1VMRCBpZ25vcmUgZmllbGRzIGZvdW5kIGluIHRo ZQ0KICAgcmVnaXN0cnkgdGhhdCBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4N Cg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAx NywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIw MDcNCg0KDQozLjEuMy4gIFN1YnRhZyBhbmQgVGFnIEZpZWxkcw0KDQogICBUaGUgJ1N1YnRh ZycgZmllbGQgTVVTVCB1c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0aGUgc3VidGFn LA0KICAgd2l0aCB0d28gZXhjZXB0aW9ucy4gIFN1YnRhZ3Mgd2hvc2UgJ1R5cGUnIGZpZWxk IGlzICdzY3JpcHQnIChpbg0KICAgb3RoZXIgd29yZHMsIHN1YnRhZ3MgZGVmaW5lZCBieSBJ U08gMTU5MjQpIE1VU1QgdXNlIHRpdGxlY2FzZS4NCiAgIFN1YnRhZ3Mgd2hvc2UgJ1R5cGUn IGZpZWxkIGlzICdyZWdpb24nIChpbiBvdGhlciB3b3JkcywgdGhlIG5vbi0NCiAgIG51bWVy aWMgcmVnaW9uIHN1YnRhZ3MgZGVmaW5lZCBieSBJU08gMzE2NikgTVVTVCB1c2UgdXBwZXJj YXNlLg0KICAgVGhlc2UgZXhjZXB0aW9ucyBtaXJyb3IgdGhlIHVzZSBvZiBjYXNlIGluIHRo ZSB1bmRlcmx5aW5nIHN0YW5kYXJkcy4NCg0KICAgRWFjaCBzdWJ0YWcgaW4gdGhlIHRhZ3Mg Y29udGFpbmVkIGluIGEgJ1RhZycgZmllbGQgTVVTVCBiZSBmb3JtYXR0ZWQNCiAgIHVzaW5n IHRoZSBydWxlcyBpbiB0aGUgcHJlY2VlZGluZyBwYXJhZ3JhcGguICBUaGF0IGlzLCBhbGwg c3VidGFncw0KICAgYXJlIGxvd2VyY2FzZSBleGNlcHQgZm9yIHN1YnRhZ3MgdGhhdCByZXBy ZXNlbnQgc2NyaXB0IG9yIHJlZ2lvbg0KICAgY29kZXMuDQoNCjMuMS40LiAgRGVzY3JpcHRp b24gRmllbGQNCg0KICAgVGhlIGZpZWxkICdEZXNjcmlwdGlvbicgY29udGFpbnMgYSBkZXNj cmlwdGlvbiBvZiB0aGUgdGFnIG9yIHN1YnRhZw0KICAgaW4gdGhlIHJlY29yZC4gIFRoZSAn RGVzY3JpcHRpb24nIGZpZWxkIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVyDQogICBy ZWNvcmQsIHRoYXQgaXMsIHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBkZXNjcmlwdGlvbnMgZm9y IGEgZ2l2ZW4NCiAgIHJlY29yZC4gIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIE1BWSBpbmNs dWRlIHRoZSBmdWxsIHJhbmdlIG9mDQogICBVbmljb2RlIGNoYXJhY3RlcnMuICBBdCBsZWFz dCBvbmUgb2YgdGhlICdEZXNjcmlwdGlvbicgZmllbGRzIE1VU1QgYmUNCiAgIHdyaXR0ZW4g b3IgdHJhbnNjcmliZWQgaW50byB0aGUgTGF0aW4gc2NyaXB0OyBhZGRpdGlvbmFsDQogICAn RGVzY3JpcHRpb24nIGZpZWxkcyBNQVkgYWxzbyBpbmNsdWRlIGEgZGVzY3JpcHRpb24gaW4g YSBub24tTGF0aW4NCiAgIHNjcmlwdC4gIEVhY2ggJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNU IGJlIHVuaXF1ZSwgYm90aCB3aXRoaW4gdGhlDQogICByZWNvcmQgaW4gd2hpY2ggaXQgYXBw ZWFycyBhbmQgZm9yIHRoZSBjb2xsZWN0aW9uIG9mIHJlY29yZHMgb2YgdGhlDQogICBzYW1l IHR5cGUuICBNb3Jlb3ZlciwgZm9ybWF0dGluZyB2YXJpYXRpb25zIG9mIHRoZSBzYW1lIGRl c2NyaXB0aW9uDQogICBNVVNUIE5PVCBvY2N1ciBpbiB0aGF0IHNwZWNpZmljIHJlY29yZCBv ciBpbiBhbnkgb3RoZXIgcmVjb3JkIG9mIHRoZQ0KICAgc2FtZSB0eXBlLiAgRm9yIGV4YW1w bGUsIHdoaWxlIHRoZSBJU08gNjM5LTEgY29kZSAnZnknIGNvbnRhaW5zIGJvdGgNCiAgIHRo ZSBkZXNjcmlwdGlvbnMgIldlc3Rlcm4gRnJpc2lhbiIgYW5kICJGcmlzaWFuLCBXZXN0ZXJu Iiwgb25seSBvbmUNCiAgIG9mIHRoZXNlIGRlc2NyaXB0aW9ucyBhcHBlYXJzIGluIHRoZSBy ZWdpc3RyeS4NCg0KICAgVGhlICdEZXNjcmlwdGlvbicgZmllbGQgaXMgdXNlZCBmb3IgaWRl bnRpZmljYXRpb24gcHVycG9zZXMgYW5kDQogICBTSE9VTEQgTk9UIGJlIHRha2VuIHRvIHJl cHJlc2VudCB0aGUgYWN0dWFsIG5hdGl2ZSBuYW1lIG9mIHRoZQ0KICAgbGFuZ3VhZ2Ugb3Ig dmFyaWF0aW9uIG9yIHRvIGJlIGluIGFueSBwYXJ0aWN1bGFyIGxhbmd1YWdlLg0KDQogICBG b3IgcmVjb3JkcyB0YWtlbiBmcm9tIGEgc291cmNlIHN0YW5kYXJkIChzdWNoIGFzIElTTyA2 Mzkgb3IgSVNPDQogICAzMTY2KSwgdGhlICdEZXNjcmlwdGlvbicgdmFsdWUocykgU0hPVUxE IGFsc28gYmUgdGFrZW4gZnJvbSB0aGUNCiAgIHNvdXJjZSBzdGFuZGFyZC4gIE11bHRpcGxl IGRlc2NyaXB0aW9ucyBpbiB0aGUgc291cmNlIHN0YW5kYXJkIE1VU1QNCiAgIGJlIHNwbGl0 IGludG8gc2VwYXJhdGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZHMuICBUaGUgc291cmNlIHN0YW5k YXJkJ3MNCiAgIGRlc2NyaXB0aW9ucyBNQVkgYmUgZWRpdGVkLCBlaXRoZXIgcHJpb3IgdG8g aW5zZXJ0aW9uIG9yIHZpYSB0aGUNCiAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiAgRm9yIGZp ZWxkcyBvZiB0eXBlICdsYW5ndWFnZScgb3IgJ2V4dGxhbmcnLA0KICAgdGhlIGZpcnN0ICdE ZXNjcmlwdGlvbicgZmllbGQgYXBwZWFyaW5nIGluIHRoZSBSZWdpc3RyeSBjb3JyZXNwb25k cw0KICAgdG8gdGhlIFJlZmVyZW5jZSBOYW1lIGFzc2lnbmVkIGJ5IElTTyA2MzktMy4gIFRo aXMgaGVscHMgZmFjaWxpdGF0ZQ0KICAgY3Jvc3MtcmVmZXJlbmNpbmcgYmV0d2VlbiBJU08g NjM5IGFuZCB0aGUgcmVnaXN0cnkuDQoNCiAgIFdoZW4gY3JlYXRpbmcgb3IgdXBkYXRpbmcg YSByZWNvcmQgZHVlIHRvIHRoZSBhY3Rpb24gb2Ygb25lIG9mIHRoZQ0KICAgc291cmNlIHN0 YW5kYXJkcywgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSE9VTEQgcmVtb3ZlDQog ICBkdXBsaWNhdGUgb3IgcmVkdW5kYW50IGRlc2NyaXB0aW9ucyBhbmQgTUFZIGVkaXQgZGVz Y3JpcHRpb25zIHRvDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMg TWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwNw0KDQoNCiAgIGNvcnJlY3QgaXJyZWd1bGFyaXRpZXMgaW4gZm9ybWF0dGluZyAo c3VjaCBhcyBtaXNzcGVsbGluZ3MsDQogICBpbmFwcHJvcHJpYXRlIGFwb3N0cm9waGVzIG9y IG90aGVyIHB1bmN0dWF0aW9uLCBvciBleGNlc3NpdmUgb3INCiAgIG1pc3Npbmcgc3BhY2Vz KSBwcmlvciB0byBzdWJtaXR0aW5nIHRoZSBwcm9wb3NlZCByZWNvcmQgdG8gdGhlIGlldGYt DQogICBsYW5ndWFnZXMgbGlzdC4NCg0KICAgTm90ZTogRGVzY3JpcHRpb25zIGluIHJlZ2lz dHJ5IGVudHJpZXMgdGhhdCBjb3JyZXNwb25kIHRvIElTTyA2MzksDQogICBJU08gMTU5MjQs IElTTyAzMTY2LCBvciBVTiBNLjQ5IGNvZGVzIGFyZSBpbnRlbmRlZCBvbmx5IHRvIGluZGlj YXRlDQogICB0aGUgbWVhbmluZyBvZiB0aGF0IGlkZW50aWZpZXIgYXMgZGVmaW5lZCBpbiB0 aGUgc291cmNlIHN0YW5kYXJkIGF0DQogICB0aGUgdGltZSBpdCB3YXMgYWRkZWQgdG8gdGhl IHJlZ2lzdHJ5LiAgVGhlIGRlc2NyaXB0aW9uIGRvZXMgbm90DQogICByZXBsYWNlIHRoZSBj b250ZW50IG9mIHRoZSBzb3VyY2Ugc3RhbmRhcmQgaXRzZWxmLiAgVGhlIGRlc2NyaXB0aW9u cw0KICAgYXJlIG5vdCBpbnRlbmRlZCB0byBiZSB0aGUgRW5nbGlzaCBsb2NhbGl6ZWQgbmFt ZXMgZm9yIHRoZSBzdWJ0YWdzLg0KICAgTG9jYWxpemF0aW9uIG9yIHRyYW5zbGF0aW9uIG9m IGxhbmd1YWdlIHRhZyBhbmQgc3VidGFnIGRlc2NyaXB0aW9ucw0KICAgaXMgb3V0IG9mIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCjMuMS41LiAgRGVwcmVjYXRlZCBGaWVsZA0KDQog ICBUaGUgZmllbGQgJ0RlcHJlY2F0ZWQnIE1BWSBiZSBhZGRlZCB0byBhbnkgcmVjb3JkIHZp YSB0aGUgbWFpbnRlbmFuY2UNCiAgIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4z IG9yIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MNCiAgIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuNS4gIFVzdWFsbHksIHRoZSBhZGRpdGlvbiBvZiBhICdEZXByZWNhdGVkJw0KICAg ZmllbGQgaXMgZHVlIHRvIHRoZSBhY3Rpb24gb2Ygb25lIG9mIHRoZSBzdGFuZGFyZHMgYm9k aWVzLCBzdWNoIGFzDQogICBJU08gMzE2Niwgd2l0aGRyYXdpbmcgYSBjb2RlLiAgSW4gc29t ZSBoaXN0b3JpY2FsIGNhc2VzLCBpdCBtaWdodCBub3QNCiAgIGhhdmUgYmVlbiBwb3NzaWJs ZSB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwgZGVwcmVjYXRpb24gZGF0ZS4gIEZvcg0K ICAgdGhlc2UgY2FzZXMsIGFuIGFwcHJveGltYXRlIGRhdGUgYXBwZWFycyBpbiB0aGUgcmVn aXN0cnkuICBBbHRob3VnaA0KICAgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncywgc3VidGFncyBh bmQgdGFncyB3aXRoIGEgJ0RlcHJlY2F0ZWQnIGZpZWxkDQogICBhcmUgZGVwcmVjYXRlZCBh bmQgdmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QgZ2VuZXJhdGUgdGhlc2UNCiAg IHN1YnRhZ3MuICBOb3RlIHRoYXQgYSByZWNvcmQgdGhhdCBjb250YWlucyBhICdEZXByZWNh dGVkJyBmaWVsZCBhbmQNCiAgIG5vIGNvcnJlc3BvbmRpbmcgJ1ByZWZlcnJlZC1WYWx1ZScg ZmllbGQgaGFzIG5vIHJlcGxhY2VtZW50IG1hcHBpbmcuDQoNCjMuMS42LiAgUHJlZmVycmVk LVZhbHVlIEZpZWxkDQoNCiAgIFRoZSBmaWVsZCAnUHJlZmVycmVkLVZhbHVlJyBjb250YWlu cyBhIG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVjb3JkIGluDQogICB3aGljaCBpdCBhcHBlYXJz IGFuZCBhbm90aGVyIHRhZyBvciBzdWJ0YWcuICBUaGUgdmFsdWUgaW4gdGhpcyBmaWVsZA0K ICAgaXMgc3Ryb25nbHkgUkVDT01NRU5ERUQgYXMgdGhlIGJlc3QgY2hvaWNlIHRvIHJlcHJl c2VudCB0aGUgdmFsdWUgb2YNCiAgIHRoaXMgcmVjb3JkIHdoZW4gc2VsZWN0aW5nIGEgbGFu Z3VhZ2UgdGFnLiAgVGhlc2UgdmFsdWVzIGZvcm0gdGhyZWUNCiAgIGdyb3VwczoNCg0KICAg MS4gIElTTyA2MzkgbGFuZ3VhZ2UgY29kZXMgdGhhdCB3ZXJlIGxhdGVyIHdpdGhkcmF3biBp biBmYXZvciBvZg0KICAgICAgIG90aGVyIGNvZGVzLiAgVGhlc2UgdmFsdWVzIGFyZSBtb3N0 bHkgYSBoaXN0b3JpY2FsIGN1cmlvc2l0eS4NCg0KICAgMi4gIElTTyAzMTY2IHJlZ2lvbiBj b2RlcyB0aGF0IGhhdmUgYmVlbiB3aXRoZHJhd24gaW4gZmF2b3Igb2YgYSBuZXcNCiAgICAg ICBjb2RlLiAgVGhpcyBzb21ldGltZXMgaGFwcGVucyB3aGVuIGEgY291bnRyeSBjaGFuZ2Vz IGl0cyBuYW1lIG9yDQogICAgICAgYWRtaW5pc3RyYXRpb24gaW4gc3VjaCBhIHdheSB0aGF0 IHdhcnJhbnRzIGEgbmV3IHJlZ2lvbiBjb2RlLg0KDQogICAzLiAgR3JhbmRmYXRoZXJlZCBv ciByZWR1bmRhbnQgdGFncyBmcm9tIFJGQyAzMDY2LiAgSW4gbWFueSBjYXNlcywNCiAgICAg ICB0aGVzZSB0YWdzIGhhdmUgYmVjb21lIG9ic29sZXRlIGJlY2F1c2UgdGhlIHZhbHVlcyB0 aGV5IHJlcHJlc2VudA0KICAgICAgIHdlcmUgbGF0ZXIgZW5jb2RlZCBieSBJU08gNjM5Lg0K DQogICBSZWNvcmRzIHRoYXQgY29udGFpbiBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIE1V U1QgYWxzbyBoYXZlIGENCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJl cyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3Zl bWJlciAyMDA3DQoNCg0KICAgJ0RlcHJlY2F0ZWQnIGZpZWxkLiAgVGhpcyBmaWVsZCBjb250 YWlucyBhIGRhdGUgb2YgZGVwcmVjYXRpb24uDQogICBUaHVzLCBhIGxhbmd1YWdlIHRhZyBw cm9jZXNzb3IgY2FuIHVzZSB0aGUgcmVnaXN0cnkgdG8gY29uc3RydWN0IHRoZQ0KICAgdmFs aWQsIG5vbi1kZXByZWNhdGVkIHNldCBvZiBzdWJ0YWdzIGZvciBhIGdpdmVuIGRhdGUuICBJ biBhZGRpdGlvbiwNCiAgIGZvciBhbnkgZ2l2ZW4gdGFnLCBhIHByb2Nlc3NvciBjYW4gY29u c3RydWN0IHRoZSBzZXQgb2YgdmFsaWQNCiAgIGxhbmd1YWdlIHRhZ3MgdGhhdCBjb3JyZXNw b25kIHRvIHRoYXQgdGFnIGZvciBhbGwgZGF0ZXMgdXAgdG8gdGhlDQogICBkYXRlIG9mIHRo ZSByZWdpc3RyeS4gIFRoZSBhYmlsaXR5IHRvIGRvIHRoZXNlIG1hcHBpbmdzIE1BWSBiZQ0K ICAgYmVuZWZpY2lhbCB0byBhcHBsaWNhdGlvbnMgdGhhdCBhcmUgbWF0Y2hpbmcsIHNlbGVj dGluZywgZm9yDQogICBmaWx0ZXJpbmcgY29udGVudCBiYXNlZCBvbiBpdHMgbGFuZ3VhZ2Ug dGFncy4NCg0KICAgTm90ZSB0aGF0ICdQcmVmZXJyZWQtVmFsdWUnIG1hcHBpbmdzIGluIHJl Y29yZHMgb2YgdHlwZSAncmVnaW9uJw0KICAgc29tZXRpbWVzIGRvIG5vdCByZXByZXNlbnQg ZXhhY3RseSB0aGUgc2FtZSBtZWFuaW5nIGFzIHRoZSBvcmlnaW5hbA0KICAgdmFsdWUuICBU aGVyZSBhcmUgbWFueSByZWFzb25zIGZvciBhIGNvdW50cnkgY29kZSB0byBiZSBjaGFuZ2Vk LCBhbmQNCiAgIHRoZSBlZmZlY3QgdGhpcyBoYXMgb24gdGhlIGZvcm1hdGlvbiBvZiBsYW5n dWFnZSB0YWdzIHdpbGwgZGVwZW5kIG9uDQogICB0aGUgbmF0dXJlIG9mIHRoZSBjaGFuZ2Ug aW4gcXVlc3Rpb24uDQoNCiAgIEluIHBhcnRpY3VsYXIsIHRoZSAnUHJlZmVycmVkLVZhbHVl JyBmaWVsZCBkb2VzIG5vdCBpbXBseSByZXRhZ2dpbmcNCiAgIGNvbnRlbnQgdGhhdCB1c2Vz IHRoZSBhZmZlY3RlZCBzdWJ0YWcuDQoNCiAgIFRoZSBmaWVsZCAnUHJlZmVycmVkLVZhbHVl JyBNVVNUIE5PVCBiZSBtb2RpZmllZCBvbmNlIGNyZWF0ZWQgaW4gdGhlDQogICByZWdpc3Ry eS4gIFRoZSBmaWVsZCBNQVkgYmUgYWRkZWQgdG8gcmVjb3JkcyBhY2NvcmRpbmcgdG8gdGhl IHJ1bGVzDQogICBpbiBTZWN0aW9uIDMuMy4NCg0KICAgVGhlICdQcmVmZXJyZWQtVmFsdWUn IGZpZWxkIGluIHJlY29yZHMgb2YgdHlwZSAiZ3JhbmRmYXRoZXJlZCIgYW5kDQogICAicmVk dW5kYW50IiBjb250YWlucyB3aG9sZSBsYW5ndWFnZSB0YWdzIHRoYXQgYXJlIHN0cm9uZ2x5 DQogICBSRUNPTU1FTkRFRCBmb3IgdXNlIGluIHBsYWNlIG9mIHRoZSByZWNvcmQncyB2YWx1 ZS4gIEluIG1hbnkgY2FzZXMsDQogICB0aGUgbWFwcGluZ3Mgd2VyZSBjcmVhdGVkIGJ5IGRl cHJlY2F0aW9uIG9mIHRoZSB0YWdzIGR1cmluZyB0aGUNCiAgIHBlcmlvZCBiZWZvcmUgdGhp cyBkb2N1bWVudCB3YXMgYWRvcHRlZC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJuby0NCiAg IG55biIgd2FzIGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIElTTyA2MzktMS1kZWZpbmVk IGxhbmd1YWdlIGNvZGUNCiAgICdubicuDQoNCjMuMS43LiAgUHJlZml4IEZpZWxkDQoNCiAg IFRoZSAnUHJlZml4JyBmaWVsZCBjb250YWlucyBhbiBleHRlbmRlZCBsYW5ndWFnZSByYW5n ZSB3aG9zZSBzdWJ0YWdzDQogICBhcmUgYXBwcm9wcmlhdGUgdG8gdXNlIHdpdGggdGhpcyBz dWJ0YWc6IGVhY2ggb2YgdGhlIHN1YnRhZ3MgaW4gb25lDQogICBvZiB0aGUgc3VidGFnJ3Mg UHJlZml4IGZpZWxkcyBNVVNUIGFwcGVhciBiZWZvcmUgdGhlIHZhcmlhbnQgaW4gYQ0KICAg dmFsaWQgdGFnLiAgRm9yIGV4YW1wbGUsIHRoZSB2YXJpYW50IHN1YnRhZyAnMTk5NicgaGFz IGEgJ1ByZWZpeCcNCiAgIGZpZWxkIG9mICJkZSIuICBUaGlzIG1lYW5zIHRoYXQgdGFncyBz dGFydGluZyB3aXRoIHRoZSBzZXF1ZW5jZSAiZGUtIg0KICAgYXJlIGFwcHJvcHJpYXRlIHdp dGggdGhpcyBzdWJ0YWcsIHNvICJkZS1MYXRnLTE5OTYiIGFuZCAiZGUtQ0gtMTk5NiINCiAg IGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlIHRoZSB0YWcgImZyLTE5OTYiIGlzIGFuIGlu YXBwcm9wcmlhdGUNCiAgIGNob2ljZS4NCg0KICAgVGhlIGZpZWxkIG9mIHR5cGUgJ1ByZWZp eCcgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueSByZWNvcmQuICBUaGUNCiAgIGZpZWxk LWJvZHkgZm9yIHRoaXMgdHlwZSBvZiBmaWVsZCBNQVkgYmUgbW9kaWZpZWQsIGJ1dCBvbmx5 IGlmIHRoZQ0KICAgbW9kaWZpY2F0aW9uIGJyb2FkZW5zIHRoZSBtZWFuaW5nIG9mIHRoZSBz dWJ0YWcuICBUaGF0IGlzLCB0aGUgZmllbGQtDQogICBib2R5IGNhbiBiZSByZXBsYWNlZCBv bmx5IGJ5IGEgcHJlZml4IGEgcHJlZml4IG9mIGl0c2VsZi4gIEZvcg0KICAgZXhhbXBsZSwg dGhlIFByZWZpeCAiYmUtTGF0biIgKEJlbGFydXNpYW4sIExhdGluIHNjcmlwdCkgY291bGQg YmUNCiAgIHJlcGxhY2VkIGJ5IHRoZSBQcmVmaXggImJlIiAoQmVsYXJ1c2lhbikgYnV0IG5v dCBieSB0aGUgUHJlZml4ICJydS0NCiAgIExhdG4iIChSdXNzaWFuLCBMYXRpbiBzY3JpcHQp Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAw OCAgICAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0K DQogICBSZWNvcmRzIG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBoYXZlIG1vcmUgdGhhbiBvbmUg ZmllbGQgb2YgdHlwZQ0KICAgJ1ByZWZpeCcuICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlz IHR5cGUgTUFZIGJlIGFkZGVkIHRvIGEgJ3ZhcmlhbnQnDQogICByZWNvcmQgdmlhIHRoZSBy ZWdpc3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgVGhlIGZpZWxkLWJvZHkgb2YgdGhlICdQcmVm aXgnIGZpZWxkIE1VU1QgTk9UIGNvbmZsaWN0IHdpdGggYW55DQogICAnUHJlZml4JyBhbHJl YWR5IHJlZ2lzdGVyZWQgZm9yIGEgZ2l2ZW4gcmVjb3JkLiAgU3VjaCBhIGNvbmZsaWN0DQog ICB3b3VsZCBvY2N1ciB3aGVuIHdoZW4gbm8gdmFsaWQgdGFnIGNvdWxkIGJlIGNvbnN0cnVj dGVkIHRoYXQgd291bGQNCiAgIGNvbnRhaW4gdGhlIHByZWZpeCwgc3VjaCBhcyB3aGVuIHdo ZW4gdHdvIHN1YnRhZ3MgZWFjaCBoYXZlIGENCiAgICdQcmVmaXgnIHRoYXQgY29udGFpbnMg dGhlIG90aGVyIHN1YnRhZy4gIEZvciBleGFtcGxlLCBzdXBwb3NlIHRoYXQNCiAgIHRoZSBz dWJ0YWcgJ2F2YXJpYW50JyBoYXMgdGhlIHByZWZpeCAiZXMtYnZhcmlhbnQiLiAgVGhlbiB0 aGUgc3VidGFnDQogICAnYnZhcmlhbnQnIGNhbm5vdCBnaXZlbiB0aGUgcHJlZml4ICdhdmFy aWFudCcsIGZvciB0aGF0IHdvdWxkIHJlcXVpcmUNCiAgIGEgdGFnIG9mIHRoZSBmb3JtICJl cy1hdmFyaWFudC1idmFyaWFudC1hdmFyaWFudCIsIHdoaWNoIHdvdWxkIG5vdCBiZQ0KICAg dmFsaWQuDQoNCiAgIFJlY29yZHMgb2YgdHlwZSAnZXh0bGFuZycgTVVTVCBoYXZlIF9leGFj dGx5XyBvbmUgJ1ByZWZpeCcgZmllbGQuDQoNCjMuMS44LiAgU3VwcHJlc3MtU2NyaXB0IEZp ZWxkDQoNCiAgIFRoZSBmaWVsZCAnU3VwcHJlc3MtU2NyaXB0JyBjb250YWlucyBhIHNjcmlw dCBzdWJ0YWcgKHdob3NlIHJlY29yZA0KICAgYXBwZWFycyBpbiB0aGUgcmVnaXN0cnkpLiAg VGhlIGZpZWxkICdTdXBwcmVzcy1TY3JpcHQnIE1VU1Qgb25seQ0KICAgYXBwZWFyIGluIHJl Y29yZHMgd2hvc2UgJ1R5cGUnIGZpZWxkLWJvZHkgaXMgJ2xhbmd1YWdlJy4gIFRoaXMgZmll bGQNCiAgIE1VU1QgTk9UIGFwcGVhciBtb3JlIHRoYW4gb25lIHRpbWUgaW4gYSByZWNvcmQu ICBUaGlzIGZpZWxkIGluZGljYXRlcw0KICAgYSBzY3JpcHQgdXNlZCB0byB3cml0ZSB0aGUg b3ZlcndoZWxtaW5nIG1ham9yaXR5IG9mIGRvY3VtZW50cyBmb3IgdGhlDQogICBnaXZlbiBs YW5ndWFnZS4gIFRoaXMgc2NyaXB0IGNvZGUgdGhlcmVmb3JlIGFkZHMgbm8gZGlzdGluZ3Vp c2hpbmcNCiAgIGluZm9ybWF0aW9uIHRvIGEgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBoZWxwcyBl bnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFnZSB0 YWdzIGdlbmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhlDQogICBydWxlcyBpbiB0aGlzIGRvY3Vt ZW50IGFuZCBsYW5ndWFnZSB0YWdzIGFuZCB0YWcgcHJvY2Vzc29ycyBvcg0KICAgY29uc3Vt ZXJzIGJhc2VkIG9uIFJGQyAzMDY2IGJ5IGluZGljYXRpbmcgdGhhdCB0aGUgc2NyaXB0IHN1 YnRhZw0KICAgU0hPVUxEIE5PVCBiZSB1c2VkIGZvciBtb3N0IGRvY3VtZW50cyBpbiB0aGF0 IGxhbmd1YWdlLiAgRm9yIGV4YW1wbGUsDQogICB2aXJ0dWFsbHkgYWxsIEljZWxhbmRpYyBk b2N1bWVudHMgYXJlIHdyaXR0ZW4gaW4gdGhlIExhdGluIHNjcmlwdCwNCiAgIG1ha2luZyB0 aGUgc3VidGFnICdMYXRuJyByZWR1bmRhbnQgaW4gdGhlIHRhZyAiaXMtTGF0biIuDQoNCiAg IE1hbnkgbGFuZ3VhZ2Ugc3VidGFnIHJlY29yZHMgZG8gbm90IGhhdmUgYSBTdXBwcmVzcy1T Y3JpcHQgZmllbGQuDQogICBUaGUgbGFjayBvZiBhIFN1cHByZXNzLVNjcmlwdCBtaWdodCBp bmRpY2F0ZSB0aGF0IHRoZSBsYW5ndWFnZSBpcw0KICAgY3VzdG9tYXJpbHkgd3JpdHRlbiBp biBtb3JlIHRoYW4gb25lIHNjcmlwdCBvciB0aGF0IHRoZSBsYW5ndWFnZSBpcw0KICAgbm90 IGN1c3RvbWFyaWx5IHdyaXR0ZW4gYXQgYWxsLiAgSXQgbWlnaHQgYWxzbyBtZWFuIHRoYXQg c3VmZmljaWVudA0KICAgaW5mb3JtYXRpb24gd2FzIG5vdCBhdmFpbGFibGUgd2hlbiB0aGUg cmVjb3JkIHdhcyBjcmVhdGVkIGFuZCB0aHVzDQogICByZW1haW5zIGEgY2FuZGlkYXRlIGZv ciBmdXR1cmUgcmVnaXN0cmF0aW9uLg0KDQozLjEuOS4gIE1hY3JvbGFuZ3VhZ2UgRmllbGQN Cg0KICAgVGhlIE1hY3JvbGFuZ3VhZ2UgZmllbGQgY29udGFpbnMgYSBwcmltYXJ5IG9yIGV4 dGVuZGVkIGxhbmd1YWdlDQogICBzdWJ0YWcgdGhhdCBlbmNvbXBhc3NlcyB0aGlzIHN1YnRh ZydzIGxhbmd1YWdlLiAgVGhhdCBpcywgdGhlDQogICBsYW5ndWFnZSBzdWJ0YWcgd2hvc2Ug cmVjb3JkIHRoaXMgZmllbGQgYXBwZWFycyBpbiBpcyBzb21ldGltZXMNCiAgIGNvbnNpZGVy ZWQgdG8gYmUgYSBzdWItbGFuZ3VhZ2Ugb2YgdGhlIE1hY3JvbGFuZ3VhZ2UuICBNYWNyb2xh bmd1YWdlDQogICB2YWx1ZXMgYXJlIGRlZmluZWQgYnkgSVNPIDYzOS0zIGFuZCB0aGUgZXhh Y3QgbmF0dXJlIG9mIHRoZQ0KICAgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGVuY29tcGFz c2VkIGFuZCBlbmNvbXBhc3NpbmcgbGFuZ3VhZ2VzDQogICB2YXJpZXMgb24gYSBjYXNlLWJ5 LWNhc2UgYmFzaXMuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMg TWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyN10NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwNw0KDQoNCiAgIFRoaXMgZmllbGQgY2FuIGJlIHVzZWZ1bCB0byBhcHBsaWNhdGlv bnMgb3IgdXNlcnMgd2hlbiBzZWxlY3RpbmcNCiAgIGxhbmd1YWdlIHRhZ3Mgb3IgYXMgYWRk aXRpb25hbCBtZXRhZGF0YSB1c2VmdWwgaW4gbWF0Y2hpbmcuICBUaGUNCiAgIE1hY3JvbGFu Z3VhZ2UgZmllbGQgY2FuIG9ubHkgb2NjdXIgaW4gcmVjb3JkcyBvZiB0eXBlICdsYW5ndWFn ZScgb3INCiAgICdleHRsYW5nJy4gIE9ubHkgdmFsdWVzIGFzc2lnbmVkIGJ5IElTTyA2Mzkt MyB3aWxsIGJlIGNvbnNpZGVyZWQgZm9yDQogICBpbmNsdXNpb24uICBNYWNyb2xhbmd1YWdl IGZpZWxkcyBNQVkgYmUgYWRkZWQgb3IgcmVtb3ZlZCB2aWEgdGhlDQogICBub3JtYWwgcmVn aXN0cmF0aW9uIHByb2Nlc3Mgd2hlbmV2ZXIgSVNPIDYzOS0zIGRlZmluZXMgbmV3IHZhbHVl cy4NCiAgIE1hY3JvbGFuZ3VhZ2VzIGFyZSBpbmZvcm1hdGlvbmFsLCBhbmQgTUFZIGJlIHJl bW92ZWQgb3IgY2hhbmdlZCBpZg0KICAgSVNPIDYzOS0zIGNoYW5nZXMgdGhlIHZhbHVlcy4N Cg0KICAgRm9yIGV4YW1wbGUsIHRoZSBsYW5ndWFnZSBzdWJ0YWdzICduYicgKE5vcndlZ2lh biBCb2ttYWwpIGFuZCAnbm4nDQogICAoTm9yd2VnaWFuIE55bm9yc2spIGVhY2ggaGF2ZSBh IE1hY3JvbGFuZ3VhZ2UgZW50cnkgb2YgJ25vJw0KICAgKE5vcndlZ2lhbikuICBGb3IgbW9y ZSBpbmZvcm1hdGlvbiBzZWUgU2VjdGlvbiA0LjEuDQoNCjMuMS4xMC4gIENvbW1lbnRzIEZp ZWxkDQoNCiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIGNvbnZleXMgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiBhYm91dCB0aGUgcmVjb3JkDQogICBhbmQgTUFZIGFwcGVhciBtb3JlIHRoYW4g b25jZSBwZXIgcmVjb3JkLiAgVGhlIGZpZWxkLWJvZHkgTUFZIGluY2x1ZGUNCiAgIHRoZSBm dWxsIHJhbmdlIG9mIFVuaWNvZGUgY2hhcmFjdGVycyBhbmQgaXMgbm90IHJlc3RyaWN0ZWQg dG8gYW55DQogICBwYXJ0aWN1bGFyIHNjcmlwdC4gIFRoaXMgZmllbGQgTUFZIGJlIGluc2Vy dGVkIG9yIGNoYW5nZWQgdmlhIHRoZQ0KICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MgYW5kIG5v IGd1YXJhbnRlZSBvZiBzdGFiaWxpdHkgaXMgcHJvdmlkZWQuICBUaGUNCiAgIGNvbnRlbnQg b2YgdGhpcyBmaWVsZCBpcyBub3QgcmVzdHJpY3RlZCwgZXhjZXB0IGJ5IHRoZSBuZWVkIHRv DQogICByZWdpc3RlciB0aGUgaW5mb3JtYXRpb24sIHRoZSBzdWl0YWJpbGl0eSBvZiB0aGUg cmVxdWVzdCwgYW5kIGJ5DQogICByZWFzb25hYmxlIHByYWN0aWNhbCBzaXplIGxpbWl0YXRp b25zLg0KDQozLjIuICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXINCg0KICAgVGhlIExhbmd1 YWdlIFN1YnRhZyBSZXZpZXdlciBtb2RlcmF0ZXMgdGhlIGlldGYtbGFuZ3VhZ2VzIG1haWxp bmcNCiAgIGxpc3QsIHJlc3BvbmRzIHRvIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24sIGFu ZCBwZXJmb3JtcyB0aGUgb3RoZXINCiAgIHJlZ2lzdHJ5IG1haW50ZW5hbmNlIGR1dGllcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMuICBPbmx5IHRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFn IFJldmlld2VyIGlzIHBlcm1pdHRlZCB0byByZXF1ZXN0IElBTkEgdG8gY2hhbmdlLA0KICAg dXBkYXRlLCBvciBhZGQgcmVjb3JkcyB0byB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5 LiAgVGhlIExhbmd1YWdlDQogICBTdWJ0YWcgUmV2aWV3ZXIgTUFZIGRlbGVnYXRlIGxpc3Qg bW9kZXJhdGlvbiBhbmQgb3RoZXIgY2xlcmljYWwNCiAgIGR1dGllcyBhcyBuZWVkZWQuDQoN CiAgIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgaXMgYXBwb2ludGVkIGJ5IHRoZSBJ RVNHIGZvciBhbg0KICAgaW5kZWZpbml0ZSB0ZXJtLCBzdWJqZWN0IHRvIHJlbW92YWwgb3Ig cmVwbGFjZW1lbnQgYXQgdGhlIElFU0cncw0KICAgZGlzY3JldGlvbi4gIFRoZSBJRVNHIHdp bGwgc29saWNpdCBub21pbmVlcyBmb3IgdGhlIHBvc2l0aW9uICh1cG9uDQogICBhZG9wdGlv biBvZiB0aGlzIGRvY3VtZW50IG9yIHVwb24gYSB2YWNhbmN5KSBhbmQgdGhlbiBzb2xpY2l0 DQogICBmZWVkYmFjayBvbiB0aGUgbm9taW5lZXMnIHF1YWxpZmljYXRpb25zLiAgUXVhbGlm aWVkIGNhbmRpZGF0ZXMNCiAgIHNob3VsZCBiZSBmYW1pbGlhciB3aXRoIEJDUCA0NyBhbmQg aXRzIHJlcXVpcmVtZW50czsgYmUgd2lsbGluZyB0bw0KICAgZmFpcmx5LCByZXNwb25zaXZl bHksIGFuZCBqdWRpY2lvdXNseSBhZG1pbmlzdGVyIHRoZSByZWdpc3RyYXRpb24NCiAgIHBy b2Nlc3M7IGFuZCBiZSBzdWl0YWJseSBpbmZvcm1lZCBhYm91dCB0aGUgaXNzdWVzIG9mIGxh bmd1YWdlDQogICBpZGVudGlmaWNhdGlvbiBzbyB0aGF0IHRoZXkgY2FuIGRyYXcgdXBvbiBh bmQgYXNzZXNzIHRoZSBjbGFpbSBhbmQNCiAgIGNvbnRyaWJ1dGlvbnMgb2YgbGFuZ3VhZ2Ug ZXhwZXJ0cyBhbmQgc3VidGFnIHJlcXVlc3RlcnMuDQoNCiAgIFRoZSBzdWJzZXF1ZW50IHBl cmZvcm1hbmNlIG9yIGRlY2lzaW9ucyBvZiB0aGUgTGFuZ3VhZ2UgU3VidGFnDQogICBSZXZp ZXdlciBNQVkgYmUgYXBwZWFsZWQgdG8gdGhlIElFU0cgdW5kZXIgdGhlIHNhbWUgcnVsZXMg YXMgb3RoZXINCiAgIElFVEYgZGVjaXNpb25zIChzZWUgW1JGQzIwMjZdKS4gIFRoZSBJRVNH IGNhbiByZXZlcnNlIG9yIG92ZXJ0dXJuIHRoZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMjhd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBkZWNpc2lvbiBvZiB0aGUgTGFuZ3Vh Z2UgU3VidGFnIFJldmlld2VyLCBwcm92aWRlIGd1aWRhbmNlLCBvciB0YWtlDQogICBvdGhl ciBhcHByb3ByaWF0ZSBhY3Rpb25zLg0KDQozLjMuICBNYWludGVuYW5jZSBvZiB0aGUgUmVn aXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ugb2YgdGhlIHJlZ2lzdHJ5IHJlcXVpcmVzIHRoYXQg YXMgY29kZXMgYXJlIGFzc2lnbmVkIG9yDQogICB3aXRoZHJhd24gYnkgSVNPIDYzOSwgSVNP IDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDksIHRoZSBMYW5ndWFnZQ0KICAgU3VidGFn IFJldmlld2VyIE1VU1QgZXZhbHVhdGUgZWFjaCBjaGFuZ2UgYW5kIGRldGVybWluZSB0aGUN CiAgIGFwcHJvcHJpYXRlIGNvdXJzZSBvZiBhY3Rpb24gYWNjb3JkaW5nIHRvIHRoZSBydWxl cyBpbiB0aGlzIGRvY3VtZW50Lg0KICAgU3VjaCB1cGRhdGVzIGZvbGxvdyB0aGUgcmVnaXN0 cmF0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMuNS4gIFVzdWFsbHkg dGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciB3aWxsIHN0YXJ0IHRoZQ0KICAgcHJvY2Vz cyBmb3IgdGhlIG5ldyBvciB1cGRhdGVkIHJlY29yZCBieSBmaWxsaW5nIGluIHRoZSByZWdp c3RyYXRpb24NCiAgIGZvcm0gYW5kIHN1Ym1pdHRpbmcgaXQuICBJZiBhIGNoYW5nZSB0byBv bmUgb2YgdGhlc2Ugc3RhbmRhcmRzIHRha2VzDQogICBwbGFjZSBhbmQgdGhlIExhbmd1YWdl IFN1YnRhZyBSZXZpZXdlciBkb2VzIG5vdCBkbyB0aGlzIGluIGEgdGltZWx5DQogICBtYW5u ZXIsIHRoZW4gYW55IGludGVyZXN0ZWQgcGFydHkgTUFZIHN1Ym1pdCB0aGUgZm9ybS4gIFRo ZXJlYWZ0ZXINCiAgIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBjb250aW51ZXMgbm9ybWFs bHkuDQoNCiAgIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTVVTVCBlbnN1cmUgdGhh dCBuZXcgc3VidGFncyBtZWV0IHRoZQ0KICAgcmVxdWlyZW1lbnRzIGVsc2V3aGVyZSBpbiB0 aGlzIGRvY3VtZW50IChhbmQgbW9zdCBlc3BlY2lhbGx5IGluDQogICBTZWN0aW9uIDMuNCkg b3Igc3VibWl0IGFuIGFwcHJvcHJpYXRlIHJlZ2lzdHJhdGlvbiBmb3JtIGZvciBhbg0KICAg YWx0ZXJuYXRlIHN1YnRhZyBhcyBkZXNjcmliZWQgaW4gdGhhdCBzZWN0aW9uLiAgRWFjaCBp bmRpdmlkdWFsDQogICBzdWJ0YWcgYWZmZWN0ZWQgYnkgYSBjaGFuZ2UgTVVTVCBiZSBzZW50 IHRvIHRoZSBpZXRmLWxhbmd1YWdlcyBsaXN0DQogICB3aXRoIGl0cyBvd24gcmVnaXN0cmF0 aW9uIGZvcm0gYW5kIGluIGEgc2VwYXJhdGUgbWVzc2FnZS4NCg0KMy40LiAgU3RhYmlsaXR5 IG9mIElBTkEgUmVnaXN0cnkgRW50cmllcw0KDQogICBUaGUgc3RhYmlsaXR5IG9mIGVudHJp ZXMgYW5kIHRoZWlyIG1lYW5pbmcgaW4gdGhlIHJlZ2lzdHJ5IGlzDQogICBjcml0aWNhbCB0 byB0aGUgbG9uZy10ZXJtIHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLiAgVGhlIHJ1bGVz IGluDQogICB0aGlzIHNlY3Rpb24gZ3VhcmFudGVlIHRoYXQgYSBzcGVjaWZpYyBsYW5ndWFn ZSB0YWcncyBtZWFuaW5nIGlzDQogICBzdGFibGUgb3ZlciB0aW1lIGFuZCB3aWxsIG5vdCBj aGFuZ2UuDQoNCiAgIFRoZXNlIHJ1bGVzIHNwZWNpZmljYWxseSBkZWFsIHdpdGggaG93IGNo YW5nZXMgdG8gY29kZXMgKGluY2x1ZGluZw0KICAgd2l0aGRyYXdhbCBhbmQgZGVwcmVjYXRp b24gb2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYzOSwgSVNPDQogICAxNTkyNCwgSVNP IDMxNjYsIGFuZCBVTiBNLjQ5IGFyZSByZWZsZWN0ZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UN CiAgIFN1YnRhZyBSZWdpc3RyeS4gIEFzc2lnbm1lbnRzIHRvIHRoZSBJQU5BIExhbmd1YWdl IFN1YnRhZyBSZWdpc3RyeQ0KICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxvd2luZyBzdGFiaWxp dHkgcnVsZXM6DQoNCiAgIDEuICAgVmFsdWVzIGluIHRoZSBmaWVsZHMgJ1R5cGUnLCAnU3Vi dGFnJywgJ1RhZycsICdBZGRlZCcsDQogICAgICAgICdEZXByZWNhdGVkJyBhbmQgJ1ByZWZl cnJlZC1WYWx1ZScgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlDQogICAgICAgIGd1YXJh bnRlZWQgdG8gYmUgc3RhYmxlIG92ZXIgdGltZS4NCg0KICAgMi4gICBWYWx1ZXMgaW4gdGhl ICdEZXNjcmlwdGlvbicgZmllbGQgTVVTVCBOT1QgYmUgY2hhbmdlZCBpbiBhIHdheQ0KICAg ICAgICB0aGF0IHdvdWxkIGludmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAg VGhleSBNQVkgYmUNCiAgICAgICAgYnJvYWRlbmVkIHNvbWV3aGF0IGluIHNjb3BlLCBjaGFu Z2VkIHRvIGFkZCBpbmZvcm1hdGlvbiwgb3INCiAgICAgICAgYWRhcHRlZCB0byB0aGUgbW9z dCBjb21tb24gbW9kZXJuIHVzYWdlLiAgRm9yIGV4YW1wbGUsIGNvdW50cmllcw0KICAgICAg ICBvY2Nhc2lvbmFsbHkgY2hhbmdlIHRoZWlyIG9mZmljaWFsIG5hbWVzOyBhIGhpc3Rvcmlj YWwgZXhhbXBsZQ0KICAgICAgICBvZiB0aGlzIHdvdWxkIGJlICJVcHBlciBWb2x0YSIgY2hh bmdpbmcgdG8gIkJ1cmtpbmEgRmFzbyIuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDI5XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgMy4gICBWYWx1ZXMgaW4gdGhlIGZpZWxk ICdQcmVmaXgnIE1BWSBiZSBhZGRlZCB0byByZWNvcmRzIG9mIHR5cGUNCiAgICAgICAgJ3Zh cmlhbnQnIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBJZiBhIHByZWZpeCBpcyBh ZGRlZCB0bw0KICAgICAgICBhIHZhcmlhbnQgcmVjb3JkLCAnQ29tbWVudCcgZmllbGRzIFNI T1VMRCBiZSB1c2VkIHRvIGV4cGxhaW4NCiAgICAgICAgZGlmZmVyZW50IHVzYWdlcyB3aXRo IHRoZSB2YXJpb3VzIHByZWZpeGVzLg0KDQogICA0LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQg J1ByZWZpeCcgaW4gcmVjb3JkcyBvZiB0eXBlICd2YXJpYW50JyBNQVkgYmUNCiAgICAgICAg bW9kaWZpZWQsIHNvIGxvbmcgYXMgdGhlIG1vZGlmaWNhdGlvbnMgYnJvYWRlbiB0aGUgc2V0 IG9mDQogICAgICAgIHByZWZpeGVzLiAgVGhhdCBpcywgYSBwcmVmaXggTUFZIGJlIHJlcGxh Y2VkIGJ5IG9uZSBvZiBpdHMgb3duDQogICAgICAgIHByZWZpeGVzLiAgRm9yIGV4YW1wbGUs IHRoZSBwcmVmaXggImVuLVVTIiBjb3VsZCBiZSByZXBsYWNlZCBieQ0KICAgICAgICAiZW4i LCBidXQgbm90IGJ5IHRoZSBwcmVmaXhlcyAiZW4tTGF0biIsICJmciIsIG9yICJlbi1VUy1i b29udCIuDQogICAgICAgIElmIG9uZSBvZiB0aG9zZSBwcmVmaXhlcyB3ZXJlIG5lZWRlZCwg YSBuZXcgUHJlZml4IFNIT1VMRCBiZQ0KICAgICAgICByZWdpc3RlcmVkLg0KDQogICA1LiAg IFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgaW4gcmVjb3JkcyBvZiB0eXBlICdleHRs YW5nJyBNVVNUDQogICAgICAgIE5PVCBiZSBtb2RpZmllZC4NCg0KICAgNi4gICBWYWx1ZXMg aW4gdGhlIGZpZWxkICdQcmVmaXgnIE1VU1QgTk9UIGJlIHJlbW92ZWQuDQoNCiAgIDcuICAg VGhlIGZpZWxkICdDb21tZW50cycgTUFZIGJlIGFkZGVkLCBjaGFuZ2VkLCBtb2RpZmllZCwg b3IgcmVtb3ZlZA0KICAgICAgICB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIG9yIGFu eSBvZiB0aGUgcHJvY2Vzc2VzIG9yDQogICAgICAgIGNvbnNpZGVyYXRpb25zIGRlc2NyaWJl ZCBpbiB0aGlzIHNlY3Rpb24uDQoNCiAgIDguICAgVGhlIGZpZWxkICdTdXBwcmVzcy1TY3Jp cHQnIE1BWSBiZSBhZGRlZCBvciByZW1vdmVkIHZpYSB0aGUNCiAgICAgICAgcmVnaXN0cmF0 aW9uIHByb2Nlc3MuDQoNCiAgIDkuICAgVGhlIGZpZWxkICdNYWNyb2xhbmd1YWdlJyBNQVkg YmUgYWRkZWQgb3IgcmVtb3ZlZCB2aWEgdGhlDQogICAgICAgIHJlZ2lzdHJhdGlvbiBwcm9j ZXNzLCBidXQgb25seSBpbiByZXNwb25zZSB0byBjaGFuZ2VzIG1hZGUgYnkNCiAgICAgICAg SVNPIDYzOS4gIFRoZSBNYWNyb2xhbmd1YWdlIGZpZWxkIGFwcGVhcnMgd2hlbmV2ZXIgYSBs YW5ndWFnZQ0KICAgICAgICBoYXMgYSBjb3JyZXNwb25kaW5nIE1hY3JvbGFuZ3VhZ2UgaW4g SVNPIDYzOS4gIFRoYXQgaXMsIHRoZQ0KICAgICAgICBtYWNyb2xhbmd1YWdlIGZpZWxkcyBp biB0aGUgcmVnaXN0cnkgZXhhY3RseSBtYXRjaCB0aG9zZSBvZiBJU08NCiAgICAgICAgNjM5 LiAgTm8gb3RoZXIgbWFjcm9sYW5ndWFnZSBtYXBwaW5ncyB3aWxsIGJlIGNvbnNpZGVyZWQg Zm9yDQogICAgICAgIHJlZ2lzdHJhdGlvbi4NCg0KICAgMTAuICBDb2RlcyBhc3NpZ25lZCBi eSBJU08gNjM5LTEgdGhhdCBkbyBub3QgY29uZmxpY3Qgd2l0aCBleGlzdGluZw0KICAgICAg ICB0d28tbGV0dGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBhbmQgd2hpY2ggaGF2ZSBu bw0KICAgICAgICBjb3JyZXNwb25kaW5nIHRocmVlLWxldHRlciBwcmltYXJ5IG9yIGV4dGVu ZGVkIGxhbmd1YWdlIHN1YnRhZ3MNCiAgICAgICAgZGVmaW5lZCBpbiB0aGUgcmVnaXN0cnkg YXJlIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgICBuZXcgcmVj b3JkcyBvZiB0eXBlICdsYW5ndWFnZScuDQoNCiAgIDExLiAgQ29kZXMgYXNzaWduZWQgYnkg SVNPIDYzOS0yIHRoYXQgZG8gbm90IGNvbmZsaWN0IHdpdGggZXhpc3RpbmcNCiAgICAgICAg dGhyZWUtbGV0dGVyIHByaW1hcnkgb3IgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBhcmUg ZW50ZXJlZA0KICAgICAgICBpbnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRz IG9mIHR5cGUgJ2xhbmd1YWdlJy4NCg0KICAgMTIuICBDb2RlcyBhc3NpZ25lZCBieSBJU08g NjM5LTMgdGhhdCBkbyBub3QgY29uZmxpY3Qgd2l0aCBleGlzdGluZw0KICAgICAgICB0aHJl ZS1sZXR0ZXIgcHJpbWFyeSBvciBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFyZSBlbnRl cmVkDQogICAgICAgIGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgbmV3IHJlY29yZHMuDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAw OCAgICAgICAgICAgICAgICAgW1BhZ2UgMzBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0K DQogICAgICAgIDEuICBDb2RlcyB0aGF0IGhhdmUgYSBkZWZpbmVkICJtYWNyb2xhbmd1YWdl IiBtYXBwaW5nIGF0IHRoZQ0KICAgICAgICAgICAgdGltZSBvZiB0aGVpciByZWdpc3RyYXRp b24gTVVTVCBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5DQogICAgICAgICAgICBhcyBy ZWNvcmRzIG9mIHR5cGUgJ2V4dGxhbmcnIHdpdGggYSAnUHJlZml4JyBmaWVsZA0KICAgICAg ICAgICAgY29udGFpbmluZyB0aGUgYXBwcm9wcmlhdGUgcHJlZml4IHRhZy4gIFRoZXkgTVVT VCBhbHNvDQogICAgICAgICAgICBpbmNsdWRlIGEgIk1hY3JvbGFuZ3VhZ2UiIGZpZWxkIGlu IHRoZWlyIHJlY29yZC4NCg0KICAgICAgICAyLiAgQ29kZXMgdGhhdCByZXByZXNlbnQgc2ln biBsYW5ndWFnZXMgTVVTVCBiZSBlbnRlcmVkIGludG8gdGhlDQogICAgICAgICAgICByZWdp c3RyeSBhcyByZWNvcmQgb2YgdHlwZSAnZXh0bGFuZycgd2l0aCBhICdQcmVmaXgnIGZpZWxk DQogICAgICAgICAgICB0aGF0IG1hdGNoZXMgdGhlIEJhc2ljIExhbmd1YWdlIFJhbmdlICJz Z24iIChzZWUgU2VjdGlvbg0KICAgICAgICAgICAgMy4zLjEgIkJhc2ljIEZpbHRlcmluZyIg aW4gW1JGQzQ2NDddKS4NCg0KICAgICAgICAzLiAgQWxsIG90aGVyIGNvZGVzIE1VU1QgYmUg ZW50ZXJlZCBpbnRvIHRoZSByZWdpc3RyeSBhcyByZWNvcmRzDQogICAgICAgICAgICBvZiB0 eXBlICdsYW5ndWFnZScuDQoNCiAgIDEzLiAgQSByZWNvcmQgb2YgdHlwZSAnbGFuZ3VhZ2Un IG9yICdleHRsYW5nJyBNVVNUIE5PVCBiZSByZWdpc3RlcmVkDQogICAgICAgIGlmIHRoZXJl IGV4aXN0cyBhIHJlY29yZCBvZiBlaXRoZXIgdHlwZSB3aXRoIHRoZSBzYW1lIHN1YnRhZw0K ICAgICAgICB2YWx1ZS4gIEZvciBleGFtcGxlLCBpZiBhbiAnZXh0bGFuZycgc3VidGFnICdm b28nIGV4aXN0cyBpbiB0aGUNCiAgICAgICAgcmVnaXN0cnksIGFsbCBhdHRlbXB0cyB0byBy ZWdpc3RlciBhICdsYW5ndWFnZScgc3VidGFnICdmb28nDQogICAgICAgIHdpbGwgYmUgcmVq ZWN0ZWQuDQoNCiAgIDE0LiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDE1OTI0IGFuZCBJU08g MzE2NiB0aGF0IGRvIG5vdCBjb25mbGljdA0KICAgICAgICB3aXRoIGV4aXN0aW5nIHN1YnRh Z3Mgb2YgdGhlIGFzc29jaWF0ZWQgdHlwZSBhbmQgd2hvc2UgbWVhbmluZw0KICAgICAgICBp cyBub3QgdGhlIHNhbWUgYXMgYW4gZXhpc3Rpbmcgc3VidGFnIG9mIHRoZSBzYW1lIHR5cGUg YXJlDQogICAgICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVj b3Jkcy4NCg0KICAgMTUuICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQs IG9yIElTTyAzMTY2IHRoYXQgYXJlDQogICAgICAgIHdpdGhkcmF3biBieSB0aGVpciByZXNw ZWN0aXZlIG1haW50ZW5hbmNlIG9yIHJlZ2lzdHJhdGlvbg0KICAgICAgICBhdXRob3JpdHkg cmVtYWluIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MuICBBICdEZXByZWNhdGVkJyBmaWVsZA0K ICAgICAgICBjb250YWluaW5nIHRoZSBkYXRlIG9mIHdpdGhkcmF3YWwgTVVTVCBiZSBhZGRl ZCB0byB0aGUgcmVjb3JkLg0KICAgICAgICBJZiBhIG5ldyByZWNvcmQgb2YgdGhlIHNhbWUg dHlwZSBpcyBhZGRlZCB0aGF0IHJlcHJlc2VudHMgYQ0KICAgICAgICByZXBsYWNlbWVudCB2 YWx1ZSwgdGhlbiBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIE1BWSBhbHNvIGJlDQogICAg ICAgIGFkZGVkLiAgVGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIE1BWSBiZSB1c2VkIHRvIGFk ZCBjb21tZW50cw0KICAgICAgICBhYm91dCB0aGUgd2l0aGRyYXdhbCBvZiB0aGUgY29kZSBi eSB0aGUgcmVzcGVjdGl2ZSBzdGFuZGFyZC4NCg0KICAgICAgICBFeGFtcGxlICBUaGUgcmVn aW9uIGNvZGUgJ1RMJyB3YXMgYXNzaWduZWQgdG8gdGhlIGNvdW50cnkNCiAgICAgICAgICAg J1RpbW9yLUxlc3RlJywgcmVwbGFjaW5nIHRoZSBjb2RlICdUUCcgKHdoaWNoIHdhcyBhc3Np Z25lZCB0bw0KICAgICAgICAgICAnRWFzdCBUaW1vcicgd2hlbiBpdCB3YXMgdW5kZXIgYWRt aW5pc3RyYXRpb24gYnkgUG9ydHVnYWwpLg0KICAgICAgICAgICBUaGUgc3VidGFnICdUUCcg cmVtYWlucyB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLCBidXQgaXRzDQogICAgICAgICAgIHJl Y29yZCBjb250YWlucyB0aGUgYSAnUHJlZmVycmVkLVZhbHVlJyBvZiAnVEwnIGFuZCBpdHMg ZmllbGQNCiAgICAgICAgICAgJ0RlcHJlY2F0ZWQnIGNvbnRhaW5zIHRoZSBkYXRlIHRoZSBu ZXcgY29kZSB3YXMgYXNzaWduZWQNCiAgICAgICAgICAgKCcyMDA0LTA3LTA2JykuDQoNCiAg IDE2LiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBvciBJU08gMzE2 NiB0aGF0IGNvbmZsaWN0DQogICAgICAgIHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUg YXNzb2NpYXRlZCB0eXBlLCBpbmNsdWRpbmcgc3VidGFncw0KICAgICAgICB0aGF0IGFyZSBk ZXByZWNhdGVkLCBNVVNUIE5PVCBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5LiAgVGhl DQogICAgICAgIGZvbGxvd2luZyBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIGFwcGx5IHRv IHN1YnRhZyB2YWx1ZXMgdGhhdA0KICAgICAgICBhcmUgcmVhc3NpZ25lZDoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAg ICAgICAgICAgW1BhZ2UgMzFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICAgICAg IEEuICBGb3IgSVNPIDYzOSBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBt ZWFuaW5nIGlzDQogICAgICAgICAgICBub3QgcmVwcmVzZW50ZWQgYnkgYSBzdWJ0YWcgaW4g dGhlIElBTkEgcmVnaXN0cnksIHRoZQ0KICAgICAgICAgICAgTGFuZ3VhZ2UgU3VidGFnIFJl dmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUsIFNIQUxMDQogICAgICAgICAg ICBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 IGFzIHNvb24NCiAgICAgICAgICAgIGFzIHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgbGFuZ3Vh Z2Ugc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAgICAgICAgICAgdmFsdWUgZm9yIHRoZSBu ZXcgY29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIGxhbmd1YWdlDQogICAgICAg ICAgICBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgTGFuZ3VhZ2Ug U3VidGFnDQogICAgICAgICAgICBSZXZpZXdlciBhbmQgTVVTVCBjb25mb3JtIHRvIG90aGVy IHJlc3RyaWN0aW9ucyBvbiBsYW5ndWFnZQ0KICAgICAgICAgICAgc3VidGFncyBpbiB0aGlz IGRvY3VtZW50Lg0KDQogICAgICAgIEIuICBGb3IgYWxsIHN1YnRhZ3Mgd2hvc2UgbWVhbmlu ZyBpcyBkZXJpdmVkIGZyb20gYW4gZXh0ZXJuYWwNCiAgICAgICAgICAgIHN0YW5kYXJkICh0 aGF0IGlzLCBieSBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBvciBVTg0KICAgICAg ICAgICAgTS40OSksIGlmIGEgbmV3IG1lYW5pbmcgaXMgYXNzaWduZWQgdG8gYW4gZXhpc3Rp bmcgY29kZSBhbmQNCiAgICAgICAgICAgIHRoZSBuZXcgbWVhbmluZyBicm9hZGVucyB0aGUg bWVhbmluZyBvZiB0aGF0IGNvZGUsIHRoZW4gdGhlDQogICAgICAgICAgICBtZWFuaW5nIGZv ciB0aGUgYXNzb2NpYXRlZCBzdWJ0YWcgTUFZIGJlIGNoYW5nZWQgdG8gbWF0Y2guDQogICAg ICAgICAgICBUaGUgbWVhbmluZyBvZiBhIHN1YnRhZyBNVVNUIE5PVCBiZSBuYXJyb3dlZCwg aG93ZXZlciwgYXMNCiAgICAgICAgICAgIHRoaXMgY2FuIHJlc3VsdCBpbiBhbiB1bmtub3du IHByb3BvcnRpb24gb2YgdGhlIGV4aXN0aW5nDQogICAgICAgICAgICB1c2VzIG9mIGEgc3Vi dGFnIGJlY29taW5nIGludmFsaWQuICBOb3RlOiBJU08gNjM5DQogICAgICAgICAgICBtYWlu dGVuYW5jZSBhZ2VuY3kvcmVnaXN0cmF0aW9uIGF1dGhvcml0eSAoTUEvUkEpIGhhcw0KICAg ICAgICAgICAgYWRvcHRlZCBhIHNpbWlsYXIgc3RhYmlsaXR5IHBvbGljeS4NCg0KICAgICAg ICBDLiAgRm9yIElTTyAxNTkyNCBjb2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUn cyBtZWFuaW5nIGlzDQogICAgICAgICAgICBub3QgcmVwcmVzZW50ZWQgYnkgYSBzdWJ0YWcg aW4gdGhlIElBTkEgcmVnaXN0cnksIHRoZQ0KICAgICAgICAgICAgTGFuZ3VhZ2UgU3VidGFn IFJldmlld2VyLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjUsIFNIQUxMDQogICAgICAg ICAgICBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZSBJQU5BIHJlZ2lz dHJ5IGFzIHNvb24NCiAgICAgICAgICAgIGFzIHByYWN0aWNhbCBhIHJlZ2lzdGVyZWQgdmFy aWFudCBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlDQogICAgICAgICAgICB2YWx1ZSBmb3IgdGhl IG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudA0KICAgICAg ICAgICAgc3VidGFnIHdpbGwgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIExhbmd1YWdl IFN1YnRhZw0KICAgICAgICAgICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9ybSB0byBvdGhl ciByZXN0cmljdGlvbnMgb24gdmFyaWFudA0KICAgICAgICAgICAgc3VidGFncyBpbiB0aGlz IGRvY3VtZW50Lg0KDQogICAgICAgIEQuICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZSBu ZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgICAgYXNzb2NpYXRl ZCB3aXRoIHRoZSBzYW1lIFVOIE0uNDkgY29kZSBhcyBhbm90aGVyICdyZWdpb24nDQogICAg ICAgICAgICBzdWJ0YWcsIHRoZW4gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgcmVtYWlu cyBhcyB0aGUNCiAgICAgICAgICAgIHByZWZlcnJlZCB2YWx1ZSBmb3IgdGhhdCByZWdpb24g YW5kIG5vIG5ldyBlbnRyeSBpcyBjcmVhdGVkLg0KICAgICAgICAgICAgQSBjb21tZW50IE1B WSBiZSBhZGRlZCB0byB0aGUgZXhpc3RpbmcgcmVnaW9uIHN1YnRhZw0KICAgICAgICAgICAg aW5kaWNhdGluZyB0aGUgcmVsYXRpb25zaGlwIHRvIHRoZSBuZXcgSVNPIDMxNjYgY29kZS4N Cg0KICAgICAgICBFLiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWdu ZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCBhIFVO IE0uNDkgY29kZSB0aGF0IGlzIG5vdCByZXByZXNlbnRlZCBieSBhbg0KICAgICAgICAgICAg ZXhpc3RpbmcgcmVnaW9uIHN1YnRhZywgdGhlbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmll d2VyLA0KICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy41LCBTSEFMTCBw cmVwYXJlIGEgcHJvcG9zYWwgZm9yDQogICAgICAgICAgICBlbnRlcmluZyB0aGUgYXBwcm9w cmlhdGUgVU4gTS40OSBjb3VudHJ5IGNvZGUgYXMgYW4gZW50cnkgaW4NCiAgICAgICAgICAg IHRoZSBJQU5BIHJlZ2lzdHJ5Lg0KDQogICAgICAgIEYuICBGb3IgSVNPIDMxNjYgY29kZXMs IGlmIHRoZXJlIGlzIG5vIGFzc29jaWF0ZWQgVU4gbnVtZXJpYw0KICAgICAgICAgICAgY29k ZSwgdGhlbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIFNIQUxMIHBldGl0aW9uIHRo ZQ0KICAgICAgICAgICAgVU4gdG8gY3JlYXRlIG9uZS4gIElmIHRoZXJlIGlzIG5vIHJlc3Bv bnNlIGZyb20gdGhlIFVODQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGly ZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAzMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwNw0KDQoNCiAgICAgICAgICAgIHdpdGhpbiBuaW5ldHkgZGF5cyBvZiB0aGUg cmVxdWVzdCBiZWluZyBzZW50LCB0aGUgTGFuZ3VhZ2UNCiAgICAgICAgICAgIFN1YnRhZyBS ZXZpZXdlciBTSEFMTCBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yIGVudGVyaW5nIGluIHRoZQ0K ICAgICAgICAgICAgSUFOQSByZWdpc3RyeSBhcyBzb29uIGFzIHByYWN0aWNhbCBhIHJlZ2lz dGVyZWQgdmFyaWFudA0KICAgICAgICAgICAgc3VidGFnIGFzIGFuIGFsdGVybmF0ZSB2YWx1 ZSBmb3IgdGhlIG5ldyBjb2RlLiAgVGhlIGZvcm0gb2YNCiAgICAgICAgICAgIHRoZSByZWdp c3RlcmVkIHZhcmlhbnQgc3VidGFnIHdpbGwgYmUgYXQgdGhlIGRpc2NyZXRpb24gb2YNCiAg ICAgICAgICAgIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYW5kIE1VU1QgY29uZm9y bSB0byBvdGhlcg0KICAgICAgICAgICAgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQgc3VidGFn cyBpbiB0aGlzIGRvY3VtZW50LiAgVGhpcw0KICAgICAgICAgICAgc2l0dWF0aW9uIGlzIHZl cnkgdW5saWtlbHkgdG8gZXZlciBvY2N1ci4NCg0KICAgMTcuICBVTiBNLjQ5IGhhcyBjb2Rl cyBmb3IgYm90aCBjb3VudHJpZXMgYW5kIGFyZWFzIChzdWNoIGFzICcyNzYnDQogICAgICAg IGZvciBHZXJtYW55KSBhbmQgZ2VvZ3JhcGhpY2FsIHJlZ2lvbnMgYW5kIHN1Yi1yZWdpb25z IChzdWNoIGFzDQogICAgICAgICcxNTAnIGZvciBFdXJvcGUpLiAgVU4gTS40OSBjb3VudHJ5 IG9yIGFyZWEgY29kZXMgZm9yIHdoaWNoDQogICAgICAgIHRoZXJlIGlzIG5vIGNvcnJlc3Bv bmRpbmcgSVNPIDMxNjYgY29kZSBTSE9VTEQgTk9UIGJlDQogICAgICAgIHJlZ2lzdGVyZWQs IGV4Y2VwdCBhcyBhIHN1cnJvZ2F0ZSBmb3IgYW4gSVNPIDMxNjYgY29kZSB0aGF0IGlzDQog ICAgICAgIGJsb2NrZWQgZnJvbSByZWdpc3RyYXRpb24gYnkgYW4gZXhpc3Rpbmcgc3VidGFn LiAgSWYgc3VjaCBhIGNvZGUNCiAgICAgICAgYmVjb21lcyBuZWNlc3NhcnksIHRoZW4gdGhl IHJlZ2lzdHJhdGlvbiBhdXRob3JpdHkgZm9yIElTTyAzMTY2DQogICAgICAgIFNIT1VMRCBm aXJzdCBiZSBwZXRpdGlvbmVkIHRvIGFzc2lnbiBhIGNvZGUgdG8gdGhlIHJlZ2lvbi4gIElm DQogICAgICAgIHRoZSBwZXRpdGlvbiBmb3IgYSBjb2RlIGFzc2lnbm1lbnQgYnkgSVNPIDMx NjYgaXMgcmVmdXNlZCBvciBub3QNCiAgICAgICAgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFu bmVyLCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVzY3JpYmVkDQogICAgICAgIGluIFNl Y3Rpb24gMy41IE1BWSB0aGVuIGJlIHVzZWQgdG8gcmVnaXN0ZXIgdGhlIGNvcnJlc3BvbmRp bmcgVU4NCiAgICAgICAgTS40OSBjb2RlLiAgVGhpcyB3YXksIFVOIE0uNDkgY29kZXMgcmVt YWluIGF2YWlsYWJsZSBhcyB0aGUNCiAgICAgICAgdmFsdWUgb2YgbGFzdCByZXNvcnQgaW4g Y2FzZXMgd2hlcmUgSVNPIDMxNjYgcmVhc3NpZ25zIGENCiAgICAgICAgZGVwcmVjYXRlZCB2 YWx1ZSBpbiB0aGUgcmVnaXN0cnkuDQoNCiAgIDE4LiAgU3RhYmlsaXR5IHByb3Zpc2lvbnMg YXBwbHkgdG8gZ3JhbmRmYXRoZXJlZCB0YWdzIHdpdGggdGhpcw0KICAgICAgICBleGNlcHRp b246IHNob3VsZCBpdCBiZSBwb3NzaWJsZSB0byBjb21wb3NlIG9uZSBvZiB0aGUNCiAgICAg ICAgZ3JhbmRmYXRoZXJlZCB0YWdzIGZyb20gcmVnaXN0ZXJlZCBzdWJ0YWdzLCB0aGVuIHRo ZSBmaWVsZA0KICAgICAgICAnVHlwZScgaW4gdGhhdCByZWNvcmQgaXMgY2hhbmdlZCBmcm9t ICdncmFuZGZhdGhlcmVkJyB0bw0KICAgICAgICAncmVkdW5kYW50Jy4gIE5vdGUgdGhhdCB0 aGlzIHdpbGwgbm90IGFmZmVjdCBsYW5ndWFnZSB0YWdzIHRoYXQNCiAgICAgICAgbWF0Y2gg dGhlIGdyYW5kZmF0aGVyZWQgdGFnLCBzaW5jZSB0aGVzZSB0YWdzIHdpbGwgbm93IG1hdGNo DQogICAgICAgIHZhbGlkIGdlbmVyYXRpdmUgc3VidGFnIHNlcXVlbmNlcy4gIEZvciBleGFt cGxlLCB0aGlzIGRvY3VtZW50DQogICAgICAgIGNhdXNlZCB0aGUgSVNPIDYzOS0zIGNvZGUg J2dhbicsIHVzZWQgaW4gdGhlIHJlZHVuZGFudCB0YWcgInpoLQ0KICAgICAgICBnYW4iLCB0 byBiZSByZWdpc3RlcmVkIGFzIGFuIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZy4gIFRoZQ0K ICAgICAgICBmb3JtZXJseS1ncmFuZGZhdGhlcmVkIHRhZyAiemgtZ2FuIiBiZWNhbWUgYSBy ZWR1bmRhbnQgdGFnIGFzIGENCiAgICAgICAgcmVzdWx0IChidXQgZXhpc3RpbmcgY29udGVu dCBvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1c2UgInpoLQ0KICAgICAgICBnYW4iIHJlbWFp biB2YWxpZCkuDQoNCiAgIE5vdGU6IFRoZSByZWR1bmRhbnQgYW5kIGdyYW5kZmF0aGVyZWQg ZW50cmllcyB0b2dldGhlciBhcmUgdGhlDQogICBjb21wbGV0ZSBsaXN0IG9mIHRhZ3MgcmVn aXN0ZXJlZCB1bmRlciBbUkZDMzA2Nl0uICBUaGUgcmVkdW5kYW50IHRhZ3MNCiAgIGFyZSB0 aG9zZSB0aGF0IGNhbiBub3cgYmUgZm9ybWVkIHVzaW5nIHRoZSBzdWJ0YWdzIGRlZmluZWQg aW4gdGhlDQogICByZWdpc3RyeSB0b2dldGhlciB3aXRoIHRoZSBydWxlcyBvZiBTZWN0aW9u IDIuMi4gIFRoZSBncmFuZGZhdGhlcmVkDQogICBlbnRyaWVzIGluY2x1ZGUgdGhvc2UgdGhh dCBjYW4gbmV2ZXIgYmUgbGVnYWwgdW5kZXIgdGhvc2Ugc2FtZQ0KICAgcHJvdmlzaW9ucyBw bHVzIHRob3NlIHRhZ3MgdGhhdCBjb250YWluIHN1YnRhZ3Mgbm90IHlldCByZWdpc3RlcmVk DQogICBvciwgcGVyaGFwcywgaW5hcHByb3ByaWF0ZSBmb3IgcmVnaXN0cmF0aW9uLg0KDQog ICBUaGUgc2V0IG9mIHJlZHVuZGFudCBhbmQgZ3JhbmRmYXRoZXJlZCB0YWdzIGlzIHBlcm1h bmVudCBhbmQgc3RhYmxlOg0KICAgbmV3IGVudHJpZXMgaW4gdGhpcyBzZWN0aW9uIE1VU1Qg Tk9UIGJlIGFkZGVkIGFuZCBleGlzdGluZyBlbnRyaWVzDQogICBNVVNUIE5PVCBiZSByZW1v dmVkLiAgUmVjb3JkcyBvZiB0eXBlICdncmFuZGZhdGhlcmVkJyBNQVkgaGF2ZSB0aGVpcg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAg ICAgICAgICAgICAgICAgW1BhZ2UgMzNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQog ICB0eXBlIGNvbnZlcnRlZCB0byAncmVkdW5kYW50Jzsgc2VlIGl0ZW0gMTIgaW4gU2VjdGlv biAzLjYgZm9yIG1vcmUNCiAgIGluZm9ybWF0aW9uLiAgVGhlIGRlY2lzaW9uLW1ha2luZyBw cm9jZXNzIGFib3V0IHdoaWNoIHRhZ3Mgd2VyZQ0KICAgaW5pdGlhbGx5IGdyYW5kZmF0aGVy ZWQgYW5kIHdoaWNoIHdlcmUgbWFkZSByZWR1bmRhbnQgaXMgZGVzY3JpYmVkIGluDQogICBb UkZDNDY0NV0uDQoNCiAgIFJGQyAzMDY2IHRhZ3MgdGhhdCB3ZXJlIGRlcHJlY2F0ZWQgcHJp b3IgdG8gdGhlIGFkb3B0aW9uIG9mIFtSRkM0NjQ2XQ0KICAgYXJlIHBhcnQgb2YgdGhlIGxp c3Qgb2YgZ3JhbmRmYXRoZXJlZCB0YWdzLCBhbmQgdGhlaXIgY29tcG9uZW50DQogICBzdWJ0 YWdzIHdlcmUgbm90IGluY2x1ZGVkIGFzIHJlZ2lzdGVyZWQgdmFyaWFudHMgKGFsdGhvdWdo IHRoZXkNCiAgIHJlbWFpbiBlbGlnaWJsZSBmb3IgcmVnaXN0cmF0aW9uKS4gIEZvciBleGFt cGxlLCB0aGUgdGFnICJhcnQtbG9qYmFuIg0KICAgd2FzIGRlcHJlY2F0ZWQgaW4gZmF2b3Ig b2YgdGhlIGxhbmd1YWdlIHN1YnRhZyAnamJvJy4NCg0KMy41LiAgUmVnaXN0cmF0aW9uIFBy b2NlZHVyZSBmb3IgU3VidGFncw0KDQogICBUaGUgcHJvY2VkdXJlIGdpdmVuIGhlcmUgTVVT VCBiZSB1c2VkIGJ5IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIGENCiAgIHN1YnRhZyBub3Qg Y3VycmVudGx5IGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4NCg0KICAg T25seSBzdWJ0YWdzIG9mIHR5cGUgJ2xhbmd1YWdlJyBhbmQgJ3ZhcmlhbnQnIHdpbGwgYmUg Y29uc2lkZXJlZCBmb3INCiAgIGluZGVwZW5kZW50IHJlZ2lzdHJhdGlvbiBvZiBuZXcgc3Vi dGFncy4gIFN1YnRhZ3MgbmVlZGVkIGZvcg0KICAgc3RhYmlsaXR5IGFuZCBzdWJ0YWdzIG5l Y2Vzc2FyeSB0byBrZWVwIHRoZSByZWdpc3RyeSBzeW5jaHJvbml6ZWQNCiAgIHdpdGggSVNP IDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDkgd2l0aGluIHRoZSBsaW1p dHMNCiAgIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhbHNvIHVzZSB0aGlzIHByb2Nlc3Ms IGFzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjMuICBTdGFiaWxpdHkgcHJvdmlzaW9u cyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40Lg0KDQogICBUaGlzIHByb2NlZHVyZSBN QVkgYWxzbyBiZSB1c2VkIHRvIHJlZ2lzdGVyIG9yIGFsdGVyIHRoZSBpbmZvcm1hdGlvbg0K ICAgZm9yIHRoZSAnRGVzY3JpcHRpb24nLCAnQ29tbWVudHMnLCAnRGVwcmVjYXRlZCcsICdQ cmVmaXgnLCBvcg0KICAgJ1N1cHByZXNzLVNjcmlwdCcgZmllbGRzIGluIGEgc3VidGFnJ3Mg cmVjb3JkIGFzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjQuICBDaGFuZ2VzIHRvIGFs bCBvdGhlciBmaWVsZHMgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXJlDQogICBOT1QgcGVybWl0 dGVkLg0KDQogICBSZWdpc3RlcmluZyBhIG5ldyBzdWJ0YWcgb3IgcmVxdWVzdGluZyBtb2Rp ZmljYXRpb25zIHRvIGFuIGV4aXN0aW5nDQogICB0YWcgb3Igc3VidGFnIHN0YXJ0cyB3aXRo IHRoZSByZXF1ZXN0ZXIgZmlsbGluZyBvdXQgdGhlIHJlZ2lzdHJhdGlvbg0KICAgZm9ybSBy ZXByb2R1Y2VkIGJlbG93LiAgTm90ZSB0aGF0IGVhY2ggcmVzcG9uc2UgaXMgbm90IGxpbWl0 ZWQgaW4NCiAgIHNpemUgc28gdGhhdCB0aGUgcmVxdWVzdCBjYW4gYWRlcXVhdGVseSBkZXNj cmliZSB0aGUgcmVnaXN0cmF0aW9uLg0KICAgVGhlIGZpZWxkcyBpbiB0aGUgIlJlY29yZCBS ZXF1ZXN0ZWQiIHNlY3Rpb24gU0hPVUxEIGZvbGxvdyB0aGUNCiAgIHJlcXVpcmVtZW50cyBp biBTZWN0aW9uIDMuMS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAg ICAgW1BhZ2UgMzRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBMQU5HVUFHRSBT VUJUQUcgUkVHSVNUUkFUSU9OIEZPUk0NCiAgIDEuIE5hbWUgb2YgcmVxdWVzdGVyOg0KICAg Mi4gRS1tYWlsIGFkZHJlc3Mgb2YgcmVxdWVzdGVyOg0KICAgMy4gUmVjb3JkIFJlcXVlc3Rl ZDoNCg0KICAgICAgVHlwZToNCiAgICAgIFN1YnRhZzoNCiAgICAgIERlc2NyaXB0aW9uOg0K ICAgICAgUHJlZml4Og0KICAgICAgUHJlZmVycmVkLVZhbHVlOg0KICAgICAgRGVwcmVjYXRl ZDoNCiAgICAgIFN1cHByZXNzLVNjcmlwdDoNCiAgICAgIE1hY3JvbGFuZ3VhZ2U6DQogICAg ICBDb21tZW50czoNCg0KICAgNC4gSW50ZW5kZWQgbWVhbmluZyBvZiB0aGUgc3VidGFnOg0K ICAgNS4gUmVmZXJlbmNlIHRvIHB1Ymxpc2hlZCBkZXNjcmlwdGlvbg0KICAgICAgb2YgdGhl IGxhbmd1YWdlIChib29rIG9yIGFydGljbGUpOg0KICAgNi4gQW55IG90aGVyIHJlbGV2YW50 IGluZm9ybWF0aW9uOg0KDQogICAgICAgICAgICAgIEZpZ3VyZSA0OiBUaGUgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJhdGlvbiBGb3JtDQoNCiAgIEV4YW1wbGVzIG9mIGNvbXBsZXRlZCBy ZWdpc3RyYXRpb24gZm9ybXMgY2FuIGJlIGZvdW5kIGluIEFwcGVuZGl4IEMNCiAgIG9yIG9u bGluZSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xhbmctc3VidGFncy10 ZW1wbGF0ZXMvLg0KDQogICBUaGUgc3VidGFnIHJlZ2lzdHJhdGlvbiBmb3JtIE1VU1QgYmUg c2VudCB0bw0KICAgPGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnPiBmb3IgYSB0d28td2VlayBy ZXZpZXcgcGVyaW9kIGJlZm9yZSBpdCBjYW4NCiAgIGJlIHN1Ym1pdHRlZCB0byBJQU5BLiAg SWYgbW9kaWZpY2F0aW9ucyBhcmUgbWFkZSB0byB0aGUgcmVxdWVzdA0KICAgZHVyaW5nIHRo ZSBjb3Vyc2Ugb2YgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIChzdWNoIGFzIGNvcnJlY3Rp b25zIHRvDQogICBtZWV0IHRoZSByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiAzLjEpIHRoZSBt b2RpZmllZCBmb3JtIE1VU1QgYWxzbyBiZQ0KICAgc2VudCB0byA8aWV0Zi1sYW5ndWFnZXNA aWFuYS5vcmc+IGF0IGxlYXN0IG9uZSB3ZWVrIHByaW9yIHRvDQogICBzdWJtaXNzaW9uIHRv IElBTkEuDQoNCiAgIFdoZW5ldmVyIGFuIGVudHJ5IGlzIGNyZWF0ZWQgb3IgbW9kaWZpZWQg aW4gdGhlIHJlZ2lzdHJ5LCB0aGUgJ0ZpbGUtDQogICBEYXRlJyByZWNvcmQgYXQgdGhlIHN0 YXJ0IG9mIHRoZSByZWdpc3RyeSBpcyB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlDQogICBtb3N0 IHJlY2VudCBtb2RpZmljYXRpb24gZGF0ZSBpbiB0aGUgW1JGQzMzMzldICJmdWxsLWRhdGUi IGZvcm1hdC4NCg0KICAgQmVmb3JlIGZvcndhcmRpbmcgYSBuZXcgcmVnaXN0cmF0aW9uIHRv IElBTkEsIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgIFJldmlld2VyIE1VU1QgZW5zdXJlIHRo YXQgdmFsdWVzIGluIHRoZSAnU3VidGFnJyBmaWVsZCBtYXRjaCBjYXNlDQogICBhY2NvcmRp bmcgdG8gdGhlIGRlc2NyaXB0aW9uIGluIFNlY3Rpb24gMy4xLg0KDQogICBUaGUgaWV0Zi1s YW5ndWFnZXMgbGlzdCBpcyBhbiBvcGVuIGxpc3QgYW5kIGNhbiBiZSBqb2luZWQgYnkgc2Vu ZGluZw0KICAgYSByZXF1ZXN0IHRvIDxpZXRmLWxhbmd1YWdlcy1yZXF1ZXN0QGlhbmEub3Jn Pi4gIFRoZSBsaXN0IGNhbiBiZQ0KICAgaG9zdGVkIGJ5IElBTkEgb3IgYnkgYW55IHRoaXJk IHBhcnR5IGF0IHRoZSByZXF1ZXN0IG9mIElFU0cuDQoNCiAgIFNvbWUgZmllbGRzIGluIGJv dGggdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGFzIHdlbGwgYXMgdGhlIHJlZ2lzdHJ5DQogICBy ZWNvcmQgaXRzZWxmIHBlcm1pdCB0aGUgdXNlIG9mIG5vbi1BU0NJSSBjaGFyYWN0ZXJzLiAg UmVnaXN0cmF0aW9uDQogICByZXF1ZXN0cyBTSE9VTEQgdXNlIHRoZSBVVEYtOCBlbmNvZGlu ZyBmb3IgY29uc2lzdGVuY3kgYW5kIGNsYXJpdHkuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAz NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIEhvd2V2ZXIsIHNpbmNlIHNvbWUg bWFpbCBjbGllbnRzIGRvIG5vdCBzdXBwb3J0IHRoaXMgZW5jb2RpbmcsIG90aGVyDQogICBl bmNvZGluZ3MgTUFZIGJlIHVzZWQgZm9yIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdC4gIFRo ZSBMYW5ndWFnZQ0KICAgU3VidGFnIFJldmlld2VyIGlzIHJlc3BvbnNpYmxlIGZvciBlbnN1 cmluZyB0aGF0IHRoZSBwcm9wZXIgVW5pY29kZQ0KICAgY2hhcmFjdGVycyBhcHBlYXIgaW4g Ym90aCB0aGUgYXJjaGl2ZWQgcmVxdWVzdCBmb3JtIGFuZCB0aGUgcmVnaXN0cnkNCiAgIHJl Y29yZC4gIEluIHRoZSBjYXNlIG9mIGEgdHJhbnNjcmlwdGlvbiBvciBlbmNvZGluZyBlcnJv ciBieSBJQU5BLA0KICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciB3aWxsIHJlcXVl c3QgdGhhdCB0aGUgcmVnaXN0cnkgYmUNCiAgIHJlcGFpcmVkLCBwcm92aWRpbmcgYW55IG5l Y2Vzc2FyeSBpbmZvcm1hdGlvbiB0byBhc3Npc3QgSUFOQS4NCg0KICAgVmFyaWFudCBzdWJ0 YWdzIGFyZSB1c3VhbGx5IHJlZ2lzdGVyZWQgZm9yIHVzZSB3aXRoIGEgcGFydGljdWxhcg0K ICAgcmFuZ2Ugb2YgbGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxlLCB0aGUgc3VidGFnICdy b3phaicgaXMgaW50ZW5kZWQNCiAgIGZvciB1c2Ugd2l0aCBsYW5ndWFnZSB0YWdzIHRoYXQg c3RhcnQgd2l0aCB0aGUgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnICJzbCIsIHNpbmNl IFJlc2lhbiBpcyBhIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLiAgVGh1cywgdGhlDQogICBzdWJ0 YWcgJ3JvemFqJyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpbiB0YWdzIHN1Y2ggYXMgInNsLUxh dG4tcm96YWoiDQogICBvciAic2wtSVQtcm96YWoiLiAgVGhpcyBpbmZvcm1hdGlvbiBpcyBz dG9yZWQgaW4gdGhlICdQcmVmaXgnIGZpZWxkDQogICBpbiB0aGUgcmVnaXN0cnkuICBWYXJp YW50IHJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBTSE9VTEQgaW5jbHVkZSBhdA0KICAgbGVhc3Qg b25lICdQcmVmaXgnIGZpZWxkIGluIHRoZSByZWdpc3RyYXRpb24gZm9ybS4NCg0KICAgRXh0 ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGluY2x1ZGUgZXhhY3RseSBvbmUgJ1ByZWZp eCcgZmllbGQuDQoNCiAgIFRoZSAnUHJlZml4JyBmaWVsZCBmb3IgYSBnaXZlbiByZWdpc3Rl cmVkIHN1YnRhZyBleGlzdHMgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5IGFzIGEgZ3VpZGUg dG8gdXNhZ2UuICBBZGRpdGlvbmFsIHByZWZpeGVzIE1BWSBiZSBhZGRlZCBieQ0KICAgZmls aW5nIGFuIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uIGZvcm0uICBJbiB0aGF0IGZvcm0sIHRo ZSAiQW55IG90aGVyDQogICByZWxldmFudCBpbmZvcm1hdGlvbjoiIGZpZWxkIE1VU1QgaW5k aWNhdGUgdGhhdCBpdCBpcyB0aGUgYWRkaXRpb24gb2YNCiAgIGEgcHJlZml4Lg0KDQogICBS ZXF1ZXN0cyB0byBhZGQgYSBwcmVmaXggdG8gYSB2YXJpYW50IHN1YnRhZyB0aGF0IGltcGx5 IGEgZGlmZmVyZW50DQogICBzZW1hbnRpYyBtZWFuaW5nIHdpbGwgcHJvYmFibHkgYmUgcmVq ZWN0ZWQuICBGb3IgZXhhbXBsZSwgYSByZXF1ZXN0DQogICB0byBhZGQgdGhlIHByZWZpeCAi ZGUiIHRvIHRoZSBzdWJ0YWcgJ25lZGlzJyBzbyB0aGF0IHRoZSB0YWcgImRlLQ0KICAgbmVk aXMiIHJlcHJlc2VudGVkIHNvbWUgR2VybWFuIGRpYWxlY3Qgd291bGQgYmUgcmVqZWN0ZWQu ICBUaGUNCiAgICduZWRpcycgc3VidGFnIHJlcHJlc2VudHMgYSBwYXJ0aWN1bGFyIFNsb3Zl bmlhbiBkaWFsZWN0IGFuZCB0aGUNCiAgIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uIHdvdWxk IGNoYW5nZSB0aGUgc2VtYW50aWMgbWVhbmluZyBhc3NpZ25lZCB0bw0KICAgdGhlIHN1YnRh Zy4gIEEgc2VwYXJhdGUgc3VidGFnIFNIT1VMRCBiZSBwcm9wb3NlZCBpbnN0ZWFkLg0KDQog ICBUaGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNUIGNvbnRhaW4gYSBkZXNjcmlwdGlvbiBv ZiB0aGUgdGFnIGJlaW5nDQogICByZWdpc3RlcmVkIHdyaXR0ZW4gb3IgdHJhbnNjcmliZWQg aW50byB0aGUgTGF0aW4gc2NyaXB0OyBpdCBNQVkgYWxzbw0KICAgaW5jbHVkZSBhIGRlc2Ny aXB0aW9uIGluIGEgbm9uLUxhdGluIHNjcmlwdC4gIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxk DQogICBpcyB1c2VkIGZvciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgZG9lc24ndCBu ZWNlc3NhcmlseSByZXByZXNlbnQNCiAgIHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2YgdGhl IGxhbmd1YWdlIG9yIHZhcmlhdGlvbiBvciB0byBiZSBpbiBhbnkNCiAgIHBhcnRpY3VsYXIg bGFuZ3VhZ2UuDQoNCiAgIFdoaWxlIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0c2VsZiBp cyBub3QgZ3VhcmFudGVlZCB0byBiZSBzdGFibGUNCiAgIGFuZCBlcnJhdGEgY29ycmVjdGlv bnMgTUFZIGJlIHVuZGVydGFrZW4gZnJvbSB0aW1lIHRvIHRpbWUsIGF0dGVtcHRzDQogICB0 byBwcm92aWRlIHRyYW5zbGF0aW9ucyBvciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGlu IHRoZSByZWdpc3RyeQ0KICAgaXRzZWxmIHdpbGwgcHJvYmFibHkgYmUgZnJvd25lZCB1cG9u IGJ5IHRoZSBjb21tdW5pdHkgb3IgcmVqZWN0ZWQNCiAgIG91dHJpZ2h0LCBhcyBjaGFuZ2Vz IG9mIHRoaXMgbmF0dXJlIGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBwcm92aXNpb25zDQogICBp biBTZWN0aW9uIDMuNC4NCg0KICAgV2hlbiB0aGUgdHdvLXdlZWsgcGVyaW9kIGhhcyBwYXNz ZWQsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXINCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdl IDM2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgTVVTVCB0YWtlIG9uZSBvZiB0 aGUgZm9sbG93aW5nIGFjdGlvbnM6DQoNCiAgIG8gIEV4cGxpY2l0bHkgYWNjZXB0IHRoZSBy ZXF1ZXN0IGFuZCBmb3J3YXJkIHRoZSBmb3JtIGNvbnRhaW5pbmcgdGhlDQogICAgICByZWNv cmQgdG8gYmUgaW5zZXJ0ZWQgb3IgbW9kaWZpZWQgdG8gaWFuYUBpYW5hLm9yZyBhY2NvcmRp bmcgdG8NCiAgICAgIHRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLg0K DQogICBvICBFeHBsaWNpdGx5IHJlamVjdCB0aGUgcmVxdWVzdCBiZWNhdXNlIG9mIHNpZ25p ZmljYW50IG9iamVjdGlvbnMNCiAgICAgIHJhaXNlZCBvbiB0aGUgbGlzdCBvciBkdWUgdG8g cHJvYmxlbXMgd2l0aCBjb25zdHJhaW50cyBpbiB0aGlzDQogICAgICBkb2N1bWVudCAod2hp Y2ggTVVTVCBiZSBleHBsaWNpdGx5IGNpdGVkKS4NCg0KICAgbyAgRXh0ZW5kIHRoZSByZXZp ZXcgcGVyaW9kIGJ5IGdyYW50aW5nIGFuIGFkZGl0aW9uYWwgdHdvLXdlZWsNCiAgICAgIGlu Y3JlbWVudCB0byBwZXJtaXQgZnVydGhlciBkaXNjdXNzaW9uLiAgQWZ0ZXIgZWFjaCB0d28t d2Vlaw0KICAgICAgaW5jcmVtZW50LCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1V U1QgaW5kaWNhdGUgb24gdGhlIGxpc3QNCiAgICAgIHdoZXRoZXIgdGhlIHJlZ2lzdHJhdGlv biBoYXMgYmVlbiBhY2NlcHRlZCwgcmVqZWN0ZWQsIG9yIGV4dGVuZGVkLg0KDQogICBOb3Rl IHRoYXQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNQVkgcmFpc2Ugb2JqZWN0aW9u cyBvbiB0aGUNCiAgIGxpc3QgaWYgaGUgb3Igc2hlIHNvIGRlc2lyZXMuICBUaGUgaW1wb3J0 YW50IHRoaW5nIGlzIHRoYXQgdGhlDQogICBvYmplY3Rpb24gTVVTVCBiZSBtYWRlIHB1Ymxp Y2x5Lg0KDQogICBTb21ldGltZXMgdGhlIHJlcXVlc3QgbmVlZHMgdG8gYmUgbW9kaWZpZWQg YXMgYSByZXN1bHQgb2YgZGlzY3Vzc2lvbg0KICAgZHVyaW5nIHRoZSByZXZpZXcgcGVyaW9k IG9yIGR1ZSB0byByZXF1aXJlbWVudHMgaW4gdGhpcyBkb2N1bWVudC4NCiAgIFRoZSBhcHBs aWNhbnQsIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwgb3Igb3RoZXJzIGFyZSBmcmVlIHRv IHN1Ym1pdA0KICAgYSBtb2RpZmllZCB2ZXJzaW9uIG9mIHRoZSBjb21wbGV0ZWQgcmVnaXN0 cmF0aW9uIGZvcm0sIHdoaWNoIHdpbGwgYmUNCiAgIGNvbnNpZGVyZWQgaW4gbGlldSBvZiB0 aGUgb3JpZ2luYWwgcmVxdWVzdCB3aXRoIHRoZSBleHBsaWNpdCBhcHByb3ZhbA0KICAgb2Yg dGhlIGFwcGxpY2FudC4gIFN1Y2ggY2hhbmdlcyBkbyBub3QgcmVzdGFydCB0aGUgdHdvLXdl ZWsNCiAgIGRpc2N1c3Npb24gcGVyaW9kLCBhbHRob3VnaCBhbiBhcHBsaWNhdGlvbiBjb250 YWluaW5nIHRoZSBmaW5hbA0KICAgcmVjb3JkIHN1Ym1pdHRlZCB0byBJQU5BIE1VU1QgYXBw ZWFyIG9uIHRoZSBsaXN0IGF0IGxlYXN0IG9uZSB3ZWVrDQogICBwcmlvciB0byB0aGUgTGFu Z3VhZ2UgU3VidGFnIFJldmlld2VyIGZvcndhcmRpbmcgdGhlIHJlY29yZCB0byBJQU5BLg0K ICAgVGhlIGFwcGxpY2FudCBpcyBhbHNvIGZyZWUgdG8gbW9kaWZ5IGEgcmVqZWN0ZWQgYXBw bGljYXRpb24gd2l0aA0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhbmQgc3VibWl0IGl0 IGFnYWluOyB0aGlzIHN0YXJ0cyBhIG5ldyB0d28tDQogICB3ZWVrIGNvbW1lbnQgcGVyaW9k Lg0KDQogICBSZWdpc3RyYXRpb25zIGluaXRpYXRlZCBkdWUgdG8gdGhlIHByb3Zpc2lvbnMg b2YgU2VjdGlvbiAzLjMgb3INCiAgIFNlY3Rpb24gMy40IFNIQUxMIE5PVCBiZSByZWplY3Rl ZCBhbHRvZ2V0aGVyIChzaW5jZSB0aGV5IGhhdmUgdG8NCiAgIHVsdGltYXRlbHkgYXBwZWFy IGluIHRoZSByZWdpc3RyeSkgYW5kIFNIT1VMRCBiZSBjb21wbGV0ZWQgYXMgcXVpY2tseQ0K ICAgYXMgcG9zc2libGUuICBUaGUgcmV2aWV3IHByb2Nlc3MgYWxsb3dzIGxpc3QgbWVtYmVy cyB0byBjb21tZW50IG9uDQogICB0aGUgc3BlY2lmaWMgaW5mb3JtYXRpb24gaW4gdGhlIGZv cm0gYW5kIHRoZSByZWNvcmQgaXQgY29udGFpbnMgYW5kDQogICB0aHVzIGhlbHAgZW5zdXJl IHRoYXQgaXQgaXMgY29ycmVjdCBhbmQgY29uc2lzdGVudC4gIFRoZSBMYW5ndWFnZQ0KICAg U3VidGFnIFJldmlld2VyIE1BWSByZWplY3QgYSBzcGVjaWZpYyB2ZXJzaW9uIG9mIHRoZSBm b3JtLCBidXQgTVVTVA0KICAgaW5jbHVkZSBpbiB0aGUgcmVqZWN0aW9uIGEgc3VpdGFibGUg cmVwbGFjZW1lbnQsIGV4dGVuZGluZyB0aGUgcmV2aWV3DQogICBwZXJpb2QgYXMgZGVzY3Jp YmVkIGFib3ZlLCB1bnRpbCB0aGUgZm9ybSBpcyBpbiBhIGZvcm1hdCB3b3J0aHkgb2YNCiAg IHJldmlld2VyJ3MgYXBwcm92YWwuDQoNCiAgIERlY2lzaW9ucyBtYWRlIGJ5IHRoZSBMYW5n dWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZIGJlIGFwcGVhbGVkIHRvIHRoZQ0KICAgSUVTRyBb UkZDMjAyOF0gdW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMgb3RoZXIgSUVURiBkZWNpc2lvbnMN CiAgIFtSRkMyMDI2XS4gIFRoaXMgaW5jbHVkZXMgYSBkZWNpc2lvbiB0byBleHRlbmQgdGhl IHJldmlldyBwZXJpb2Qgb3INCiAgIHRoZSBmYWlsdXJlIHRvIGFubm91bmNlIGEgZGVjaXNp b24gaW4gYSBjbGVhciBhbmQgdGltZWx5IG1hbm5lci4NCg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgMzddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBUaGUgYXBwcm92ZWQgcmVj b3JkcyBhcHBlYXIgaW4gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIFRoZQ0KICAg YXBwcm92ZWQgcmVnaXN0cmF0aW9uIGZvcm1zIGFyZSBhdmFpbGFibGUgb25saW5lIHVuZGVy DQogICBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xhbmctc3VidGFncy10ZW1w bGF0ZXMvLg0KDQogICBVcGRhdGVzIG9yIGNoYW5nZXMgdG8gZXhpc3RpbmcgcmVjb3JkcyBm b2xsb3cgdGhlIHNhbWUgcHJvY2VkdXJlIGFzDQogICBuZXcgcmVnaXN0cmF0aW9ucy4gIFRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgZGVjaWRlcyB3aGV0aGVyDQogICB0aGVyZSBp cyBjb25zZW5zdXMgdG8gdXBkYXRlIHRoZSByZWdpc3RyYXRpb24gZm9sbG93aW5nIHRoZSB0 d28gd2Vlaw0KICAgcmV2aWV3IHBlcmlvZDsgbm9ybWFsbHksIG9iamVjdGlvbnMgYnkgdGhl IG9yaWdpbmFsIHJlZ2lzdHJhbnQgd2lsbA0KICAgY2FycnkgZXh0cmEgd2VpZ2h0IGluIGZv cm1pbmcgc3VjaCBhIGNvbnNlbnN1cy4NCg0KICAgUmVnaXN0cmF0aW9ucyBhcmUgcGVybWFu ZW50IGFuZCBzdGFibGUuICBPbmNlIHJlZ2lzdGVyZWQsIHN1YnRhZ3MNCiAgIHdpbGwgbm90 IGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVnaXN0cnkgYW5kIHdpbGwgcmVtYWluIGEgdmFsaWQg d2F5IGluDQogICB3aGljaCB0byBzcGVjaWZ5IGEgc3BlY2lmaWMgbGFuZ3VhZ2Ugb3IgdmFy aWFudC4NCg0KICAgTm90ZTogVGhlIHB1cnBvc2Ugb2YgdGhlICJSZWZlcmVuY2UgdG8gcHVi bGlzaGVkIGRlc2NyaXB0aW9uIiBzZWN0aW9uDQogICBpbiB0aGUgcmVnaXN0cmF0aW9uIGZv cm0gaXMgdG8gYWlkIGluIHZlcmlmeWluZyB3aGV0aGVyIGEgbGFuZ3VhZ2UgaXMNCiAgIHJl Z2lzdGVyZWQgb3Igd2hhdCBsYW5ndWFnZSBvciBsYW5ndWFnZSB2YXJpYXRpb24gYSBwYXJ0 aWN1bGFyIHN1YnRhZw0KICAgcmVmZXJzIHRvLiAgSW4gbW9zdCBjYXNlcywgcmVmZXJlbmNl IHRvIGFuIGF1dGhvcml0YXRpdmUgZ3JhbW1hciBvcg0KICAgZGljdGlvbmFyeSBvZiB0aGF0 IGxhbmd1YWdlIHdpbGwgYmUgdXNlZnVsOyBpbiBjYXNlcyB3aGVyZSBubyBzdWNoDQogICB3 b3JrIGV4aXN0cywgb3RoZXIgd2VsbC1rbm93biB3b3JrcyBkZXNjcmliaW5nIHRoYXQgbGFu Z3VhZ2Ugb3IgaW4NCiAgIHRoYXQgbGFuZ3VhZ2UgTUFZIGJlIGFwcHJvcHJpYXRlLiAgVGhl IExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KICAgZGVjaWRlcyB3aGF0IGNvbnN0aXR1dGVz ICJnb29kIGVub3VnaCIgcmVmZXJlbmNlIG1hdGVyaWFsLiAgVGhpcw0KICAgcmVxdWlyZW1l bnQgaXMgbm90IGludGVuZGVkIHRvIGV4Y2x1ZGUgcGFydGljdWxhciBsYW5ndWFnZXMgb3IN CiAgIGRpYWxlY3RzIGR1ZSB0byB0aGUgc2l6ZSBvZiB0aGUgc3BlYWtlciBwb3B1bGF0aW9u IG9yIGxhY2sgb2YgYQ0KICAgc3RhbmRhcmRpemVkIG9ydGhvZ3JhcGh5LiAgTWlub3JpdHkg bGFuZ3VhZ2VzIHdpbGwgYmUgY29uc2lkZXJlZA0KICAgZXF1YWxseSBvbiB0aGVpciBvd24g bWVyaXRzLg0KDQozLjYuICBQb3NzaWJpbGl0aWVzIGZvciBSZWdpc3RyYXRpb24NCg0KICAg UG9zc2liaWxpdGllcyBmb3IgcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3Mgb3IgaW5mb3JtYXRp b24gYWJvdXQNCiAgIHN1YnRhZ3MgaW5jbHVkZToNCg0KICAgbyAgUHJpbWFyeSBsYW5ndWFn ZSBzdWJ0YWdzIGZvciBsYW5ndWFnZXMgbm90IGxpc3RlZCBpbiBJU08gNjM5IHRoYXQNCiAg ICAgIGFyZSBub3QgdmFyaWFudHMgb2YgYW55IGxpc3RlZCBvciByZWdpc3RlcmVkIGxhbmd1 YWdlIE1BWSBiZQ0KICAgICAgcmVnaXN0ZXJlZC4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1l bnQgd2FzIGNyZWF0ZWQsIHRoZXJlIHdlcmUgbm8NCiAgICAgIGV4YW1wbGVzIG9mIHRoaXMg Zm9ybSBvZiBzdWJ0YWcuICBCZWZvcmUgYXR0ZW1wdGluZyB0byByZWdpc3RlciBhDQogICAg ICBsYW5ndWFnZSBzdWJ0YWcsIHRoZXJlIE1VU1QgYmUgYW4gYXR0ZW1wdCB0byByZWdpc3Rl ciB0aGUgbGFuZ3VhZ2UNCiAgICAgIHdpdGggSVNPIDYzOS4gIFN1YnRhZ3MgTVVTVCBOT1Qg YmUgcmVnaXN0ZXJlZCBmb3IgbGFuZ3VhZ2VzDQogICAgICBkZWZpbmVkIGJ5IGNvZGVzIHRo YXQgZXhpc3QgaW4gSVNPIDYzOS0xLCBJU08gNjM5LTIsIG9yIElTTyA2MzktMywNCiAgICAg IG9yIHRoYXQgYXJlIHVuZGVyIGNvbnNpZGVyYXRpb24gYnkgdGhlIElTTyA2MzkgcmVnaXN0 cmF0aW9uDQogICAgICBhdXRob3JpdGllcywgb3IgdGhhdCBoYXZlIG5ldmVyIGJlZW4gYXR0 ZW1wdGVkIGZvciByZWdpc3RyYXRpb24NCiAgICAgIHdpdGggdGhvc2UgYXV0aG9yaXRpZXMu ICBJZiBJU08gNjM5IGhhcyBwcmV2aW91c2x5IHJlamVjdGVkIGENCiAgICAgIGxhbmd1YWdl IGZvciByZWdpc3RyYXRpb24sIGl0IGlzIHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoYXQgdGhl cmUNCiAgICAgIG11c3QgYmUgYWRkaXRpb25hbCwgdmVyeSBjb21wZWxsaW5nIGV2aWRlbmNl IG9mIG5lZWQgYmVmb3JlIGl0DQogICAgICB3aWxsIGJlIHJlZ2lzdGVyZWQgYXMgYSBwcmlt YXJ5IGxhbmd1YWdlIHN1YnRhZyBpbiB0aGUgSUFOQQ0KICAgICAgcmVnaXN0cnkgKHRvIHRo ZSBleHRlbnQgdGhhdCBpdCBpcyB2ZXJ5IHVubGlrZWx5IHRoYXQgYW55IHN1YnRhZ3MNCiAg ICAgIHdpbGwgYmUgcmVnaXN0ZXJlZCBvZiB0aGlzIHR5cGUpLg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAg ICBbUGFnZSAzOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIG8gIERpYWxlY3Qg b3Igb3RoZXIgZGl2aXNpb25zIG9yIHZhcmlhdGlvbnMgd2l0aGluIGEgbGFuZ3VhZ2UsIGl0 cw0KICAgICAgb3J0aG9ncmFwaHksIHdyaXRpbmcgc3lzdGVtLCByZWdpb25hbCBvciBoaXN0 b3JpY2FsIHVzYWdlLA0KICAgICAgdHJhbnNsaXRlcmF0aW9uIG9yIG90aGVyIHRyYW5zZm9y bWF0aW9uLCBvciBkaXN0aW5ndWlzaGluZw0KICAgICAgdmFyaWF0aW9uIE1BWSBiZSByZWdp c3RlcmVkIGFzIHZhcmlhbnQgc3VidGFncy4gIEFuIGV4YW1wbGUgaXMgdGhlDQogICAgICAn cm96YWonIHN1YnRhZyAodGhlIFJlc2lhbiBkaWFsZWN0IG9mIFNsb3ZlbmlhbikuDQoNCiAg IG8gIFRoZSBhZGRpdGlvbiBvciBtYWludGVuYW5jZSBvZiBmaWVsZHMgKGdlbmVyYWxseSBv ZiBhbg0KICAgICAgaW5mb3JtYXRpb25hbCBuYXR1cmUpIGluIFRhZyBvciBTdWJ0YWcgcmVj b3JkcyBhcyBkZXNjcmliZWQgaW4NCiAgICAgIFNlY3Rpb24gMy4xIGFuZCBzdWJqZWN0IHRv IHRoZSBzdGFiaWxpdHkgcHJvdmlzaW9ucyBpbg0KICAgICAgU2VjdGlvbiAzLjQuICBUaGlz IGluY2x1ZGVzIGRlc2NyaXB0aW9ucywgY29tbWVudHMsIGRlcHJlY2F0aW9uDQogICAgICBh bmQgcHJlZmVycmVkIHZhbHVlcyBmb3Igb2Jzb2xldGUgb3Igd2l0aGRyYXduIGNvZGVzLCBv ciB0aGUNCiAgICAgIGFkZGl0aW9uIG9mIHNjcmlwdCBvciBleHRsYW5nIGluZm9ybWF0aW9u IHRvIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgIHN1YnRhZ3MuDQoNCiAgIG8gIFRoZSBhZGRp dGlvbiBvZiByZWNvcmRzIGFuZCByZWxhdGVkIGZpZWxkIHZhbHVlIGNoYW5nZXMgbmVjZXNz YXJ5DQogICAgICB0byByZWZsZWN0IGFzc2lnbm1lbnRzIG1hZGUgYnkgSVNPIDYzOSwgSVNP IDE1OTI0LCBJU08gMzE2NiwgYW5kDQogICAgICBVTiBNLjQ5IGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuNC4NCg0KICAgU3VidGFncyBwcm9wb3NlZCBmb3IgcmVnaXN0cmF0aW9uIHRo YXQgd291bGQgY2F1c2UgYWxsIG9yIHBhcnQgb2YgYQ0KICAgZ3JhbmRmYXRoZXJlZCB0YWcg dG8gYmVjb21lIHJlZHVuZGFudCBidXQgd2hvc2UgbWVhbmluZyBjb25mbGljdHMNCiAgIHdp dGggb3IgYWx0ZXJzIHRoZSBtZWFuaW5nIG9mIHRoZSBncmFuZGZhdGhlcmVkIHRhZyBNVVNU IGJlIHJlamVjdGVkLg0KDQogICBUaGlzIGRvY3VtZW50IGxlYXZlcyB0aGUgZGVjaXNpb24g b24gd2hhdCBzdWJ0YWdzIG9yIGNoYW5nZXMgdG8NCiAgIHN1YnRhZ3MgYXJlIGFwcHJvcHJp YXRlIChvciBub3QpIHRvIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgZGVzY3JpYmVk IGluIFNlY3Rpb24gMy41Lg0KDQogICBOb3RlOiBmb3VyLWNoYXJhY3RlciBwcmltYXJ5IGxh bmd1YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGFsbG93DQogICBmb3IgdGhlIHBvc3Np YmlsaXR5IG9mIGFscGhhNCBjb2RlcyBpbiBzb21lIGZ1dHVyZSBhZGRpdGlvbiB0byB0aGUN CiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0YW5kYXJkcy4NCg0KICAgSVNPIDYzOSBkZWZpbmVz IGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBhZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMgaW4N CiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJU08gNjM5LiAgVGhpcyBhZ2VuY3kgaXM6 DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24gQ2VudHJlIGZvciBUZXJtaW5vbG9n eSAoSW5mb3Rlcm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIsIEFULTExMjANCiAgIFdpZW4s IEF1c3RyaWENCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQuIDMxMiBGYXg6ICs0MyAx IDIxNiAzMiA3Mg0KDQogICBJU08gNjM5LTIgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFnZW5j eSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlzdCBvZiBsYW5n dWFnZXMgaW4gSVNPIDYzOS0yLiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIExpYnJhcnkgb2Yg Q29uZ3Jlc3MNCiAgIE5ldHdvcmsgRGV2ZWxvcG1lbnQgYW5kIE1BUkMgU3RhbmRhcmRzIE9m ZmljZQ0KICAgV2FzaGluZ3RvbiwgRC5DLiAyMDU0MCBVU0ENCiAgIFBob25lOiArMSAyMDIg NzA3IDYyMzcgRmF4OiArMSAyMDIgNzA3IDAxMTUNCiAgIFVSTDogaHR0cDovL3d3dy5sb2Mu Z292L3N0YW5kYXJkcy9pc282MzktMg0KDQogICBJU08gNjM5LTMgZGVmaW5lcyBhIG1haW50 ZW5hbmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAg ICAgICBbUGFnZSAzOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIGluIHRoZSBs aXN0IG9mIGxhbmd1YWdlcyBpbiBJU08gNjM5LTMuICBUaGlzIGFnZW5jeSBpczoNCg0KICAg U0lMIEludGVybmF0aW9uYWwNCiAgIElTTyA2MzktMyBSZWdpc3RyYXINCiAgIDc1MDAgVy4g Q2FtcCBXaXNkb20gUmQuDQogICBEYWxsYXMsIFRYIDc1MjM2IFVTQQ0KICAgUGhvbmU6ICsx IDk3MiA3MDggNzQwMCwgZXh0LiAyMjkzIEZheDogKzEgOTcyIDcwOCA3NTQ2DQogICBFbWFp bDogaXNvNjM5LTNAc2lsLm9yZw0KICAgVVJMOiBodHRwOi8vd3d3LnNpbC5vcmcvaXNvNjM5 LTMNCg0KICAgVGhlIG1haW50ZW5hbmNlIGFnZW5jeSBmb3IgSVNPIDMxNjYgKGNvdW50cnkg Y29kZXMpIGlzOg0KDQogICBJU08gMzE2NiBNYWludGVuYW5jZSBBZ2VuY3kNCiAgIGMvbyBJ bnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uDQogICBDYXNl IHBvc3RhbGUgNTYNCiAgIENILTEyMTEgR2VuZXZhIDIwIFN3aXR6ZXJsYW5kDQogICBQaG9u ZTogKzQxIDIyIDc0OSA3MiAzMyBGYXg6ICs0MSAyMiA3NDkgNzMgNDkNCiAgIFVSTDogaHR0 cDovL3d3dy5pc28ub3JnL2lzby9lbi9wcm9kcy1zZXJ2aWNlcy9pc28zMTY2bWEvaW5kZXgu aHRtbA0KDQogICBUaGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDE1OTI0IChz Y3JpcHQgY29kZXMpIGlzOg0KDQogICBVbmljb2RlIENvbnNvcnRpdW0gQm94IDM5MTQ3Ng0K ICAgTW91bnRhaW4gVmlldywgQ0EgOTQwMzktMTQ3NiwgVVNBDQogICBVUkw6IGh0dHA6Ly93 d3cudW5pY29kZS5vcmcvaXNvMTU5MjQNCg0KICAgVGhlIFN0YXRpc3RpY3MgRGl2aXNpb24g b2YgdGhlIFVuaXRlZCBOYXRpb25zIFNlY3JldGFyaWF0IG1haW50YWlucw0KICAgdGhlIFN0 YW5kYXJkIENvdW50cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIGFuZCBj YW4gYmUNCiAgIHJlYWNoZWQgYXQ6DQoNCiAgIFN0YXRpc3RpY2FsIFNlcnZpY2VzIEJyYW5j aA0KICAgU3RhdGlzdGljcyBEaXZpc2lvbg0KICAgVW5pdGVkIE5hdGlvbnMsIFJvb20gREMy LTE2MjANCiAgIE5ldyBZb3JrLCBOWSAxMDAxNywgVVNBDQoNCiAgIEZheDogKzEtMjEyLTk2 My0wNjIzDQogICBFLW1haWw6IHN0YXRpc3RpY3NAdW4ub3JnDQogICBVUkw6IGh0dHA6Ly91 bnN0YXRzLnVuLm9yZy91bnNkL21ldGhvZHMvbTQ5L200OWFscGhhLmh0bQ0KDQozLjcuICBF eHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgIEV4dGVuc2lvbiBzdWJ0 YWdzIGFyZSB0aG9zZSBpbnRyb2R1Y2VkIGJ5IHNpbmdsZS1jaGFyYWN0ZXIgc3VidGFncw0K ICAgKCJzaW5nbGV0b25zIikgb3RoZXIgdGhhbiAneCcuICBUaGV5IGFyZSByZXNlcnZlZCBm b3IgdGhlIGdlbmVyYXRpb24NCiAgIG9mIGlkZW50aWZpZXJzIHRoYXQgY29udGFpbiBhIGxh bmd1YWdlIGNvbXBvbmVudCBhbmQgYXJlIGNvbXBhdGlibGUNCiAgIHdpdGggYXBwbGljYXRp b25zIHRoYXQgdW5kZXJzdGFuZCBsYW5ndWFnZSB0YWdzLg0KDQogICBUaGUgc3RydWN0dXJl IGFuZCBmb3JtIG9mIGV4dGVuc2lvbnMgYXJlIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBz bw0KICAgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIGNyZWF0ZWQgdGhhdCBhcmUgZm9y d2FyZCBjb21wYXRpYmxlIHdpdGgNCiAgIGFwcGxpY2F0aW9ucyB0aGF0IG1pZ2h0IGJlIGNy ZWF0ZWQgdXNpbmcgc2luZ2xldG9ucyBpbiB0aGUgZnV0dXJlLg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAg W1BhZ2UgNDBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBJbiBhZGRpdGlvbiwg ZGVmaW5pbmcgYSBtZWNoYW5pc20gZm9yIG1haW50YWluaW5nIHNpbmdsZXRvbnMgd2lsbA0K ICAgbGVuZCBzdGFiaWxpdHkgdG8gdGhpcyBkb2N1bWVudCBieSByZWR1Y2luZyB0aGUgbGlr ZWx5IG5lZWQgZm9yDQogICBmdXR1cmUgcmV2aXNpb25zIG9yIHVwZGF0ZXMuDQoNCiAgIFNp bmdsZS1jaGFyYWN0ZXIgc3VidGFncyBhcmUgYXNzaWduZWQgYnkgSUFOQSB1c2luZyB0aGUg IklFVEYNCiAgIENvbnNlbnN1cyIgcG9saWN5IGRlZmluZWQgYnkgW1JGQzI0MzRdLiAgVGhp cyBwb2xpY3kgcmVxdWlyZXMgdGhlDQogICBkZXZlbG9wbWVudCBvZiBhbiBSRkMsIHdoaWNo IFNIQUxMIGRlZmluZSB0aGUgbmFtZSwgcHVycG9zZSwNCiAgIHByb2Nlc3NlcywgYW5kIHBy b2NlZHVyZXMgZm9yIG1haW50YWluaW5nIHRoZSBzdWJ0YWdzLiAgVGhlDQogICBtYWludGFp bmluZyBvciByZWdpc3RlcmluZyBhdXRob3JpdHksIGluY2x1ZGluZyBuYW1lLCBjb250YWN0 IGVtYWlsLA0KICAgZGlzY3Vzc2lvbiBsaXN0IGVtYWlsLCBhbmQgVVJMIGxvY2F0aW9uIG9m IHRoZSByZWdpc3RyeSwgTVVTVCBiZQ0KICAgaW5kaWNhdGVkIGNsZWFybHkgaW4gdGhlIFJG Qy4gIFRoZSBSRkMgTVVTVCBzcGVjaWZ5IG9yIGluY2x1ZGUgZWFjaA0KICAgb2YgdGhlIGZv bGxvd2luZzoNCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCByZWZlcmVuY2UgdGhl IHNwZWNpZmljIHZlcnNpb24gb3IgcmV2aXNpb24NCiAgICAgIG9mIHRoaXMgZG9jdW1lbnQg dGhhdCBnb3Zlcm5zIGl0cyBjcmVhdGlvbiBhbmQgTVVTVCByZWZlcmVuY2UgdGhpcw0KICAg ICAgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlv biBhbmQgYWxsIHN1YnRhZ3MgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbg0KICAgICAg TVVTVCBmb2xsb3cgdGhlIEFCTkYgYW5kIG90aGVyIHJ1bGVzIGZvciB0aGUgZm9ybWF0aW9u IG9mIHRhZ3MgYW5kDQogICAgICBzdWJ0YWdzIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dC4gIEluIHBhcnRpY3VsYXIsIGl0IE1VU1QNCiAgICAgIHNwZWNpZnkgdGhhdCBjYXNlIGlz IG5vdCBzaWduaWZpY2FudCBhbmQgdGhhdCBzdWJ0YWdzIE1VU1QgTk9UDQogICAgICBleGNl ZWQgZWlnaHQgY2hhcmFjdGVycyBpbiBsZW5ndGguDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0 aW9uIE1VU1Qgc3BlY2lmeSBhIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbi4NCg0KICAgbyAg VGhlIHNwZWNpZmljYXRpb24gb2YgdmFsaWQgc3VidGFncyBNVVNUIGJlIGF2YWlsYWJsZSBv dmVyIHRoZQ0KICAgICAgSW50ZXJuZXQgYW5kIGF0IG5vIGNvc3QuDQoNCiAgIG8gIFRoZSBz cGVjaWZpY2F0aW9uIE1VU1QgYmUgaW4gdGhlIHB1YmxpYyBkb21haW4gb3IgYXZhaWxhYmxl IHZpYSBhDQogICAgICByb3lhbHR5LWZyZWUgbGljZW5zZSBhY2NlcHRhYmxlIHRvIHRoZSBJ RVRGIGFuZCBzcGVjaWZpZWQgaW4gdGhlDQogICAgICBSRkMuDQoNCiAgIG8gIFRoZSBzcGVj aWZpY2F0aW9uIE1VU1QgYmUgdmVyc2lvbmVkLCBhbmQgZWFjaCB2ZXJzaW9uIG9mIHRoZQ0K ICAgICAgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIG51bWJlcmVkLCBkYXRlZCwgYW5kIHN0YWJs ZS4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24gTVVTVCBiZSBzdGFibGUuICBUaGF0IGlz LCBleHRlbnNpb24gc3VidGFncywNCiAgICAgIG9uY2UgZGVmaW5lZCBieSBhIHNwZWNpZmlj YXRpb24sIE1VU1QgTk9UIGJlIHJldHJhY3RlZCBvciBjaGFuZ2UNCiAgICAgIGluIG1lYW5p bmcgaW4gYW55IHN1YnN0YW50aWFsIHdheS4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24g TVVTVCBpbmNsdWRlIGluIGEgc2VwYXJhdGUgc2VjdGlvbiB0aGUNCiAgICAgIHJlZ2lzdHJh dGlvbiBmb3JtIHJlcHJvZHVjZWQgaW4gdGhpcyBzZWN0aW9uIChiZWxvdykgdG8gYmUgdXNl ZCBpbg0KICAgICAgcmVnaXN0ZXJpbmcgdGhlIGV4dGVuc2lvbiB1cG9uIHB1YmxpY2F0aW9u IGFzIGFuIFJGQy4NCg0KICAgbyAgSUFOQSBNVVNUIGJlIGluZm9ybWVkIG9mIGNoYW5nZXMg dG8gdGhlIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kDQogICAgICBVUkwgZm9yIHRoZSBzcGVj aWZpY2F0aW9uLg0KDQogICBJQU5BIHdpbGwgbWFpbnRhaW4gYSByZWdpc3RyeSBvZiBhbGxv Y2F0ZWQgc2luZ2xlLWNoYXJhY3Rlcg0KICAgKHNpbmdsZXRvbikgc3VidGFncy4gIFRoaXMg cmVnaXN0cnkgTVVTVCB1c2UgdGhlIHJlY29yZC1qYXIgZm9ybWF0DQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAg ICBbUGFnZSA0MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIGRlc2NyaWJlZCBi eSB0aGUgQUJORiBpbiBTZWN0aW9uIDMuMS4gIFVwb24gcHVibGljYXRpb24gb2YgYW4NCiAg IGV4dGVuc2lvbiBhcyBhbiBSRkMsIHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkgZGVmaW5l ZCBpbiB0aGUgUkZDDQogICBNVVNUIGZvcndhcmQgdGhpcyByZWdpc3RyYXRpb24gZm9ybSB0 byBpZXNnQGlldGYub3JnLCB3aG8gTVVTVA0KICAgZm9yd2FyZCB0aGUgcmVxdWVzdCB0byBp YW5hQGlhbmEub3JnLiAgVGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBvZg0KICAgdGhlIGV4 dGVuc2lvbiBNVVNUIG1haW50YWluIHRoZSBhY2N1cmFjeSBvZiB0aGUgcmVjb3JkIGJ5IHNl bmRpbmcgYW4NCiAgIHVwZGF0ZWQgZnVsbCBjb3B5IG9mIHRoZSByZWNvcmQgdG8gaWFuYUBp YW5hLm9yZyB3aXRoIHRoZSBzdWJqZWN0DQogICBsaW5lICJMQU5HVUFHRSBUQUcgRVhURU5T SU9OIFVQREFURSIgd2hlbmV2ZXIgY29udGVudCBjaGFuZ2VzLiAgT25seQ0KICAgdGhlICdD b21tZW50cycsICdDb250YWN0X0VtYWlsJywgJ01haWxpbmdfTGlzdCcsIGFuZCAnVVJMJyBm aWVsZHMgTUFZDQogICBiZSBtb2RpZmllZCBpbiB0aGVzZSB1cGRhdGVzLg0KDQogICBGYWls dXJlIHRvIG1haW50YWluIHRoaXMgcmVjb3JkLCBtYWludGFpbiB0aGUgY29ycmVzcG9uZGlu ZyByZWdpc3RyeSwNCiAgIG9yIG1lZXQgb3RoZXIgY29uZGl0aW9ucyBpbXBvc2VkIGJ5IHRo aXMgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50IE1BWQ0KICAgYmUgYXBwZWFsZWQgdG8gdGhl IElFU0cgW1JGQzIwMjhdIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYNCiAg IGRlY2lzaW9ucyAoc2VlIFtSRkMyMDI2XSkgYW5kIE1BWSByZXN1bHQgaW4gdGhlIGF1dGhv cml0eSB0byBtYWludGFpbg0KICAgdGhlIGV4dGVuc2lvbiBiZWluZyB3aXRoZHJhd24gb3Ig cmVhc3NpZ25lZCBieSB0aGUgSUVTRy4NCiAgICUlDQogICBJZGVudGlmaWVyOg0KICAgRGVz Y3JpcHRpb246DQogICBDb21tZW50czoNCiAgIEFkZGVkOg0KICAgUkZDOg0KICAgQXV0aG9y aXR5Og0KICAgQ29udGFjdF9FbWFpbDoNCiAgIE1haWxpbmdfTGlzdDoNCiAgIFVSTDoNCiAg ICUlDQoNCiAgICBGaWd1cmUgNTogRm9ybWF0IG9mIFJlY29yZHMgaW4gdGhlIExhbmd1YWdl IFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5DQoNCiAgICdJZGVudGlmaWVyJyBjb250YWlucyB0 aGUgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgKHNpbmdsZXRvbikNCiAgIGFzc2lnbmVkIHRv IHRoZSBleHRlbnNpb24uICBUaGUgSW50ZXJuZXQtRHJhZnQgc3VibWl0dGVkIHRvIGRlZmlu ZQ0KICAgdGhlIGV4dGVuc2lvbiBTSE9VTEQgc3BlY2lmeSB3aGljaCBsZXR0ZXIgb3IgZGln aXQgdG8gdXNlLCBhbHRob3VnaA0KICAgdGhlIElFU0cgTUFZIGNoYW5nZSB0aGUgYXNzaWdu bWVudCB3aGVuIGFwcHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRpb24nIGNvbnRh aW5zIHRoZSBuYW1lIGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAn Q29tbWVudHMnIGlzIGFuIE9QVElPTkFMIGZpZWxkIGFuZCBNQVkgY29udGFpbiBhIGJyb2Fk ZXIgZGVzY3JpcHRpb24NCiAgIG9mIHRoZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29u dGFpbnMgdGhlIGRhdGUgdGhlIFJGQyB3YXMgcHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRl Ig0KICAgZm9ybWF0IHNwZWNpZmllZCBpbiBbUkZDMzMzOV0uICBGb3IgZXhhbXBsZTogMjAw NC0wNi0yOCByZXByZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0LCBpbiB0aGUgR3JlZ29yaWFu IGNhbGVuZGFyLg0KDQogICAnUkZDJyBjb250YWlucyB0aGUgUkZDIG51bWJlciBhc3NpZ25l ZCB0byB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQXV0aG9yaXR5JyBjb250YWlucyB0aGUgbmFt ZSBvZiB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciB0aGUNCiAgIGV4dGVuc2lvbi4N Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAw OCAgICAgICAgICAgICAgICAgW1BhZ2UgNDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0K DQogICAnQ29udGFjdF9FbWFpbCcgY29udGFpbnMgdGhlIGVtYWlsIGFkZHJlc3MgdXNlZCB0 byBjb250YWN0IHRoZQ0KICAgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICAnTWFpbGlu Z19MaXN0JyBjb250YWlucyB0aGUgVVJMIG9yIHN1YnNjcmlwdGlvbiBlbWFpbCBhZGRyZXNz IG9mIHRoZQ0KICAgbWFpbGluZyBsaXN0IHVzZWQgYnkgdGhlIG1haW50YWluaW5nIGF1dGhv cml0eS4NCg0KICAgJ1VSTCcgY29udGFpbnMgdGhlIFVSTCBvZiB0aGUgcmVnaXN0cnkgZm9y IHRoaXMgZXh0ZW5zaW9uLg0KDQogICBUaGUgZGV0ZXJtaW5hdGlvbiBvZiB3aGV0aGVyIGFu IEludGVybmV0LURyYWZ0IG1lZXRzIHRoZSBhYm92ZQ0KICAgY29uZGl0aW9ucyBhbmQgdGhl IGRlY2lzaW9uIHRvIGdyYW50IG9yIHdpdGhob2xkIHN1Y2ggYXV0aG9yaXR5IHJlc3RzDQog ICBzb2xlbHkgd2l0aCB0aGUgSUVTRyBhbmQgaXMgc3ViamVjdCB0byB0aGUgbm9ybWFsIHJl dmlldyBhbmQgYXBwZWFscw0KICAgcHJvY2VzcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJGQyBw cm9jZXNzLg0KDQogICBFeHRlbnNpb24gYXV0aG9ycyBhcmUgc3Ryb25nbHkgY2F1dGlvbmVk IHRoYXQgbWFueSAoaW5jbHVkaW5nIG1vc3QNCiAgIHdlbGwtZm9ybWVkKSBwcm9jZXNzb3Jz IHdpbGwgYmUgdW5hd2FyZSBvZiBhbnkgc3BlY2lhbCByZWxhdGlvbnNoaXBzDQogICBvciBt ZWFuaW5nIGluaGVyZW50IGluIHRoZSBvcmRlciBvZiBleHRlbnNpb24gc3VidGFncy4gIEV4 dGVuc2lvbg0KICAgYXV0aG9ycyBTSE9VTEQgYXZvaWQgc3VidGFnIHJlbGF0aW9uc2hpcHMg b3IgY2Fub25pY2FsaXphdGlvbg0KICAgbWVjaGFuaXNtcyB0aGF0IGludGVyZmVyZSB3aXRo IG1hdGNoaW5nIG9yIHdpdGggbGVuZ3RoIHJlc3RyaWN0aW9ucw0KICAgdGhhdCBzb21ldGlt ZXMgZXhpc3QgaW4gY29tbW9uIHByb3RvY29scyB3aGVyZSB0aGUgZXh0ZW5zaW9uIGlzIHVz ZWQuDQogICBJbiBwYXJ0aWN1bGFyLCBhcHBsaWNhdGlvbnMgTUFZIHRydW5jYXRlIHRoZSBz dWJ0YWdzIGluIGRvaW5nDQogICBtYXRjaGluZyBvciBpbiBmaXR0aW5nIGludG8gbGltaXRl ZCBsZW5ndGhzLCBzbyBpdCBpcyBSRUNPTU1FTkRFRA0KICAgdGhhdCB0aGUgbW9zdCBzaWdu aWZpY2FudCBpbmZvcm1hdGlvbiBiZSBpbiB0aGUgbW9zdCBzaWduaWZpY2FudA0KICAgKGxl ZnQtbW9zdCkgc3VidGFncyBhbmQgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBncmFjZWZ1bGx5 IGhhbmRsZQ0KICAgdHJ1bmNhdGVkIHN1YnRhZ3MuDQoNCiAgIFdoZW4gYSBsYW5ndWFnZSB0 YWcgaXMgdG8gYmUgdXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwgcHJvdG9jb2wsIGl0DQog ICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBub3QgY29udGFp biBleHRlbnNpb25zIG5vdA0KICAgc3VwcG9ydGVkIGJ5IHRoYXQgcHJvdG9jb2wuICBJbiBh ZGRpdGlvbiwgbm90ZSB0aGF0IHNvbWUgcHJvdG9jb2xzDQogICBNQVkgaW1wb3NlIHVwcGVy IGxpbWl0cyBvbiB0aGUgbGVuZ3RoIG9mIHRoZSBzdHJpbmdzIHVzZWQgdG8gc3RvcmUgb3IN CiAgIHRyYW5zcG9ydCB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQozLjguICBVcGRhdGUgb2YgdGhl IExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KDQogICBVcG9uIGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IHdpbGwNCiAgIG5l ZWQgYW4gdXBkYXRlIHNvIHRoYXQgaXQgY29udGFpbnMgdGhlIGNvbXBsZXRlIHNldCBvZiBz dWJ0YWdzIHZhbGlkDQogICBpbiBhIGxhbmd1YWdlIHRhZy4gIFRoaXMgY29sbGVjdGlvbiBv ZiBzdWJ0YWdzLCBhbG9uZyB3aXRoIGENCiAgIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9jZXNz IHVzZWQgdG8gY3JlYXRlIGl0LCBpcyBkZXNjcmliZWQgYnkNCiAgIFtyZWdpc3RyeS11cGRh dGVdLiAgSUFOQSB3aWxsIHB1Ymxpc2ggdGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUNCiAg IHJlZ2lzdHJ5IGRlc2NyaWJlZCBieSB0aGlzIGRvY3VtZW50IHVzaW5nIHRoZSBpbnN0cnVj dGlvbnMgYW5kDQogICBjb250ZW50IG9mIFtyZWdpc3RyeS11cGRhdGVdLiAgT25jZSBwdWJs aXNoZWQgYnkgSUFOQSwgdGhlDQogICBtYWludGVuYW5jZSBwcm9jZWR1cmVzLCBydWxlcywg YW5kIHJlZ2lzdHJhdGlvbiBwcm9jZXNzZXMgZGVzY3JpYmVkDQogICBpbiB0aGlzIGRvY3Vt ZW50IHdpbGwgYmUgYXZhaWxhYmxlIGZvciBuZXcgcmVnaXN0cmF0aW9ucyBvciB1cGRhdGVz Lg0KDQogICBSZWdpc3RyYXRpb25zIHRoYXQgYXJlIGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1 bGVzIGRlZmluZWQgaW4NCiAgIFtSRkM0NjQ2XSB3aGVuIHRoaXMgZG9jdW1lbnQgaXMgYWRv cHRlZCBNVVNUIGJlIGNvbXBsZXRlZCB1bmRlciB0aGUNCiAgIHJ1bGVzIGNvbnRhaW5lZCBp biB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAg RXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDQzXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDA3DQoNCg0KNC4gIEZvcm1hdGlvbiBhbmQgUHJvY2Vzc2luZyBvZiBM YW5ndWFnZSBUYWdzDQoNCiAgIFRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgaG93IHRvIHVzZSB0 aGUgaW5mb3JtYXRpb24gaW4gdGhlIHJlZ2lzdHJ5DQogICB3aXRoIHRoZSB0YWcgc3ludGF4 IHRvIGNob29zZSwgZm9ybSwgYW5kIHByb2Nlc3MgbGFuZ3VhZ2UgdGFncy4NCg0KNC4xLiAg Q2hvaWNlIG9mIExhbmd1YWdlIFRhZw0KDQogICBUaGUgZ3VpZGluZyBwcmluY2lwbGUgaW4g Zm9ybWluZyBsYW5ndWFnZSB0YWdzIGlzIHRvICJ0YWcgY29udGVudA0KICAgd2lzZWx5LiIg IFNvbWV0aW1lcyB0aGVyZSBpcyBhIGNob2ljZSBiZXR3ZWVuIHNldmVyYWwgcG9zc2libGUg dGFncw0KICAgZm9yIHRoZSBzYW1lIGNvbnRlbnQuICBUaGUgY2hvaWNlIG9mIHdoaWNoIHRh ZyB0byB1c2UgZGVwZW5kcyBvbiB0aGUNCiAgIGNvbnRlbnQgYW5kIGFwcGxpY2F0aW9uIGlu IHF1ZXN0aW9uIGFuZCBzb21lIGFtb3VudCBvZiBqdWRnbWVudCBtaWdodA0KICAgYmUgbmVj ZXNzYXJ5IHdoZW4gc2VsZWN0aW5nIGEgdGFnLg0KDQogICBJbnRlcm9wZXJhYmlsaXR5IGlz IGJlc3Qgc2VydmVkIHdoZW4gdGhlIHNhbWUgbGFuZ3VhZ2UgdGFnIGlzIHVzZWQNCiAgIGNv bnNpc3RlbnRseSB0byByZXByZXNlbnQgdGhlIHNhbWUgbGFuZ3VhZ2UuICBJZiBhbiBhcHBs aWNhdGlvbiBoYXMNCiAgIHJlcXVpcmVtZW50cyB0aGF0IG1ha2UgdGhlIHJ1bGVzIGhlcmUg aW5hcHBsaWNhYmxlLCB0aGVuIHRoYXQNCiAgIGFwcGxpY2F0aW9uIHJpc2tzIGRhbWFnaW5n IGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBzdHJvbmdseQ0KICAgUkVDT01NRU5ERUQgdGhh dCB1c2VycyBub3QgZGVmaW5lIHRoZWlyIG93biBydWxlcyBmb3IgbGFuZ3VhZ2UgdGFnDQog ICBjaG9pY2UuDQoNCiAgIEEgc3VidGFnIFNIT1VMRCBvbmx5IGJlIHVzZWQgd2hlbiBpdCBh ZGRzIHVzZWZ1bCBkaXN0aW5ndWlzaGluZw0KICAgaW5mb3JtYXRpb24gdG8gdGhlIHRhZy4g IEV4dHJhbmVvdXMgc3VidGFncyBpbnRlcmZlcmUgd2l0aCB0aGUNCiAgIG1lYW5pbmcsIHVu ZGVyc3RhbmRpbmcsIGFuZCBwcm9jZXNzaW5nIG9mIGxhbmd1YWdlIHRhZ3MuICBJbg0KICAg cGFydGljdWxhciwgdXNlcnMgYW5kIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgZm9sbG93IHRo ZSAnUHJlZml4JyBhbmQNCiAgICdTdXBwcmVzcy1TY3JpcHQnIGZpZWxkcyBpbiB0aGUgcmVn aXN0cnkgKGRlZmluZWQgaW4gU2VjdGlvbiAzLjEpOg0KICAgdGhlc2UgZmllbGRzIHByb3Zp ZGUgZ3VpZGFuY2Ugb24gd2hlbiBzcGVjaWZpYyBhZGRpdGlvbmFsIHN1YnRhZ3MNCiAgIFNI T1VMRCBiZSB1c2VkIG9yIGF2b2lkZWQgaW4gYSBsYW5ndWFnZSB0YWcuDQoNCiAgIFNvbWUg YXBwbGljYXRpb25zIGNhbiBiZW5lZml0IGZyb20gdGhlIHVzZSBvZiBzY3JpcHQgc3VidGFn cyBpbg0KICAgbGFuZ3VhZ2UgdGFncywgYXMgbG9uZyBhcyB0aGUgdXNlIGlzIGNvbnNpc3Rl bnQgZm9yIGEgZ2l2ZW4gY29udGV4dC4NCiAgIFNjcmlwdCBzdWJ0YWdzIGFyZSBuZXZlciBh cHByb3ByaWF0ZSBmb3IgdW53cml0dGVuIGNvbnRlbnQgKHN1Y2ggYXMNCiAgIGF1ZGlvIHJl Y29yZGluZ3MpLg0KDQogICBTY3JpcHQgc3VidGFncyB3ZXJlIG5vdCBmb3JtYWxseSBkZWZp bmVkIGluIFtSRkMzMDY2XSBhbmQgdGhlaXIgdXNlDQogICBjYW4gYWZmZWN0IG1hdGNoaW5n IGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRpb24gZm9yIGltcGxlbWVudGF0aW9ucyBvZg0KICAg UkZDIDMwNjYsIGFzIHRoZXNlIHN1YnRhZ3MgYXBwZWFyIGJldHdlZW4gdGhlIHByaW1hcnkg bGFuZ3VhZ2UgYW5kDQogICByZWdpb24gc3VidGFncy4gIEZvciBleGFtcGxlLCBpZiBhbiBp bXBsZW1lbnRhdGlvbiBzZWxlY3RzIGNvbnRlbnQNCiAgIHVzaW5nIEJhc2ljIEZpbHRlcmlu ZyBbUkZDNDY0N10gKG9yaWdpbmFsbHkgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi41DQogICBv ZiBbUkZDMzA2Nl0pIGFuZCB0aGUgdXNlciByZXF1ZXN0ZWQgdGhlIGxhbmd1YWdlIHJhbmdl ICJlbi1VUyIsDQogICBjb250ZW50IGxhYmVsZWQgImVuLUxhdG4tVVMiIHdpbGwgbm90IG1h dGNoIHRoZSByZXF1ZXN0IGFuZCB0aHVzIG5vdA0KICAgYmUgc2VsZWN0ZWQuICBUaGVyZWZv cmUsIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdoZW4gc2NyaXB0IHN1YnRhZ3MNCiAgIHdp bGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0aGV5IG91Z2h0IG5vdCBiZSB1c2Vk LiAgSW4gdGhlDQogICByZWdpc3RyeSwgdGhlIFN1cHByZXNzLVNjcmlwdCBmaWVsZCBoZWxw cyBlbnN1cmUgZ3JlYXRlcg0KICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoZSBsYW5ndWFn ZSB0YWdzIGJ5IGRlZmluaW5nIHdoZW4gdXNlcnMgU0hPVUxEDQogICBOT1QgaW5jbHVkZSBh IHNjcmlwdCBzdWJ0YWcgd2l0aCBhIHBhcnRpY3VsYXIgcHJpbWFyeSBsYW5ndWFnZQ0KICAg c3VidGFnLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzICh0eXBlICdleHRsYW5n JyBpbiB0aGUgcmVnaXN0cnk7IHNlZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg ICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNDRdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBTZWN0aW9uIDMuMSkgYWxzbyBhcHBlYXIgYmV0 d2VlbiB0aGUgcHJpbWFyeSBsYW5ndWFnZSBhbmQgc3Vic2VxdWVudA0KICAgKHNjcmlwdCwg cmVnaW9uLCBvciB2YXJpYW50KSBzdWJ0YWdzLiAgSW4gbW9zdCBjYXNlcywgdXNlIHRoZQ0K ICAgTWFjcm9sYW5nYXVnZSAoaW5kaWNhdGVkIGJ5IHRoZSBQcmVmaXgpIGJ5IGl0c2VsZiB0 byBmb3JtIHRoZQ0KICAgbGFuZ3VhZ2UgdGFnIGluIHByZWZlcmVuY2UgdG8gaW5jbHVkaW5n IHRoZSBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcuDQogICBPbmx5IHVzZSB0aGUgZXh0ZW5k ZWQgbGFuZ3VhZ2Ugc3VidGFnIGlmIGl0IGFkZHMgdXNlZnVsDQogICBkaXN0aW5ndWlzaGlu ZyBpbmZvcm1hdGlvbiB0byB0aGUgdGFnIHdpdGhpbiB5b3VyIGFwcGxpY2F0aW9uLg0KDQog ICBUaGUgY2hvaWNlIG9mIHN1YnRhZ3MgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnIFNI T1VMRCBiZSBndWlkZWQgYnkNCiAgIHRoZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEuICBV c2UgYXMgcHJlY2lzZSBhIHRhZyBhcyBwb3NzaWJsZSwgYnV0IG5vIG1vcmUgc3BlY2lmaWMg dGhhbiBpcw0KICAgICAgIGp1c3RpZmllZC4gIEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBh cmUgbm90IGltcG9ydGFudCBmb3INCiAgICAgICBkaXN0aW5ndWlzaGluZyBjb250ZW50IGlu IGFuIGFwcGxpY2F0aW9uLg0KDQogICAgICAgKiAgRm9yIGV4YW1wbGUsICdkZScgbWlnaHQg c3VmZmljZSBmb3IgdGFnZ2luZyBhbiBlbWFpbCB3cml0dGVuDQogICAgICAgICAgaW4gR2Vy bWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFibHkgdW5uZWNlc3NhcmlseQ0KICAg ICAgICAgIHByZWNpc2UgZm9yIHN1Y2ggYSB0YXNrLg0KDQogICAyLiAgVGhlIHNjcmlwdCBz dWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB1bmxlc3MN CiAgICAgICB0aGUgc2NyaXB0IGFkZHMgc29tZSBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlv biB0byB0aGUgdGFnLiAgVGhlDQogICAgICAgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgaW4g dGhlIHByaW1hcnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRoZQ0KICAgICAgIHJlZ2lzdHJ5IGlu ZGljYXRlcyBzY3JpcHQgc3VidGFncyB0aGF0IGRvIG5vdCBhZGQgZGlzdGluZ3Vpc2hpbmcN CiAgICAgICBpbmZvcm1hdGlvbiBmb3IgbW9zdCBhcHBsaWNhdGlvbnMuICBGb3IgZXhhbXBs ZToNCg0KICAgICAgICogIFRoZSBzdWJ0YWcgJ0xhdG4nIHNob3VsZCBub3QgYmUgdXNlZCB3 aXRoIHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgICAgJ2VuJyBiZWNhdXNlIG5lYXJs eSBhbGwgRW5nbGlzaCBkb2N1bWVudHMgYXJlIHdyaXR0ZW4gaW4gdGhlDQogICAgICAgICAg TGF0aW4gc2NyaXB0IGFuZCBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nIGluZm9ybWF0aW9u Lg0KICAgICAgICAgIEhvd2V2ZXIsIGlmIGEgZG9jdW1lbnQgd2VyZSB3cml0dGVuIGluIEVu Z2xpc2ggbWl4aW5nIExhdGluDQogICAgICAgICAgc2NyaXB0IHdpdGggYW5vdGhlciBzY3Jp cHQgc3VjaCBhcyBCcmFpbGxlICgnQnJhaScpLCB0aGVuIGl0DQogICAgICAgICAgbWlnaHQg YmUgYXBwcm9wcmlhdGUgdG8gY2hvb3NlIHRvIGluZGljYXRlIGJvdGggc2NyaXB0cyB0byBh aWQNCiAgICAgICAgICBpbiBjb250ZW50IHNlbGVjdGlvbiwgc3VjaCBhcyB0aGUgYXBwbGlj YXRpb24gb2YgYSBzdHlsZQ0KICAgICAgICAgIHNoZWV0Lg0KDQogICAgICAgKiAgV2hlbiBs YWJlbGluZyBjb250ZW50IHRoYXQgaXMgdW53cml0dGVuIChzdWNoIGFzIGEgcmVjb3JkaW5n DQogICAgICAgICAgb2YgaHVtYW4gc3BlZWNoKSwgdGhlIHNjcmlwdCBzdWJ0YWcgc2hvdWxk IG5vdCBiZSB1c2VkLCBldmVuDQogICAgICAgICAgaWYgdGhlIGxhbmd1YWdlIGlzIGN1c3Rv bWFyaWx5IHdyaXR0ZW4gaW4gc2V2ZXJhbCBzY3JpcHRzLg0KICAgICAgICAgIFRodXMgdGhl IHN1YnRpdGxlcyB0byBhIG1vdmllIG1pZ2h0IHVzZSB0aGUgdGFnICJ6aC1jbW4tSGFudCIN CiAgICAgICAgICAoQ2hpbmVzZSwgTWFuZGFyaW4sIFRyYWRpdGlvbmFsIHNjcmlwdCksIGJ1 dCB0aGUgYXVkaW8gdHJhY2sNCiAgICAgICAgICBmb3IgdGhlIHNhbWUgbGFuZ3VhZ2Ugd291 bGQgYmUgdGFnZ2VkICJ6aC1jbW4iLg0KDQogICAzLiAgSWYgYSB0YWcgb3Igc3VidGFnIGhh cyBhICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxkIGluIGl0cyByZWdpc3RyeQ0KICAgICAgIGVu dHJ5LCB0aGVuIHRoZSB2YWx1ZSBvZiB0aGF0IGZpZWxkIFNIT1VMRCBiZSB1c2VkIHRvIGZv cm0gdGhlDQogICAgICAgbGFuZ3VhZ2UgdGFnIGluIHByZWZlcmVuY2UgdG8gdGhlIHRhZyBv ciBzdWJ0YWcgaW4gd2hpY2ggdGhlDQogICAgICAgcHJlZmVycmVkIHZhbHVlIGFwcGVhcnMu DQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgdXNlICdoZScgZm9yIEhlYnJldyBpbiBwcmVm ZXJlbmNlIHRvICdpdycuDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBF eHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNDVdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDcNCg0KDQogICA0LiAgW0lTTzYzOS0yXSBoYXMgZGVmaW5lZCBzZXZl cmFsIGNvZGVzIGluY2x1ZGVkIGluIHRoZSBzdWJ0YWcNCiAgICAgICByZWdpc3RyeSB0aGF0 IHJlcXVpcmUgYWRkaXRpb25hbCBjYXJlIHdoZW4gY2hvb3NpbmcgbGFuZ3VhZ2UNCiAgICAg ICB0YWdzLiAgSW4gbW9zdCBvZiB0aGVzZSBjYXNlcywgd2hlcmUgb21pdHRpbmcgdGhlIGxh bmd1YWdlIHRhZyBpcw0KICAgICAgIHBlcm1pdHRlZCwgc3VjaCBvbWlzc2lvbiBpcyBwcmVm ZXJhYmxlIHRvIHVzaW5nIHRoZXNlIGNvZGVzLg0KICAgICAgIExhbmd1YWdlIHRhZ3MgU0hP VUxEIE5PVCBpbmNvcnBvcmF0ZSB0aGVzZSBzdWJ0YWdzIGFzIGEgcHJlZml4LA0KICAgICAg IHVubGVzcyB0aGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBjb252ZXlzIHNvbWUgdmFsdWUg dG8gdGhlDQogICAgICAgYXBwbGljYXRpb24uDQoNCiAgICAgICAxLiAgVXNlIHNwZWNpZmlj IGxhbmd1YWdlIHN1YnRhZ3Mgb3Igc3VidGFnIHNlcXVlbmNlcyBpbg0KICAgICAgICAgICBw cmVmZXJlbmNlIHRvIHN1YnRhZ3MgZm9yIGxhbmd1YWdlIGNvbGxlY3Rpb25zLiAgQSAibGFu Z3VhZ2UNCiAgICAgICAgICAgY29sbGVjdGlvbiIgaXMgYSBzdWJ0YWcgZGVyaXZlZCBmcm9t IG9uZSBvZiB0aGUgW0lTTzYzOS0yXQ0KICAgICAgICAgICBjb2RlcyB0aGF0IHJlcHJlc2Vu dHMgbXVsdGlwbGUgcmVsYXRlZCBsYW5ndWFnZXMuICBUaGVzZQ0KICAgICAgICAgICBjb2Rl cyBhcmUgaW5jbHVkZWQgYXMgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIGluIHRoZQ0KICAg ICAgICAgICByZWdpc3RyeS4gIEZvciBleGFtcGxlLCB0aGUgY29kZSAnY21jJyByZXByZXNl bnRzICJDaGFtaWMNCiAgICAgICAgICAgbGFuZ3VhZ2VzIi4gIFRoZSByZWdpc3RyeSBjb250 YWlucyB2YWx1ZXMgZm9yIGVhY2ggb2YgdGhlDQogICAgICAgICAgIGFwcHJveGltYXRlbHkg dGVuIGluZGl2aWR1YWwgbGFuZ3VhZ2VzIHJlcHJlc2VudGVkIGJ5IHRoaXMNCiAgICAgICAg ICAgY29sbGVjdGl2ZSBjb2RlLiAgU29tZSBvdGhlciBleGFtcGxlcyBpbmNsdWRlIHRoZSBz dWJ0YWdzDQogICAgICAgICAgIEdlcm1hbmljIGxhbmd1YWdlcyAoJ2dlbScpIG9yIEFsZ29u cXVpYW4gbGFuZ3VhZ2VzICgnYWxnJykuDQogICAgICAgICAgIFNpbmNlIHRoZXNlIGNvZGVz IGFyZSBpbnRlcnByZXRlZCBpbmNsdXNpdmVseSwgY29udGVudCB0YWdnZWQNCiAgICAgICAg ICAgd2l0aCAiZW4iIChFbmdsaXNoKSwgImRlIiAoR2VybWFuKSwgb3IgImdzdyIgKFN3aXNz IEdlcm1hbiwNCiAgICAgICAgICAgQWxlbWFubmljKSBjb3VsZCBhbHNvIChidXQgU0hPVUxE IE5PVCkgYmUgdGFnZ2VkIHdpdGggImdlbSINCiAgICAgICAgICAgKEdlcm1hbmljIGxhbmd1 YWdlcykuICBTdWJ0YWdzIGRlcml2ZWQgZnJvbSBjb2xsZWN0aW9uIGNvZGVzDQogICAgICAg ICAgIFNIT1VMRCBOT1QgYmUgdXNlZCBiZSB1c2VkIHVubGVzcyBtb3JlIHNwZWNpZmljIGxh bmd1YWdlDQogICAgICAgICAgIGluZm9ybWF0aW9uIGlzIG5vdCBhdmFpbGFibGUuICBOb3Rl IHRoYXQgbWF0Y2hpbmcNCiAgICAgICAgICAgaW1wbGVtZW50YXRpb25zIGdlbmVyYWxseSBk byBub3QgdW5kZXJzdGFuZCB0aGUgcmVsYXRpb25zaGlwDQogICAgICAgICAgIGJldHdlZW4g dGhlIGNvbGxlY3Rpb24gYW5kIGl0cyBlbmNvbXBhc3NlZCBsYW5ndWFnZXMsIGFuZCBzbw0K ICAgICAgICAgICB1c2VycyBvdWdodCBub3QgYXNzdW1lIGEgc3VidGFnIGJhc2VkIG9uIGEg bGFuZ3VhZ2UNCiAgICAgICAgICAgY29sbGVjdGlvbiBpcyBhIHVzZWZ1bCBtZWFucyBmb3Ig c2VsZWN0aW5nIGNvbnRlbnQgaW4gaXRzDQogICAgICAgICAgIGVuY29tcGFzc2VkIGxhbmd1 YWdlcy4NCg0KICAgICAgIDIuICBUaGUgJ211bCcgKE11bHRpcGxlKSBwcmltYXJ5IGxhbmd1 YWdlIHN1YnRhZyBpZGVudGlmaWVzDQogICAgICAgICAgIGNvbnRlbnQgaW4gbXVsdGlwbGUg bGFuZ3VhZ2VzLiAgSXQgU0hPVUxEIE5PVCBiZSB1c2VkIHdoZW4gYQ0KICAgICAgICAgICBs aXN0IG9mIGxhbmd1YWdlcyAoc3VjaCBhcyBDb250ZW50LUxhbmd1YWdlKSBvciBpbmRpdmlk dWFsDQogICAgICAgICAgIHRhZ3MgZm9yIGVhY2ggY29udGVudCBlbGVtZW50IGNhbiBiZSB1 c2VkIGluc3RlYWQuDQoNCiAgICAgICAzLiAgVGhlICd1bmQnIChVbmRldGVybWluZWQpIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlkZW50aWZpZXMNCiAgICAgICAgICAgbGluZ3Vpc3Rp YyBjb250ZW50IHdob3NlIGxhbmd1YWdlIGlzIG5vdCBrbm93bi4gIEl0IFNIT1VMRA0KICAg ICAgICAgICBOT1QgYmUgdXNlZCB1bmxlc3MgYSBsYW5ndWFnZSB0YWcgaXMgcmVxdWlyZWQg YW5kIGxhbmd1YWdlDQogICAgICAgICAgIGluZm9ybWF0aW9uIGlzIG5vdCBhdmFpbGFibGUg b3IgY2Fubm90IGJlIGRldGVybWluZWQuDQogICAgICAgICAgIE9taXR0aW5nIHRoZSBsYW5n dWFnZSB0YWcgKHdoZXJlIHBlcm1pdHRlZCkgaXMgcHJlZmVycmVkLg0KICAgICAgICAgICBU aGUgJ3VuZCcgc3VidGFnIE1BWSBiZSB1c2VmdWwgZm9yIHByb3RvY29scyB0aGF0IHJlcXVp cmUgYQ0KICAgICAgICAgICBsYW5ndWFnZSB0YWcgdG8gYmUgcHJvdmlkZWQgb3Igd2hlcmUg YSBwcmltYXJ5IGxhbmd1YWdlDQogICAgICAgICAgIHN1YnRhZyBpcyByZXF1aXJlZCAoc3Vj aCBhcyBpbiAidW5kLUxhdG4iKS4gIFRoZSAndW5kJyBzdWJ0YWcNCiAgICAgICAgICAgTUFZ IGFsc28gYmUgdXNlZnVsIHdoZW4gbWF0Y2hpbmcgbGFuZ3VhZ2UgdGFncyBpbiBjZXJ0YWlu DQogICAgICAgICAgIHNpdHVhdGlvbnMuDQoNCiAgICAgICA0LiAgVGhlICd6eHgnIChOb24t TGluZ3Vpc3RpYykgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgaWRlbnRpZmllcw0KICAgICAg ICAgICBjb250ZW50IHRoYXQgaGFzIG5vIGxhbmd1YWdlLiAgU29tZSBleGFtcGxlcyBtaWdo dCBpbmNsdWRlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5 IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA0Nl0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIg MjAwNw0KDQoNCiAgICAgICAgICAgaW5zdHJ1bWVudGFsIG9yIGVsZWN0cm9uaWMgbXVzaWM7 IHNvdW5kIHJlY29yZGluZ3MgY29uc2lzdGluZw0KICAgICAgICAgICBvZiBub252ZXJiYWwg c291bmRzOyBhdWRpb3Zpc3VhbCBtYXRlcmlhbHMgd2l0aCBubyBuYXJyYXRpb24sDQogICAg ICAgICAgIHByaW50ZWQgdGl0bGVzLCBvciBzdWJ0aXRsZXM7IG1hY2hpbmUtcmVhZGFibGUg ZGF0YSBmaWxlcw0KICAgICAgICAgICBjb25zaXN0aW5nIG9mIG1hY2hpbmUgbGFuZ3VhZ2Vz IG9yIGNoYXJhY3RlciBjb2Rlczsgb3INCiAgICAgICAgICAgcHJvZ3JhbW1pbmcgc291cmNl IGNvZGUuICBOb3RlOiB3aGVyZSB0aGVyZSBhcmUgZnJhZ21lbnRzIG9mDQogICAgICAgICAg IGxpbmd1aXN0aWMgY29udGVudCwgc3VjaCBhcyBwcm9ncmFtbWluZyBzb3VyY2UgY29kZQ0K ICAgICAgICAgICBjb250YWluaW5nIGNvbW1lbnRzIHdyaXR0ZW4gaW4gRW5nbGlzaCwgdGhl IHN1YnRhZyAnenh4Jw0KICAgICAgICAgICBtaWdodCBzdGlsbCBiZSB1c2VkIHRvIGluZGlj YXRlIHRoZSBwcmltYXJ5IHN0YXR1cyBvZiB0aGUNCiAgICAgICAgICAgY29udGVudCwganVz dCBhcyAnZW4nIGNhbiBiZSBhcHBsaWVkIHRvIGEgcHJlZG9taW5hbnRseQ0KICAgICAgICAg ICBFbmdsaXNoIHRleHQgdGhhdCBjb250YWlucyBhIGZldyBGcmVuY2ggcGhyYXNlcy4NCg0K ICAgICAgIDUuICBUaGUgJ21pcycgKFVuY29kZWQpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFn IGlkZW50aWZpZXMNCiAgICAgICAgICAgY29udGVudCB3aG9zZSBsYW5ndWFnZSBpcyBrbm93 biBidXQgd2hpY2ggZG9lcyBub3QgY3VycmVudGx5DQogICAgICAgICAgIGhhdmUgYSBjb3Jy ZXNwb25kaW5nIHN1YnRhZy4gIFRoaXMgc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZC4NCiAg ICAgICAgICAgQmVjYXVzZSB0aGUgYWRkaXRpb24gb2Ygb3RoZXIgY29kZXMgaW4gdGhlIGZ1 dHVyZSBjYW4gcmVuZGVyDQogICAgICAgICAgIGl0cyBhcHBsaWNhdGlvbiBpbnZhbGlkLCBp dCBpcyBpbmhlcmVudGx5IHVuc3RhYmxlIGFuZCBoZW5jZQ0KICAgICAgICAgICBpbmNvbXBh dGlibGUgd2l0aCB0aGUgc3RhYmlsaXR5IGdvYWxzIG9mIEJDUCA0Ny4gIEl0IGlzDQogICAg ICAgICAgIGFsd2F5cyBwcmVmZXJhYmxlIHRvIHVzZSBvdGhlciBzdWJ0YWdzOiBlaXRoZXIg J3VuZCcgb3IgKHdpdGgNCiAgICAgICAgICAgcHJpb3IgYWdyZWVtZW50KSBwcml2YXRlIHVz ZSBzdWJ0YWdzLg0KDQogICAgICAgNi4gIFRoZSBncmFuZGZhdGhlcmVkIHRhZyAiaS1kZWZh dWx0IiAoRGVmYXVsdCBMYW5ndWFnZSkgd2FzDQogICAgICAgICAgIG9yaWdpbmFsbHkgcmVn aXN0ZXJlZCBhY2NvcmRpbmcgdG8gW1JGQzE3NjZdIHRvIG1lZXQgdGhlDQogICAgICAgICAg IG5lZWRzIG9mIFtSRkMyMjc3XS4gIEl0IGlzIHVzZWQgdG8gaW5kaWNhdGUgbm90IGEgc3Bl Y2lmaWMNCiAgICAgICAgICAgbGFuZ3VhZ2UsIGJ1dCByYXRoZXIsIGl0IGlkZW50aWZpZXMg dGhlIGNvbmRpdGlvbiBvciBjb250ZW50DQogICAgICAgICAgIHVzZWQgd2hlcmUgdGhlIGxh bmd1YWdlIHByZWZlcmVuY2VzIG9mIHRoZSB1c2VyIGNhbm5vdCBiZQ0KICAgICAgICAgICBl c3RhYmxpc2hlZC4gIEl0IFNIT1VMRCBOT1QgYmUgdXNlZCBleGNlcHQgYXMgYSBtZWFucyBv Zg0KICAgICAgICAgICBsYWJlbGluZyB0aGUgZGVmYXVsdCBjb250ZW50IGZvciBhcHBsaWNh dGlvbnMgb3IgcHJvdG9jb2xzDQogICAgICAgICAgIHRoYXQgcmVxdWlyZSBkZWZhdWx0IGxh bmd1YWdlIGNvbnRlbnQgdG8gYmUgbGFiZWxlZCB3aXRoIHRoYXQNCiAgICAgICAgICAgc3Bl Y2lmaWMgdGFnLiAgSXQgTUFZIGFsc28gYmUgdXNlZCBieSBhbiBhcHBsaWNhdGlvbiBvcg0K ICAgICAgICAgICBwcm90b2NvbCB0byBpZGVudGlmeSB3aGVuIHRoZSBkZWZhdWx0IGxhbmd1 YWdlIGNvbnRlbnQgaXMNCiAgICAgICAgICAgYmVpbmcgcmV0dXJuZWQuDQoNCiAgIDUuICBU aGUgc2FtZSB2YXJpYW50IHN1YnRhZyBNVVNUIE5PVCBiZSB1c2VkIG1vcmUgdGhhbiBvbmNl IHdpdGhpbiBhDQogICAgICAgbGFuZ3VhZ2UgdGFnLg0KDQogICAgICAgKiAgRm9yIGV4YW1w bGUsIHRoZSB0YWcgImRlLURFLTE5MDEtMTkwMSIgaXMgbm90IHZhbGlkLg0KDQogICBMYW5n dWFnZXMgd2l0aCBhIE1hY3JvbGFuZ3VhZ2UgZmllbGQgaW4gdGhlIHJlZ2lzdHJ5IHNvbWV0 aW1lcyBjYW4gYmUNCiAgIHVzZWZ1bGx5IHJlZmVyZW5jZWQgdXNpbmcgdGhlaXIgTWFjcm9s YW5ndWFnZS4gIEhvd2V2ZXIsIHRoZQ0KICAgTWFjcm9sYW5ndWFnZSBmaWVsZCBkb2Vzbid0 IGRlZmluZSB3aGF0IHRoZSByZWxhdGlvbnNoaXAgaXMgYmV0d2Vlbg0KICAgdGhlIGxhbmd1 YWdlIHN1YnRhZyB3aG9zZSByZWNvcmQgaXQgYXBwZWFycyBpbiBhbmQgaXRzIGVuY29tcGFz c2VkDQogICBsYW5ndWFnZSBvciBsYW5ndWFnZXMuICBOb3IgZG9lcyBpdCBkZWZpbmUgaG93 IHRoZSBlbmNvbXBhc3NlZA0KICAgbGFuZ3VhZ2VzIGFyZSByZWxhdGVkIHRvIG9uZS1hbm90 aGVyLiAgSW4gc29tZSBjYXNlcywgdGhlDQogICBNYWNyb2xhbmd1YWdlIGhhcyBhIHN0YW5k YXJkIGZvcm0gYXMgd2VsbCBhcyBhIHZhcmlldHkgb2YgbGVzcy1jb21tb24NCiAgIGRpYWxl Y3RzLiAgSW4gb3RoZXIgY2FzZXMgdGhlcmUgaXMgbm8gcGFydGljdWxhciBzdGFuZGFyZCBm b3JtIGFuZA0KICAgdGhlIGVuY29tcGFzc2VkIHN1YnRhZ3MgZGVzY3JpYmUgc3BlY2lmaWMg dmFyaWF0aW9ucyB3aXRoaW4gdGhlDQogICBwYXJlbnQgbGFuZ3VhZ2UuDQoNCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAg ICAgICAgIFtQYWdlIDQ3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgQXBwbGlj YXRpb25zIE1BWSB1c2UgTWFjcm9sYW5ndWFnZSBpbmZvcm1hdGlvbiB0byBpbXByb3ZlIG1h dGNoaW5nIG9yDQogICBsYW5ndWFnZSBuZWdvdGlhdGlvbi4gIEZvciBleGFtcGxlLCB0aGUg aW5mb3JtYXRpb24gdGhhdCAnc3InDQogICAoU2VyYmlhbikgYW5kICdocicgKENyb2F0aWFu KSBzaGFyZSBhIE1hY3JvbGFuZ3VhZ2UgZXhwcmVzc2VzIGENCiAgIGNsb3NlciByZWxhdGlv biBiZXR3ZWVuIHRob3NlIGxhbmd1YWdlcyB0aGFuIGJldHdlZW4sIHNheSwgJ3NyJw0KICAg KFNlcmJpYW4pIGFuZCAnbWEnIChNYWNlZG9uaWFuKS4gIEl0IGlzIHZhbGlkIHRvIHVzZSB0 aGUgZW5jb21wYXNzZWQNCiAgIGxhbmd1YWdlIG9yIGp1c3QgaXRzIE1hY3JvbGFuZ3VhZ2Ug dG8gZm9ybSBsYW5ndWFnZSB0YWdzLiAgSG93ZXZlciwNCiAgIG1hbnkgbWF0Y2hpbmcgYXBw bGljYXRpb25zIHdpbGwgbm90IGJlIGF3YXJlIG9mIHRoZSByZWxhdGlvbnNoaXANCiAgIGJl dHdlZW4gdGhlIGxhbmd1YWdlcy4gIENhcmUgaW4gc2VsZWN0aW5nIHdoaWNoIHN1YnRhZ3Mg YXJlIHVzZWQgaXMNCiAgIGNydWNpYWwgdG8gaW50ZXJvcGVyYWJpbGl0eS4gIEluIGdlbmVy YWwsIHVzZSB0aGUgbW9zdCBzcGVjaWZpYyB0YWcuDQogICBIb3dldmVyLCB3aGVyZSB0aGUg c3RhbmRhcmQgZm9ybSBvZiBhbiBlbmNvbXBhc3NlZCBsYW5ndWFnZSBpcw0KICAgY2FwdHVy ZWQgYnkgdGhlIE1hY3JvbGFuZ3VhZ2UsIHRoZSBNYWNyb2xhbmd1YWdlIFNIT1VMRCBiZSB1 c2VkIGluDQogICBwcmVmZXJlbmNlIHRvIG9uZSBvZiBpdHMgc3VibGFuZ3VhZ2VzIHVubGVz cyB0aGVyZSBpcyBhIHNwZWNpZmljDQogICByZWFzb24gbm90IHRvLg0KDQogICBJbiBwYXJ0 aWN1bGFyLCB0aGUgQ2hpbmVzZSBmYW1pbHkgb2YgbGFuZ3VhZ2VzIGNhbGwgZm9yIHNwZWNp YWwNCiAgIGNvbnNpZGVyYXRpb24uICBCZWNhdXNlIHRoZSB3cml0dGVuIGZvcm0gaXMgdmVy eSBzaW1pbGFyIGZvciBtb3N0DQogICBsYW5ndWFnZXMgaGF2aW5nICd6aCcgYXMgYSBNYWNy b2xhbmd1YWdlIChhbmQgYmVjYXVzZSBoaXN0b3JpY2FsbHkNCiAgIHN1YnRhZ3MgZm9yIHRo ZSB2YXJpb3VzIHN1Yi1sYW5ndWFnZXMgYW5kIGRpYWxlY3RzIHdlcmUgbm90DQogICBhdmFp bGFibGUpLCBsYW5ndWFnZXMgc3VjaCBhcyAneXVlJyAoQ2FudG9uZXNlKSBoYXZlIHVzdWFs bHkgdXNlZA0KICAgdGFncyBiZWdpbm5pbmcgd2l0aCB0aGUgc3VidGFnICd6aCcuICBUaGlz IG1lYW5zIHRoYXQgTWFjcm9sYW5ndWFnZQ0KICAgaW5mb3JtYXRpb24gaXMgY2FuIGJlIHVz ZWZ1bGx5IGFwcGxpZWQgd2hlbiBzZWFyY2hpbmcgZm9yIGNvbnRlbnQgb3INCiAgIHdoZW4g cHJvdmlkaW5nIGZhbGxiYWNrcyBpbiBsYW5ndWFnZSBuZWdvdGlhdGlvbi4gIEZvciBleGFt cGxlLCB0aGUNCiAgIGluZm9ybWF0aW9uIHRoYXQgJ3l1ZScgaGFzIGEgbWFjcm9sYW5nYXVn ZSBvZiAnemgnIGNvdWxkIGJlIHVzZWQgaW4NCiAgIHRoZSBMb29rdXAgYWxnb3JpdGhtIHRv IGZhbGxiYWNrIGZyb20gYSByZXF1ZXN0IGZvciAieXVlLUhhbnMtQ04iIHRvDQogICAiemgt SGFucy1DTiIgd2l0aG91dCBsb3NpbmcgdGhlIHNjcmlwdCBhbmQgcmVnaW9uIGluZm9ybWF0 aW9uIChldmVuDQogICB0aG91Z2ggdGhlIHVzZXIgZGlkIG5vdCBzcGVjaWZ5ICJ6aC1IYW5z LUNOIiBpbiB0aGVpciByZXF1ZXN0KS4NCg0KICAgVG8gZW5zdXJlIGNvbnNpc3RlbnQgYmFj a3dhcmQgY29tcGF0aWJpbGl0eSwgdGhpcyBkb2N1bWVudCBjb250YWlucw0KICAgc2V2ZXJh bCBwcm92aXNpb25zIHRvIGFjY291bnQgZm9yIHBvdGVudGlhbCBpbnN0YWJpbGl0eSBpbiB0 aGUNCiAgIHN0YW5kYXJkcyB1c2VkIHRvIGRlZmluZSB0aGUgc3VidGFncyB0aGF0IG1ha2Ug dXAgbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIHByb3Zpc2lvbnMgbWVhbiB0aGF0IG5vIGxh bmd1YWdlIHRhZyBjcmVhdGVkIHVuZGVyIHRoZSBydWxlcyBpbg0KICAgdGhpcyBkb2N1bWVu dCB3aWxsIGJlY29tZSBpbnZhbGlkLg0KDQogICBTdGFuZGFyZHMsIHByb3RvY29scywgYW5k IGFwcGxpY2F0aW9ucyB0aGF0IHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50DQogICBub3JtYXRp dmVseSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRvIHRoZSBvbmVzIGdpdmVuIGluIHRo aXMNCiAgIHNlY3Rpb24gTVVTVCBzcGVjaWZ5IGhvdyBsYW5ndWFnZSB0YWcgc2VsZWN0aW9u IHZhcmllcyBmcm9tIHRoZQ0KICAgZ3VpZGVsaW5lcyBnaXZlbiBoZXJlLg0KDQo0LjIuICBN ZWFuaW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcNCg0KICAgVGhlIG1lYW5pbmcgb2YgYSBsYW5n dWFnZSB0YWcgaXMgcmVsYXRlZCB0byB0aGUgbWVhbmluZyBvZiB0aGUNCiAgIHN1YnRhZ3Mg dGhhdCBpdCBjb250YWlucy4gIEVhY2ggc3VidGFnLCBpbiB0dXJuLCBpbXBsaWVzIGEgY2Vy dGFpbg0KICAgcmFuZ2Ugb2YgZXhwZWN0YXRpb25zIG9uZSBtaWdodCBoYXZlIGZvciByZWxh dGVkIGNvbnRlbnQsIGFsdGhvdWdoIGl0DQogICBpcyBub3QgYSBndWFyYW50ZWUuICBGb3Ig ZXhhbXBsZSwgdGhlIHVzZSBvZiBhIHNjcmlwdCBzdWJ0YWcgc3VjaCBhcw0KICAgJ0FyYWIn IChBcmFiaWMgc2NyaXB0KSBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlIGNvbnRlbnQgY29udGFp bnMgb25seQ0KICAgQXJhYmljIGNoYXJhY3RlcnMuICBJdCBkb2VzIG1lYW4gdGhhdCB0aGUg bGFuZ3VhZ2UgaW52b2x2ZWQgaXMNCiAgIHByZWRvbWluZW50bHkgaW4gdGhlIEFyYWJpYyBz Y3JpcHQuICBUaHVzIGEgbGFuZ3VhZ2UgdGFnIGFuZCBpdHMNCiAgIHN1YnRhZ3MgY2FuIGVu Y29tcGFzcyBhIHZlcnkgd2lkZSByYW5nZSBvZiB2YXJpYXRpb24gYW5kIHlldCByZW1haW4N Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDgg ICAgICAgICAgICAgICAgIFtQYWdlIDQ4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0K ICAgdmFsaWQgaW4gZWFjaCBwYXJ0aWN1bGFyIGluc3RhbmNlLg0KDQogICBWYWxpZGl0eSBv ZiBhIHRhZyBpcyBub3QgZXZlcnl0aGluZy4gIFdoaWxlIGV2ZXJ5IHZhbGlkIHRhZyBoYXMg YQ0KICAgbWVhbmluZywgaXQgbWlnaHQgbm90IHJlcHJlc2VudCBhbnkgcmVhbC13b3JsZCBs YW5ndWFnZSB1c2FnZS4gIFRoaXMNCiAgIGlzIHVuYXZvaWRhYmxlIGluIGEgc3lzdGVtIGlu IHdoaWNoIHN1YnRhZ3MgY2FuIGJlIGNvbWJpbmVkIGZyZWVseS4NCiAgIEZvciBleGFtcGxl LCB0YWdzIHN1Y2ggYXMgImFyLUN5cmwtQ08iIChBcmFiaWMsIEN5cmlsbGljIHNjcmlwdCwg YXMNCiAgIHVzZWQgaW4gQ29sb21iaWEgKSBvciAidGxoLUtvcmUtQVEtZm9uaXBhIiAoS2xp bmdvbiwgS29yZWFuIHNjcmlwdCwNCiAgIGFzIHVzZWQgaW4gQW50YXJjdGljYSwgSVBBIHBo b25ldGljIHRyYW5zY3JpcHRpb24pIGFyZSBib3RoIHZhbGlkIGFuZA0KICAgdW5saWtlbHkg dG8gcmVwcmVzZW50IGEgdXNlZnVsIGNvbWJpbmF0aW9uIG9mIGxhbmd1YWdlIGF0dHJpYnV0 ZXMuDQoNCiAgIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdGFnIGFuZCB0aGUgaW5m b3JtYXRpb24gaXQgaWRlbnRpZmllcyBpcw0KICAgZGVmaW5lZCBieSB0aGUgY29udGV4dCBp biB3aGljaCB0aGUgdGFnIGFwcGVhcnMuICBBY2NvcmRpbmdseSwgdGhpcw0KICAgc2VjdGlv biBnaXZlcyBvbmx5IHBvc3NpYmxlIGV4YW1wbGVzIG9mIGl0cyB1c2FnZS4NCg0KICAgbyAg Rm9yIGEgc2luZ2xlIGluZm9ybWF0aW9uIG9iamVjdCwgdGhlIGFzc29jaWF0ZWQgbGFuZ3Vh Z2UgdGFncw0KICAgICAgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIHNldCBvZiBsYW5n dWFnZXMgdGhhdCBpcyBuZWNlc3NhcnkgZm9yDQogICAgICBhIGNvbXBsZXRlIGNvbXByZWhl bnNpb24gb2YgdGhlIGNvbXBsZXRlIG9iamVjdC4gIEV4YW1wbGU6IFBsYWluDQogICAgICB0 ZXh0IGRvY3VtZW50cy4NCg0KICAgbyAgRm9yIGFuIGFnZ3JlZ2F0aW9uIG9mIGluZm9ybWF0 aW9uIG9iamVjdHMsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlDQogICAgICB0YWdzIGNvdWxk IGJlIHRha2VuIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHVzZWQgaW5zaWRlIGNvbXBvbmVu dHMNCiAgICAgIG9mIHRoYXQgYWdncmVnYXRpb24uICBFeGFtcGxlczogRG9jdW1lbnQgc3Rv cmVzIGFuZCBsaWJyYXJpZXMuDQoNCiAgIG8gIEZvciBpbmZvcm1hdGlvbiBvYmplY3RzIHdo b3NlIHB1cnBvc2UgaXMgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZXMsDQogICAgICB0aGUgYXNz b2NpYXRlZCBsYW5ndWFnZSB0YWdzIGNvdWxkIGJlIHJlZ2FyZGVkIGFzIGEgaGludCB0aGF0 IHRoZQ0KICAgICAgY29udGVudCBpcyBwcm92aWRlZCBpbiBzZXZlcmFsIGxhbmd1YWdlcyBh bmQgdGhhdCBvbmUgaGFzIHRvDQogICAgICBpbnNwZWN0IGVhY2ggb2YgdGhlIGFsdGVybmF0 aXZlcyBpbiBvcmRlciB0byBmaW5kIGl0cyBsYW5ndWFnZSBvcg0KICAgICAgbGFuZ3VhZ2Vz LiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgdGFncyBtaWdodCBu b3QNCiAgICAgIG1lYW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGktbGluZ3VhbCB0byBn ZXQgY29tcGxldGUNCiAgICAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3VtZW50LiAgRXhh bXBsZTogTUlNRSBtdWx0aXBhcnQvDQogICAgICBhbHRlcm5hdGl2ZS4NCg0KICAgbyAgSW4g bWFya3VwIGxhbmd1YWdlcywgc3VjaCBhcyBIVE1MIGFuZCBYTUwsIGxhbmd1YWdlIGluZm9y bWF0aW9uDQogICAgICBjYW4gYmUgYWRkZWQgdG8gZWFjaCBwYXJ0IG9mIHRoZSBkb2N1bWVu dCBpZGVudGlmaWVkIGJ5IHRoZSBtYXJrdXANCiAgICAgIHN0cnVjdHVyZSAoaW5jbHVkaW5n IHRoZSB3aG9sZSBkb2N1bWVudCBpdHNlbGYpLiAgRm9yIGV4YW1wbGUsIG9uZQ0KICAgICAg Y291bGQgd3JpdGUgPHNwYW4gbGFuZz0iZnIiPkMnZXN0IGxhIHZpZS48L3NwYW4+IGluc2lk ZSBhDQogICAgICBOb3J3ZWdpYW4gZG9jdW1lbnQ7IHRoZSBOb3J3ZWdpYW4tc3BlYWtpbmcg dXNlciBjb3VsZCB0aGVuIGFjY2Vzcw0KICAgICAgYSBGcmVuY2gtTm9yd2VnaWFuIGRpY3Rp b25hcnkgdG8gZmluZCBvdXQgd2hhdCB0aGUgbWFya2VkIHNlY3Rpb24NCiAgICAgIG1lYW50 LiAgSWYgdGhlIHVzZXIgd2VyZSBsaXN0ZW5pbmcgdG8gdGhhdCBkb2N1bWVudCB0aHJvdWdo IGENCiAgICAgIHNwZWVjaCBzeW50aGVzaXMgaW50ZXJmYWNlLCB0aGlzIGZvcm1hdGlvbiBj b3VsZCBiZSB1c2VkIHRvIHNpZ25hbA0KICAgICAgdGhlIHN5bnRoZXNpemVyIHRvIGFwcHJv cHJpYXRlbHkgYXBwbHkgRnJlbmNoIHRleHQtdG8tc3BlZWNoDQogICAgICBwcm9udW5jaWF0 aW9uIHJ1bGVzIHRvIHRoYXQgc3BhbiBvZiB0ZXh0LCBpbnN0ZWFkIG9mIGFwcGx5aW5nIHRo ZQ0KICAgICAgaW5hcHByb3ByaWF0ZSBOb3J3ZWdpYW4gcnVsZXMuDQoNCiAgIExhbmd1YWdl IHRhZ3MgYXJlIHJlbGF0ZWQgd2hlbiB0aGV5IGNvbnRhaW4gYSBzaW1pbGFyIHNlcXVlbmNl IG9mDQogICBzdWJ0YWdzLiAgRm9yIGV4YW1wbGUsIGlmIGEgbGFuZ3VhZ2UgdGFnIEIgY29u dGFpbnMgbGFuZ3VhZ2UgdGFnIEEgYXMNCiAgIGEgcHJlZml4LCB0aGVuIEIgaXMgdHlwaWNh bGx5ICJuYXJyb3dlciIgb3IgIm1vcmUgc3BlY2lmaWMiIHRoYW4gQS4NCiAgIFRodXMsICJ6 aC1IYW50LVRXIiBpcyBtb3JlIHNwZWNpZmljIHRoYW4gInpoLUhhbnQiLg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAg ICAgICAgW1BhZ2UgNDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBUaGlzIHJl bGF0aW9uc2hpcCBpcyBub3QgZ3VhcmFudGVlZCBpbiBhbGwgY2FzZXM6IHNwZWNpZmljYWxs eSwNCiAgIGxhbmd1YWdlcyB0aGF0IGJlZ2luIHdpdGggdGhlIHNhbWUgc2VxdWVuY2Ugb2Yg c3VidGFncyBhcmUgTk9UDQogICBndWFyYW50ZWVkIHRvIGJlIG11dHVhbGx5IGludGVsbGln aWJsZSwgYWx0aG91Z2ggdGhleSBtaWdodCBiZS4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIHRh ZyAiYXoiIHNoYXJlcyBhIHByZWZpeCB3aXRoIGJvdGggImF6LUxhdG4iDQogICAoQXplcmJh aWphbmkgd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0KSBhbmQgImF6LUN5cmwiDQog ICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgQ3lyaWxsaWMgc2NyaXB0KS4gIEEg cGVyc29uIGZsdWVudCBpbg0KICAgb25lIHNjcmlwdCBtaWdodCBub3QgYmUgYWJsZSB0byBy ZWFkIHRoZSBvdGhlciwgZXZlbiB0aG91Z2ggdGhlIHRleHQNCiAgIG1pZ2h0IGJlIGlkZW50 aWNhbC4gIENvbnRlbnQgdGFnZ2VkIGFzICJheiIgbW9zdCBwcm9iYWJseSBpcyB3cml0dGVu DQogICBpbiBqdXN0IG9uZSBzY3JpcHQgYW5kIHRodXMgbWlnaHQgbm90IGJlIGludGVsbGln aWJsZSB0byBhIHJlYWRlcg0KICAgZmFtaWxpYXIgd2l0aCB0aGUgb3RoZXIgc2NyaXB0Lg0K DQo0LjMuICBMZW5ndGggQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlcmUgaXMgbm8gZGVmaW5l ZCB1cHBlciBsaW1pdCBvbiB0aGUgc2l6ZSBvZiBsYW5ndWFnZSB0YWdzLiAgV2hpbGUNCiAg IGhpc3RvcmljYWxseSBtb3N0IGxhbmd1YWdlIHRhZ3MgaGF2ZSBjb25zaXN0ZWQgb2YgbGFu Z3VhZ2UgYW5kIHJlZ2lvbg0KICAgc3VidGFncyB3aXRoIGEgY29tYmluZWQgdG90YWwgbGVu Z3RoIG9mIHVwIHRvIHNpeCBjaGFyYWN0ZXJzLCBsYXJnZXINCiAgIHRhZ3MgaGF2ZSBhbHdh eXMgYmVlbiBib3RoIHBvc3NpYmxlIGFuZCBhY3R1YWxseSBhcHBlYXJlZCBpbiB1c2UuDQoN CiAgIE5laXRoZXIgdGhlIGxhbmd1YWdlIHRhZyBzeW50YXggbm9yIG90aGVyIHJlcXVpcmVt ZW50cyBpbiB0aGlzDQogICBkb2N1bWVudCBpbXBvc2UgYSBmaXhlZCB1cHBlciBsaW1pdCBv biB0aGUgbnVtYmVyIG9mIHN1YnRhZ3MgaW4gYQ0KICAgbGFuZ3VhZ2UgdGFnIChhbmQgdGh1 cyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiBhIHRhZykuICBUaGUNCiAgIGxhbmd1 YWdlIHRhZyBzeW50YXggc3VnZ2VzdHMgdGhhdCwgZGVwZW5kaW5nIG9uIHRoZSBzcGVjaWZp Yw0KICAgbGFuZ3VhZ2UsIG1vcmUgc3VidGFncyAoYW5kIHRodXMgYSBsb25nZXIgdGFnKSBh cmUgc29tZXRpbWVzDQogICBuZWNlc3NhcnkgdG8gY29tcGxldGVseSBpZGVudGlmeSB0aGUg bGFuZ3VhZ2UgZm9yIGNlcnRhaW4NCiAgIGFwcGxpY2F0aW9uczsgdGh1cywgaXQgaXMgcG9z c2libGUgdG8gZW52aXNpb24gbG9uZyBvciBjb21wbGV4IHN1YnRhZw0KICAgc2VxdWVuY2Vz Lg0KDQo0LjMuMS4gIFdvcmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZlciBTaXplcw0KDQogICBT b21lIGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzIGFyZSBmb3JjZWQgdG8gYWxsb2NhdGUg Zml4ZWQgYnVmZmVyDQogICBzaXplcyBvciBvdGhlcndpc2UgbGltaXQgdGhlIGxlbmd0aCBv ZiBhIGxhbmd1YWdlIHRhZy4gIEEgY29uZm9ybWFudA0KICAgaW1wbGVtZW50YXRpb24gb3Ig c3BlY2lmaWNhdGlvbiBNQVkgcmVmdXNlIHRvIHN1cHBvcnQgdGhlIHN0b3JhZ2Ugb2YNCiAg IGxhbmd1YWdlIHRhZ3MgdGhhdCBleGNlZWQgYSBzcGVjaWZpZWQgbGVuZ3RoLiAgQW55IHN1 Y2ggbGltaXRhdGlvbg0KICAgU0hPVUxEIGJlIGNsZWFybHkgZG9jdW1lbnRlZCwgYW5kIHN1 Y2ggZG9jdW1lbnRhdGlvbiBTSE9VTEQgaW5jbHVkZQ0KICAgd2hhdCBoYXBwZW5zIHRvIGxv bmdlciB0YWdzIChmb3IgZXhhbXBsZSwgd2hldGhlciBhbiBlcnJvciB2YWx1ZSBpcw0KICAg Z2VuZXJhdGVkIG9yIHRoZSBsYW5ndWFnZSB0YWcgaXMgdHJ1bmNhdGVkKS4gIEEgcHJvdG9j b2wgdGhhdCBhbGxvd3MNCiAgIHRhZ3MgdG8gYmUgdHJ1bmNhdGVkIGF0IGFuIGFyYml0cmFy eSBsaW1pdCwgd2l0aG91dCBnaXZpbmcgYW55DQogICBpbmRpY2F0aW9uIG9mIHdoYXQgdGhh dCBsaW1pdCBpcywgaGFzIHRoZSBwb3RlbnRpYWwgZm9yIGNhdXNpbmcgaGFybQ0KICAgYnkg Y2hhbmdpbmcgdGhlIG1lYW5pbmcgb2YgdGFncyBpbiBzdWJzdGFudGlhbCB3YXlzLg0KDQog ICBJbiBwcmFjdGljZSwgbW9zdCBsYW5ndWFnZSB0YWdzIGRvIG5vdCByZXF1aXJlIG1vcmUg dGhhbiBhIGZldw0KICAgc3VidGFncyBhbmQgd2lsbCBub3QgYXBwcm9hY2ggcmVhc29uYWJs eSBzaXplZCBidWZmZXIgbGltaXRhdGlvbnM7DQogICBzZWUgU2VjdGlvbiA0LjEuDQoNCiAg IFNvbWUgc3BlY2lmaWNhdGlvbnMgb3IgcHJvdG9jb2xzIGhhdmUgbGltaXRzIG9uIHRhZyBs ZW5ndGggYnV0IGRvIG5vdA0KICAgaGF2ZSBhIGZpeGVkIGxlbmd0aCBsaW1pdGF0aW9uLiAg Rm9yIGV4YW1wbGUsIFtSRkMyMjMxXSBoYXMgbm8NCiAgIGV4cGxpY2l0IGxlbmd0aCBsaW1p dGF0aW9uOiB0aGUgbGVuZ3RoIGF2YWlsYWJsZSBmb3IgdGhlIGxhbmd1YWdlIHRhZw0KICAg aXMgY29uc3RyYWluZWQgYnkgdGhlIGxlbmd0aCBvZiBvdGhlciBoZWFkZXIgY29tcG9uZW50 cyAoc3VjaCBhcyB0aGUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJl cyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDUwXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3Zl bWJlciAyMDA3DQoNCg0KICAgY2hhcnNldCdzIG5hbWUpIGNvdXBsZWQgd2l0aCB0aGUgNzYt Y2hhcmFjdGVyIGxpbWl0IGluIFtSRkMyMDQ3XS4NCiAgIFRodXMsIHRoZSAibGltaXQiIG1p Z2h0IGJlIDUwIG9yIG1vcmUgY2hhcmFjdGVycywgYnV0IGl0IGNvdWxkDQogICBwb3RlbnRp YWxseSBiZSBxdWl0ZSBzbWFsbC4NCg0KICAgVGhlIGNvbnNpZGVyYXRpb25zIGZvciBhc3Np Z25pbmcgYSBidWZmZXIgbGltaXQgYXJlOg0KDQogICAgICBJbXBsZW1lbnRhdGlvbnMgU0hP VUxEIE5PVCB0cnVuY2F0ZSBsYW5ndWFnZSB0YWdzIHVubGVzcyB0aGUNCiAgICAgIG1lYW5p bmcgb2YgdGhlIHRhZyBpcyBwdXJwb3NlZnVsbHkgYmVpbmcgY2hhbmdlZCwgb3IgdW5sZXNz IHRoZQ0KICAgICAgdGFnIGRvZXMgbm90IGZpdCBpbnRvIGEgbGltaXRlZCBidWZmZXIgc2l6 ZSBzcGVjaWZpZWQgYnkgYQ0KICAgICAgcHJvdG9jb2wgZm9yIHN0b3JhZ2Ugb3IgdHJhbnNt aXNzaW9uLg0KDQogICAgICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIHdhcm4gdGhlIHVzZXIg d2hlbiBhIHRhZyBpcyB0cnVuY2F0ZWQgc2luY2UNCiAgICAgIHRydW5jYXRpb24gY2hhbmdl cyB0aGUgc2VtYW50aWMgbWVhbmluZyBvZiB0aGUgdGFnLg0KDQogICAgICBJbXBsZW1lbnRh dGlvbnMgb2YgcHJvdG9jb2xzIG9yIHNwZWNpZmljYXRpb25zIHRoYXQgYXJlIHNwYWNlDQog ICAgICBjb25zdHJhaW5lZCBidXQgZG8gbm90IGhhdmUgYSBmaXhlZCBsaW1pdCBTSE9VTEQg dXNlIHRoZSBsb25nZXN0DQogICAgICBwb3NzaWJsZSB0YWcgaW4gcHJlZmVyZW5jZSB0byB0 cnVuY2F0aW9uLg0KDQogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBz cGVjaWZ5IGxpbWl0ZWQgYnVmZmVyIHNpemVzIGZvcg0KICAgICAgbGFuZ3VhZ2UgdGFncyBN VVNUIGFsbG93IGZvciBsYW5ndWFnZSB0YWdzIG9mIHVwIHRvIDMzIGNoYXJhY3RlcnMuDQoN CiAgICAgIFByb3RvY29scyBvciBzcGVjaWZpY2F0aW9ucyB0aGF0IHNwZWNpZnkgbGltaXRl ZCBidWZmZXIgc2l6ZXMgZm9yDQogICAgICBsYW5ndWFnZSB0YWdzIFNIT1VMRCBhbGxvdyBm b3IgbGFuZ3VhZ2UgdGFncyBvZiBhdCBsZWFzdCA0Mg0KICAgICAgY2hhcmFjdGVycy4NCg0K ICAgVGhlIGZvbGxvd2luZyBpbGx1c3RyYXRpb24gc2hvd3MgaG93IHRoZSA0Mi1jaGFyYWN0 ZXIgcmVjb21tZW5kYXRpb24NCiAgIHdhcyBkZXJpdmVkLiAgVGhlIGNvbWJpbmF0aW9uIG9m IGxhbmd1YWdlIGFuZCBleHRlbmRlZCBsYW5ndWFnZQ0KICAgc3VidGFncyB3YXMgY2hvc2Vu IGZvciBmdXR1cmUgY29tcGF0aWJpbGl0eS4gIEF0IHVwIHRvIDE1IGNoYXJhY3RlcnMsDQog ICB0aGlzIGNvbWJpbmF0aW9uIGlzIGxvbmdlciB0aGFuIHRoZSBsb25nZXN0IHBvc3NpYmxl IHByaW1hcnkgbGFuZ3VhZ2UNCiAgIHN1YnRhZyAoOCBjaGFyYWN0ZXJzKToNCg0KICAgbGFu Z3VhZ2UgICAgICA9ICAzIChJU08gNjM5LTI7IElTTyA2MzktMSByZXF1aXJlcyAyKQ0KICAg ZXh0bGFuZzEgICAgICA9ICA0IChlYWNoIHN1YnNlcXVlbnQgc3VidGFnIGluY2x1ZGVzICct JykNCiAgIGV4dGxhbmcyICAgICAgPSAgNCAodW5saWtlbHk6IG5lZWRzIHByZWZpeD0ibGFu Z3VhZ2UtZXh0bGFuZzEiKQ0KICAgZXh0bGFuZzMgICAgICA9ICA0IChleHRyZW1lbHkgdW5s aWtlbHkpDQogICBzY3JpcHQgICAgICAgID0gIDUgKGlmIG5vdCBzdXBwcmVzc2VkOiBzZWUg U2VjdGlvbiA0LjEpDQogICByZWdpb24gICAgICAgID0gIDQgKFVOIE0uNDk7IElTTyAzMTY2 IHJlcXVpcmVzIDMpDQogICB2YXJpYW50MSAgICAgID0gIDkgKG5lZWRzICdsYW5ndWFnZScg YXMgYSBwcmVmaXgpDQogICB2YXJpYW50MiAgICAgID0gIDkgKG5lZWRzICdsYW5ndWFnZS12 YXJpYW50MScgYXMgYSBwcmVmaXgpDQoNCiAgIHRvdGFsICAgICAgICAgPSA0MiBjaGFyYWN0 ZXJzDQoNCiAgICAgICAgICAgICAgRmlndXJlIDY6IERlcml2YXRpb24gb2YgdGhlIExpbWl0 IG9uIFRhZyBMZW5ndGgNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA1MV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjQuMy4yLiAgVHJ1bmNhdGlvbiBvZiBMYW5ndWFn ZSBUYWdzDQoNCiAgIFRydW5jYXRpb24gb2YgYSBsYW5ndWFnZSB0YWcgYWx0ZXJzIHRoZSBt ZWFuaW5nIG9mIHRoZSB0YWcsIGFuZCB0aHVzDQogICBTSE9VTEQgYmUgYXZvaWRlZC4gIEhv d2V2ZXIsIHRydW5jYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBpcyBzb21ldGltZXMNCiAgIG5l Y2Vzc2FyeSBkdWUgdG8gbGltaXRlZCBidWZmZXIgc2l6ZXMuICBTdWNoIHRydW5jYXRpb24g TVVTVCBOT1QNCiAgIHBlcm1pdCBhIHN1YnRhZyB0byBiZSBjaG9wcGVkIG9mZiBpbiB0aGUg bWlkZGxlIG9yIHRoZSBmb3JtYXRpb24gb2YNCiAgIGludmFsaWQgdGFncyAoZm9yIGV4YW1w bGUsIG9uZSBlbmRpbmcgd2l0aCB0aGUgIi0iIGNoYXJhY3RlcikuDQoNCiAgIFRoaXMgbWVh bnMgdGhhdCBhcHBsaWNhdGlvbnMgb3IgcHJvdG9jb2xzIHRoYXQgdHJ1bmNhdGUgdGFncyBN VVNUIGRvDQogICBzbyBieSBwcm9ncmVzc2l2ZWx5IHJlbW92aW5nIHN1YnRhZ3MgYWxvbmcg d2l0aCB0aGVpciBwcmVjZWRpbmcgIi0iDQogICBmcm9tIHRoZSByaWdodCBzaWRlIG9mIHRo ZSBsYW5ndWFnZSB0YWcgdW50aWwgdGhlIHRhZyBpcyBzaG9ydCBlbm91Z2gNCiAgIGZvciB0 aGUgZ2l2ZW4gYnVmZmVyLiAgSWYgdGhlIHJlc3VsdGluZyB0YWcgZW5kcyB3aXRoIGEgc2lu Z2xlLQ0KICAgY2hhcmFjdGVyIHN1YnRhZywgdGhhdCBzdWJ0YWcgYW5kIGl0cyBwcmVjZWRp bmcgIi0iIE1VU1QgYWxzbyBiZQ0KICAgcmVtb3ZlZC4gIEZvciBleGFtcGxlOg0KDQogICBU YWcgdG8gdHJ1bmNhdGU6IHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxLXgtd2FkZWdp bGUtcHJpdmF0ZTENCiAgIDEuIHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxLXgtd2Fk ZWdpbGUNCiAgIDIuIHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxDQogICAzLiB6aC1M YXRuLUNOLXZhcmlhbnQxDQogICA0LiB6aC1MYXRuLUNODQogICA1LiB6aC1MYXRuDQogICA2 LiB6aA0KDQogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA3OiBFeGFtcGxlIG9mIFRhZyBU cnVuY2F0aW9uDQoNCjQuNC4gIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0K DQogICBTaW5jZSBhIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdGFnIGlzIHNvbWV0aW1lcyB1c2Vk IGJ5IG1hbnkgcHJvY2Vzc2VzLA0KICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJl IGNyZWF0ZWQgb3IgZ2VuZXJhdGVkIGluIGEgY2Fub25pY2FsDQogICBmb3JtLg0KDQogICBB IGxhbmd1YWdlIHRhZyBpcyBpbiBjYW5vbmljYWwgZm9ybSB3aGVuOg0KDQogICAxLiAgVGhl IHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2NvcmRpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4x IGFuZA0KICAgICAgIFNlY3Rpb24gMi4yLg0KDQogICAyLiAgU3VidGFncyBvZiB0eXBlICdS ZWdpb24nIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1WYWx1ZSBtYXBwaW5nIGluDQogICAgICAg dGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMuMSkgU0hPVUxEIGJlIHJlcGxhY2Vk IHdpdGggdGhlaXINCiAgICAgICBtYXBwZWQgdmFsdWUuICBOb3RlOiBJbiByYXJlIGNhc2Vz LCB0aGUgbWFwcGVkIHZhbHVlIHdpbGwgYWxzbw0KICAgICAgIGhhdmUgYSBQcmVmZXJyZWQt VmFsdWUuDQoNCiAgIDMuICBSZWR1bmRhbnQgb3IgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQg aGF2ZSBhIFByZWZlcnJlZC1WYWx1ZQ0KICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVn aXN0cnkgKHNlZSBTZWN0aW9uIDMuMSkgTVVTVCBiZSByZXBsYWNlZA0KICAgICAgIHdpdGgg dGhlaXIgbWFwcGVkIHZhbHVlLiAgVGhlc2UgaXRlbXMgZWl0aGVyIGFyZSBkZXByZWNhdGVk DQogICAgICAgbWFwcGluZ3MgY3JlYXRlZCBiZWZvcmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQgKHN1Y2ggYXMNCiAgICAgICB0aGUgbWFwcGluZyBvZiAibm8tbnluIiB0byAi bm4iIG9yICJpLWtsaW5nb24iIHRvICJ0bGgiKSBvciBhcmUNCiAgICAgICB0aGUgcmVzdWx0 IG9mIGxhdGVyIHJlZ2lzdHJhdGlvbnMgb3IgYWRkaXRpb25zIHRvIHRoaXMgZG9jdW1lbnQN CiAgICAgICAoZm9yIGV4YW1wbGUsICJ6aC1oYWtrYSIgd2FzIGRlcHJlY2F0ZWQgaW4gZmF2 b3Igb2YgdGhlIGxhbmd1YWdlLQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBF eHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNTJdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDcNCg0KDQogICAgICAgZXh0bGFuZyBjb21iaW5hdGlvbiAiemgtaGFr IiB3aGVuIHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQpLg0KDQogICA0LiAgT3RoZXIgc3Vi dGFncyB0aGF0IGhhdmUgYSBQcmVmZXJyZWQtVmFsdWUgbWFwcGluZyBpbiB0aGUgSUFOQQ0K ICAgICAgIHJlZ2lzdHJ5IChzZWUgU2VjdGlvbiAzLjEpIE1VU1QgYmUgcmVwbGFjZWQgd2l0 aCB0aGVpciBtYXBwZWQNCiAgICAgICB2YWx1ZS4gIFRoZXNlIGl0ZW1zIGNvbnNpc3QgZW50 aXJlbHkgb2YgY2xlcmljYWwgY29ycmVjdGlvbnMgdG8NCiAgICAgICBJU08gNjM5LTEgaW4g d2hpY2ggdGhlIGRlcHJlY2F0ZWQgc3VidGFncyBoYXZlIGJlZW4gbWFpbnRhaW5lZA0KICAg ICAgIGZvciBjb21wYXRpYmlsaXR5IHB1cnBvc2VzLg0KDQogICA1LiAgSWYgbW9yZSB0aGFu IG9uZSBleHRlbnNpb24gc3VidGFnIHNlcXVlbmNlIGV4aXN0cywgdGhlIGV4dGVuc2lvbg0K ICAgICAgIHNlcXVlbmNlcyBhcmUgb3JkZXJlZCBpbnRvIGNhc2UtaW5zZW5zaXRpdmUgQVND SUkgb3JkZXIgYnkNCiAgICAgICBzaW5nbGV0b24gc3VidGFnLg0KDQogICBFeGFtcGxlOiBU aGUgbGFuZ3VhZ2UgdGFnICJlbi1BLWFhYS1CLWNjYy1iYmIteC14eXoiIGlzIGluIGNhbm9u aWNhbA0KICAgZm9ybSwgd2hpbGUgImVuLUItY2NjLWJiYi1BLWFhYS1YLXh5eiIgaXMgd2Vs bC1mb3JtZWQgYnV0IG5vdCBpbg0KICAgY2Fub25pY2FsIGZvcm0uDQoNCiAgIEV4YW1wbGU6 IFRoZSBsYW5ndWFnZSB0YWcgImVuLUJVIiAoRW5nbGlzaCBhcyB1c2VkIGluIEJ1cm1hKSBp cyBub3QNCiAgIGNhbm9uaWNhbCBiZWNhdXNlIHRoZSAnQlUnIHN1YnRhZyBoYXMgYSBjYW5v bmljYWwgbWFwcGluZyB0byAnTU0nDQogICAoTXlhbm1hciksIGFsdGhvdWdoIHRoZSB0YWcg ImVuLUJVIiBtYWludGFpbnMgaXRzIHZhbGlkaXR5Lg0KDQogICBDYW5vbmljYWxpemF0aW9u IG9mIGxhbmd1YWdlIHRhZ3MgZG9lcyBub3QgaW1wbHkgYW55dGhpbmcgYWJvdXQgdGhlDQog ICB1c2Ugb2YgdXBwZXIgb3IgbG93ZXJjYXNlIGxldHRlcnMgd2hlbiBwcm9jZXNzaW5nIG9y IGNvbXBhcmluZw0KICAgc3VidGFncyAoYW5kIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIu MSkuICBBbGwgY29tcGFyaXNvbnMgTVVTVCBiZQ0KICAgcGVyZm9ybWVkIGluIGEgY2FzZS1p bnNlbnNpdGl2ZSBtYW5uZXIuDQoNCiAgIFdoZW4gcGVyZm9ybWluZyBjYW5vbmljYWxpemF0 aW9uIG9mIGxhbmd1YWdlIHRhZ3MsIHByb2Nlc3NvcnMgTUFZDQogICByZWd1bGFyaXplIHRo ZSBjYXNlIG9mIHRoZSBzdWJ0YWdzICh0aGF0IGlzLCB0aGlzIHByb2Nlc3MgaXMNCiAgIE9Q VElPTkFMKSwgZm9sbG93aW5nIHRoZSBjYXNlIHVzZWQgaW4gdGhlIHJlZ2lzdHJ5LiAgTm90 ZSB0aGF0IHRoaXMNCiAgIGNvcnJlc3BvbmRzIHRvIHRoZSBmb2xsb3dpbmcgY2FzaW5nIHJ1 bGVzOiB1cHBlcmNhc2UgYWxsIG5vbi1pbml0aWFsDQogICB0d28tbGV0dGVyIHN1YnRhZ3M7 IHRpdGxlY2FzZSBhbGwgbm9uLWluaXRpYWwgZm91ci1sZXR0ZXIgc3VidGFnczsNCiAgIGxv d2VyY2FzZSBldmVyeXRoaW5nIGVsc2UuDQoNCiAgIE5vdGU6IENhc2UgZm9sZGluZyBvZiBB U0NJSSBsZXR0ZXJzIGluIGNlcnRhaW4gbG9jYWxlcywgdW5sZXNzDQogICBjYXJlZnVsbHkg aGFuZGxlZCwgc29tZXRpbWVzIHByb2R1Y2VzIG5vbi1BU0NJSSBjaGFyYWN0ZXIgdmFsdWVz Lg0KICAgVGhlIFVuaWNvZGUgQ2hhcmFjdGVyIERhdGFiYXNlIGZpbGUgIlNwZWNpYWxDYXNp bmcudHh0IiBkZWZpbmVzIHRoZQ0KICAgc3BlY2lmaWMgY2FzZXMgdGhhdCBhcmUga25vd24g dG8gY2F1c2UgcHJvYmxlbXMgd2l0aCB0aGlzLiAgSW4NCiAgIHBhcnRpY3VsYXIsIHRoZSBs ZXR0ZXIgJ2knIChVKzAwNjkpIGluIFR1cmtpc2ggYW5kIEF6ZXJiYWlqYW5pIGlzDQogICB1 cHBlcmNhc2VkIHRvIFUrMDEzMCAoTEFUSU4gQ0FQSVRBTCBMRVRURVIgSSBXSVRIIERPVCBB Qk9WRSkuDQogICBJbXBsZW1lbnRlcnMgU0hPVUxEIHNwZWNpZnkgYSBsb2NhbGUtbmV1dHJh bCBjYXNpbmcgb3BlcmF0aW9uIHRvDQogICBlbnN1cmUgdGhhdCBjYXNlIGZvbGRpbmcgb2Yg c3VidGFncyBkb2VzIG5vdCBwcm9kdWNlIHRoaXMgdmFsdWUsDQogICB3aGljaCBpcyBpbGxl Z2FsIGluIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8NCiAg IHVwcGVyY2FzZSB0aGUgcmVnaW9uIHN1YnRhZyAnaW4nIHVzaW5nIFR1cmtpc2ggbG9jYWxl IHJ1bGVzLCB0aGUNCiAgIHNlcXVlbmNlIFUrMDEzMCBVKzAwNEUgd291bGQgcmVzdWx0IGlu c3RlYWQgb2YgdGhlIGV4cGVjdGVkICdJTicuDQoNCiAgIE5vdGU6IGlmIHRoZSBmaWVsZCAn RGVwcmVjYXRlZCcgYXBwZWFycyBpbiBhIHJlZ2lzdHJ5IHJlY29yZCB3aXRob3V0DQogICBh biBhY2NvbXBhbnlpbmcgJ1ByZWZlcnJlZC1WYWx1ZScgZmllbGQsIHRoZW4gdGhhdCB0YWcg b3Igc3VidGFnIGlzDQogICBkZXByZWNhdGVkIHdpdGhvdXQgYSByZXBsYWNlbWVudC4gIFZh bGlkYXRpbmcgcHJvY2Vzc29ycyBTSE9VTEQgTk9UDQogICBnZW5lcmF0ZSB0YWdzIHRoYXQg aW5jbHVkZSB0aGVzZSB2YWx1ZXMsIGFsdGhvdWdoIHRoZSB2YWx1ZXMgYXJlDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAg ICAgICAgICBbUGFnZSA1M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIGNhbm9u aWNhbCB3aGVuIHRoZXkgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBBbiBleHRl bnNpb24gTVVTVCBkZWZpbmUgYW55IHJlbGF0aW9uc2hpcHMgdGhhdCBleGlzdCBiZXR3ZWVu IHRoZQ0KICAgdmFyaW91cyBzdWJ0YWdzIGluIHRoZSBleHRlbnNpb24gYW5kIHRodXMgTUFZ IGRlZmluZSBhbiBhbHRlcm5hdGUNCiAgIGNhbm9uaWNhbGl6YXRpb24gc2NoZW1lIGZvciB0 aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncy4gIEV4dGVuc2lvbnMgTUFZDQogICBkZWZpbmUgaG93 IHRoZSBvcmRlciBvZiB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBhcmUgaW50ZXJwcmV0ZWQu ICBGb3INCiAgIGV4YW1wbGUsIGFuIGV4dGVuc2lvbiBjb3VsZCBkZWZpbmUgdGhhdCBpdHMg c3VidGFncyBhcmUgaW4gY2Fub25pY2FsDQogICBvcmRlciB3aGVuIHRoZSBzdWJ0YWdzIGFy ZSBwbGFjZWQgaW50byBBU0NJSSBvcmRlcjogdGhhdCBpcywgImVuLWEtDQogICBhYWEtYmJi LWNjYyIgaW5zdGVhZCBvZiAiZW4tYS1jY2MtYmJiLWFhYSIuICBBbm90aGVyIGV4dGVuc2lv biBtaWdodA0KICAgZGVmaW5lIHRoYXQgdGhlIG9yZGVyIG9mIHRoZSBzdWJ0YWdzIGluZmx1 ZW5jZXMgdGhlaXIgc2VtYW50aWMNCiAgIG1lYW5pbmcgKHNvIHRoYXQgImVuLWItY2NjLWJi Yi1hYWEiIGhhcyBhIGRpZmZlcmVudCB2YWx1ZSBmcm9tICJlbi1iLQ0KICAgYWFhLWJiYi1j Y2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lvbiBzcGVjaWZpY2F0aW9ucyBTSE9VTEQgYmUgZGVz aWduZWQNCiAgIHNvIHRoYXQgdGhleSBhcmUgdG9sZXJhbnQgb2YgdGhlIHR5cGljYWwgcHJv Y2Vzc2VzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjcuDQoNCjQuNS4gIENvbnNpZGVy YXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzDQoNCiAgIFByaXZhdGUgdXNlIHN1YnRh Z3MsIGxpa2UgYWxsIG90aGVyIHN1YnRhZ3MsIE1VU1QgY29uZm9ybSB0byB0aGUNCiAgIGZv cm1hdCBhbmQgY29udGVudCBjb25zdHJhaW50cyBpbiB0aGUgQUJORi4gIFByaXZhdGUgdXNl IHN1YnRhZ3MgaGF2ZQ0KICAgbm8gbWVhbmluZyBvdXRzaWRlIHRoZSBwcml2YXRlIGFncmVl bWVudCBiZXR3ZWVuIHRoZSBwYXJ0aWVzIHRoYXQNCiAgIGludGVuZCB0byB1c2Ugb3IgZXhj aGFuZ2UgbGFuZ3VhZ2UgdGFncyB0aGF0IGVtcGxveSB0aGVtLiAgVGhlIHNhbWUNCiAgIHN1 YnRhZ3MgTUFZIGJlIHVzZWQgd2l0aCBhIGRpZmZlcmVudCBtZWFuaW5nIHVuZGVyIGEgc2Vw YXJhdGUgcHJpdmF0ZQ0KICAgYWdyZWVtZW50LiAgVGhleSBTSE9VTEQgTk9UIGJlIHVzZWQg d2hlcmUgYWx0ZXJuYXRpdmVzIGV4aXN0IGFuZA0KICAgU0hPVUxEIE5PVCBiZSB1c2VkIGlu IGNvbnRlbnQgb3IgcHJvdG9jb2xzIGludGVuZGVkIGZvciBnZW5lcmFsIHVzZS4NCg0KICAg UHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUgc2ltcGx5IHVzZWxlc3MgZm9yIGluZm9ybWF0aW9u IGV4Y2hhbmdlDQogICB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50LiAgVGhlIHZhbHVlIGFu ZCBzZW1hbnRpYyBtZWFuaW5nIG9mIHByaXZhdGUNCiAgIHVzZSB0YWdzIGFuZCBvZiB0aGUg c3VidGFncyB1c2VkIHdpdGhpbiBzdWNoIGEgbGFuZ3VhZ2UgdGFnIGFyZSBub3QNCiAgIGRl ZmluZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KICAgU3VidGFncyBkZWZpbmVkIGluIHRoZSBJ QU5BIHJlZ2lzdHJ5IGFzIGhhdmluZyBhIHNwZWNpZmljIHByaXZhdGUgdXNlDQogICBtZWFu aW5nIGNvbnZleSBtb3JlIGluZm9ybWF0aW9uIHRoYXQgYSBwdXJlbHkgcHJpdmF0ZSB1c2Ug dGFnDQogICBwcmVmaXhlZCBieSB0aGUgc2luZ2xldG9uIHN1YnRhZyAneCcuICBGb3IgYXBw bGljYXRpb25zLCB0aGlzDQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIE1BWSBiZSB1c2Vm dWwuDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgcmVnaW9uIHN1YnRhZ3MgJ0FBJywgJ1paJywg YW5kIGluIHRoZSByYW5nZXMNCiAgICdRTSctJ1FaJyBhbmQgJ1hBJy0nWFonIChkZXJpdmVk IGZyb20gSVNPIDMxNjYgcHJpdmF0ZSB1c2UgY29kZXMpIE1BWQ0KICAgYmUgdXNlZCB0byBm b3JtIGEgbGFuZ3VhZ2UgdGFnLiAgQSB0YWcgc3VjaCBhcyAiemgtSGFucy1YUSIgY29udmV5 cyBhDQogICBncmVhdCBkZWFsIG9mIHB1YmxpYywgaW50ZXJjaGFuZ2VhYmxlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBsYW5ndWFnZQ0KICAgbWF0ZXJpYWwgKHRoYXQgaXQgaXMgQ2hpbmVz ZSBpbiB0aGUgc2ltcGxpZmllZCBDaGluZXNlIHNjcmlwdCBhbmQgaXMNCiAgIHN1aXRhYmxl IGZvciBzb21lIGdlb2dyYXBoaWMgcmVnaW9uICdYUScpLiAgV2hpbGUgdGhlIHByZWNpc2UN CiAgIGdlb2dyYXBoaWMgcmVnaW9uIGlzIG5vdCBrbm93biBvdXRzaWRlIG9mIHByaXZhdGUg YWdyZWVtZW50LCB0aGUgdGFnDQogICBjb252ZXlzIGZhciBtb3JlIGluZm9ybWF0aW9uIHRo YW4gYW4gb3BhcXVlIHRhZyBzdWNoIGFzICJ4LXNvbWVMYW5nIiwNCiAgIHdoaWNoIGNvbnRh aW5zIG5vIGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYW5ndWFnZSBzdWJ0YWcgb3Igc2NyaXB0 DQogICBzdWJ0YWcgb3V0c2lkZSBvZiB0aGUgcHJpdmF0ZSBhZ3JlZW1lbnQuDQoNCiAgIEhv d2V2ZXIsIGluIHNvbWUgY2FzZXMgY29udGVudCB0YWdnZWQgd2l0aCBwcml2YXRlIHVzZSBz dWJ0YWdzIE1BWQ0KICAgaW50ZXJhY3Qgd2l0aCBvdGhlciBzeXN0ZW1zIGluIGEgZGlmZmVy ZW50IGFuZCBwb3NzaWJseSB1bnN1aXRhYmxlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA1NF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIG1hbm5lciBjb21wYXJlZCB0byB0YWdz IHRoYXQgdXNlIG9wYXF1ZSwgcHJpdmF0ZWx5IGRlZmluZWQgc3VidGFncywNCiAgIHNvIHRo ZSBjaG9pY2Ugb2YgdGhlIGJlc3QgYXBwcm9hY2ggc29tZXRpbWVzIGRlcGVuZHMgb24gdGhl DQogICBwYXJ0aWN1bGFyIGRvbWFpbiBpbiBxdWVzdGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhw aXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDU1XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBO b3ZlbWJlciAyMDA3DQoNCg0KNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBz ZWN0aW9uIGRlYWxzIHdpdGggdGhlIHByb2Nlc3NlcyBhbmQgcmVxdWlyZW1lbnRzIG5lY2Vz c2FyeSBmb3INCiAgIElBTkEgdG8gdW5kZXJ0YWtlIHRvIG1haW50YWluIHRoZSBzdWJ0YWcg YW5kIGV4dGVuc2lvbiByZWdpc3RyaWVzIGFzDQogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1l bnQgYW5kIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcmVxdWlyZW1lbnRzIG9mDQogICBbUkZD MjQzNF0uDQoNCiAgIFRoZSBpbXBhY3Qgb24gdGhlIElBTkEgbWFpbnRhaW5lcnMgb2YgdGhl IHR3byByZWdpc3RyaWVzIGRlZmluZWQgYnkNCiAgIHRoaXMgZG9jdW1lbnQgd2lsbCBiZSBh IHNtYWxsIGluY3JlYXNlIGluIHRoZSBmcmVxdWVuY3kgb2YgbmV3DQogICBlbnRyaWVzIG9y IHVwZGF0ZXMuDQoNCjUuMS4gIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KDQogICBVcG9u IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQsIElBTkEgd2lsbCB1cGRhdGUgdGhlIHJlZ2lz dHJ5IHVzaW5nDQogICBpbnN0cnVjdGlvbnMgYW5kIGNvbnRlbnQgcHJvdmlkZWQgaW4gYSBj b21wYW5pb24gZG9jdW1lbnQ6DQogICBbcmVnaXN0cnktdXBkYXRlXS4gIFRoZSBjcml0ZXJp YSBhbmQgcHJvY2VzcyBmb3Igc2VsZWN0aW5nIHRoZQ0KICAgdXBkYXRlZCBzZXQgb2YgcmVj b3JkcyBhcmUgZGVzY3JpYmVkIGluIHRoYXQgZG9jdW1lbnQuICBUaGUgdXBkYXRlZA0KICAg c2V0IG9mIHJlY29yZHMgcmVwcmVzZW50cyBubyBpbXBhY3Qgb24gSUFOQSwgc2luY2UgdGhl IHdvcmsgdG8gY3JlYXRlDQogICBpdCB3aWxsIGJlIHBlcmZvcm1lZCBleHRlcm5hbGx5Lg0K DQogICBGdXR1cmUgd29yayBvbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IGhhcyBi ZWVuIGxpbWl0ZWQgdG8NCiAgIGluc2VydGluZyBvciByZXBsYWNpbmcgd2hvbGUgcmVjb3Jk cyBwcmVmb3JtYXR0ZWQgZm9yIElBTkEgYnkgdGhlDQogICBMYW5ndWFnZSBTdWJ0YWcgUmV2 aWV3ZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zIG9mIHRoaXMgZG9jdW1lbnQNCiAg IGFuZCBhcmNoaXZpbmcgYW5kIG1ha2luZyBwdWJsaWNhbGx5IGF2YWlsYWJsZSB0aGUgZm9y d2FyZGVkDQogICByZWdpc3RyYXRpb24gZm9ybS4NCg0KICAgRWFjaCByZWdpc3RyYXRpb24g Zm9ybSBzZW50IHRvIElBTkEgY29udGFpbnMgYSBzaW5nbGUgcmVjb3JkIGZvcg0KICAgaW5j b3Jwb3JhdGlvbiBpbnRvIHRoZSByZWdpc3RyeS4gIFRoZSBmb3JtIE1VU1QgYmUgc2VudCB0 bw0KICAgaWFuYUBpYW5hLm9yZyBieSB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLiAg SXQgd2lsbCBoYXZlIGENCiAgIHN1YmplY3QgbGluZSBpbmRpY2F0aW5nIHdoZXRoZXIgdGhl IGVuY2xvc2VkIGZvcm0gcmVwcmVzZW50cyBhbg0KICAgaW5zZXJ0aW9uIG9mIGEgbmV3IHJl Y29yZCAoaW5kaWNhdGVkIGJ5IHRoZSB3b3JkICJJTlNFUlQiIGluIHRoZQ0KICAgc3ViamVj dCBsaW5lKSBvciBhIHJlcGxhY2VtZW50IG9mIGFuIGV4aXN0aW5nIHJlY29yZCAoaW5kaWNh dGVkIGJ5DQogICB0aGUgd29yZCAiTU9ESUZZIiBpbiB0aGUgc3ViamVjdCBsaW5lKS4gIFJl Y29yZHMgTVVTVCBOT1QgYmUgZGVsZXRlZA0KICAgZnJvbSB0aGUgcmVnaXN0cnkuDQoNCiAg IElBTkEgTVVTVCBleHRyYWN0IHRoZSByZWNvcmQgZnJvbSB0aGUgZm9ybSBhbmQgcGxhY2Ug dGhlIGluc2VydGVkIG9yDQogICBtb2RpZmllZCByZWNvcmQgaW50byB0aGUgYXBwcm9wcmlh dGUgc2VjdGlvbiBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnDQogICByZWdpc3RyeSwgZ3JvdXBp bmcgdGhlIHJlY29yZHMgYnkgdGhlaXIgJ1R5cGUnIGZpZWxkLiAgSW5zZXJ0ZWQNCiAgIHJl Y29yZHMgTUFZIGJlIHBsYWNlZCBhbnl3aGVyZSBpbiB0aGUgYXBwcm9wcmlhdGUgc2VjdGlv bjsgdGhlcmUgaXMNCiAgIG5vIGd1YXJhbnRlZSBvZiB0aGUgb3JkZXIgb2YgdGhlIHJlY29y ZHMgYmV5b25kIGdyb3VwaW5nIHRoZW0NCiAgIHRvZ2V0aGVyIGJ5ICdUeXBlJy4gIE1vZGlm aWVkIHJlY29yZHMgTVVTVCBvdmVyd3JpdGUgdGhlIHJlY29yZCB0aGV5DQogICByZXBsYWNl Lg0KDQogICBJQU5BIE1VU1QgdXBkYXRlIHRoZSBGaWxlLURhdGUgcmVjb3JkIHRvIGNvbnRh aW4gdGhlIG1vc3QgcmVjZW50DQogICBtb2RpZmljYXRpb24gZGF0ZSB3aGVuIHBlcmZvcm1p bmcgYW55IGluc2VydGluZyBvciBtb2RpZmljYXRpb246DQogICBpbmNsdWRlZCBpbiBhbnkg cmVxdWVzdCB0byBpbnNlcnQgb3IgbW9kaWZ5IHJlY29yZHMgd2lsbCBiZSBhIG5ldw0KICAg RmlsZS1EYXRlIHJlY29yZCBpbmRpY2F0aW5nIHRoZSBhY2NlcHRhbmNlIGRhdGUgb2YgdGhl IHJlY29yZC4gIFRoaXMNCiAgIHJlY29yZCBNVVNUIGJlIHBsYWNlZCBmaXJzdCBpbiB0aGUg cmVnaXN0cnksIHJlcGxhY2luZyB0aGUgZXhpc3RpbmcNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdl IDU2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgRmlsZS1EYXRlIHJlY29yZC4g IEluIHRoZSBldmVudCB0aGF0IHRoZSBGaWxlLURhdGUgcmVjb3JkIHByZXNlbnQgaW4NCiAg IHRoZSByZWdpc3RyeSBoYXMgYSBsYXRlciBkYXRlIHRoYW4gdGhlIHJlY29yZCBiZWluZyBp bnNlcnRlZCBvcg0KICAgbW9kaWZpZWQsIHRoZW4gdGhlIGxhdGVzdCAobW9zdCByZWNlbnQp IHJlY29yZCBNVVNUIGJlIHByZXNlcnZlZC4NCiAgIElBTkEgU0hPVUxEIHByb2Nlc3MgbXVs dGlwbGUgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIGluIG9yZGVyIGFjY29yZGluZw0KICAgdG8g dGhlIEZpbGUtRGF0ZSBpbiB0aGUgZm9ybSwgc2luY2Ugb25lIHJlZ2lzdHJhdGlvbiBjb3Vs ZCBvdGhlcndpc2UNCiAgIGNhdXNlIGEgbW9yZSByZWNlbnQgY2hhbmdlIHRvIGJlIG92ZXJ3 cml0dGVuLg0KDQogICBUaGUgdXBkYXRlZCByZWdpc3RyeSBmaWxlIE1VU1QgdXNlIHRoZSBV VEYtOCBjaGFyYWN0ZXIgZW5jb2RpbmcgYW5kDQogICBJQU5BIE1VU1QgY2hlY2sgdGhlIHJl Z2lzdHJ5IGZpbGUgZm9yIHByb3BlciBlbmNvZGluZy4gIE5vbi1BU0NJSQ0KICAgY2hhcmFj dGVycyBjYW4gYmUgc2VudCB0byBJQU5BIGJ5IGF0dGFjaGluZyB0aGUgcmVnaXN0cmF0aW9u IGZvcm0gdG8NCiAgIHRoZSBlbWFpbCBtZXNzYWdlIG9yIGJ5IHVzaW5nIHZhcmlvdXMgZW5j b2RpbmdzIGluIHRoZSBtYWlsIG1lc3NhZ2UNCiAgIGJvZHkgKFVURi04IGlzIHJlY29tbWVu ZGVkKS4gIElBTkEgd2lsbCB2ZXJpZnkgYW55IHVuY2xlYXIgb3INCiAgIGNvcnJ1cHRlZCBj aGFyYWN0ZXJzIHdpdGggdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBwcmlvciB0bw0K ICAgcG9zdGluZyB0aGUgdXBkYXRlZCByZWdpc3RyeS4NCg0KICAgVGhlIHJlZ2lzdHJhdGlv biBmb3JtIHNlbnQgdG8gSUFOQSBNVVNUIGJlIGFyY2hpdmVkIGFuZCBtYWRlIHB1YmxpY2x5 DQogICBhdmFpbGFibGUgZnJvbQ0KICAgImh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvbGFuZy1zdWJ0YWdzLXRlbXBsYXRlcy8iLiAgTm90ZSB0aGF0DQogICBtdWx0aXBsZSBy ZWdpc3RyYXRpb25zIGNhbiBwZXJ0YWluIHRvIHRoZSBzYW1lIHJlY29yZCBpbiB0aGUNCiAg IHJlZ2lzdHJ5Lg0KDQogICBEZXZlbG9wZXJzIHdobyBhcmUgZGVwZW5kZW50IHVwb24gdGhl IGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeQ0KICAgc29tZXRpbWVzIHdvdWxkIGxpa2UgdG8g YmUgaW5mb3JtZWQgb2YgY2hhbmdlcyBpbiB0aGUgcmVnaXN0cnkgc28NCiAgIHRoYXQgdGhl eSBjYW4gdXBkYXRlIHRoZWlyIGltcGxlbWVudGF0aW9ucy4gIFdoZW4gYW55IGNoYW5nZSBp cyBtYWRlDQogICB0byB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lzdHJ5LCBJQU5BIE1VU1Qg c2VuZCBhbiBhbm5vdW5jZW1lbnQNCiAgIG1lc3NhZ2UgdG8gaWV0Zi1sYW5ndWFnZXMtYW5u b3VuY2VtZW50c0BpYW5hLm9yZyAoYSBzZWxmLXN1YnNjcmliaW5nDQogICBsaXN0IHRoYXQg b25seSBJQU5BIGNhbiBwb3N0IHRvKS4NCg0KNS4yLiAgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0K DQogICBUaGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVnaXN0cnkgY2FuIGNvbnRhaW4g YXQgbW9zdCAzNSByZWNvcmRzDQogICBhbmQgdGh1cyBjaGFuZ2VzIHRvIHRoaXMgcmVnaXN0 cnkgYXJlIGV4cGVjdGVkIHRvIGJlIHZlcnkgaW5mcmVxdWVudC4NCg0KICAgRnV0dXJlIHdv cmsgYnkgSUFOQSBvbiB0aGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVnaXN0cnkgaXMN CiAgIGxpbWl0ZWQgdG8gdHdvIGNhc2VzLiAgRmlyc3QsIHRoZSBJRVNHIE1BWSByZXF1ZXN0 IHRoYXQgbmV3IHJlY29yZHMNCiAgIGJlIGluc2VydGVkIGludG8gdGhpcyByZWdpc3RyeSBm cm9tIHRpbWUgdG8gdGltZS4gIFRoZXNlIHJlcXVlc3RzDQogICBNVVNUIGluY2x1ZGUgdGhl IHJlY29yZCB0byBpbnNlcnQgaW4gdGhlIGV4YWN0IGZvcm1hdCBkZXNjcmliZWQgaW4NCiAg IFNlY3Rpb24gMy43LiAgSW4gYWRkaXRpb24sIHRoZXJlIE1BWSBiZSBvY2Nhc2lvbmFsIHJl cXVlc3RzIGZyb20gdGhlDQogICBtYWludGFpbmluZyBhdXRob3JpdHkgZm9yIGEgc3BlY2lm aWMgZXh0ZW5zaW9uIHRvIHVwZGF0ZSB0aGUgY29udGFjdA0KICAgaW5mb3JtYXRpb24gb3Ig VVJMcyBpbiB0aGUgcmVjb3JkLiAgVGhlc2UgcmVxdWVzdHMgTVVTVCBpbmNsdWRlIHRoZQ0K ICAgY29tcGxldGUsIHVwZGF0ZWQgcmVjb3JkLiAgSUFOQSBpcyBub3QgcmVzcG9uc2libGUg Zm9yIHZhbGlkYXRpbmcgdGhlDQogICBpbmZvcm1hdGlvbiBwcm92aWRlZCwgb25seSB0aGF0 IGl0IGlzIHByb3Blcmx5IGZvcm1hdHRlZC4gIEl0IHNob3VsZA0KICAgcmVhc29uYWJseSBi ZSBzZWVuIHRvIGNvbWUgZnJvbSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IG5hbWVkIGlu DQogICB0aGUgcmVjb3JkIHByZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5Lg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAg ICAgICAgICAgICBbUGFnZSA1N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjYuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBMYW5ndWFnZSB0YWdzIHVzZWQgaW4gY29u dGVudCBuZWdvdGlhdGlvbiwgbGlrZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24NCiAgIGV4Y2hh bmdlZCBvbiB0aGUgSW50ZXJuZXQsIG1pZ2h0IGJlIGEgc291cmNlIG9mIGNvbmNlcm4gYmVj YXVzZSB0aGV5DQogICBtaWdodCBiZSB1c2VkIHRvIGluZmVyIHRoZSBuYXRpb25hbGl0eSBv ZiB0aGUgc2VuZGVyLCBhbmQgdGh1cw0KICAgaWRlbnRpZnkgcG90ZW50aWFsIHRhcmdldHMg Zm9yIHN1cnZlaWxsYW5jZS4NCg0KICAgVGhpcyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUg Z2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgc2VudCBpcw0KICAgdmlzaWJsZSB0byB0 aGUgcmVjZWl2aW5nIHBhcnR5IGFuZCBwb3NzaWJseSB0byB0aGlyZCBwYXJ0aWVzIGFzIHdl bGwuDQogICBJdCBpcyB1c2VmdWwgdG8gYmUgYXdhcmUgdGhhdCBzdWNoIGNvbmNlcm5zIGNh biBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBUaGUgZXZhbHVhdGlvbiBvZiB0aGUgZXhh Y3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBhbnkgcG9zc2libGUNCiAgIGNvdW50 ZXJtZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0aW9uIHByb3RvY29sIChzZWUg QkNQIDcyDQogICBbUkZDMzU1Ml0gZm9yIGJlc3QgY3VycmVudCBwcmFjdGljZSBndWlkYW5j ZSBvbiBzZWN1cml0eSB0aHJlYXRzIGFuZA0KICAgZGVmZW5zZXMpLg0KDQogICBUaGUgbGFu Z3VhZ2UgdGFnIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgaW5mb3JtYXRpb24gaXRl bSBpcyBvZg0KICAgbm8gY29uc2VxdWVuY2Ugd2hhdHNvZXZlciBpbiBkZXRlcm1pbmluZyB3 aGV0aGVyIHRoYXQgY29udGVudCBtaWdodA0KICAgY29udGFpbiBwb3NzaWJsZSBob21vZ3Jh cGhzLiAgVGhlIGZhY3QgdGhhdCBhIHRleHQgaXMgdGFnZ2VkIGFzIGJlaW5nDQogICBpbiBv bmUgbGFuZ3VhZ2Ugb3IgdXNpbmcgYSBwYXJ0aWN1bGFyIHNjcmlwdCBzdWJ0YWcgcHJvdmlk ZXMgbm8NCiAgIGFzc3VyYW5jZSB3aGF0c29ldmVyIHRoYXQgaXQgZG9lcyBub3QgY29udGFp biBjaGFyYWN0ZXJzIGZyb20gc2NyaXB0cw0KICAgb3RoZXIgdGhhbiB0aGUgb25lKHMpIGFz c29jaWF0ZWQgd2l0aCBvciBzcGVjaWZpZWQgYnkgdGhhdCBsYW5ndWFnZQ0KICAgdGFnLg0K DQogICBTaW5jZSB0aGVyZSBpcyBubyBsaW1pdCB0byB0aGUgbnVtYmVyIG9mIHZhcmlhbnQs IHByaXZhdGUgdXNlLCBhbmQNCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLCBhbmQgY29uc2VxdWVu dGx5IG5vIGxpbWl0IG9uIHRoZSBwb3NzaWJsZSBsZW5ndGgNCiAgIG9mIGEgdGFnLCBpbXBs ZW1lbnRhdGlvbnMgbmVlZCB0byBndWFyZCBhZ2FpbnN0IGJ1ZmZlciBvdmVyZmxvdw0KICAg YXR0YWNrcy4gIFNlZSBTZWN0aW9uIDQuMyBmb3IgZGV0YWlscyBvbiBsYW5ndWFnZSB0YWcg dHJ1bmNhdGlvbiwNCiAgIHdoaWNoIGNhbiBvY2N1ciBhcyBhIGNvbnNlcXVlbmNlIG9mIGRl ZmVuc2VzIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93Lg0KDQogICBBbHRob3VnaCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIGZvciBhbiBleHRlbnNpb24gKHNlZQ0KICAg U2VjdGlvbiAzLjcpIE1VU1QgYmUgYXZhaWxhYmxlIG92ZXIgdGhlIEludGVybmV0LCBpbXBs ZW1lbnRhdGlvbnMNCiAgIFNIT1VMRCBOT1QgbWVjaGFuaWNhbGx5IGRlcGVuZCBvbiBpdCBi ZWluZyBhbHdheXMgYWNjZXNzaWJsZSwgdG8NCiAgIHByZXZlbnQgZGVuaWFsLW9mLXNlcnZp Y2UgYXR0YWNrcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAg ICBbUGFnZSA1OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjcuICBDaGFyYWN0ZXIg U2V0IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBzeW50YXggaW4gdGhpcyBkb2N1bWVudCBy ZXF1aXJlcyB0aGF0IGxhbmd1YWdlIHRhZ3MgdXNlIG9ubHkgdGhlDQogICBjaGFyYWN0ZXJz IEEtWiwgYS16LCAwLTksIGFuZCBIWVBIRU4tTUlOVVMsIHdoaWNoIGFyZSBwcmVzZW50IGlu IG1vc3QNCiAgIGNoYXJhY3RlciBzZXRzLCBzbyB0aGUgY29tcG9zaXRpb24gb2YgbGFuZ3Vh Z2UgdGFncyBzaG91bGQgbm90IGhhdmUNCiAgIGFueSBjaGFyYWN0ZXIgc2V0IGlzc3Vlcy4N Cg0KICAgUmVuZGVyaW5nIG9mIGNoYXJhY3RlcnMgYmFzZWQgb24gdGhlIGNvbnRlbnQgb2Yg YSBsYW5ndWFnZSB0YWcgaXMgbm90DQogICBhZGRyZXNzZWQgaW4gdGhpcyBtZW1vLiAgSGlz dG9yaWNhbGx5LCBzb21lIGxhbmd1YWdlcyBoYXZlIHJlbGllZCBvbg0KICAgdGhlIHVzZSBv ZiBzcGVjaWZpYyBjaGFyYWN0ZXIgc2V0cyBvciBvdGhlciBpbmZvcm1hdGlvbiBpbiBvcmRl ciB0bw0KICAgaW5mZXIgaG93IGEgc3BlY2lmaWMgY2hhcmFjdGVyIHNob3VsZCBiZSByZW5k ZXJlZCAobm90YWJseSB0aGlzDQogICBhcHBsaWVzIHRvIGxhbmd1YWdlLSBhbmQgY3VsdHVy ZS1zcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbg0KICAgaWRlb2dyYXBocyBhcyB1c2VkIGlu IEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdoZW4gbGFuZ3VhZ2UNCiAgIHRh Z3MgYXJlIGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVyaW5nIGVuZ2luZXMgc29t ZXRpbWVzIHVzZQ0KICAgdGhhdCBpbmZvcm1hdGlvbiBpbiBkZWNpZGluZyB3aGljaCBmb250 IHRvIHVzZSBpbiB0aGUgYWJzZW5jZSBvZg0KICAgb3RoZXIgaW5mb3JtYXRpb24sIHBhcnRp Y3VsYXJseSB3aGVyZSBsYW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nDQogICB0cmFk aXRpb25zIHVzZSB0aGUgc2FtZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAg ICBbUGFnZSA1OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjguICBDaGFuZ2VzIGZy b20gUkZDIDQ2NDYNCg0KICAgVGhlIG1haW4gZ29hbCBmb3IgdGhpcyByZXZpc2lvbiBvZiB0 aGlzIGRvY3VtZW50IHdhcyB0byBpbmNvcnBvcmF0ZQ0KICAgSVNPIDYzOS0zIGFuZCBpdHMg YXR0ZW5kZW50IHNldCBvZiBsYW5ndWFnZSBjb2RlcyBpbnRvIHRoZSBJQU5BDQogICBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnksIHBlcm1pdHRpbmcgdGhlIGlkZW50aWZpY2F0aW9uIG9m IG1hbnkgbW9yZQ0KICAgbGFuZ3VhZ2VzIGFuZCBkaWFsZWN0cyB0aGFuIHByZXZpb3VzbHkg c3VwcG9ydGVkLg0KDQogICBUaGUgc3BlY2lmaWMgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50 IHRvIG1lZXQgdGhlc2UgZ29hbHMgYXJlOg0KDQogICBvICBEZWZpbmVzIHRoZSBpbmNvcnBv cmF0aW9uIG9mIElTTyA2MzktMyBjb2RlcyBhcyBsYW5ndWFnZSBhbmQNCiAgICAgIGV4dGxh bmcgc3VidGFncy4gIEV4dGxhbmdzIGFyZSBub3cgcGVybWl0dGVkIGluIGxhbmd1YWdlIHRh Z3MuDQogICAgICBUaGUgY2hhbmdlcyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSB0aGlzIHdlcmU6 DQoNCiAgICAgICogIHNvbWV0aGluZw0KDQogICBvICBDaGFuZ2VkIHRoZSBBQk5GIHJlbGF0 ZWQgdG8gZ3JhbmRmYXRoZXJlZCB0YWdzLiAgVGhlIGlycmVndWxhcg0KICAgICAgdGFncyBh cmUgbm93IGxpc3RlZC4gIFdlbGwtZm9ybWVkIGdyYW5kZmF0aGVyZWQgdGFncyBhcmUgbm93 DQogICAgICBkZXNjcmliZWQgYnkgdGhlICdsYW5ndGFnJyBwcm9kdWN0aW9uIGFuZCB0aGUg J2dyYW5kZmF0aGVyZWQnDQogICAgICBwcm9kdWN0aW9uIHdhcyByZW1vdmVkIGFzIGEgcmVz dWx0LiAgQWxzbzogYWRkZWQgZGVzY3JpcHRpb24gb2YNCiAgICAgIGJvdGggdHlwZXMgb2Yg Z3JhbmRmYXRoZXJlZCB0YWdzIHRvIFNlY3Rpb24gMi4yLjguDQoNCiAgIG8gIEFkZGVkIHRo ZSBwYXJhZ3JhcGggb24gImNvbGxlY3Rpb25zIiB0byBTZWN0aW9uIDQuMS4NCg0KICAgbyAg Q2hhbmdlZCB0aGUgY2FwaXRhbGl6YXRpb24gcnVsZXMgZm9yICdUYWcnIGZpZWxkcyBpbiBT ZWN0aW9uIDMuMS4NCg0KICAgbyAgU3BsaXQgc2VjdGlvbiAzLjEgdXAgaW50byBzdWJzZWN0 aW9ucy4NCg0KICAgbyAgTW9kaWZpZWQgc2VjdGlvbiAzLjUgdG8gYWxsb3cgU3VwcHJlc3Mt U2NyaXB0IGZpZWxkcyB0byBiZSBhZGRlZCwNCiAgICAgIG1vZGlmaWVkLCBvciByZW1vdmVk IHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBUaGlzIHdhcyBhbg0KICAgICAgZXJy YXR1bSBmcm9tIFJGQyA0NjQ2Lg0KDQogICBvICBNb2RpZmllZCBleGFtcGxlcyB0aGF0IHVz ZWQgcmVnaW9uIGNvZGUgJ0NTJyAoZm9ybWVybHkgU2VyYmlhIGFuZA0KICAgICAgTW9udGVu ZWdybykgdG8gdXNlICdSUycgKFNlcmJpYSkgaW5zdGVhZC4NCg0KICAgbyAgTW9kaWZpZWQg dGhlIHJ1bGVzIGZvciBjcmVhdGluZyBhbmQgbWFpbnRhaW5pbmcgcmVjb3JkDQogICAgICAn RGVzY3JpcHRpb24nIGZpZWxkcyB0byBwcmV2ZW50IGR1cGxpY2F0ZXMsIGluY2x1ZGluZyBp bnZlcnRlZA0KICAgICAgZHVwbGljYXRlcy4NCg0KICAgbyAgUmVtb3ZlZCB0aGUgbGVuZ3Ro eSBkZXNjcmlwdGlvbiBvZiB3aHkgUkZDIDQ2NDYgd2FzIGNyZWF0ZWQgZnJvbQ0KICAgICAg dGhpcyBzZWN0aW9uLCB3aGljaCBhbHNvIGNhdXNlZCB0aGUgcmVtb3ZhbCBvZiB0aGUgcmVm ZXJlbmNlIHRvDQogICAgICBYTUwgU2NoZW1hLg0KDQogICBvICBNb2RpZmllZCB0aGUgdGV4 dCBpbiBzZWN0aW9uIDIuMSB0byBwbGFjZSBtb3JlIGVtcGhhc2lzIG9uIHRoZQ0KICAgICAg ZmFjdCB0aGF0IGxhbmd1YWdlIHRhZ3MgYXJlIG5vdCBjYXNlIHNlbnNpdGl2ZS4NCg0KICAg byAgUmVwbGFjZWQgdGhlIGV4YW1wbGUgImZyLUxhdG4tQ0EiIGluIFNlY3Rpb24gMi4xIHdp dGggInNyLUxhdG4tUlMiDQogICAgICBhbmQgImF6LUFyYWItSVIiIGJlY2F1c2UgImZyLUxh dG4tQ0EiIGRvZXNuJ3QgcmVzcGVjdCB0aGUNCiAgICAgIFN1cHByZXNzLVNjcmlwdCBvbiAn TGF0bicgd2l0aCAnZnInLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBp cmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNjBdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5v dmVtYmVyIDIwMDcNCg0KDQogICBvICBDaGFuZ2VkIHRoZSByZXF1aXJlbWVudHMgZm9yIHdl bGwtZm9ybWVkbmVzcyB0byBtYWtlIHNpbmdsZXRvbg0KICAgICAgcmVwZXRpdGlvbiBjaGVj a2luZyBvcHRpb25hbCAoaXQgaXMgcmVxdWlyZWQgZm9yIHZhbGlkaXR5DQogICAgICBjaGVj a2luZykgaW4gU2VjdGlvbiAyLjIuOS4NCg0KICAgbyAgQ2hhbmdlZCB0aGUgdGV4dCBpbiBT ZWN0aW9uIDIuMi45IHJlZmVyaW5nIHRvIGdyYW5kZmF0aGVyZWQNCiAgICAgIGNoZWNraW5n IHRvIG5vdGUgdGhhdCB0aGUgbGlzdCBpcyBub3cgaW5jbHVkZWQgaW4gdGhlIEFCTkYuDQoN CiAgIG8gIE1vZGlmaWVkIGFuZCBhZGRlZCB0ZXh0IHRvIFNlY3Rpb24gMy4yLiAgVGhlIGpv YiBkZXNjcmlwdGlvbiB3YXMNCiAgICAgIHBsYWNlZCBmaXJzdC4gIEEgbm90ZSB3YXMgYWRk ZWQgbWFraW5nIGNsZWFyIHRoYXQgdGhlIExhbmd1YWdlDQogICAgICBTdWJ0YWcgUmV2aWV3 ZXIgbWF5IGRlbGVnYXRlIHZhcmlvdXMgbm9uLWNyaXRpY2FsIGR1dGllcywNCiAgICAgIGlu Y2x1ZGluZyBsaXN0IG1vZGVyYXRpb24uICBGaW5hbGx5LCBhZGRpdGlvbmFsIHRleHQgd2Fz IGFkZGVkIHRvDQogICAgICBtYWtlIHRoZSBhcHBvaW50bWVudCBwcm9jZXNzIGNsZWFyIGFu ZCB0byBjbGFyaWZ5IHRoYXQgZGVjaXNpb25zDQogICAgICBhbmQgcGVyZm9ybWFuY2Ugb2Yg dGhlIHJldmlld2VyIGFyZSBhcHBlYWxhYmxlLg0KDQogICBvICBBZGRlZCB0ZXh0IHRvIFNl Y3Rpb24gMy41IGNsYXJpZnlpbmcgdGhhdCB0aGUgaWV0Zi1sYW5ndWFnZXMgbGlzdA0KICAg ICAgaXMgb3BlcmF0ZWQgYnkgd2hvbWV2ZXIgdGhlIElFU0cgYXBwb2ludHMuDQoNCiAgIG8g IEFkZGVkIHRleHQgdG8gU2VjdGlvbiAzLjEuNCBjbGFyaWZ5aW5nIHRoYXQgdGhlIGZpcnN0 IERlc2NyaXB0aW9uDQogICAgICBpbiBhICdsYW5ndWFnZScgb3IgJ2V4dGxhbmcnIHJlY29y ZCBtYXRjaGVzIHRoZSBjb3JyZXNwb25kaW5nDQogICAgICBSZWZlcmVuY2UgTmFtZSBmb3Ig dGhlIGxhbmd1YWdlIGluIElTTyA2MzktMy4NCg0KICAgbyAgTW9kaWZpZWQgU2VjdGlvbiAy LjIuOSB0byBkZWZpbmUgY2xhc3NlcyBvZiBjb25mb3JtYW5jZSByZWxhdGVkIHRvDQogICAg ICBzcGVjaWZpYyB0YWdzIChmb3JtZXJseSAnd2VsbC1mb3JtZWQnIGFuZCAndmFsaWQnIHJl ZmVycmVkIHRvDQogICAgICBpbXBsZW1lbnRhdGlvbnMpLg0KDQogICBvICBBZGRlZCB0ZXh0 IHRvIHRoZSBlbmQgb2YgU2VjdGlvbiAzLjEuMiBub3RpbmcgdGhhdCBmdXR1cmUgdmVyc2lv bnMNCiAgICAgIG9mIHRoaXMgZG9jdW1lbnQgbWlnaHQgYWRkIG5ldyBmaWVsZCB0eXBlcyBh bmQgcmVjb21tZW5kaW5nIHRoYXQNCiAgICAgIGltcGxlbWVudGF0aW9ucyBpZ25vcmUgYW55 IHVucmVjb2duaXplZCBmaWVsZHMuDQoNCiAgIG8gIE1vZGlmaWVkIHRoZSAnZXh0bGFuZycg ZXhhbXBsZXMgaW4gQXBwZW5kaXggQSB0byB1c2UgdmFsaWQgc3VidGFncw0KICAgICAgYW5k IHJlbW92ZWQgdGhlIG5vdGUgc2F5aW5nIHRoYXQgdGhleSB3ZXJlIG9ubHkgZXhhbXBsZXMu DQoNCiAgIG8gIEFkZGVkIHRleHQgYWJvdXQgd2hhdCB0aGUgbGFjayBvZiBhIFN1cHByZXNz LVNjcmlwdCBmaWVsZCBtZWFucyBpbg0KICAgICAgYSByZWNvcmQgdG8gU2VjdGlvbiAzLjEu OC4NCg0KICAgbyAgQWRkZWQgdGV4dCBhbGxvd2luZyB0aGUgY29ycmVjdGlvbiBvZiBtaXNz cGVsbGluZ3MgYW5kIHR5cG9ncmFwaGljDQogICAgICBlcnJvcnMgdG8gU2VjdGlvbiAzLjEu NC4NCg0KICAgbyAgQWRkZWQgdGV4dCB0byBTZWN0aW9uIDMuMS43IGRpc2FsbG93aW5nIFBy ZWZpeCBmaWVsZCBjb25mbGljdHMNCiAgICAgIChzdWNoIGFzIGNpcmN1bGFyIHByZWZpeCBy ZWZlcmVuY2VzKS4NCg0KICAgbyAgTW9kaWZpZWQgdGV4dCBpbiBTZWN0aW9uIDMuNSB0byBy ZXF1aXJlIHRoZSBzdWJ0YWcgcmV2aWV3ZXIgdG8NCiAgICAgIGFubm91bmNlIGhpcy9oZXIg ZGVjaXNpb24gKG9yIGV4dGVuc2lvbikgZm9sbG93aW5nIHRoZSB0d28td2Vlaw0KICAgICAg cGVyaW9kLiAgQWxzbyBjbGFyaWZpZWQgdGhhdCBhbnkgZGVjaXNpb24gb3IgZmFpbHVyZSB0 byBkZWNpZGUgY2FuDQogICAgICBiZSBhcHBlYWxlZC4NCg0KICAgbyAgTW9kaWZpZWQgdGV4 dCBpbiBTZWN0aW9uIDQuMSB0byBpbmNsdWRlIHRoZSAoaGVyZXRvZm9yZSBhbmVjZG90YWwp DQogICAgICBndWlkaW5nIHByaW5jaXBsZSBvZiB0YWcgY2hvaWNlLCBhbmQgY2xhcmlmeWlu ZyB0aGUgbm9uLXVzZSBvZg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBp cmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNjFdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5v dmVtYmVyIDIwMDcNCg0KDQogICAgICBzY3JpcHQgc3VidGFncyBpbiBub24td3JpdHRlbiBh cHBsaWNhdGlvbnMuICBBbHNvIHVwZGF0ZWQgZXhhbXBsZXMNCiAgICAgIGluIHRoaXMgc2Vj dGlvbiB0byB1c2UgQ2hhbWljIGxhbmd1YWdlcyBhcyBhbiBleGFtcGxlIG9mIGxhbmd1YWdl DQogICAgICBjb2xsZWN0aW9ucy4NCg0KICAgbyAgUHJvaGliaXRlZCBtdWx0aXBsZSB1c2Ug b2YgdGhlIHNhbWUgdmFyaWFudCBpbiBhIHRhZyAoaS5lLiAiZGUtDQogICAgICAxOTAxLTE5 MDEiKS4gIFByZXZpb3VzbHkgdGhpcyB3YXMgb25seSBhIHJlY29tbWVuZGF0aW9uDQogICAg ICAoIlNIT1VMRCIpLg0KDQogICBvICBSZW1vdmVkIGluYXBwcm9wcmlhdGUgW1JGQzIxMTld IGxhbmd1YWdlIGZyb20gdGhlIGlsbHVzdHJhdGlvbiBpbg0KICAgICAgU2VjdGlvbiA0LjMu MS4NCg0KICAgbyAgUmVwbGFjZWQgdGhlIGV4YW1wbGUgb2YgInpoLWdvdXl1IiB3aXRoICJ6 aC1oYWtrYSItPiJ6aC1oYWsiIGluDQogICAgICBTZWN0aW9uIDQuNCwgbm90aW5nIHRoYXQg aXQgd2FzIHRoaXMgZG9jdW1lbnQgdGhhdCBjYXVzZWQgdGhlDQogICAgICBjaGFuZ2UuDQoN CiAgIG8gIFJlcGxhY2VkIHRoZSBzZWN0aW9uIGluIFNlY3Rpb24gNC4xIGRlYWxpbmcgd2l0 aCAibXVsIi8idW5kIiB0bw0KICAgICAgaW5jbHVkZSB0aGUgc3VidGFncyAnenh4JyBhbmQg J21pcycsIGFzIHdlbGwgYXMgdGhlIHRhZw0KICAgICAgImktZGVmYXVsdCIuICBBIG5vcm1h dGl2ZSByZWZlcmVuY2UgdG8gUkZDIDIyNzcgd2FzIGFkZGVkLCBhbG9uZw0KICAgICAgd2l0 aCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gTUFSQzIxLg0KDQogICBvICBBZGRlZCB0 ZXh0IHRvIFNlY3Rpb24gMy41IGNsYXJpZnlpbmcgdGhhdCBhbnkgbW9kaWZpY2F0aW9ucyBv ZiBhDQogICAgICByZWdpc3RyYXRpb24gcmVxdWVzdCBtdXN0IGJlIHNlbnQgdG8gdGhlIGll dGYtbGFuZ3VhZ2VzIGxpc3QNCiAgICAgIGJlZm9yZSBzdWJtaXNzaW9uIHRvIElBTkEuDQoN CiAgIG8gIENoYW5nZWQgdGhlIEFCTkYgZm9yIHRoZSByZWNvcmQtamFyIGZvcm1hdCBmcm9t IHVzaW5nIHRoZSBMV1NQDQogICAgICBwcm9kdWN0aW9uIHRvIHVzZSBhIGZvbGRpbmcgd2hp dGVzcGFjZSBwcm9kdWN0aW9uIHNpbWlsYXIgdG8gb2JzLQ0KICAgICAgRldTIGluIFtSRkM0 MjM0XS4gIFRoaXMgZWZmZWN0aXZlbHkgcHJldmVudHMgdW5pbnRlbnRpb25hbCBibGFuaw0K ICAgICAgbGluZXMgaW5zaWRlIGEgZmllbGQuDQoNCiAgIG8gIENsYXJpZmllZCBhbmQgcmV2 aXNlZCB0ZXh0IGluIFNlY3Rpb24gMy4zLCBTZWN0aW9uIDMuNSwgYW5kDQogICAgICBTZWN0 aW9uIDUuMSB0byBjbGFyaWZ5IHRoYXQgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBz ZW5kcyB0aGUNCiAgICAgIGNvbXBsZXRlIHJlZ2lzdHJhdGlvbiBmb3JtcyB0byBJQU5BLCB0 aGF0IElBTkEgZXh0cmFjdHMgdGhlIHJlY29yZA0KICAgICAgZnJvbSB0aGUgZm9ybSwgYW5k IHRoYXQgdGhlIGZvcm1zIG11c3QgYWxzbyBiZSBhcmNoaXZlZCBzZXBhcmF0ZWx5DQogICAg ICBmcm9tIHRoZSByZWdpc3RyeS4NCg0KICAgbyAgQWRkZWQgdGV4dCB0byBTZWN0aW9uIDUg cmVxdWlyaW5nIElBTkEgdG8gc2VuZCBhbiBhbm5vdW5jZW1lbnQgdG8NCiAgICAgIGFuIGll dGYtbGFuZ3VhZ2VzLWFubm91bmNlIGxpc3Qgd2hlbmV2ZXIgdGhlIHJlZ2lzdHJ5IGlzIHVw ZGF0ZWQuDQoNCiAgIG8gIE1vZGlmaWNhdGlvbiBvZiB0aGUgcmVnaXN0cnkgdG8gdXNlIFVU Ri04IGFzIGl0cyBjaGFyYWN0ZXINCiAgICAgIGVuY29kaW5nLiAgVGhpcyBhbHNvIGVudGFp bHMgYWRkaXRpb25hbCBpbnN0cnVjdGlvbnMgdG8gSUFOQSBhbmQNCiAgICAgIHRoZSBMYW5n dWFnZSBTdWJ0YWcgUmV2aWV3ZXIgaW4gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLg0KDQog ICBvICBNb2RpZmllZCB0aGUgcnVsZXMgaW4gU2VjdGlvbiAyLjIuNCBzbyB0aGF0ICJleGNl cHRpb25hbGx5DQogICAgICByZXNlcnZlZCIgSVNPIDMxNjYtMSBjb2RlcyBvdGhlciB0aGFu ICdVSycgd2VyZSBpbmNsdWRlZCBpbnRvIHRoZQ0KICAgICAgcmVnaXN0cnkuICBJbiBwYXJ0 aWN1bGFyLCB0aGlzIGFsbG93cyB0aGUgY29kZSAnRVUnIChFdXJvcGVhbg0KICAgICAgVW5p b24pIHRvIGJlIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIG9yIChtb3JlIGNvbW1vbmx5 KSBmb3INCiAgICAgIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGUgcmVnaXN0cnkgZm9yIHJl Z2lvbiBjb2RlcyB0byByZWZlcmVuY2UNCiAgICAgIHRoaXMgc3VidGFnLg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAg ICAgICAgW1BhZ2UgNjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBbW0VkLk5v dGU6IE9wZW4gaXNzdWVzIGluIHRoaXMgdmVyc2lvbjoNCg0KICAgICAgV2hldGhlciBlbmNv bXBhc3NlZCBsYW5ndWFnZSBydWxlcyBmb3IgdGhlIGNyZWF0aW9uIG9mIGV4dGxhbmcNCiAg ICAgIHJlY29yZHMgaW4gdGhlIHJlZ2lzdHJ5IHNob3VsZCBiZSByZXRhaW5lZCBvciBtb2Rp ZmllZC4NCg0KICAgICAgSW5jbHVzaW9uIG9mIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVs YXRlZCB0byBTdXBwcmVzcy1TY3JpcHQgaW4NCiAgICAgIHRoZSByZWdpc3RyeSAoZS5nLiB0 aGF0IGl0IHdhc24ndCBhc3NpZ25lZCBvbiBwdXJwb3NlKQ0KDQogICBdXQ0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVz IE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNjNdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVt YmVyIDIwMDcNCg0KDQo5LiAgUmVmZXJlbmNlcw0KDQo5LjEuICBOb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQogICBbSVNPMTA2NDZdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3Jn YW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08vSUVDDQogICAgICAgICAgICAg IDEwNjQ2OjIwMDMuIEluZm9ybWF0aW9uIHRlY2hub2xvZ3kgLS0gVW5pdmVyc2FsIE11bHRp cGxlLQ0KICAgICAgICAgICAgICBPY3RldCBDb2RlZCBDaGFyYWN0ZXIgU2V0IChVQ1MpIiwg MjAwMy4NCg0KICAgW0lTTzE1OTI0XQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9y Z2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPDQogICAgICAgICAgICAgIDE1 OTI0OjIwMDQuIEluZm9ybWF0aW9uIGFuZCBkb2N1bWVudGF0aW9uIC0tIENvZGVzIGZvciB0 aGUNCiAgICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2Ygc2NyaXB0cyIs IEphbnVhcnkgMjAwNC4NCg0KICAgW0lTTzMxNjYtMV0NCiAgICAgICAgICAgICAgSW50ZXJu YXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyAzMTY2LQ0K ICAgICAgICAgICAgICAxOjE5OTcuIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2Yg bmFtZXMgb2YgY291bnRyaWVzDQogICAgICAgICAgICAgIGFuZCB0aGVpciBzdWJkaXZpc2lv bnMgLS0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIiwgMTk5Ny4NCg0KICAgW0lTTzYzOS0xXQ0K ICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRp emF0aW9uLCAiSVNPIDYzOS0NCiAgICAgICAgICAgICAgMToyMDAyLiBDb2RlcyBmb3IgdGhl IHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcw0KICAgICAgICAgICAgICAt LSBQYXJ0IDE6IEFscGhhLTIgY29kZSIsIDIwMDIuDQoNCiAgIFtJU082MzktMl0NCiAgICAg ICAgICAgICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlv biwgIklTTyA2MzktDQogICAgICAgICAgICAgIDI6MTk5OC4gQ29kZXMgZm9yIHRoZSByZXBy ZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFnZXMNCiAgICAgICAgICAgICAgLS0gUGFy dCAyOiBBbHBoYS0zIGNvZGUsIGZpcnN0IGVkaXRpb24iLCAxOTk4Lg0KDQogICBbSVNPNjM5 LTNdDQogICAgICAgICAgICAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFu ZGFyZGl6YXRpb24sICJJU08gNjM5LQ0KICAgICAgICAgICAgICAzOjIwMDcuIENvZGVzIGZv ciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2VzDQogICAgICAgICAg ICAgIC0tIFBhcnQgMzogQWxwaGEtMyBjb2RlIGZvciBjb21wcmVoZW5zaXZlIGNvdmVyYWdl IG9mDQogICAgICAgICAgICAgIGxhbmd1YWdlcyIsIDIwMDcuDQoNCiAgIFtJU082NDZdICAg SW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTy9J RUMNCiAgICAgICAgICAgICAgNjQ2OjE5OTEsIEluZm9ybWF0aW9uIHRlY2hub2xvZ3kgLS0g SVNPIDctYml0IGNvZGVkDQogICAgICAgICAgICAgIGNoYXJhY3RlciBzZXQgZm9yIGluZm9y bWF0aW9uIGludGVyY2hhbmdlLiIsIDE5OTEuDQoNCiAgIFtSRkMyMDI2XSAgQnJhZG5lciwg Uy4sICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3MgLS0gUmV2aXNpb24NCiAgICAg ICAgICAgICAgMyIsIEJDUCA5LCBSRkMgMjAyNiwgT2N0b2JlciAxOTk2Lg0KDQogICBbUkZD MjAyOF0gIEhvdmV5LCBSLiBhbmQgUy4gQnJhZG5lciwgIlRoZSBPcmdhbml6YXRpb25zIElu dm9sdmVkIGluDQogICAgICAgICAgICAgIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzIiwg QkNQIDExLCBSRkMgMjAyOCwNCiAgICAgICAgICAgICAgT2N0b2JlciAxOTk2Lg0KDQogICBb UkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJ bmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJG QyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgICBF eHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNjRdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg IE5vdmVtYmVyIDIwMDcNCg0KDQogICBbUkZDMjI3N10gIEFsdmVzdHJhbmQsIEguLCAiSUVU RiBQb2xpY3kgb24gQ2hhcmFjdGVyIFNldHMgYW5kDQogICAgICAgICAgICAgIExhbmd1YWdl cyIsIEJDUCAxOCwgUkZDIDIyNzcsIEphbnVhcnkgMTk5OC4NCg0KICAgW1JGQzI0MzRdICBO YXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBh bg0KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcyIs IEJDUCAyNiwgUkZDIDI0MzQsDQogICAgICAgICAgICAgIE9jdG9iZXIgMTk5OC4NCg0KICAg W1JGQzI4NjBdICBDYXJwZW50ZXIsIEIuLCBCYWtlciwgRi4sIGFuZCBNLiBSb2JlcnRzLCAi TWVtb3JhbmR1bSBvZg0KICAgICAgICAgICAgICBVbmRlcnN0YW5kaW5nIENvbmNlcm5pbmcg dGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZQ0KICAgICAgICAgICAgICBJbnRlcm5ldCBBc3Np Z25lZCBOdW1iZXJzIEF1dGhvcml0eSIsIFJGQyAyODYwLCBKdW5lIDIwMDAuDQoNCiAgIFtS RkMzMzM5XSAgS2x5bmUsIEcuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRo ZSBJbnRlcm5ldDoNCiAgICAgICAgICAgICAgVGltZXN0YW1wcyIsIFJGQyAzMzM5LCBKdWx5 IDIwMDIuDQoNCiAgIFtSRkM0MjM0XSAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJB dWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6 IEFCTkYiLCBSRkMgNDIzNCwgT2N0b2JlciAyMDA1Lg0KDQogICBbUkZDNDY0NV0gIEV3ZWxs LCBELiwgRWQuLCAiSW5pdGlhbCBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkiLA0KICAgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNiwgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzQ2 NDUudHh0Pi4NCg0KICAgW1JGQzQ2NDddICBQaGlsbGlwcywgQS4sIEVkLiBhbmQgTS4gRGF2 aXMsIEVkLiwgIk1hdGNoaW5nIG9mIExhbmd1YWdlDQogICAgICAgICAgICAgIFRhZ3MiLCBT ZXB0ZW1iZXIgMjAwNiwNCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj L3JmYzQ2NDcudHh0Pi4NCg0KICAgW1VOX00uNDldICBTdGF0aXN0aWNzIERpdmlzaW9uLCBV bml0ZWQgTmF0aW9ucywgIlN0YW5kYXJkIENvdW50cnkgb3INCiAgICAgICAgICAgICAgQXJl YSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIiwgVU4gU3RhbmRhcmQgQ291bnRyeSBvcg0K ICAgICAgICAgICAgICBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UsIFJldmlzaW9u IDQgKFVuaXRlZCBOYXRpb25zDQogICAgICAgICAgICAgIHB1YmxpY2F0aW9uLCBTYWxlcyBO by4gOTguWFZJSS45LCBKdW5lIDE5OTkuDQoNCjkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMNCg0KICAgW1JGQzE3NjZdICBBbHZlc3RyYW5kLCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVu dGlmaWNhdGlvbiBvZg0KICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBSRkMgMTc2NiwgTWFy Y2ggMTk5NS4NCg0KICAgW1JGQzIwNDddICBNb29yZSwgSy4sICJNSU1FIChNdWx0aXB1cnBv c2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zKQ0KICAgICAgICAgICAgICBQYXJ0IFRocmVl OiBNZXNzYWdlIEhlYWRlciBFeHRlbnNpb25zIGZvciBOb24tQVNDSUkgVGV4dCIsDQogICAg ICAgICAgICAgIFJGQyAyMDQ3LCBOb3ZlbWJlciAxOTk2Lg0KDQogICBbUkZDMjIzMV0gIEZy ZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1ZSBhbmQgRW5jb2Rl ZA0KICAgICAgICAgICAgICBXb3JkIEV4dGVuc2lvbnM6IENoYXJhY3RlciBTZXRzLCBMYW5n dWFnZXMsIGFuZA0KICAgICAgICAgICAgICBDb250aW51YXRpb25zIiwgUkZDIDIyMzEsIE5v dmVtYmVyIDE5OTcuDQoNCiAgIFtSRkMyNzgxXSAgSG9mZm1hbiwgUC4gYW5kIEYuIFllcmdl YXUsICJVVEYtMTYsIGFuIGVuY29kaW5nIG9mIElTTw0KICAgICAgICAgICAgICAxMDY0NiIs IFJGQyAyNzgxLCBGZWJydWFyeSAyMDAwLg0KDQogICBbUkZDMzA2Nl0gIEFsdmVzdHJhbmQs IEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mDQogICAgICAgICAgICAgIExh bmd1YWdlcyIsIEJDUCA0NywgUkZDIDMwNjYsIEphbnVhcnkgMjAwMS4NCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAg ICAgICAgW1BhZ2UgNjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBbUkZDMzU1 Ml0gIFJlc2NvcmxhLCBFLiBhbmQgQi4gS29ydmVyLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGlu ZyBSRkMNCiAgICAgICAgICAgICAgVGV4dCBvbiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIs IEJDUCA3MiwgUkZDIDM1NTIsDQogICAgICAgICAgICAgIEp1bHkgMjAwMy4NCg0KICAgW1JG QzM2MjldICBZZXJnZWF1LCBGLiwgIlVURi04LCBhIHRyYW5zZm9ybWF0aW9uIGZvcm1hdCBv ZiBJU08NCiAgICAgICAgICAgICAgMTA2NDYiLCBTVEQgNjMsIFJGQyAzNjI5LCBOb3ZlbWJl ciAyMDAzLg0KDQogICBbUkZDNDY0Nl0gIFBoaWxsaXBzLCBBLiwgRWQuIGFuZCBNLiBEYXZp cywgRWQuLCAiVGFncyBmb3IgdGhlDQogICAgICAgICAgICAgIElkZW50aWZpY2F0aW9uIG9m IExhbmd1YWdlcyIsIFNlcHRlbWJlciAyMDA2LA0KICAgICAgICAgICAgICA8aHR0cDovL3d3 dy5pZXRmLm9yZy9yZmMvcmZjNDY0Ni50eHQ+Lg0KDQogICBbVW5pY29kZV0gIFVuaWNvZGUg Q29uc29ydGl1bSwgIlRoZSBVbmljb2RlIENvbnNvcnRpdW0uIFRoZSBVbmljb2RlDQogICAg ICAgICAgICAgIFN0YW5kYXJkLCBWZXJzaW9uIDUuMCwgKEJvc3RvbiwgTUEsIEFkZGlzb24t V2VzbGV5LCAyMDAzLg0KICAgICAgICAgICAgICBJU0JOIDAtMzIxLTQ5MDgxLTApIiwgSmFu dWFyeSAyMDA3Lg0KDQogICBbaXNvNjM5LnByaW5dDQogICAgICAgICAgICAgIElTTyA2Mzkg Sm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlLCAiSVNPIDYzOSBKb2ludCBBZHZpc29yeQ0KICAg ICAgICAgICAgICBDb21taXR0ZWU6ICBXb3JraW5nIHByaW5jaXBsZXMgZm9yIElTTyA2Mzkg bWFpbnRlbmFuY2UiLA0KICAgICAgICAgICAgICBNYXJjaCAyMDAwLA0KICAgICAgICAgICAg ICA8aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi8NCiAgICAgICAgICAg ICAgaXNvNjM5amFjX24zci5odG1sPi4NCg0KICAgW3JlY29yZC1qYXJdDQogICAgICAgICAg ICAgIFJheW1vbmQsIEUuLCAiVGhlIEFydCBvZiBVbml4IFByb2dyYW1taW5nIiwgMjAwMywN CiAgICAgICAgICAgICAgPHVybjppc2JuOjAtMTMtMTQyOTAxLTk+Lg0KDQogICBbcmVnaXN0 cnktdXBkYXRlXQ0KICAgICAgICAgICAgICBFd2VsbCwgRC4sIEVkLiwgIlVwZGF0ZSB0byB0 aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IiwNCiAgICAgICAgICAgICAgU2VwdGVtYmVy IDIwMDYsIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi1sdHJ1LWluaXRpYWwtcmVnaXN0cnktMDAudHh0Pi4NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDY2 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KQXBwZW5kaXggQS4gIEFja25vd2xlZGdl bWVudHMNCg0KICAgQW55IGxpc3Qgb2YgY29udHJpYnV0b3JzIGlzIGJvdW5kIHRvIGJlIGlu Y29tcGxldGU7IHBsZWFzZSByZWdhcmQgdGhlDQogICBmb2xsb3dpbmcgYXMgb25seSBhIHNl bGVjdGlvbiBmcm9tIHRoZSBncm91cCBvZiBwZW9wbGUgd2hvIGhhdmUNCiAgIGNvbnRyaWJ1 dGVkIHRvIG1ha2UgdGhpcyBkb2N1bWVudCB3aGF0IGl0IGlzIHRvZGF5Lg0KDQogICBUaGUg Y29udHJpYnV0b3JzIHRvIFJGQyA0NjQ2LCBSRkMgNDY0NywgUkZDIDMwNjYsIGFuZCBSRkMg MTc2NiwgdGhlDQogICBwcmVjdXJzb3JzIG9mIHRoaXMgZG9jdW1lbnQsIG1hZGUgZW5vcm1v dXMgY29udHJpYnV0aW9ucyBkaXJlY3RseSBvcg0KICAgaW5kaXJlY3RseSB0byB0aGlzIGRv Y3VtZW50IGFuZCBhcmUgZ2VuZXJhbGx5IHJlc3BvbnNpYmxlIGZvciB0aGUNCiAgIHN1Y2Nl c3Mgb2YgbGFuZ3VhZ2UgdGFncy4NCg0KICAgVGhlIGZvbGxvd2luZyBwZW9wbGUgY29udHJp YnV0ZWQgdG8gdGhpcyBkb2N1bWVudDoNCg0KICAgU3RlcGhhbmUgQm9ydHptZXllciwgS2Fy ZW4gQnJvb21lLCBQZXRlciBDb25zdGFibGUsIEpvaG4gQ293YW4sDQogICBNYXJ0aW4gRHVl cnN0LCBGcmFuayBFbGxlcm1hbiwgRG91ZyBFd2VsbCwgRGVib3JhaCBHYXJzaWRlLCBNYXJp b24NCiAgIEd1bm4sIEtlbnQgS2FybHNzb24sIENocmlzIE5ld21hbiwgUmFuZHkgUHJlc3Vo biwgU3RlcGhlbiBTaWx2ZXIsIGFuZA0KICAgbWFueSwgbWFueSBvdGhlcnMuDQoNCiAgIFZl cnkgc3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwg d2hvDQogICBvcmlnaW5hdGVkIFJGQ3MgMTc2NiBhbmQgMzA2NiwgYW5kIHdpdGhvdXQgd2hv bSB0aGlzIGRvY3VtZW50IHdvdWxkDQogICBub3QgaGF2ZSBiZWVuIHBvc3NpYmxlLg0KDQog ICBTcGVjaWFsIHRoYW5rcyBnbyB0byBNaWNoYWVsIEV2ZXJzb24sIHdobyBzZXJ2ZWQgYXMg dGhlIExhbmd1YWdlIFRhZw0KICAgUmV2aWV3ZXIgZm9yIGFsbW9zdCB0aGUgZW50aXJlIFJG QyAxNzY2L1JGQyAzMDY2IHBlcmlvZCwgYXMgd2VsbCBhcw0KICAgdGhlIExhbmd1YWdlIFN1 YnRhZyBSZXZpZXdlciBzaW5jZSB0aGUgYWRvcHRpb24gb2YgUkZDIDQ2NDYuDQoNCiAgIFNw ZWNpYWwgdGhhbmtzIGFsc28gdG8gRG91ZyBFd2VsbCwgZm9yIGhpcyBwcm9kdWN0aW9uIG9m IHRoZSBmaXJzdA0KICAgY29tcGxldGUgc3VidGFnIHJlZ2lzdHJ5LCBoaXMgd29yayB0byBz dXBwb3J0IGFuZCBtYWludGFpbiBuZXcNCiAgIHJlZ2lzdHJhdGlvbnMsIGFuZCBoaXMgY2Fy ZWZ1bCBlZGl0b3JzaGlwIG9mIGJvdGggUkZDIDQ2NDUgYW5kDQogICBbcmVnaXN0cnktdXBk YXRlXS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAg ICAgIFtQYWdlIDY3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KQXBwZW5kaXggQi4g IEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKEluZm9ybWF0aXZlKQ0KDQogICBTaW1wbGUg bGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAgICBkZSAoR2VybWFuKQ0KDQogICAgICBmciAoRnJl bmNoKQ0KDQogICAgICBqYSAoSmFwYW5lc2UpDQoNCiAgICAgIGktZW5vY2hpYW4gKGV4YW1w bGUgb2YgYSBncmFuZGZhdGhlcmVkIHRhZykNCg0KICAgTGFuZ3VhZ2Ugc3VidGFnIHBsdXMg U2NyaXB0IHN1YnRhZzoNCg0KICAgICAgemgtSGFudCAoQ2hpbmVzZSB3cml0dGVuIHVzaW5n IHRoZSBUcmFkaXRpb25hbCBDaGluZXNlIHNjcmlwdCkNCg0KICAgICAgemgtSGFucyAoQ2hp bmVzZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0KQ0KDQog ICAgICBzci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlIEN5cmlsbGljIHNjcmlw dCkNCg0KICAgICAgc3ItTGF0biAoU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBz Y3JpcHQpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb246DQoNCiAgICAgIHpoLUhhbnMt Q04gKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgU2ltcGxpZmllZCBzY3JpcHQgYXMgdXNl ZCBpbg0KICAgICAgbWFpbmxhbmQgQ2hpbmEpDQoNCiAgICAgIHNyLUxhdG4tUlMgKFNlcmJp YW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0IGFzIHVzZWQgaW4NCiAgICAgIFNl cmJpYSkNCg0KICAgTGFuZ3VhZ2UtVmFyaWFudDoNCg0KICAgICAgc2wtcm96YWogKFJlc2lh biBkaWFsZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAgICAgc2wtbmVkaXMgKE5hZGl6YSBkaWFs ZWN0IG9mIFNsb3ZlbmlhbikNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uLVZhcmlhbnQ6DQoNCiAg ICAgIGRlLUNILTE5MDEgKEdlcm1hbiBhcyB1c2VkIGluIFN3aXR6ZXJsYW5kIHVzaW5nIHRo ZSAxOTAxIHZhcmlhbnQNCiAgICAgIFtvcnRob2dyYXBoeV0pDQoNCiAgICAgIHNsLUlULW5l ZGlzIChTbG92ZW5pYW4gYXMgdXNlZCBpbiBJdGFseSwgTmFkaXphIGRpYWxlY3QpDQoNCiAg IExhbmd1YWdlLVNjcmlwdC1SZWdpb24tVmFyaWFudDoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAg ICAgW1BhZ2UgNjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICAgICBoeS1MYXRu LUlULWFyZXZlbGEgKEVhc3Rlcm4gQXJtZW5pYW4gd3JpdHRlbiBpbiBMYXRpbiBzY3JpcHQs IGFzDQogICAgICB1c2VkIGluIEl0YWx5KQ0KDQogICBMYW5ndWFnZS1SZWdpb246DQoNCiAg ICAgIGRlLURFIChHZXJtYW4gZm9yIEdlcm1hbnkpDQoNCiAgICAgIGVuLVVTIChFbmdsaXNo IGFzIHVzZWQgaW4gdGhlIFVuaXRlZCBTdGF0ZXMpDQoNCiAgICAgIGVzLTQxOSAoU3Bhbmlz aCBhcHByb3ByaWF0ZSBmb3IgdGhlIExhdGluIEFtZXJpY2EgYW5kIENhcmliYmVhbg0KICAg ICAgcmVnaW9uIHVzaW5nIHRoZSBVTiByZWdpb24gY29kZSkNCg0KICAgUHJpdmF0ZSB1c2Ug c3VidGFnczoNCg0KICAgICAgZGUtQ0gteC1waG9uZWJrDQoNCiAgICAgIGF6LUFyYWIteC1B WkUtZGVyYmVuZA0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzOg0KDQogICAgICB6 aC1jbW4NCg0KICAgICAgemgtY21uLUhhbnQtQ04NCg0KICAgUHJpdmF0ZSB1c2UgcmVnaXN0 cnkgdmFsdWVzOg0KDQogICAgICB4LXdoYXRldmVyIChwcml2YXRlIHVzZSB1c2luZyB0aGUg c2luZ2xldG9uICd4JykNCg0KICAgICAgcWFhLVFhYWEtUU0teC1zb3V0aGVybiAoYWxsIHBy aXZhdGUgdGFncykNCg0KICAgICAgZGUtUWFhYSAoR2VybWFuLCB3aXRoIGEgcHJpdmF0ZSBz Y3JpcHQpDQoNCiAgICAgIHNyLUxhdG4tUU0gKFNlcmJpYW4sIExhdGluLXNjcmlwdCwgcHJp dmF0ZSByZWdpb24pDQoNCiAgICAgIHNyLVFhYWEtUlMgKFNlcmJpYW4sIHByaXZhdGUgc2Ny aXB0LCBmb3IgU2VyYmlhKQ0KDQogICBUYWdzIHRoYXQgdXNlIGV4dGVuc2lvbnMgKGV4YW1w bGVzIE9OTFk6IGV4dGVuc2lvbnMgTVVTVCBiZSBkZWZpbmVkDQogICBieSByZXZpc2lvbiBv ciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCBvciBieSBSRkMpOg0KDQogICAgICBlbi1VUy11 LWlzbGFtQ2FsDQoNCiAgICAgIHpoLUNOLWEtbXlFeHQteC1wcml2YXRlDQoNCiAgICAgIGVu LWEtbXlFeHQtYi1hbm90aGVyDQoNCiAgIFNvbWUgSW52YWxpZCBUYWdzOg0KDQoNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAg ICAgICAgICAgIFtQYWdlIDY5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgICAg ZGUtNDE5LURFICh0d28gcmVnaW9uIHRhZ3MpDQoNCiAgICAgIGEtREUgKHVzZSBvZiBhIHNp bmdsZS1jaGFyYWN0ZXIgc3VidGFnIGluIHByaW1hcnkgcG9zaXRpb247IG5vdGUNCiAgICAg IHRoYXQgdGhlcmUgYXJlIGEgZmV3IGdyYW5kZmF0aGVyZWQgdGFncyB0aGF0IHN0YXJ0IHdp dGggImktIiB0aGF0DQogICAgICBhcmUgdmFsaWQpDQoNCiAgICAgIGFyLWEtYWFhLWItYmJi LWEtY2NjICh0d28gZXh0ZW5zaW9ucyB3aXRoIHNhbWUgc2luZ2xlLWxldHRlcg0KICAgICAg cHJlZml4KQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFn ZSA3MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3Ry eSAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCkFwcGVuZGl4IEMuICBFeGFtcGxl cyBvZiBSZWdpc3RyYXRpb24gRm9ybXMNCiAgIExBTkdVQUdFIFNVQlRBRyBSRUdJU1RSQVRJ T04gRk9STQ0KICAgMS4gTmFtZSBvZiByZXF1ZXN0ZXI6IEhhbiBTdGVlbndpamsNCiAgIDIu IEUtbWFpbCBhZGRyZXNzIG9mIHJlcXVlc3RlcjogaGFuLnN0ZWVud2lqayBAIHVuaXBkLml0 DQogICAzLiBSZWNvcmQgUmVxdWVzdGVkOg0KDQogICBUeXBlOiAgICAgICAgdmFyaWFudA0K ICAgU3VidGFnOiAgICAgIGJpc2tlDQogICBEZXNjcmlwdGlvbjogVGhlIFNhbiBHaW9yZ2lv IGRpYWxlY3Qgb2YgUmVzaWFuDQogICBEZXNjcmlwdGlvbjogVGhlIEJpbGEgZGlhbGVjdCBv ZiBSZXNpYW4NCiAgIFByZWZpeDogICAgICBzbC1yb3phag0KICAgQ29tbWVudHM6ICAgIFRo ZSBkaWFsZWN0IG9mIFNhbiBHaW9yZ2lvL0JpbGEgaXMgb25lIG9mIHRoZQ0KICAgICAgZm91 ciBtYWpvciBsb2NhbCBkaWFsZWN0cyBvZiBSZXNpYW4NCg0KICAgNC4gSW50ZW5kZWQgbWVh bmluZyBvZiB0aGUgc3VidGFnOiBUaGUgbG9jYWwgdmFyaWV0eSBvZiBSZXNpYW4gYXMNCiAg IHNwb2tlbiBpbiBTYW4gR2lvcmdpby9CaWxhDQoNCiAgIDUuIFJlZmVyZW5jZSB0byBwdWJs aXNoZWQgZGVzY3JpcHRpb24gb2YgdGhlIGxhbmd1YWdlIChib29rIG9yDQogICBhcnRpY2xl KToNCiAgICAtLSBKYW4gSS5OLiBCYXVkb3VpbiBkZSBDb3VydGVuYXkgLSBPcHl0IGZvbmV0 aWtpIHJleidqYW5za2ljaA0KICAgZ292b3JvdiwgVmFyc2F2YSAtIFBldGVyYnVyZzogVmVu ZGUgLSBLb3phbmNpa292LCAxODc1Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg ICBFeHBpcmVzIE1heSAxNywgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNzFdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMDcNCg0KDQpMQU5HVUFHRSBTVUJUQUcgUkVHSVNUUkFUSU9OIEZP Uk0NCjEuIE5hbWUgb2YgcmVxdWVzdGVyOiBKYXNrYSBaZWRsaWsNCjIuIEUtbWFpbCBhZGRy ZXNzIG9mIHJlcXVlc3Rlcjogano1MyBAIHplZGxpay5jb20NCjMuIFJlY29yZCBSZXF1ZXN0 ZWQ6DQoNClR5cGU6ICAgdmFyaWFudA0KU3VidGFnOiB0YXJhc2sNCkRlc2NyaXB0aW9uOiBC ZWxhcnVzaWFuIGluIFRhcmFza2lldmljYSBvcnRob2dyYXBoeQ0KUHJlZml4OiBiZQ0KQ29t bWVudHM6IFRoZSBzdWJ0YWcgcmVwcmVzZW50cyBCcmFuaXNsYXUgVGFyYXNraWV2aWMncyBC ZWxhcnVzaWFuDQogIG9ydGhvZ3JhcGh5IGFzIHB1Ymxpc2hlZCBpbiAiQmllbGFydXNraSBr bGFzeWNueSBwcmF2YXBpcyIgYnkgSnVyYXMNCiAgQnVzbGFrb3UsIFZpbmN1ayBWaWFjb3Jr YSwgWm1pY2llciBTYW5rbywgYW5kIFptaWNpZXIgU2F1a2ENCiAgKFZpbG5pYS1NaWVuc2sg MjAwNSkuDQoNCjQuIEludGVuZGVkIG1lYW5pbmcgb2YgdGhlIHN1YnRhZzoNCg0KVGhlIHN1 YnRhZyBpcyBpbnRlbmRlZCB0byByZXByZXNlbnQgdGhlIEJlbGFydXNpYW4gb3J0aG9ncmFw aHkgYXMNCnB1Ymxpc2hlZCBpbiAiQmllbGFydXNraSBrbGFzeWNueSBwcmF2YXBpcyIgYnkg SnVyYXMgQnVzbGFrb3UsIFZpbmN1aw0KVmlhY29ya2EsIFptaWNpZXIgU2Fua28sIGFuZCBa bWljaWVyIFNhdWthIChWaWxuaWEtTWllbnNrIDIwMDUpLg0KDQo1LiBSZWZlcmVuY2UgdG8g cHVibGlzaGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBsYW5ndWFnZSAoYm9vayBvciBhcnRpY2xl KToNCg0KVGFyYXNraWV2aWMsIEJyYW5pc2xhdS4gQmllbGFydXNrYWphIGdyYW1hdHlrYSBk bGEgc2tvbC4gVmlsbmlhOiBWeWQuDQoiQmllbGFydXNrYWhhIGthbWl0ZXR1IiwgMTkyOSwg NXRoIGVkaXRpb24uDQoNCkJ1c2xha291LCBKdXJhczsgVmlhY29ya2EsIFZpbmN1azsgU2Fu a28sIFptaWNpZXI7IFNhdWthLCBabWljaWVyLg0KQmllbGFydXNraSBrbGFzeWNueSBwcmF2 YXBpcy4gVmlsbmlhLU1pZW5zaywgMjAwNS4NCg0KNi4gQW55IG90aGVyIHJlbGV2YW50IGlu Zm9ybWF0aW9uOg0KDQpCZWxhcnVzaWFuIGluIFRhcmFza2lldmljYSBvcnRob2dyYXBoeSBi ZWNhbWUgd2lkZWx5IHVzZWQsIGVzcGVjaWFsbHkgaW4NCkJlbGFydXNpYW4tc3BlYWtpbmcg SW50ZXJuZXQgc2VnbWVudCwgYnV0IGJlc2lkZXMgdGhpcyBzb21lIGJvb2tzIGFuZA0KbmV3 c3BhcGVycyBhcmUgYWxzbyBwcmludGVkIHVzaW5nIHRoaXMgb3J0aG9ncmFwaHkgb2YgQmVs YXJ1c2lhbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDggICAgICAgICAgICAgICAg IFtQYWdlIDcyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KQXV0aG9ycycgQWRkcmVz c2VzDQoNCiAgIEFkZGlzb24gUGhpbGxpcHMgKGVkaXRvcikNCiAgIFlhaG9vISBJbmMuDQoN CiAgIEVtYWlsOiBhZGRpc29uQGludGVyLWxvY2FsZS5jb20NCiAgIFVSSTogICBodHRwOi8v d3d3LmludGVyLWxvY2FsZS5jb20NCg0KDQogICBNYXJrIERhdmlzIChlZGl0b3IpDQogICBH b29nbGUNCg0KICAgRW1haWw6IG1hcmsuZGF2aXNAbWFjY2hpYXRvLmNvbSBvciBtYXJrLmRh dmlzQGdvb2dsZS5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA3 M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVu dA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0 cmljdGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZv cnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4N Cg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJ QlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQ T05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRS VVNUIEFORA0KICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xB SU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MNCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBC VVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRg0KICAgVEhF IElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFO WSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkN Cg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0 eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Ig b3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0 aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBp bg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNl IHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxl OyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVw ZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlv bg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMg ZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAg IENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlh dCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxh YmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2gg cHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQog ICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUg SVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBU aGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBh dHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNh dGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIg dGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMg c3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYg YXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1 bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3ZpZGVkIGJ5IHRoZSBJ RVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4NCg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA4ICAg ICAgICAgICAgICAgICBbUGFnZSA3NF0NCgwNCg== --------------030203010202090500000406 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 --------------030203010202090500000406-- From ltru-bounces@ietf.org Wed Nov 14 19:12: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 1IsSLX-0003Bs-9X; Wed, 14 Nov 2007 19:12:39 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsSLW-00038d-BU for ltru-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 19:12:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsSLV-00031J-7t for ltru@ietf.org; Wed, 14 Nov 2007 19:12:37 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsSLU-00014v-SV for ltru@ietf.org; Wed, 14 Nov 2007 19:12:37 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAF0COAD002417 for ; Wed, 14 Nov 2007 16:12:24 -0800 (PST) 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=ru4FWYRJ2530TLgfQMRJB5C+RSht7ID/+ehiaWT7mOY0ZMN41pmYMksek8+HiHFW Message-ID: <473B8EE7.6000104@yahoo-inc.com> Date: Wed, 14 Nov 2007 16:12:23 -0800 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] new draft submission X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, I just submitted draft-09. It's main change is the one discussed on list today (regarding exceptionally reserved codes). It also allows me to refresh the draft (we haven't published one since August). As usual, the new draft is published on inter-locale with diffs, etc. provided as links. Hopefully we will soon be able to make many more changes (to finalize the extlang stuff). 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 Nov 15 01:19: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 1IsY4T-0006wK-4q; Thu, 15 Nov 2007 01:19:25 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsY4R-0006up-UW for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:19:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsY4R-0006mY-1j for ltru@ietf.org; Thu, 15 Nov 2007 01:19:23 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsY4O-0003YK-LF for ltru@ietf.org; Thu, 15 Nov 2007 01:19:21 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAF6JHWT008079 for ; Thu, 15 Nov 2007 15:19:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 120d_b199a646_9342_11dc_9798_0014221fa3c9; Thu, 15 Nov 2007 15:19:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36464) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 15 Nov 2007 15:15:27 +0900 Message-Id: <6.0.0.20.2.20071115150438.08bd05e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 15 Nov 2007 15:06:32 +0900 To: John Cowan , Debbie Garside From: Martin Duerst Subject: [OT] Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <20071114214711.GC12525@mercury.ccil.org> References: <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> <0b0e01c826d6$b7bec9d0$0d00a8c0@CPQ86763045110> <20071114214711.GC12525@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 06:47 07/11/15, John Cowan wrote: > Assigning a code to the E.U. looks >plausible except that (as many have pointed out) the composition of >the E.U. changes over time, making historical comparisons meaningless. >(When the ancestor of the E.U. began in 1951, it had only six members; >partial precursors go back to 1948 (three members) and 1921 (two members). >Now there are 27, with seven more in candidate or potential-candidate >status.) There are other things that go even further back. For a European monetary union that worked for quite a while, starting in 1865), please see http://en.wikipedia.org/wiki/Latin_Monetary_Union. [at that time, even Switzerland was part of the club :-]. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 15 01:19: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 1IsY4X-00077J-At; Thu, 15 Nov 2007 01:19:29 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsY4W-00074n-9U for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:19:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsY4V-00073W-Rw for ltru@ietf.org; Thu, 15 Nov 2007 01:19:27 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsY4R-0006Su-Dp for ltru@ietf.org; Thu, 15 Nov 2007 01:19:27 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAF6JKKO008097 for ; Thu, 15 Nov 2007 15:19:20 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1e51_b3dab1ca_9342_11dc_8b8d_0014221f2a2d; Thu, 15 Nov 2007 15:19:20 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36464) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 15 Nov 2007 15:15:30 +0900 Message-Id: <6.0.0.20.2.20071115150715.08bf1650@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 15 Nov 2007 15:09:39 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: The "QU" territory/region code In-Reply-To: <20071114140625.GK13650@mercury.ccil.org> References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> <20071114140625.GK13650@mercury.ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.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 The proposed text, without or (even better) with Misha's improvement, looks okay to me. However, I have a concern regarding the future evolution of "exceptionally reserved" codes. Do new codes go into the registry straight away? Or should we charge ietf-languages with making a decision, to weed out examples similar to "UK"? Regards, Martin. At 23:06 07/11/14, John Cowan wrote: >Addison Phillips scripsit: > >> So: I think it would be just grand if 'EU' were actually assigned by ISO >> 3166 and not just reserved. > >As I said, I don't think that's practical. > >> I'd propose changing Section 2.2.4, item 2 in the list to read: > >Here's my proposed version: > >All two-character subtags following the primary subtag were defined in >the IANA registry according to the assignments found in [ISO3166$B".(B1] >(International Organization for Standardization, $B!H(BISO 3166-1:1997. Codes >for the representation of names of countries and their subdivisions -- >Part 1: Country codes,$B!I(B 1997.) ("Codes for the representation of names >of countries and their subdivisions -- Part 1: Country codes") using the >list of alpha-2 country codes, or using assignments subsequently made by >the ISO 3166 maintenance agency or governing standardization bodies. In >addition, the codes that are "exceptionally reserved" (as opposed to >"assigned") in ISO 3166-1 were also defined in the registry, with the >exception of 'UK', which is an exact synonym for the assigned code >'GB'. It would only be confusing to allow 'UK', so it is excluded. > >Yeah, it's cherry-picking, but this particular cherry has a worm in it. > >-- >John Cowan http://ccil.org/~cowan cowan@ccil.org >All "isms" should be "wasms". --Abbie > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 15 03:01: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 1IsZfV-0002cI-8h; Thu, 15 Nov 2007 03:01:45 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsZfU-0002by-Gi for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 03:01:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZfU-0002bn-1e for ltru@ietf.org; Thu, 15 Nov 2007 03:01:44 -0500 Received: from mail-dub.bigfish.com ([213.199.154.10] helo=mail176-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsZfT-0007c5-Cp for ltru@ietf.org; Thu, 15 Nov 2007 03:01:43 -0500 Received: from mail176-dub (localhost.localdomain [127.0.0.1]) by mail176-dub-R.bigfish.com (Postfix) with ESMTP id 748D61180729 for ; Thu, 15 Nov 2007 08:01:42 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 192.165.213.23; Service: EHS Received: by mail176-dub (MessageSwitch) id 119511370259598_11521; Thu, 15 Nov 2007 08:01:42 +0000 (UCT) Received: from lonsmime02.rit.reuters.com (lonsmimeo.rit.reuters.com [192.165.213.23]) by mail176-dub.bigfish.com (Postfix) with ESMTP id C76B41050065 for ; Thu, 15 Nov 2007 08:01:41 +0000 (UTC) Received: from eupig2 (unverified [129.1.30.40]) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Thu, 15 Nov 2007 08:01:41 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-1x10 #31408) with ESMTP id <0JRJ00067FMTRX@eupig2.dtc.lon.ime.reuters.com>; Thu, 15 Nov 2007 08:01:41 +0000 (GMT) Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.1830); Thu, 15 Nov 2007 08:01:41 +0000 Date: Thu, 15 Nov 2007 08:01:40 +0000 From: Misha Wolf Subject: RE: [Ltru] Re: The "QU" territory/region code In-reply-to: <6.0.0.20.2.20071115150715.08bf1650@localhost> To: Martin Duerst , John Cowan , Addison Phillips Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgnT3xK7+wSFus7QzOrbpfWt5ihPQADZ3Ig Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Nov 2007 08:01:41.0520 (UTC) FILETIME=[C1B27900:01C8275D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Doug Ewell , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I suggest that we state that the basis for exclusion is a code being a synonym for an existing code, and then quote 'UK' as an example. Something like: [...] with the exception of codes which are exact synonyms for assigned codes (eg 'UK', which is a synonym for 'GB'). Misha -----Original Message----- From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] Sent: 15 November 2007 06:10 To: John Cowan; Addison Phillips Cc: Doug Ewell; LTRU Working Group Subject: Re: [Ltru] Re: The "QU" territory/region code The proposed text, without or (even better) with Misha's improvement, looks okay to me. However, I have a concern regarding the future evolution of "exceptionally reserved" codes. Do new codes go into the registry straight away? Or should we charge ietf-languages with making a decision, to weed out examples similar to "UK"? Regards, Martin. At 23:06 07/11/14, John Cowan wrote: >Addison Phillips scripsit: > >> So: I think it would be just grand if 'EU' were actually assigned by ISO >> 3166 and not just reserved. > >As I said, I don't think that's practical. > >> I'd propose changing Section 2.2.4, item 2 in the list to read: > >Here's my proposed version: > >All two-character subtags following the primary subtag were defined in >the IANA registry according to the assignments found in [ISO3166$B".(J1] >(International Organization for Standardization, $B!H(JISO 3166-1:1997. Codes >for the representation of names of countries and their subdivisions -- >Part 1: Country codes,$B!I(J 1997.) ("Codes for the representation of names >of countries and their subdivisions -- Part 1: Country codes") using the >list of alpha-2 country codes, or using assignments subsequently made by >the ISO 3166 maintenance agency or governing standardization bodies. In >addition, the codes that are "exceptionally reserved" (as opposed to >"assigned") in ISO 3166-1 were also defined in the registry, with the >exception of 'UK', which is an exact synonym for the assigned code >'GB'. It would only be confusing to allow 'UK', so it is excluded. > >Yeah, it's cherry-picking, but this particular cherry has a worm in it. > >-- >John Cowan http://ccil.org/~cowan cowan@ccil.org >All "isms" should be "wasms". --Abbie > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# 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 This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 15 03:23: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 1Isa0u-0002uE-HR; Thu, 15 Nov 2007 03:23:52 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Isa0t-0002rl-5j for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 03:23:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isa0s-0002rH-Jr for ltru@lists.ietf.org; Thu, 15 Nov 2007 03:23:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isa0p-0001mA-8y for ltru@lists.ietf.org; Thu, 15 Nov 2007 03:23:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Isa0j-0007Z1-Jd for ltru@lists.ietf.org; Thu, 15 Nov 2007 08:23:41 +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, 15 Nov 2007 08:23:41 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2007 08:23:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 15 Nov 2007 09:20:11 +0100 Lines: 25 Message-ID: References: <6.0.0.20.2.20071115150715.08bf1650@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: Re: The "QU" territory/region code X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Misha Wolf wrote: > I suggest that we state that the basis for exclusion is a code being a = synonym=20 > for an existing code, and then quote 'UK' as an example. Something = like: =20 > [...] with the exception of codes which are exact synonyms for = assigned codes=20 > (eg 'UK', which is a synonym for 'GB'). I think DG is a proper subset of IO, and wonder how many languages are = spoken on this military base, apart from en-DG, en-IO, en-GB, and en-US. All these exceptionally reserved codes are utter dubious for the purpose = of language tags. Please let Debbie handle the EU issue, not 4646bis. When I proposed to adopt IANA ccTLDs as reference for 4646 it was = rejected, now you're going to introduce codes that are even more obscure than = ccTLDs ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 15 09:23: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 1Isfcc-0005DJ-Lp; Thu, 15 Nov 2007 09:23:10 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Isfcb-0005B2-K3 for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 09:23:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isfcb-00059N-72 for ltru@ietf.org; Thu, 15 Nov 2007 09:23:09 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isfca-0006HL-Tr for ltru@ietf.org; Thu, 15 Nov 2007 09:23:09 -0500 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; Thu, 15 Nov 2007 06:22:50 -0800 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; Thu, 15 Nov 2007 06:23:07 -0800 From: Peter Constable To: Martin Duerst , John Cowan , Addison Phillips Date: Thu, 15 Nov 2007 06:23:03 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgnT3uwETCGFbyLSASj0KGtmGvcMQAQ3b+w Message-ID: References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> <20071114140625.GK13650@mercury.ccil.org> <6.0.0.20.2.20071115150715.08bf1650@localhost> In-Reply-To: <6.0.0.20.2.20071115150715.08bf1650@localhost> 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > However, I have a concern regarding the future > evolution of "exceptionally reserved" codes. Do new codes go into > the registry straight away? Or should we charge ietf-languages > with making a decision, to weed out examples similar to "UK"? Some text can be added to 3.4 to deal with that scenario -- seems to me tha= t's where that belongs. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 15 10:40: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 1IsgpE-0001sk-5d; Thu, 15 Nov 2007 10:40:16 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IsgpB-0001fP-6S for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 10:40:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgpA-0001cG-38 for ltru@ietf.org; Thu, 15 Nov 2007 10:40:12 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isgp6-0000uR-OC for ltru@ietf.org; Thu, 15 Nov 2007 10:40:12 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007464336.msg for ; Thu, 15 Nov 2007 15:44:32 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 15 Nov 2007 15:40:02 +0000 From: "Debbie Garside" To: , "'Doug Ewell'" References: <002501c82608$beecc140$6601a8c0@DGBP7M81> <4739E608.2080005@yahoo-inc.com> Subject: RE: [Ltru] Re: The "QU" territory/region code Date: Thu, 15 Nov 2007 15:39:13 -0000 Message-ID: <005001c8279d$acec86b0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wBfau1Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4739E608.2080005@yahoo-inc.com> X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Thu, 15 Nov 2007 15:44:32 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=183979e8af=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, 15 Nov 2007 15:44:34 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: 'LTRU Working Group' 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 agree with Doug that one of the UN M.49 codes could be used > to identify an artificial linguistic variant for the EU. In looking at the data surrounding all this, I think we should be careful when discussing EU as designated within ISO 3166-1 in the same vein as M.49 codes as they are not one and the same; in ISO 3166-1 EU is an exceptionally reserved code representing the European Union (with no real distinction over time) whereas M.49 represents the region of Europe as 150 (with sub-regions also designated). http://unstats.un.org/unsd/methods/m49/m49regin.htm http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EU Best regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 13 November 2007 18:00 > To: Doug Ewell > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: The "QU" territory/region code > > What follows is a bit of a rant, albeit with a textual > propose for our draft (remember our draft?). Pardon my dust. :-) > > Okay, here's my concern: there was, at one time, a very long > and not-very-friendly thread on ietf-languages in which folks > mostly from the software industry attempted (and failed) to > register "es-americas" > to identify some kind of Latin American or mid-Atlantic > Spanish. The argument against this (basically) was that there > was no such "real" > language, as in "a language recognized by linguistic > scholars". There were, however, some who thought they had a > quite real need to identify an artificially created > linguistic variant. > > In RFC 4646 we explicitly acknowledged the potential for use of the UN > M.49 code "419" for this purpose. > > I agree with Doug that one of the UN M.49 codes could be used > to identify an artificial linguistic variant for the EU. > However, I would be unsurprised if, for example, the EC were > to adopt specially controlled language variations for > translating EU "stuff" without having to choose particular > local variants (or translate into all of them). > Thus I can imagine an "fr-EU" or "de-EU" which is both "not a > real language" and also not "fr-FR" or "de-DE". This could > also be addressed as "fr-x-euro" or "de-eunion" or some-such. > > What bothers me is the sense that "we" (there is no "we") > know better than the users making the request about their > application's needs. I tend to be a little more promiscuous > about supporting variants as a result. There are cases where > the thing being requested isn't well thought out. But I am > not altogether happy with the notion that there is only one > way to use language tags or that "there is no such language > as X hence no use for this subtag in language tags". We don't > actually know that. > > So: I think it would be just grand if 'EU' were actually > assigned by ISO > 3166 and not just reserved. Further, I would support our > acknowledging the "exceptional reservation" as "an > assignment" in 4646bis. To that end, I'd propose changing > Section 2.2.4, item 2 in the list to read: > > -- > All two-character subtags following the primary subtag, with one > exception, were defined in the IANA registry according to the > assignments found in [ISO3166-1] (International Organization for > Standardization, "ISO 3166-1:1997. Codes for the > representation of names > of countries and their subdivisions -- Part 1: Country codes," 1997.) > ("Codes for the representation of names of countries and their > subdivisions -- Part 1: Country codes") using the list of alpha-2 > country codes, or using assignments subsequently made by the ISO 3166 > maintenance agency or governing standardization bodies. The one > exception is the code 'EU' (European Union), which is "exceptionally > reserved" for that purpose (but not "assigned") by ISO 3166. > This code > is assigned in the registry and is subject to the same > constraints that > appear elsewhere in this document as if it were actually > assigned by ISO > 3166. > -- > > Regards, > > Addison > > Doug Ewell wrote: > > Martin Duerst wrote: > > > >> What I'm a bit worried about, and would like to see some > confirmation, > >> is the following scenario. Assume for one reason or > another, some EU > >> variant of a language develops, is defined, or what not. > > > > Back to this in a moment. > > > >> Obviously at least to me, the region subtag 'EU' would be > most suited > >> in this case. Is it possible that the ietf-languages list > just adds > >> this subtag to the registry, or would we have to convene a WG and > >> write another version of what's currently RFC 4646? If the > later is > >> the case, my preference would be to carefully tweak our > texts so that > >> we can avoid rechartering just for the potential scenario > described > >> above. > > > > Both RFC 4646 and draft-4646bis is that they refer to code elements > > "assigned" in ISO 3166-1. RFC 4645 uses the terms "valid" and > > "assigned" in populating the initial LSR. Exceptionally > reserved code > > elements are not "assigned" according to the ISO 3166/MA > definition, and > > thus they don't qualify to have region subtags derived from them > > according to our definition. We would need to change the > requirements > > in 4646bis, and possibly in 4645bis, or else recharter the > group to do > > this in the future. > > > > As Addison said, if we really need a region subtag EU, > someone needs to > > petition ISO 3166/MA to assign the code element. > > > > This discussion, however, continues to presume a > (potential) need for a > > region subtag to describe language usage in exactly these > countries (as > > of 2007-11-03): > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > IT, LT, LU, > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > and all of their dependencies, but NOT neighboring > countries such as > > Iceland, Norway, Switzerland, or the Baltics. And the list of EU > > countries changes with some regularity -- there are currently three > > "official candidate states" and four "potential candidates" > -- making > > code instability not merely a possibility, as it is with > all country > > coding systems, but a certainty. > > > > This is not at all (IMHO) like the recent addition of BL > and MF to 3166 > > and the LSR, two countries (if that they are) which don't appear to > > exhibit distinct language usage. In that case, we are > mirroring the > > decisions made by ISO 3166/MA, as we claim to do, without > consideration > > of the linguistic angle. In the case of EU, we are > actively seeking an > > exception to our rules, which implies we must have a pretty > good reason > > to do so. > > > > Thanks to numeric region codes based on UN M.49, we now > have lots of way > > to indicate pan-European usage: 039, 150, 151, 154, 155. This has > > nothing to do with serving the language-tagging needs of Europe. > > > > Bureaucratic jargon is NOT a regional variation; as Frank said, a > > variant would be better suited to this. Even Michael > Everson's famous > > crusade against use of "euro" as a plural was NOT an > instance of "EU > > usage," but rather a misinterpretation of an EU directive > by local Irish > > officials and journalists. > > > > > -- > 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 Thu Nov 15 10:50: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 1Isgyh-0000Ku-ID; Thu, 15 Nov 2007 10:50:03 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Isgye-0000HW-6a for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 10:50:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isgyd-0000GQ-Qa for ltru@ietf.org; Thu, 15 Nov 2007 10:49:59 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isgyc-0001vx-Gd for ltru@ietf.org; Thu, 15 Nov 2007 10:49:59 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007464391.msg for ; Thu, 15 Nov 2007 15:54:23 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 15 Nov 2007 15:49:52 +0000 From: "Debbie Garside" To: , References: <002501c82608$beecc140$6601a8c0@DGBP7M81><4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] Re: The "QU" territory/region code Date: Thu, 15 Nov 2007 15:49:03 -0000 Message-ID: <005101c8279f$0cadf6f0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZAAMoLR0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Thu, 15 Nov 2007 15:54:23 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=183979e8af=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, 15 Nov 2007 15:54:24 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: 'LTRU Working Group' 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 Peter In looking at the rules governing inclusion of entities within ISO 3166-1, I think the MA have got it right insofar as they can whilst adhering to the rules. By allowing exceptionally reserved codes to be included within the standard I think they have responded to the needs of industry and users alike. As far as I can see, the only other option the MA would have is to update the standard to allow inclusion of codes that are not included within UN M.49 (other than as exceptionally reserved); this would need some sort of criteria design. There are a number of reasons why this would be a bad idea, not least is the fact that there are only so many codes left available for allocation. As it is, whilst I understand the frustration of LTRU members in this regard, I am not sure that there is a wise way to move forward on this with regard to updating ISO 3166-1. Let me know if you think I am wrong. Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 14 November 2007 15:43 > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > Debbie: > > I think it might help for the MA to consider the entire issue > of exceptional reservations. It is effectively providing > something for use in public interchange without fully > endorsing it: that's just going to leave people dealing with > consuming standards in a quandary, just as we're facing now: > they need to interoperate with the publicly-encountered > identifier, but they also need to make normative reference to > the standard. With exceptional reservations, they end up > stuck in a hole with no good way out. > > > Peter > > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: Wednesday, November 14, 2007 2:51 AM > > To: addison@yahoo-inc.com > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > Hi Addison > > > > I am attending the next meeting of the ISO 3166-1 MA on the 31st of > > January > > 2008 on behalf of the BSI. If it would help to have this code > > allocated > > within ISO 3166-1 I would be happy to put forward a proposal to the > > other MA members. When writing any proposal please be > mindful of the > > criteria for inclusion within ISO 3166-1. If you can make the > > proposal fit the inclusion criteria I will present and support it. > > > > Best regards > > > > Debbie Garside > > > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > Sent: 13 November 2007 18:00 > > > To: Doug Ewell > > > Cc: LTRU Working Group > > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > > > What follows is a bit of a rant, albeit with a textual > propose for > > > our draft (remember our draft?). Pardon my dust. :-) > > > > > > Okay, here's my concern: there was, at one time, a very long and > > > not-very-friendly thread on ietf-languages in which folks mostly > > > from the software industry attempted (and failed) to register > > > "es-americas" > > > to identify some kind of Latin American or mid-Atlantic > Spanish. The > > > argument against this (basically) was that there was no > such "real" > > > language, as in "a language recognized by linguistic scholars". > > > There were, however, some who thought they had a quite > real need to > > > identify an artificially created linguistic variant. > > > > > > In RFC 4646 we explicitly acknowledged the potential for > use of the > > UN > > > M.49 code "419" for this purpose. > > > > > > I agree with Doug that one of the UN M.49 codes could be used to > > > identify an artificial linguistic variant for the EU. > > > However, I would be unsurprised if, for example, the EC were to > > > adopt specially controlled language variations for translating EU > > > "stuff" without having to choose particular local variants (or > > > translate into all of them). > > > Thus I can imagine an "fr-EU" or "de-EU" which is both > "not a real > > > language" and also not "fr-FR" or "de-DE". This could also be > > > addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > > > What bothers me is the sense that "we" (there is no "we") know > > > better than the users making the request about their > application's > > > needs. I tend to be a little more promiscuous about supporting > > > variants as a result. There are cases where the thing being > > > requested isn't well thought out. But I am not altogether > happy with > > > the notion that there is only one way to use language > tags or that > > > "there is no such language as X hence no use for this subtag in > > > language tags". We don't actually know that. > > > > > > So: I think it would be just grand if 'EU' were actually > assigned by > > > ISO > > > 3166 and not just reserved. Further, I would support our > > > acknowledging the "exceptional reservation" as "an assignment" in > > > 4646bis. To that end, I'd propose changing Section 2.2.4, > item 2 in > > > the list to read: > > > > > > -- > > > All two-character subtags following the primary subtag, with one > > > exception, were defined in the IANA registry according to the > > > assignments found in [ISO3166-1] (International Organization for > > > Standardization, "ISO 3166-1:1997. Codes for the > representation of > > > names of countries and their subdivisions -- Part 1: > Country codes," > > > 1997.) ("Codes for the representation of names of countries and > > > their subdivisions -- Part 1: Country codes") using the list of > > > alpha-2 country codes, or using assignments subsequently > made by the > > > ISO 3166 maintenance agency or governing standardization > bodies. The > > > one exception is the code 'EU' (European Union), which is > > > "exceptionally reserved" for that purpose (but not "assigned") by > > > ISO 3166. > > > This code > > > is assigned in the registry and is subject to the same > constraints > > > that appear elsewhere in this document as if it were actually > > > assigned by ISO 3166. > > > -- > > > > > > Regards, > > > > > > Addison > > > > > > Doug Ewell wrote: > > > > Martin Duerst wrote: > > > > > > > >> What I'm a bit worried about, and would like to see some > > > confirmation, > > > >> is the following scenario. Assume for one reason or > > > another, some EU > > > >> variant of a language develops, is defined, or what not. > > > > > > > > Back to this in a moment. > > > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > > most suited > > > >> in this case. Is it possible that the ietf-languages list > > > just adds > > > >> this subtag to the registry, or would we have to > convene a WG and > > > >> write another version of what's currently RFC 4646? If the > > > later is > > > >> the case, my preference would be to carefully tweak our > > > texts so that > > > >> we can avoid rechartering just for the potential scenario > > > described > > > >> above. > > > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code > > > > elements "assigned" in ISO 3166-1. RFC 4645 uses the terms > > > > "valid" and "assigned" in populating the initial LSR. > > > > Exceptionally > > > reserved code > > > > elements are not "assigned" according to the ISO 3166/MA > > > definition, and > > > > thus they don't qualify to have region subtags derived > from them > > > > according to our definition. We would need to change the > > > requirements > > > > in 4646bis, and possibly in 4645bis, or else recharter the > > > group to do > > > > this in the future. > > > > > > > > As Addison said, if we really need a region subtag EU, > > > someone needs to > > > > petition ISO 3166/MA to assign the code element. > > > > > > > > This discussion, however, continues to presume a > > > (potential) need for a > > > > region subtag to describe language usage in exactly these > > > countries (as > > > > of 2007-11-03): > > > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > > IT, LT, LU, > > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > > > and all of their dependencies, but NOT neighboring > > > countries such as > > > > Iceland, Norway, Switzerland, or the Baltics. And the > list of EU > > > > countries changes with some regularity -- there are currently > > > > three "official candidate states" and four "potential > candidates" > > > -- making > > > > code instability not merely a possibility, as it is with > > > all country > > > > coding systems, but a certainty. > > > > > > > > This is not at all (IMHO) like the recent addition of BL > > > and MF to 3166 > > > > and the LSR, two countries (if that they are) which > don't appear > > > > to exhibit distinct language usage. In that case, we are > > > mirroring the > > > > decisions made by ISO 3166/MA, as we claim to do, without > > > consideration > > > > of the linguistic angle. In the case of EU, we are > > > actively seeking an > > > > exception to our rules, which implies we must have a pretty > > > good reason > > > > to do so. > > > > > > > > Thanks to numeric region codes based on UN M.49, we now > > > have lots of way > > > > to indicate pan-European usage: 039, 150, 151, 154, > 155. This has > > > > nothing to do with serving the language-tagging needs of Europe. > > > > > > > > Bureaucratic jargon is NOT a regional variation; as > Frank said, a > > > > variant would be better suited to this. Even Michael > > > Everson's famous > > > > crusade against use of "euro" as a plural was NOT an > > > instance of "EU > > > > usage," but rather a misinterpretation of an EU directive > > > by local Irish > > > > officials and journalists. > > > > > > > > > > > > > -- > > > 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 Thu Nov 15 11:15: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 1IshNW-0003Ev-13; Thu, 15 Nov 2007 11:15:42 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IshNN-00034a-Re for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:15:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshNN-00033f-6p; Thu, 15 Nov 2007 11:15:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshNM-00035C-3w; Thu, 15 Nov 2007 11:15:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 069052AC73; Thu, 15 Nov 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IshMr-0004u0-OL; Thu, 15 Nov 2007 11:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 11:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-4646bis-09.txt Pages : 74 Date : 2007-11-15 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-4646bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-4646bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15105042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-4646bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-4646bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15105042.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Thu Nov 15 11:53: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 1IshyT-00070S-RL; Thu, 15 Nov 2007 11:53:53 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IshyS-0006yE-AF for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:53:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshyR-0006y4-UC for ltru@ietf.org; Thu, 15 Nov 2007 11:53:52 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshyQ-00067c-Mu for ltru@ietf.org; Thu, 15 Nov 2007 11:53:51 -0500 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.222.3; Thu, 15 Nov 2007 08:53:31 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu, 15 Nov 2007 08:53:49 -0800 From: Peter Constable To: "debbie@ictmarketing.co.uk" , "addison@yahoo-inc.com" Date: Thu, 15 Nov 2007 08:53:48 -0800 Subject: RE: [Ltru] Re: The "QU" territory/region code Thread-Topic: [Ltru] Re: The "QU" territory/region code Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZAAMoLR0AACe2Ig Message-ID: References: <002501c82608$beecc140$6601a8c0@DGBP7M81><4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> <005101c8279f$0cadf6f0$0d00a8c0@CPQ86763045110> In-Reply-To: <005101c8279f$0cadf6f0$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: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I could look into this, but perhaps you know: what status do they give to e= xceptionally-reserved IDs? Is stability the same as for assigned IDs? Peter > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: Thursday, November 15, 2007 7:49 AM > To: Peter Constable; addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > Hi Peter > > In looking at the rules governing inclusion of entities within ISO > 3166-1, I > think the MA have got it right insofar as they can whilst adhering to > the > rules. By allowing exceptionally reserved codes to be included within > the > standard I think they have responded to the needs of industry and users > alike. As far as I can see, the only other option the MA would have is > to > update the standard to allow inclusion of codes that are not included > within > UN M.49 (other than as exceptionally reserved); this would need some > sort of > criteria design. There are a number of reasons why this would be a bad > idea, not least is the fact that there are only so many codes left > available > for allocation. > > As it is, whilst I understand the frustration of LTRU members in this > regard, I am not sure that there is a wise way to move forward on this > with > regard to updating ISO 3166-1. > > Let me know if you think I am wrong. > > Best regards > > Debbie > > > -----Original Message----- > > From: Peter Constable [mailto:petercon@microsoft.com] > > Sent: 14 November 2007 15:43 > > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > Debbie: > > > > I think it might help for the MA to consider the entire issue > > of exceptional reservations. It is effectively providing > > something for use in public interchange without fully > > endorsing it: that's just going to leave people dealing with > > consuming standards in a quandary, just as we're facing now: > > they need to interoperate with the publicly-encountered > > identifier, but they also need to make normative reference to > > the standard. With exceptional reservations, they end up > > stuck in a hole with no good way out. > > > > > > Peter > > > > > > > -----Original Message----- > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > Sent: Wednesday, November 14, 2007 2:51 AM > > > To: addison@yahoo-inc.com > > > Cc: 'LTRU Working Group' > > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > > > Hi Addison > > > > > > I am attending the next meeting of the ISO 3166-1 MA on the 31st of > > > January > > > 2008 on behalf of the BSI. If it would help to have this code > > > allocated > > > within ISO 3166-1 I would be happy to put forward a proposal to the > > > other MA members. When writing any proposal please be > > mindful of the > > > criteria for inclusion within ISO 3166-1. If you can make the > > > proposal fit the inclusion criteria I will present and support it. > > > > > > Best regards > > > > > > Debbie Garside > > > > > > > > > > -----Original Message----- > > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > > Sent: 13 November 2007 18:00 > > > > To: Doug Ewell > > > > Cc: LTRU Working Group > > > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > > > > > What follows is a bit of a rant, albeit with a textual > > propose for > > > > our draft (remember our draft?). Pardon my dust. :-) > > > > > > > > Okay, here's my concern: there was, at one time, a very long and > > > > not-very-friendly thread on ietf-languages in which folks mostly > > > > from the software industry attempted (and failed) to register > > > > "es-americas" > > > > to identify some kind of Latin American or mid-Atlantic > > Spanish. The > > > > argument against this (basically) was that there was no > > such "real" > > > > language, as in "a language recognized by linguistic scholars". > > > > There were, however, some who thought they had a quite > > real need to > > > > identify an artificially created linguistic variant. > > > > > > > > In RFC 4646 we explicitly acknowledged the potential for > > use of the > > > UN > > > > M.49 code "419" for this purpose. > > > > > > > > I agree with Doug that one of the UN M.49 codes could be used to > > > > identify an artificial linguistic variant for the EU. > > > > However, I would be unsurprised if, for example, the EC were to > > > > adopt specially controlled language variations for translating EU > > > > "stuff" without having to choose particular local variants (or > > > > translate into all of them). > > > > Thus I can imagine an "fr-EU" or "de-EU" which is both > > "not a real > > > > language" and also not "fr-FR" or "de-DE". This could also be > > > > addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > > > > > What bothers me is the sense that "we" (there is no "we") know > > > > better than the users making the request about their > > application's > > > > needs. I tend to be a little more promiscuous about supporting > > > > variants as a result. There are cases where the thing being > > > > requested isn't well thought out. But I am not altogether > > happy with > > > > the notion that there is only one way to use language > > tags or that > > > > "there is no such language as X hence no use for this subtag in > > > > language tags". We don't actually know that. > > > > > > > > So: I think it would be just grand if 'EU' were actually > > assigned by > > > > ISO > > > > 3166 and not just reserved. Further, I would support our > > > > acknowledging the "exceptional reservation" as "an assignment" in > > > > 4646bis. To that end, I'd propose changing Section 2.2.4, > > item 2 in > > > > the list to read: > > > > > > > > -- > > > > All two-character subtags following the primary subtag, with one > > > > exception, were defined in the IANA registry according to the > > > > assignments found in [ISO3166-1] (International Organization for > > > > Standardization, "ISO 3166-1:1997. Codes for the > > representation of > > > > names of countries and their subdivisions -- Part 1: > > Country codes," > > > > 1997.) ("Codes for the representation of names of countries and > > > > their subdivisions -- Part 1: Country codes") using the list of > > > > alpha-2 country codes, or using assignments subsequently > > made by the > > > > ISO 3166 maintenance agency or governing standardization > > bodies. The > > > > one exception is the code 'EU' (European Union), which is > > > > "exceptionally reserved" for that purpose (but not "assigned") by > > > > ISO 3166. > > > > This code > > > > is assigned in the registry and is subject to the same > > constraints > > > > that appear elsewhere in this document as if it were actually > > > > assigned by ISO 3166. > > > > -- > > > > > > > > Regards, > > > > > > > > Addison > > > > > > > > Doug Ewell wrote: > > > > > Martin Duerst wrote: > > > > > > > > > >> What I'm a bit worried about, and would like to see some > > > > confirmation, > > > > >> is the following scenario. Assume for one reason or > > > > another, some EU > > > > >> variant of a language develops, is defined, or what not. > > > > > > > > > > Back to this in a moment. > > > > > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > > > most suited > > > > >> in this case. Is it possible that the ietf-languages list > > > > just adds > > > > >> this subtag to the registry, or would we have to > > convene a WG and > > > > >> write another version of what's currently RFC 4646? If the > > > > later is > > > > >> the case, my preference would be to carefully tweak our > > > > texts so that > > > > >> we can avoid rechartering just for the potential scenario > > > > described > > > > >> above. > > > > > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code > > > > > elements "assigned" in ISO 3166-1. RFC 4645 uses the terms > > > > > "valid" and "assigned" in populating the initial LSR. > > > > > Exceptionally > > > > reserved code > > > > > elements are not "assigned" according to the ISO 3166/MA > > > > definition, and > > > > > thus they don't qualify to have region subtags derived > > from them > > > > > according to our definition. We would need to change the > > > > requirements > > > > > in 4646bis, and possibly in 4645bis, or else recharter the > > > > group to do > > > > > this in the future. > > > > > > > > > > As Addison said, if we really need a region subtag EU, > > > > someone needs to > > > > > petition ISO 3166/MA to assign the code element. > > > > > > > > > > This discussion, however, continues to presume a > > > > (potential) need for a > > > > > region subtag to describe language usage in exactly these > > > > countries (as > > > > > of 2007-11-03): > > > > > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > > > IT, LT, LU, > > > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > > > > > and all of their dependencies, but NOT neighboring > > > > countries such as > > > > > Iceland, Norway, Switzerland, or the Baltics. And the > > list of EU > > > > > countries changes with some regularity -- there are currently > > > > > three "official candidate states" and four "potential > > candidates" > > > > -- making > > > > > code instability not merely a possibility, as it is with > > > > all country > > > > > coding systems, but a certainty. > > > > > > > > > > This is not at all (IMHO) like the recent addition of BL > > > > and MF to 3166 > > > > > and the LSR, two countries (if that they are) which > > don't appear > > > > > to exhibit distinct language usage. In that case, we are > > > > mirroring the > > > > > decisions made by ISO 3166/MA, as we claim to do, without > > > > consideration > > > > > of the linguistic angle. In the case of EU, we are > > > > actively seeking an > > > > > exception to our rules, which implies we must have a pretty > > > > good reason > > > > > to do so. > > > > > > > > > > Thanks to numeric region codes based on UN M.49, we now > > > > have lots of way > > > > > to indicate pan-European usage: 039, 150, 151, 154, > > 155. This has > > > > > nothing to do with serving the language-tagging needs of Europe. > > > > > > > > > > Bureaucratic jargon is NOT a regional variation; as > > Frank said, a > > > > > variant would be better suited to this. Even Michael > > > > Everson's famous > > > > > crusade against use of "euro" as a plural was NOT an > > > > instance of "EU > > > > > usage," but rather a misinterpretation of an EU directive > > > > by local Irish > > > > > officials and journalists. > > > > > > > > > > > > > > > > > -- > > > > 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 Thu Nov 15 15:51: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 1Islgi-0004u4-Db; Thu, 15 Nov 2007 15:51:48 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Islgg-0004tW-WF for ltru-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 15:51:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Islgg-0004tM-K5 for ltru@ietf.org; Thu, 15 Nov 2007 15:51:46 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Islgf-0007UT-3M for ltru@ietf.org; Thu, 15 Nov 2007 15:51:46 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007465251.msg for ; Thu, 15 Nov 2007 20:56:09 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Thu, 15 Nov 2007 20:51:38 +0000 From: "Debbie Garside" To: , References: <002501c82608$beecc140$6601a8c0@DGBP7M81><4739E608.2080005@yahoo-inc.com> <0a5701c826ac$3100b720$0d00a8c0@CPQ86763045110> <005101c8279f$0cadf6f0$0d00a8c0@CPQ86763045110> Subject: RE: [Ltru] Re: The "QU" territory/region code Date: Thu, 15 Nov 2007 20:50:48 -0000 Message-ID: <00a801c827c9$3393e7a0$0d00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgmHzQZNIZcKVI+T4iCXsNdPxtv4wAjCdFgAAonWZAAMoLR0AACe2IgAAfSGFA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Thu, 15 Nov 2007 20:56:09 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=183979e8af=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, 15 Nov 2007 20:56:11 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: 'LTRU Working Group' 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 Exceptionally Reserved codes are added at the request of ISO member bodies, government or international organizations. It is my belief that the MA would have to go back to the applicant org if they wanted to change a code status. As the status of exceptionally reserved codes states "Code elements may be used but restrictions may apply" I don't think the MA would reallocate under any circumstances (bar a 50 year wait as stipulated in the new standard). Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 15 November 2007 16:54 > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Re: The "QU" territory/region code > > I could look into this, but perhaps you know: what status do > they give to exceptionally-reserved IDs? Is stability the > same as for assigned IDs? > > > Peter > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: Thursday, November 15, 2007 7:49 AM > > To: Peter Constable; addison@yahoo-inc.com > > Cc: 'LTRU Working Group' > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > Hi Peter > > > > In looking at the rules governing inclusion of entities within ISO > > 3166-1, I think the MA have got it right insofar as they can whilst > > adhering to the rules. By allowing exceptionally reserved > codes to be > > included within the standard I think they have responded to > the needs > > of industry and users alike. As far as I can see, the only other > > option the MA would have is to update the standard to allow > inclusion > > of codes that are not included within UN M.49 (other than as > > exceptionally reserved); this would need some sort of > criteria design. > > There are a number of reasons why this would be a bad idea, > not least > > is the fact that there are only so many codes left available for > > allocation. > > > > As it is, whilst I understand the frustration of LTRU > members in this > > regard, I am not sure that there is a wise way to move > forward on this > > with regard to updating ISO 3166-1. > > > > Let me know if you think I am wrong. > > > > Best regards > > > > Debbie > > > > > -----Original Message----- > > > From: Peter Constable [mailto:petercon@microsoft.com] > > > Sent: 14 November 2007 15:43 > > > To: debbie@ictmarketing.co.uk; addison@yahoo-inc.com > > > Cc: 'LTRU Working Group' > > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > > > Debbie: > > > > > > I think it might help for the MA to consider the entire issue of > > > exceptional reservations. It is effectively providing > something for > > > use in public interchange without fully endorsing it: that's just > > > going to leave people dealing with consuming standards in a > > > quandary, just as we're facing now: > > > they need to interoperate with the publicly-encountered > identifier, > > > but they also need to make normative reference to the > standard. With > > > exceptional reservations, they end up stuck in a hole > with no good > > > way out. > > > > > > > > > Peter > > > > > > > > > > -----Original Message----- > > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > > Sent: Wednesday, November 14, 2007 2:51 AM > > > > To: addison@yahoo-inc.com > > > > Cc: 'LTRU Working Group' > > > > Subject: RE: [Ltru] Re: The "QU" territory/region code > > > > > > > > Hi Addison > > > > > > > > I am attending the next meeting of the ISO 3166-1 MA on > the 31st > > > > of January > > > > 2008 on behalf of the BSI. If it would help to have this code > > > > allocated > > > > within ISO 3166-1 I would be happy to put forward a proposal to > > > > the other MA members. When writing any proposal please be > > > mindful of the > > > > criteria for inclusion within ISO 3166-1. If you can make the > > > > proposal fit the inclusion criteria I will present and > support it. > > > > > > > > Best regards > > > > > > > > Debbie Garside > > > > > > > > > > > > > -----Original Message----- > > > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > > > Sent: 13 November 2007 18:00 > > > > > To: Doug Ewell > > > > > Cc: LTRU Working Group > > > > > Subject: Re: [Ltru] Re: The "QU" territory/region code > > > > > > > > > > What follows is a bit of a rant, albeit with a textual > > > propose for > > > > > our draft (remember our draft?). Pardon my dust. :-) > > > > > > > > > > Okay, here's my concern: there was, at one time, a > very long and > > > > > not-very-friendly thread on ietf-languages in which > folks mostly > > > > > from the software industry attempted (and failed) to register > > > > > "es-americas" > > > > > to identify some kind of Latin American or mid-Atlantic > > > Spanish. The > > > > > argument against this (basically) was that there was no > > > such "real" > > > > > language, as in "a language recognized by linguistic > scholars". > > > > > There were, however, some who thought they had a quite > > > real need to > > > > > identify an artificially created linguistic variant. > > > > > > > > > > In RFC 4646 we explicitly acknowledged the potential for > > > use of the > > > > UN > > > > > M.49 code "419" for this purpose. > > > > > > > > > > I agree with Doug that one of the UN M.49 codes could > be used to > > > > > identify an artificial linguistic variant for the EU. > > > > > However, I would be unsurprised if, for example, the > EC were to > > > > > adopt specially controlled language variations for > translating > > > > > EU "stuff" without having to choose particular local variants > > > > > (or translate into all of them). > > > > > Thus I can imagine an "fr-EU" or "de-EU" which is both > > > "not a real > > > > > language" and also not "fr-FR" or "de-DE". This could also be > > > > > addressed as "fr-x-euro" or "de-eunion" or some-such. > > > > > > > > > > What bothers me is the sense that "we" (there is no > "we") know > > > > > better than the users making the request about their > > > application's > > > > > needs. I tend to be a little more promiscuous about > supporting > > > > > variants as a result. There are cases where the thing being > > > > > requested isn't well thought out. But I am not altogether > > > happy with > > > > > the notion that there is only one way to use language > > > tags or that > > > > > "there is no such language as X hence no use for this > subtag in > > > > > language tags". We don't actually know that. > > > > > > > > > > So: I think it would be just grand if 'EU' were actually > > > assigned by > > > > > ISO > > > > > 3166 and not just reserved. Further, I would support our > > > > > acknowledging the "exceptional reservation" as "an > assignment" > > > > > in 4646bis. To that end, I'd propose changing Section 2.2.4, > > > item 2 in > > > > > the list to read: > > > > > > > > > > -- > > > > > All two-character subtags following the primary > subtag, with one > > > > > exception, were defined in the IANA registry according to the > > > > > assignments found in [ISO3166-1] (International > Organization for > > > > > Standardization, "ISO 3166-1:1997. Codes for the > > > representation of > > > > > names of countries and their subdivisions -- Part 1: > > > Country codes," > > > > > 1997.) ("Codes for the representation of names of > countries and > > > > > their subdivisions -- Part 1: Country codes") using > the list of > > > > > alpha-2 country codes, or using assignments subsequently > > > made by the > > > > > ISO 3166 maintenance agency or governing standardization > > > bodies. The > > > > > one exception is the code 'EU' (European Union), which is > > > > > "exceptionally reserved" for that purpose (but not > "assigned") > > > > > by ISO 3166. > > > > > This code > > > > > is assigned in the registry and is subject to the same > > > constraints > > > > > that appear elsewhere in this document as if it were actually > > > > > assigned by ISO 3166. > > > > > -- > > > > > > > > > > Regards, > > > > > > > > > > Addison > > > > > > > > > > Doug Ewell wrote: > > > > > > Martin Duerst wrote: > > > > > > > > > > > >> What I'm a bit worried about, and would like to see some > > > > > confirmation, > > > > > >> is the following scenario. Assume for one reason or > > > > > another, some EU > > > > > >> variant of a language develops, is defined, or what not. > > > > > > > > > > > > Back to this in a moment. > > > > > > > > > > > >> Obviously at least to me, the region subtag 'EU' would be > > > > > most suited > > > > > >> in this case. Is it possible that the ietf-languages list > > > > > just adds > > > > > >> this subtag to the registry, or would we have to > > > convene a WG and > > > > > >> write another version of what's currently RFC 4646? If the > > > > > later is > > > > > >> the case, my preference would be to carefully tweak our > > > > > texts so that > > > > > >> we can avoid rechartering just for the potential scenario > > > > > described > > > > > >> above. > > > > > > > > > > > > Both RFC 4646 and draft-4646bis is that they refer to code > > > > > > elements "assigned" in ISO 3166-1. RFC 4645 uses the terms > > > > > > "valid" and "assigned" in populating the initial LSR. > > > > > > Exceptionally > > > > > reserved code > > > > > > elements are not "assigned" according to the ISO 3166/MA > > > > > definition, and > > > > > > thus they don't qualify to have region subtags derived > > > from them > > > > > > according to our definition. We would need to change the > > > > > requirements > > > > > > in 4646bis, and possibly in 4645bis, or else recharter the > > > > > group to do > > > > > > this in the future. > > > > > > > > > > > > As Addison said, if we really need a region subtag EU, > > > > > someone needs to > > > > > > petition ISO 3166/MA to assign the code element. > > > > > > > > > > > > This discussion, however, continues to presume a > > > > > (potential) need for a > > > > > > region subtag to describe language usage in exactly these > > > > > countries (as > > > > > > of 2007-11-03): > > > > > > > > > > > > AT, BE, BG, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, > > > > > IT, LT, LU, > > > > > > LV, MT, NL, PL, PT, RO, SE, SI, SK > > > > > > > > > > > > and all of their dependencies, but NOT neighboring > > > > > countries such as > > > > > > Iceland, Norway, Switzerland, or the Baltics. And the > > > list of EU > > > > > > countries changes with some regularity -- there are > currently > > > > > > three "official candidate states" and four "potential > > > candidates" > > > > > -- making > > > > > > code instability not merely a possibility, as it is with > > > > > all country > > > > > > coding systems, but a certainty. > > > > > > > > > > > > This is not at all (IMHO) like the recent addition of BL > > > > > and MF to 3166 > > > > > > and the LSR, two countries (if that they are) which > > > don't appear > > > > > > to exhibit distinct language usage. In that case, we are > > > > > mirroring the > > > > > > decisions made by ISO 3166/MA, as we claim to do, without > > > > > consideration > > > > > > of the linguistic angle. In the case of EU, we are > > > > > actively seeking an > > > > > > exception to our rules, which implies we must have a pretty > > > > > good reason > > > > > > to do so. > > > > > > > > > > > > Thanks to numeric region codes based on UN M.49, we now > > > > > have lots of way > > > > > > to indicate pan-European usage: 039, 150, 151, 154, > > > 155. This has > > > > > > nothing to do with serving the language-tagging > needs of Europe. > > > > > > > > > > > > Bureaucratic jargon is NOT a regional variation; as > > > Frank said, a > > > > > > variant would be better suited to this. Even Michael > > > > > Everson's famous > > > > > > crusade against use of "euro" as a plural was NOT an > > > > > instance of "EU > > > > > > usage," but rather a misinterpretation of an EU directive > > > > > by local Irish > > > > > > officials and journalists. > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 Mon Nov 19 21:16: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 1IuIfF-000864-Py; Mon, 19 Nov 2007 21:16:37 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IuIfE-00085w-UZ for ltru-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 21:16:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIfE-00085j-Ih for ltru@ietf.org; Mon, 19 Nov 2007 21:16:36 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIf8-0003ns-87 for ltru@ietf.org; Mon, 19 Nov 2007 21:16:36 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAK2GP8f028682 for ; Tue, 20 Nov 2007 11:16:25 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0f64_987764da_970e_11dc_94e3_0014221f2a2d; Tue, 20 Nov 2007 11:16:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36289) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 20 Nov 2007 11:12:34 +0900 Message-Id: <6.0.0.20.2.20071120111127.06fdb3e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 20 Nov 2007 11:15:27 +0900 To: LTRU Working Group From: Martin Duerst Subject: Re: [Ltru] trying again: teleconference??? In-Reply-To: <473B179D.5020600@yahoo-inc.com> References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> <6.0.0.20.2.20071114193837.0983c140@localhost> <473B179D.5020600@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 After looking at all the replies I got, the best place for the teleconference seems to be plan (B) on Wednesday/Thursday. I'm therefore looking to a teleconference this week at the following times: >>> (B) >>> >>> 14:00 Pacific (Wednesday, Nov. 21) >>> 22:00 London (Wednesday, Nov. 21) >>> 09:00 Sydney (Thursday, Nov. 22) >>> 07:00 Tokyo (Thursday, Nov. 22) >>> 17:00 Toronto (Wednesday, Nov. 21) Addison, can you please make a reservation for your bridge and send complete dialin instructions? Of course everybody is welcome to this call, even those who haven't sent in any preferences. 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 Nov 19 21:30: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 1IuIsW-00033h-FJ; Mon, 19 Nov 2007 21:30:20 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IuIsU-00033O-Hq for ltru-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 21:30:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIsU-00033F-8G for ltru@ietf.org; Mon, 19 Nov 2007 21:30:18 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIsS-00046R-KY for ltru@ietf.org; Mon, 19 Nov 2007 21:30:18 -0500 Received: by wa-out-1112.google.com with SMTP id k40so3217434wah for ; Mon, 19 Nov 2007 18:30:15 -0800 (PST) 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=zQhI6Y9fp8Kt62oPvYR6ik4uviMQqAzFukjIVgba/ng=; b=OKVXUF6wsJuCWErcOrfMK92uaXgWMPP/t5T9CIbR4ZiZN3n+J7mUzoW4ri6eGDBUcyVj15hxwoM2nbjjFsNoronNfj8rLTHiZr2/A8PGXiK5yFOBlDtSDsBy6c8ecni1bnm3J17GkD6i9aPXuL1jC5PyWwq26eYoU0AhKcBd9Ak= 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=XJON4y8sevXoQJmZDqmD5qJmKUZBvrDg6ANHuTwGQCZcuRBw3lEJqkZl4iLNePpNF9FIjCtRHiflnBZAyT7neOnlSGGlrpEBSEouZ2VkzTp8X4Q1zOoCf/ajljs8TyRo+yQDjkALQwHNEB3eRmJFOD0qwJ0c8IG6uJS3dGmdgSE= Received: by 10.114.149.2 with SMTP id w2mr111013wad.1195525815847; Mon, 19 Nov 2007 18:30:15 -0800 (PST) Received: by 10.114.198.8 with HTTP; Mon, 19 Nov 2007 18:30:15 -0800 (PST) Message-ID: <30b660a20711191830l134793a4p670b5dc4ab98266a@mail.gmail.com> Date: Mon, 19 Nov 2007 18:30:15 -0800 From: "Mark Davis" To: "Martin Duerst" Subject: Re: [Ltru] trying again: teleconference??? In-Reply-To: <6.0.0.20.2.20071120111127.06fdb3e0@localhost> MIME-Version: 1.0 References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> <6.0.0.20.2.20071114193837.0983c140@localhost> <473B179D.5020600@yahoo-inc.com> <6.0.0.20.2.20071120111127.06fdb3e0@localhost> X-Google-Sender-Auth: f6c806281458af1c X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0651041284==" Errors-To: ltru-bounces@ietf.org --===============0651041284== Content-Type: multipart/alternative; boundary="----=_Part_21616_4583999.1195525815841" ------=_Part_21616_4583999.1195525815841 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I suggest that all those planning to attend send that information to Addison and me; we can make a calendar entry (arm wrestling for Google vs Yahoo calendar) for the attendees. Mark On Nov 19, 2007 6:15 PM, Martin Duerst wrote: > After looking at all the replies I got, the best place for > the teleconference seems to be plan (B) on Wednesday/Thursday. > > I'm therefore looking to a teleconference this week at the > following times: > > >>> (B) > >>> > >>> 14:00 Pacific (Wednesday, Nov. 21) > >>> 22:00 London (Wednesday, Nov. 21) > >>> 09:00 Sydney (Thursday, Nov. 22) > >>> 07:00 Tokyo (Thursday, Nov. 22) > >>> 17:00 Toronto (Wednesday, Nov. 21) > > Addison, can you please make a reservation for your bridge and > send complete dialin instructions? > > Of course everybody is welcome to this call, even those who > haven't sent in any preferences. > > 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 > -- Mark ------=_Part_21616_4583999.1195525815841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I suggest that all those planning to attend send that information to Addison and me; we can make a calendar entry (arm wrestling for Google vs Yahoo calendar) for the attendees.

Mark

On Nov 19, 2007 6:15 PM, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
After looking at all the replies I got, the best place for
the teleconference seems to be plan (B) on Wednesday/Thursday.

I'm therefore looking to a teleconference this week at the
following times:

>>> (B)
>>>
>>> 14:00 Pacific (Wednesday, Nov. 21)
>>> 22:00 London (Wednesday, Nov. 21)
>>> 09:00 Sydney (Thursday, Nov. 22)
>>> 07:00 Tokyo (Thursday, Nov. 22)
>>> 17:00 Toronto (Wednesday, Nov. 21)

Addison, can you please make a reservation for your bridge and
send complete dialin instructions?

Of course everybody is welcome to this call, even those who
haven't sent in any preferences.

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



--
Mark ------=_Part_21616_4583999.1195525815841-- --===============0651041284== 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 --===============0651041284==-- From ltru-bounces@ietf.org Mon Nov 19 23:03: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 1IuKKf-0003Jj-5E; Mon, 19 Nov 2007 23:03:29 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IuKKd-0003CK-M7 for ltru-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 23:03:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuKKd-0003Aj-C4 for ltru@ietf.org; Mon, 19 Nov 2007 23:03:27 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuKKb-0005nF-8o for ltru@ietf.org; Mon, 19 Nov 2007 23:03:27 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IuKKV-0006TE-UT; Mon, 19 Nov 2007 23:03:20 -0500 Date: Mon, 19 Nov 2007 23:03:19 -0500 To: Mark Davis Subject: Re: [Ltru] trying again: teleconference??? Message-ID: <20071120040319.GA4066@mercury.ccil.org> References: <472D0B0A.3010200@yahoo-inc.com> <6.0.0.20.2.20071113193802.0ab17ba0@localhost> <4739CF8C.3050408@yahoo-inc.com> <6.0.0.20.2.20071114193837.0983c140@localhost> <473B179D.5020600@yahoo-inc.com> <6.0.0.20.2.20071120111127.06fdb3e0@localhost> <30b660a20711191830l134793a4p670b5dc4ab98266a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20711191830l134793a4p670b5dc4ab98266a@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > I suggest that all those planning to attend send that information to Addison > and me; we can make a calendar entry (arm wrestling for Google vs Yahoo > calendar) for the attendees. I'll be there this Wed but will have to leave early: I can then make the full time on later Wednesdays until the last week of December or so. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.ccil.org/~cowan men and women enjoy mating. cowan@ccil.org --Isaac Asimov in Earth: Our Crowded Spaceship _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 20 20:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iue2d-0001Pj-2g; Tue, 20 Nov 2007 20:06:11 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iue2b-0001LG-Uz for ltru-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 20:06:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iue2b-0001Ji-Id for ltru@ietf.org; Tue, 20 Nov 2007 20:06:09 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iue2b-0004rl-5X for ltru@ietf.org; Tue, 20 Nov 2007 20:06:09 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAL15r8O082410 for ; Tue, 20 Nov 2007 17:05:53 -0800 (PST) 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=luwbnf9A1kGxziqZ+JASEY0NZxoWvIGiXeDPXB3EfQRvcWkIeAIu+gN+amHgngXS Message-ID: <47438471.1080609@yahoo-inc.com> Date: Tue, 20 Nov 2007 17:05:53 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ltru] Telecon Reminder/Info for 21 NOVEMBER 22:00 UTC (tomorrow) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Tomorrow's teleconference will occur at: 14:00 Pacific (Wednesday, Nov. 21) 22:00 London (Wednesday, Nov. 21) 09:00 Sydney (Thursday, Nov. 22) 07:00 Tokyo (Thursday, Nov. 22) 17:00 Toronto (Wednesday, Nov. 21) Or Find Your Local Time Here: http://tinyurl.com/2a6vtn Dial In Information * USA: 1-888-371-8922 * International: +1.617.224.4792 Random Other Countries: * Austria: (0) 1.7957.6003 * France: (0) 1.71230263 * Germany: 06950.072802 * Ireland: 012421577 * Italy: 0.269.6828.47 * Netherlands: 0202013357 * Spain: 9.1270268.8 * UK: (0) 207.365.0742 * Japan: 0335708092 Participant Passcode: 58371972 Note: I won't be able to participate in this particular call, other than to start it. For our next teleconference I will also provide a URI for Web meeting (content sharing, whiteboard, etc.) -- 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 Nov 21 16:50: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 1IuxSu-0003lq-UT; Wed, 21 Nov 2007 16:50:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IuxSt-0003lg-Q8 for ltru-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxSt-0003lY-G0 for ltru@ietf.org; Wed, 21 Nov 2007 16:50:35 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuxSq-0006tw-5u for ltru@ietf.org; Wed, 21 Nov 2007 16:50:35 -0500 Received: by nz-out-0506.google.com with SMTP id n1so2010170nzf for ; Wed, 21 Nov 2007 13:50:31 -0800 (PST) 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=hAA3YUM+1pjpP+f0AkWmMksug9QZxYLRiro/Gpy+rgM=; b=jufk7cNjKRrG/gXINj8SOYwRSS/ynW5Wl09yyiI0VhQRdcixxeEcmY1owNPUeONU+kb7MekF6ltRLI4LuN9hALTw/yqKznkHVv02ydTW3qAnNp0iD1nmOurjxl6v4EpBssFbSvRxCLy8g9CRyqmtYxGq3D9Tj+KYiMRfcL7/wnA= 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=KDlgSH6t8bU4t3Zxj6Qy3wQDKLRNGZ8g76RlIhpbWCcI/3SrgWRCzBh8KiQF775aMJM3ikF1jNTdLgiYI2CwwqVSm7Mkzvsgbe7mee/OGVZiph8sxJYn50rNxNIONRqobbXxox361ZVir4mvly0cAOxPJou0r9Hxtoa2Mgb9VUo= Received: by 10.142.214.5 with SMTP id m5mr2261778wfg.1195681831277; Wed, 21 Nov 2007 13:50:31 -0800 (PST) Received: by 10.142.128.8 with HTTP; Wed, 21 Nov 2007 13:50:31 -0800 (PST) Message-ID: <30b660a20711211350lcea0b35k3fc58ccf126fe0f1@mail.gmail.com> Date: Wed, 21 Nov 2007 13:50:31 -0800 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 877a0cc5978202d5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] LTRU telecon X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1074278498==" Errors-To: ltru-bounces@ietf.org --===============1074278498== Content-Type: multipart/alternative; boundary="----=_Part_34897_31003430.1195681831266" ------=_Part_34897_31003430.1195681831266 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Today's telecon is likely to be quite light, since it is just before a major US holiday. I sent out a calendar entry with people who'd signed up; let me know if you want to be added to the list. Addison also sent out the phone information in an email. I suggest that we talk a bit about the process; I also made a document with my suggested text changes for 4647 (previously in email) in case we want to discuss it, in http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s -- Mark ------=_Part_34897_31003430.1195681831266 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Today's telecon is likely to be quite light, since it is just before a major US holiday. I sent out a calendar entry with people who'd signed up; let me know if you want to be added to the list. Addison also sent out the phone information in an email.

I suggest that we talk a bit about the process; I also made a document with my suggested text changes for 4647 (previously in email) in case we want to discuss it, in

http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s

--
Mark ------=_Part_34897_31003430.1195681831266-- --===============1074278498== 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 --===============1074278498==-- From ltru-bounces@ietf.org Wed Nov 21 18:10: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 1IuyiI-0007NV-If; Wed, 21 Nov 2007 18:10:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IuyiH-0007N9-3k for ltru-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:10:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyiG-0007Mw-Ne for ltru@ietf.org; Wed, 21 Nov 2007 18:10:32 -0500 Received: from ro-out-1112.google.com ([72.14.202.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyiD-0001td-G0 for ltru@ietf.org; Wed, 21 Nov 2007 18:10:32 -0500 Received: by ro-out-1112.google.com with SMTP id k4so2770130rog for ; Wed, 21 Nov 2007 15:10:29 -0800 (PST) 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=FMtg2hUGUtG8zcusIIdjzCwY6clsUTOv+5AjRVSJCSo=; b=Qdlay3nIbzb5rEqYQroIbrlghPoCZYNVboNy/tIqYHHkXwtMFQCkWxcqUyk4NKMERCI5ZmrhbawqkcbKz43C+F9kf2d/KKQaW5tfgujfM89K49K3gPKl3VhbgyDzN+04ZQcJWzHrpXVwVfRq8NlSgAakFLAarbvK70fXUHU1uC8= 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=QwgBd2p6VoeRovP1KiqNW204DIHQUwl0Zr0pCf0FjloStkNzLdwsQ2LVPDy3jbdAKNIEIZFJmdZxhSA5FwHUxsv8XUMJhmi75c5IFylAanW/ovsra+0LxyMfaQ5KUkGKy17HdS+K0DB8yEfv/v2pfOl/6WhrgitnSSS6SyRZJdI= Received: by 10.142.111.14 with SMTP id j14mr2268015wfc.1195686628122; Wed, 21 Nov 2007 15:10:28 -0800 (PST) Received: by 10.142.128.8 with HTTP; Wed, 21 Nov 2007 15:10:28 -0800 (PST) Message-ID: <30b660a20711211510u78e3c55bw647b77cd4c63ed82@mail.gmail.com> Date: Wed, 21 Nov 2007 15:10:28 -0800 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 5bc81e0004133de9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Fragmentary notes from telecon X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1045550795==" Errors-To: ltru-bounces@ietf.org --===============1045550795== Content-Type: multipart/alternative; boundary="----=_Part_35030_24449827.1195686628127" ------=_Part_35030_24449827.1195686628127 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline http://docs.google.com/Doc?id=dfqr8rd5_43dnw36c -- Mark ------=_Part_35030_24449827.1195686628127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline http://docs.google.com/Doc?id=dfqr8rd5_43dnw36c

--
Mark ------=_Part_35030_24449827.1195686628127-- --===============1045550795== 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 --===============1045550795==-- From ltru-bounces@ietf.org Thu Nov 22 09:02: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 1IvCdY-00063Q-Ai; Thu, 22 Nov 2007 09:02:36 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IvCdV-000638-TG for ltru-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:02:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCdV-000630-JL for ltru@ietf.org; Thu, 22 Nov 2007 09:02:33 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCdR-0001NS-J9 for ltru@ietf.org; Thu, 22 Nov 2007 09:02:33 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 863CB24082F; Thu, 22 Nov 2007 14:02:15 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 5A9EF93CEE; Thu, 22 Nov 2007 15:01:12 +0100 (CET) Date: Thu, 22 Nov 2007 15:01:13 +0100 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20071122140113.GB23416@laperouse.bortzmeyer.org> References: <30b660a20711211510u78e3c55bw647b77cd4c63ed82@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20711211510u78e3c55bw647b77cd4c63ed82@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: LTRU Working Group Subject: [Ltru] Re: Fragmentary notes from telecon X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Nov 21, 2007 at 03:10:28PM -0800, Mark Davis wrote a message of 38 lines which said: > http://docs.google.com/Doc?id=dfqr8rd5_43dnw36c IMHO, the IETF rules for mailing lists do not mix well with "outside" documents, which may not be available in the future, when someone will read the archive. So, I take the liberty to copy it here: LTRU Telecon Notes Felix, Randy, Martin, John, Addison, Mark Fragmentary notes (see end) Mark: We could look over the suggested changes in http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s to see how this would be/change depending on the choices we make. Addison: Mostly in agreement about difficulties with macrolanguages. Disagreement: extlang is a useful mechanism, gives better results extlang is not a useful mechanism, gives worse results (Someone): Conflation of macrolanguage and majority language is a mistake. John: with extlang, should deviate from truncate from right in lookup Mark: sole reason for extlang is for not changing the algorithm Others: reason is to avoid need to look at registry Mark: doesn't matter -- no big deal to look at registry. Not proposing that it be required, just optional. And practically, software can update every so often to get the cases it cares about. Not a lot of data. Even for limited-memory environments, like cellphones, can Addision: people would be recommended to use the languages they can handle: eg zh, yue John: have registered tags encoded with extlang style Mark: those are not productive in tags Addision: those were in good faith, but can deprecate and remap; have done in other cases. Addision: lookup with extlang would look like: zh-yue-Hant-TW zh-yue-Hant zh-yue zh-hant-tw zh-hant zh (default) ... (many interesting points made, but was too involved in the conversation to keep up with the notes) ... Martin: Why not have extlang (question about google) Mark: Concerned with more than just Google: impacts Unicode (CLDR), ICU, Java, ... Concern is that better results overall are returned if we don't have extlang; we're inventing a mechanism and complications that we don't need. Example, zh/yue -- we got along without extlang for the analogous case of de/gsw. ... (Q about filtering). For filtering, in other cases, we specify the languages we want; if I want de and gsw, I list them. Similar for yue and zh. ... At the end. * Will have weekly meeting. * We talked about assigning a scribe, or having people note what they just said -- either way, set up something before we start next time. * Addison will set up a collaboration tool for next time, and notify us ahead of time. Google Docs -- Web word processing, presentations and spreadsheets. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 22 14:44: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 1IvHya-0004Nr-BH; Thu, 22 Nov 2007 14:44:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IvHyY-0004NR-VH for ltru-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 14:44:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHyY-0004NI-KI for ltru@ietf.org; Thu, 22 Nov 2007 14:44:38 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvHyX-000378-Vw for ltru@ietf.org; Thu, 22 Nov 2007 14:44:38 -0500 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 <20071122194437.GAZM16758.mta13.adelphia.net@DGBP7M81> for ; Thu, 22 Nov 2007 14:44:37 -0500 Message-ID: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 22 Nov 2007 11:44:36 -0800 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Ltru] Preparing ourselves for IETF Last Call X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org (Apologies in advance if this message serves as troll food, but I believe it's important in conducting and focusing the business of this WG.) Assuming that we can come to a decision on how to support extlangs-- or more likely, how to modify 4647 *instead of* supporting extlangs -- we will eventually find ourselves submitting two (or three) new drafts for IETF Last Call. IETF Last Call isn't just a formality, as many LTRU members know. There are lots of people in the IETF, not only the Gen-ART reviewer but others, who will likely take a look at our charter and at our deliverables, and who may ask some tough questions when those two don't seem to match. The change to Section 2.2.4 to add seven ISO 3166 exceptionally reserved code elements to the Registry ("FX" is already there) may be one of those issues that raises eyebrows. Adding more region subtags is not mentioned anywhere in our charter, and people may wonder how this change got there, especially with such rapidity (eight days from mention of "QU" by Philippe Verdy on the Unicode list to submission of draft-09 allowing "EU" and others). I think we may want to prepare ourselves for the type of questioning we are likely to see from the IETF during Last Call: Q: Why the change to add exceptionally reserved country codes? A: We wanted to permit access within language tags to regions that have no officially assigned ISO 3166 code element. Q: Many of these are small, sparsely inhabited islands or areas that don't show a distinct linguistic identity. What's the motivation for adding them? A: OK, we really just wanted to add "EU" for "European Union," and adding the others prevents us from being accused of cherry-picking. We didn't want to claim to know the needs of tagging applications better than the users of those applications. Q: Isn't it cherry-picking to exclude "UK"? A: Yes, but in a good way. "UK" is a duplicate of "GB". Q: Some rogue tagging applications currently use "UK" instead of "GB". Do you know those applications' needs better than their users? A: Yes; that's not "best current practice" in the way that "EU" would be. Q. What distinct language variety is associated with the EU to justify this change to the BCP? A: Possible official bureaucratic terminology promulgated by EU leadership; other as-yet unknown language variations. Q: Does BCP 47 normally represent bureaucratic terminology or unknown variations by adding region subtags? A: No, but the EU is different. Q: Don't the existing numeric region subtags for Europe, Western Europe, etc. adequately cover European language usage, without the inherent tag instability caused by changes to EU membership? A: OK, this isn't just about language tagging after all. We really want the LSR to be not only the source of language tags, but *the* reference for stabilized, maintainable codes for languages, scripts, and regions. Q: I thought that's what the ISO standards were for. A: We're more stable and traceable than they are. Q: That's a non-trivial change of scope. Is this in the LTRU's charter? A: The charter does say that the WG can "make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience." Operational experience shows that projects like CLDR, ICU, Java, etc. already use the LSR as their reference instead of ISO standards. Q: How are you guys doing on adding support for ISO 639-3 code elements? That was the main purpose for rechartering the WG. The charter page says you were going to be ready with IETF LC drafts back in January 2007, assuming that ISO 639-3 was approved. A: We still don't have that worked out yet. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Thu Nov 22 16:23: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 1IvJW4-0000Dy-2m; Thu, 22 Nov 2007 16:23:20 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IvJW3-00009G-Bw for ltru-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 16:23:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvJW2-0008Vt-I0 for ltru@ietf.org; Thu, 22 Nov 2007 16:23:18 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvJW2-0006ng-8a for ltru@ietf.org; Thu, 22 Nov 2007 16:23:18 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 22 Nov 2007 13:22:53 -0800 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; Thu, 22 Nov 2007 13:23:17 -0800 From: Peter Constable To: LTRU Working Group Date: Thu, 22 Nov 2007 13:23:15 -0800 Subject: RE: [Ltru] Preparing ourselves for IETF Last Call Thread-Topic: [Ltru] Preparing ourselves for IETF Last Call Thread-Index: AcgtQCB95nJC0UUqQSezVp9m+M2XhwADTdxA Message-ID: References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> In-Reply-To: <00b101c82d40$1d438420$6601a8c0@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: 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="===============1161762644==" Errors-To: ltru-bounces@ietf.org --===============1161762644== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQHJvYWRydW5uZXIuY29tXQ0KDQoNCj4g UTogIElzbid0IGl0IGNoZXJyeS1waWNraW5nIHRvIGV4Y2x1ZGUgIlVLIj8NCj4NCj4gQTogIFll cywgYnV0IGluIGEgZ29vZCB3YXkuICAiVUsiIGlzIGEgZHVwbGljYXRlIG9mICJHQiIuDQoNCkkn bGwgc2F5IGl0IHlldCBhZ2FpbjogZXhjbHVkaW5nICJVSyIgaXMgY29uc2lzdGVudCB3aXRoIHNl Y3Rpb24gMy40OyB0byB3aXQ6DQoNCiAgIjguICAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOSwg SVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYgdGhhdCBkbyBub3QNCiAgICAgICAgY29uZmxpY3Qgd2l0 aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5cGUgYW5kIHdob3NlDQogICAg ICAgIG1lYW5pbmcgaXMgKipub3QgdGhlIHNhbWUgYXMgYW4gZXhpc3Rpbmcgc3VidGFnIG9mIHRo ZSBzYW1lIHR5cGUqKg0KICAgICAgICBhcmUgZW50ZXJlZCBpbnRvIHRoZSBJQU5BIHJlZ2lzdHJ5 IGFzIG5ldyByZWNvcmRzLiINCg0KKEVtcGhhc2lzIGFkZGVkLikNCg0KDQoNClBldGVyDQo= --===============1161762644== 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 --===============1161762644==-- From ltru-bounces@ietf.org Thu Nov 22 17:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvKOU-00049E-IE; Thu, 22 Nov 2007 17:19:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IvKOS-00048g-AS for ltru-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 17:19:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvKOS-00048Y-0H for ltru@ietf.org; Thu, 22 Nov 2007 17:19:32 -0500 Received: from ch-smtp01.sth.basefarm.net ([80.76.149.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvKOR-0000hQ-M1 for ltru@ietf.org; Thu, 22 Nov 2007 17:19:31 -0500 Received: from c83-248-81-166.bredband.comhem.se ([83.248.81.166]:4052 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1IvKOQ-0002Vs-44 for ltru@ietf.org; Thu, 22 Nov 2007 23:19:30 +0100 From: "Kent Karlsson" To: "'LTRU Working Group'" References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> Subject: RE: [Ltru] Preparing ourselves for IETF Last Call Date: Thu, 22 Nov 2007 23:19:33 +0100 Message-ID: <001501c82d55$c3160750$a651f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: thread-index: AcgtQCB95nJC0UUqQSezVp9m+M2XhwADTdxAAAHhSSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Originating-IP: 83.248.81.166 X-Scan-Result: No virus found in message 1IvKOQ-0002Vs-44. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1IvKOQ-0002Vs-44 1459ecb7ad157def2896188ec219be85 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I'll say it yet again: excluding "UK" is consistent with > section 3.4; to wit: > > "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not > conflict with existing subtags of the associated type and whose > meaning is **not the same as an existing subtag of the same type** > are entered into the IANA registry as new records." > > (Emphasis added.) It seems that would not preclude including it (UK) as a deprecated subtag with a preferred value (GB). Compare other such subtags, e.g. iw. /kent k > Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 23 13:52: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 1Ivddv-0007Cg-PE; Fri, 23 Nov 2007 13:52:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ivddu-0006zN-DX for ltru-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 13:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivddu-0006zA-3r for ltru@ietf.org; Fri, 23 Nov 2007 13:52:46 -0500 Received: from mta15.adelphia.net ([68.168.78.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivdds-0002U1-JX for ltru@ietf.org; Fri, 23 Nov 2007 13:52:46 -0500 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 <20071123185244.NSPA12282.mta15.adelphia.net@DGBP7M81> for ; Fri, 23 Nov 2007 13:52:44 -0500 Message-ID: <00df01c82e02$07ba6ed0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 23 Nov 2007 10:51:59 -0800 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: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ltru] Re: Preparing ourselves for IETF Last Call X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I'll say it yet again: excluding "UK" is consistent with section 3.4; > to wit: > > "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not > conflict with existing subtags of the associated type and whose > meaning is **not the same as an existing subtag of the same > type** are entered into the IANA registry as new records." Strictly speaking, that's a rule for ongoing maintenance of the LSR to keep up with changes to the ISO standards. If ISO 3166/MA assigned "UK" tomorrow, for example, this rule says the Reviewer would not add it as a subtag. Adding the exceptionally reserved code elements is actually a matter of RFC 4645bis bulk reloading of the Registry, which is not quite the same thing. For example, in RFC 4645 we added (and pre-deprecated) the duplicate language subtags "in" and "iw" and "ji", on the basis that they were part of the 1988 ISO 639 standard referenced by RFCs 1766 and 3066, even though these code elements were withdrawn from ISO 639 well before RFC 1766 was written. Still, if we want to point to Section 3.4, rule 8 as our rationale for not adding "UK" in the bulk update, that's a good thing: it means we are following a rule in RFC 4646, not making up the rules as we go along, which is my concern. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Nov 24 11:54: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 1IvyHH-0007Gz-Ad; Sat, 24 Nov 2007 11:54:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IvyHF-0007Gu-IH for ltru-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 11:54:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyHF-0007Gm-89 for ltru@ietf.org; Sat, 24 Nov 2007 11:54:45 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvyHE-0003dT-Uf for ltru@ietf.org; Sat, 24 Nov 2007 11:54:45 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Sat, 24 Nov 2007 08:54:15 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Sat, 24 Nov 2007 08:54:44 -0800 From: Peter Constable To: LTRU Working Group Date: Sat, 24 Nov 2007 08:54:37 -0800 Subject: RE: [Ltru] Re: Preparing ourselves for IETF Last Call Thread-Topic: [Ltru] Re: Preparing ourselves for IETF Last Call Thread-Index: AcguAgw9VXFHxZqoTNa+fLSaTSTBDAAuCQ0A Message-ID: References: <00df01c82e02$07ba6ed0$6601a8c0@DGBP7M81> In-Reply-To: <00df01c82e02$07ba6ed0$6601a8c0@DGBP7M81> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AzOk A6bb B2rf B+ss DWSz ELx6 EQ30 Egyv Ep1Q E42f E8CM GE5n GWab Gx/L Jn1d JpTm; 1; bAB0AHIAdQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {9A841772-B739-4F9E-8259-36FD21F17BC3}; cABlAHQAZQByAGMAbwBuAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Sat, 24 Nov 2007 16:54:37 GMT; UgBFADoAIABbAEwAdAByAHUAXQAgAFIAZQA6ACAAUAByAGUAcABhAHIAaQBuAGcAIABvAHUAcgBzAGUAbAB2AGUAcwAgAGYAbwByACAASQBFAFQARgAgAEwAYQBzAHQAIABDAGEAbABsAA== x-cr-puzzleid: {9A841772-B739-4F9E-8259-36FD21F17BC3} acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1563386021==" Errors-To: ltru-bounces@ietf.org --===============1563386021== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQHJvYWRydW5uZXIuY29tXQ0KDQo+IEFk ZGluZyB0aGUgZXhjZXB0aW9uYWxseSByZXNlcnZlZCBjb2RlIGVsZW1lbnRzIGlzIGFjdHVhbGx5 IGEgbWF0dGVyIG9mDQo+IFJGQyA0NjQ1YmlzIGJ1bGsgcmVsb2FkaW5nIG9mIHRoZSBSZWdpc3Ry eSwgd2hpY2ggaXMgbm90IHF1aXRlIHRoZSBzYW1lDQo+IHRoaW5nLg0KDQpJIHVuZGVyc3RhbmQg dGhhdCB0aGlzIGlzIG5vdCB0aGUgc2FtZS4gQnV0IHRoZSBwcmluY2lwbGVzIGFkb3B0ZWQgZm9y IGRlYWxpbmcgd2l0aCBjaGFuZ2VzIHRvIHVuZGVybHlpbmcgSVNPIHN0YW5kYXJkcyBhcmUgZHJp dmVuIGJ5IGNvbmRpdGlvbnMgd2Ugd2FudCB0byBob2xkIGluIHRoZSBMU1IsIGFuZCB3ZSB3YW50 IHRob3NlIGNvbmRpdGlvbnMgdG8gaG9sZCBlaXRoZXIgd2hlbiB0aGUgSVNPIHN0YW5kYXJkcyBj aGFuZ2Ugb3Igd2hlbiB3ZSByZS1sb2FkIHRoZSByZWdpc3RyeS4NCg0KDQpQZXRlcg0K --===============1563386021== 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 --===============1563386021==-- From ltru-bounces@ietf.org Sat Nov 24 11:56: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 1IvyIu-0000Iz-7M; Sat, 24 Nov 2007 11:56:28 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IvyIt-0000HL-AV for ltru-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 11:56:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyIs-0000HD-RG for ltru@ietf.org; Sat, 24 Nov 2007 11:56:27 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvyIp-0000J2-H1 for ltru@ietf.org; Sat, 24 Nov 2007 11:56:26 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Sat, 24 Nov 2007 08:55:54 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Sat, 24 Nov 2007 08:56:22 -0800 From: Peter Constable To: 'LTRU Working Group' Date: Sat, 24 Nov 2007 08:56:17 -0800 Subject: RE: [Ltru] Preparing ourselves for IETF Last Call Thread-Topic: [Ltru] Preparing ourselves for IETF Last Call Thread-Index: AcgtQCB95nJC0UUqQSezVp9m+M2XhwADTdxAAAHhSSAAWXc24A== Message-ID: References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.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: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163521542==" Errors-To: ltru-bounces@ietf.org --===============0163521542== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBLZW50IEthcmxzc29uIFttYWlsdG86a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZV0N Cg0KDQo+ID4gSSdsbCBzYXkgaXQgeWV0IGFnYWluOiBleGNsdWRpbmcgIlVLIiBpcyBjb25zaXN0 ZW50IHdpdGgNCj4gPiBzZWN0aW9uIDMuNDsgdG8gd2l0Og0KPiA+DQo+ID4gICAiOC4gICBDb2Rl cyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIGFuZCBJU08gMzE2NiB0aGF0IGRvDQo+ IG5vdA0KPiA+ICAgICAgICAgY29uZmxpY3Qgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRoZSBh c3NvY2lhdGVkIHR5cGUgYW5kDQo+IHdob3NlDQo+ID4gICAgICAgICBtZWFuaW5nIGlzICoqbm90 IHRoZSBzYW1lIGFzIGFuIGV4aXN0aW5nIHN1YnRhZyBvZiB0aGUgc2FtZQ0KPiB0eXBlKioNCj4g PiAgICAgICAgIGFyZSBlbnRlcmVkIGludG8gdGhlIElBTkEgcmVnaXN0cnkgYXMgbmV3IHJlY29y ZHMuIg0KPiA+DQo+ID4gKEVtcGhhc2lzIGFkZGVkLikNCj4NCj4NCj4gSXQgc2VlbXMgdGhhdCB3 b3VsZCBub3QgcHJlY2x1ZGUgaW5jbHVkaW5nIGl0IChVSykgYXMgYSBkZXByZWNhdGVkDQo+IHN1 YnRhZyB3aXRoIGEgcHJlZmVycmVkIHZhbHVlIChHQikuIENvbXBhcmUgb3RoZXIgc3VjaCBzdWJ0 YWdzLCBlLmcuIGl3Lg0KDQpCdXQgaXMgYWxzbyBkb2Vzbid0IHByZWNsdWRlIHVzICpub3QqIGlu Y2x1ZGluZyBpdCwgYW5kIGlzIGluZGljYXRpdmUgb2YgYSBwcmluY2lwbGVkIHJhdGhlciB0aGFu IGFkIGhvYyBiYXNpcyBmb3Igbm90IGluY2x1ZGluZyBpdC4NCg0KDQpQZXRlcg0K --===============0163521542== 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 --===============0163521542==-- From ltru-bounces@ietf.org Mon Nov 26 00:00: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 1IwW4t-0007NL-CB; Mon, 26 Nov 2007 00:00:15 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwW4s-0007NG-NV for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 00:00:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW4r-0007N3-Rr for ltru@ietf.org; Mon, 26 Nov 2007 00:00:13 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwW4m-00020a-G9 for ltru@ietf.org; Mon, 26 Nov 2007 00:00:13 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAQ4xHrn004584 for ; Mon, 26 Nov 2007 13:59:20 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 196b_57573818_9bdc_11dc_9cdb_0014221f2a2d; Mon, 26 Nov 2007 13:59:17 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40022) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2007 12:34:56 +0900 Message-Id: <6.0.0.20.2.20071123155213.090bb270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Nov 2007 15:53:25 +0900 To: "Kent Karlsson" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.com> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think there is a big difference between the 'IW' case, which was changed upstreams, a long time ago, and 'UK', which would be dead on arrival. Regards, Martin. At 07:19 07/11/23, Kent Karlsson wrote: > >Peter Constable wrote: > >> I'll say it yet again: excluding "UK" is consistent with >> section 3.4; to wit: >> >> "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not >> conflict with existing subtags of the associated type and whose >> meaning is **not the same as an existing subtag of the same type** >> are entered into the IANA registry as new records." >> >> (Emphasis added.) > > >It seems that would not preclude including it (UK) as a deprecated >subtag with a preferred value (GB). Compare other such subtags, e.g. iw. > > /kent k > > >> Peter > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 01:47:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXkB-00008j-RG; Mon, 26 Nov 2007 01:46:59 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwXkB-00008e-DN for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 01:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXkB-00008W-1C for ltru@lists.ietf.org; Mon, 26 Nov 2007 01:46:59 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwXk7-0004Mp-DK for ltru@lists.ietf.org; Mon, 26 Nov 2007 01:46:59 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IwXk6-0003CL-1b for ltru@lists.ietf.org; Mon, 26 Nov 2007 06:46:54 +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, 26 Nov 2007 06:46:54 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 06:46:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Mon, 26 Nov 2007 07:43:20 +0100 Lines: 12 Message-ID: References: <00b101c82d40$1d438420$6601a8c0@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Preparing ourselves for IETF Last Call X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: [about Last Call] The draft is in an unacceptable state, not limited to the=20 fantasy islands codes. There are also biannual expert reviewer appointments by the IESG, undefined and=20 unjustified Latin transliterations, generic variants still allowed, dubious registered languages, the extlang situation is unclear, etc. (without actually looking into the draft, likely this enumeraton isn't complete). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 02:01:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXy2-0004uR-Dl; Mon, 26 Nov 2007 02:01:18 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwXy1-0004uM-4K for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 02:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXy0-0004uE-R7 for ltru@lists.ietf.org; Mon, 26 Nov 2007 02:01:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwXxx-0004fk-Cm for ltru@lists.ietf.org; Mon, 26 Nov 2007 02:01:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IwXxv-0005h6-OM for ltru@lists.ietf.org; Mon, 26 Nov 2007 07:01: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 ; Mon, 26 Nov 2007 07:01:11 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Nov 2007 07:01:11 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Mon, 26 Nov 2007 07:57:39 +0100 Lines: 16 Message-ID: References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81><001501c82d55$c3160750$a651f853@streamserve.com> <6.0.0.20.2.20071123155213.090bb270@localhost> 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: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ltru] Re: Preparing ourselves for IETF Last Call X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > I think there is a big difference between the 'IW' case, > which was changed upstreams, a long time ago, and 'UK', > which would be dead on arrival. Quite the contrary, UK is the only addition that would remotely make sense, folks confuse it anyway with GB due to the ccTLD and POSIX locale, Marion really wanted it. The other wannabe-additions are DOA, some are dangerous, e.g. DG, EA, and IC. And EU is incompatible with any=20 sense of stability, apart from being useless for language tagging. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 04:15: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 1Iwa3k-000523-Fl; Mon, 26 Nov 2007 04:15:20 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iwa3j-00051w-5m for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 04:15:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwa3i-00051a-Rv for ltru@ietf.org; Mon, 26 Nov 2007 04:15:18 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwa3g-00032M-9N for ltru@ietf.org; Mon, 26 Nov 2007 04:15:16 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAQ9Egqs005210 for ; Mon, 26 Nov 2007 18:14:45 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0330_12af02b6_9bd9_11dc_8573_0014221f2a2d; Mon, 26 Nov 2007 13:35:53 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40022) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2007 12:34:56 +0900 Message-Id: <6.0.0.20.2.20071123155213.090bb270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Nov 2007 15:53:25 +0900 To: "Kent Karlsson" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.com> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think there is a big difference between the 'IW' case, which was changed upstreams, a long time ago, and 'UK', which would be dead on arrival. Regards, Martin. At 07:19 07/11/23, Kent Karlsson wrote: > >Peter Constable wrote: > >> I'll say it yet again: excluding "UK" is consistent with >> section 3.4; to wit: >> >> "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not >> conflict with existing subtags of the associated type and whose >> meaning is **not the same as an existing subtag of the same type** >> are entered into the IANA registry as new records." >> >> (Emphasis added.) > > >It seems that would not preclude including it (UK) as a deprecated >subtag with a preferred value (GB). Compare other such subtags, e.g. iw. > > /kent k > > >> Peter > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 06:59: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 1Iwccd-0008OU-Or; Mon, 26 Nov 2007 06:59:31 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iwccc-0008OJ-La for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 06:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwccc-0008OB-Bn for ltru@ietf.org; Mon, 26 Nov 2007 06:59:30 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwccT-0003na-QR for ltru@ietf.org; Mon, 26 Nov 2007 06:59:30 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAQBxDEc017057 for ; Mon, 26 Nov 2007 20:59:13 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7551_7f8f400a_9bd7_11dc_9f22_0014221f2a2d; Mon, 26 Nov 2007 13:24:37 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40022) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2007 12:34:56 +0900 Message-Id: <6.0.0.20.2.20071123155213.090bb270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Nov 2007 15:53:25 +0900 To: "Kent Karlsson" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.com> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think there is a big difference between the 'IW' case, which was changed upstreams, a long time ago, and 'UK', which would be dead on arrival. Regards, Martin. At 07:19 07/11/23, Kent Karlsson wrote: > >Peter Constable wrote: > >> I'll say it yet again: excluding "UK" is consistent with >> section 3.4; to wit: >> >> "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not >> conflict with existing subtags of the associated type and whose >> meaning is **not the same as an existing subtag of the same type** >> are entered into the IANA registry as new records." >> >> (Emphasis added.) > > >It seems that would not preclude including it (UK) as a deprecated >subtag with a preferred value (GB). Compare other such subtags, e.g. iw. > > /kent k > > >> Peter > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 11:47: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 1Iwh7a-00014g-DP; Mon, 26 Nov 2007 11:47:46 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iwh7Z-00014a-A1 for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:47:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwh7Z-00014R-0G for ltru@ietf.org; Mon, 26 Nov 2007 11:47:45 -0500 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwh7R-00039E-Dk for ltru@ietf.org; Mon, 26 Nov 2007 11:47:44 -0500 Received: by nz-out-0506.google.com with SMTP id n1so385631nzf for ; Mon, 26 Nov 2007 08:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=go5mOw4TzBbp56lXVB+IYoO3sFcYc6uqzKEZ7yZBcRs=; b=A4Sio7I86xWHajq9Uvm7VLhrlsQGSWj1LrjGzlCpNhz8N2wYpaXz6q7CF/8l+tNAWoD0iNNmQqHLLUfStdOEuRHpd8tL78/gRzSez2+d1o18Dr/PVPzX6pO7y2Yc7MQFiExDt6I/vb7p83b+v9RdBQo3GB/tuj5MOvXHag2ypCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=TEytaPN6L51LFRiPkZeihwZVwqA6GHL5iz04DENaWhELKpC3dNEjV2rOWz1nEkm9nD29j4QF2/MB1izZ5OxlCECHoZC94TDF6k3S9heJC++WgNgVBDAZC3UW+zqfOOi3tLQau44ABu2MgQQg4wdsizUr1qQ2bki8I7fYp7xI1kw= Received: by 10.114.81.1 with SMTP id e1mr782466wab.1196095655606; Mon, 26 Nov 2007 08:47:35 -0800 (PST) Received: by 10.114.198.8 with HTTP; Mon, 26 Nov 2007 08:47:35 -0800 (PST) Message-ID: <30b660a20711260847k382d93f6g44a1c8c55c213c7f@mail.gmail.com> Date: Mon, 26 Nov 2007 08:47:35 -0800 From: "Mark Davis" To: "Stephane Bortzmeyer" MIME-Version: 1.0 X-Google-Sender-Auth: df10e9912a9f2f96 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: LTRU Working Group Subject: [Ltru] Issue on usability of extlang (was Re: Fragmentary notes from telecon) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============2100136103==" Errors-To: ltru-bounces@ietf.org --===============2100136103== Content-Type: multipart/alternative; boundary="----=_Part_16354_18061042.1196095655595" ------=_Part_16354_18061042.1196095655595 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline No problem with copying it. By the way, Martin raise an issue during the discussion which I didn't have time to address. Q. Why not have extlang for using macrolanguages if the suggested text in http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s adds macrolanguages back into the fallback chain? (These are not Martin's words, but it was roughly that.) A. The suggested text doesn't add it back in. It only says that *IF *an application wants to do extlang-equivalent fallback, the text in BCP 47 already allows for that. We really have no idea whether using macro languages in the fallback chain is a good idea or not. Some people think it will be an advantage for a few specific examples that are cited. (Cantonese comes up, but when I tested some of the assumptions with Cantonese speakers, they didn't quite hold up.) But nobody has substantiated that it will give better results for all or most macrolanguages. Or any indication of an even rough list of those for which it will be better. Nor has anyone effectively argued that the situation between yue and zh is substantially different than the situation between gsw and de, where we get along just fine without extlang. So the suggested text just provides it as an option, and leaves it up to the application. In particular, extlang plays especially badly in many cases. Suppose that we have macrolanguage m1, and microlanguages x1 and x2. By the design of 639, we can't assume that a speaker of x1 can also speaker x2 or vice versa. If a user has as accept language the list , it works fine without extlang: she gets the fallback (A) 1. x1-Ssss-Rr 2. x1-Ssss 3. x1 4. en 5. fr If she also speaks/reads x2, then she can specify or ; that is, putting x2 in the list in the position she wants it. If x2 is the predominant microlanguage, meaning that m1 is essentially always assumed to be x2, then the priority list can be , also wherever it belongs. Thus, the user gets something she can understand, based on the list she supplied. If we are using extlang, and x2 is the content for m1, then we get the fallback (B) 1. m1-x1-Ssss-Rr 2. m1-x1-Ssss 3. m1-x1 4. m1 5. en 6. fr That has two problems: first, the script and region are lost. That can be fixed by hacking the fallback (although there is a *lot *of installed base that won't do this), to (C) 1. m1-x1-Ssss-Rr 2. m1-x1-Ssss 3. m1-x1 4. m1-Ssss-Rr 5. m1-Ssss 6. m1 7. en 8. fr But even more importantly, we are disabling the user's explicit choice. If the user doesn't speak x2 (or whatever the content of m1 is), he's screwed. There is no way that he can indicate that he wants x1 *but no other version of m1 because he can't understand them. *We'd have to change the fallback to be quite substantially different to get around this, with (D)* * 1. m1-x1-Ssss-Rr 2. m1-x1-Ssss 3. m1-x1 4. en 5. fr 6. m1-Ssss-Rr 7. m1-Ssss 8. m1 This is, however, still only appropriate if it is likely that a user of x1 speaks *whatever happens to be the content for m1*. That is an extremely shaky assumption. If Peter Constable said, for each and every macrolanguage on http://www.sil.org/iso639-3/macrolanguages.asp, there is at least one microlanguage that all speakers (or even most speakers) of each of the other microlanguages would understand, I'd say: fine, let's do extlang and incorporate that information into the registry, with the "default microlanguage" for each macrolanguage. Then, for example, implementers would know that, say "fuf Pular" is understood by all the speakers of the microlanguages under "ful Fulah", so we can tell people to always have the content of "ful" be "fuf", and bake the macrolanguages in as extlang. The point of the suggested text is that if your application wants to use macrolanguages to support extlang-equivalent fallback, there is nothing stopping you from doing so. If there are particular environments where an extlang-like fallback is right for a particular language community, it is simple to do. But we don't need to bake shaky assumptions into the structure of language tags. ------------------------------ And here is the suggested text from http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s, just so there is a record for the IETF. LTRU text Latest draft of 4646: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-09.html Latest draft of 4647: *http://www.rfc-editor.org/rfc/bcp/bcp47.txt* ------------------------------ [Here are additions proposed for rfc4647bis, to account for macrolanguages without extlang. ] *Add to end of 3.4.1 (**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 have been, and may still be tagged with "de". 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. In this way, the lookup process may take into account what languages people are likely to understand, given a language priority list. Similarly, the close relations between Romanian and Moldavian, Tagalog and Filipino, Serbo-Croatian and Croatian, and so on may all be useful in doing related language lookup. This is not restricted to related languages. 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 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 there is logically 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. On Nov 22, 2007 6:01 AM, Stephane Bortzmeyer wrote: > On Wed, Nov 21, 2007 at 03:10:28PM -0800, > Mark Davis wrote > a message of 38 lines which said: > > > http://docs.google.com/Doc?id=dfqr8rd5_43dnw36c > > IMHO, the IETF rules for mailing lists do not mix well with "outside" > documents, which may not be available in the future, when someone will > read the archive. So, I take the liberty to copy it here: > > > > LTRU Telecon Notes > Felix, Randy, Martin, John, Addison, Mark > > Fragmentary notes (see end) > > Mark: > We could look over the suggested changes in > http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s to see how this would > be/change depending on the choices we make. > > Addison: > Mostly in agreement about difficulties with macrolanguages. > Disagreement: > extlang is a useful mechanism, gives better results > extlang is not a useful mechanism, gives worse results > > (Someone): Conflation of macrolanguage and majority language is a mistake. > > John: with extlang, should deviate from truncate from right in lookup > > Mark: sole reason for extlang is for not changing the algorithm > > Others: reason is to avoid need to look at registry > > Mark: doesn't matter -- no big deal to look at registry. Not proposing > that it be required, just optional. And practically, software can update > every so often to get the cases it cares about. Not a lot of data. Even for > limited-memory environments, like cellphones, can > > Addision: people would be recommended to use the languages they can > handle: eg zh, yue > > John: have registered tags encoded with extlang style > > Mark: those are not productive in tags > > Addision: those were in good faith, but can deprecate and remap; have done > in other cases. > > Addision: lookup with extlang would look like: > > zh-yue-Hant-TW > zh-yue-Hant > zh-yue > zh-hant-tw > zh-hant > zh > (default) > > ... > (many interesting points made, but was too involved in the conversation to > keep up with the notes) > ... > > Martin: Why not have extlang (question about google) > > Mark: Concerned with more than just Google: impacts Unicode (CLDR), ICU, > Java, ... Concern is that better results overall are returned if we don't > have extlang; we're inventing a mechanism and complications that we don't > need. Example, zh/yue -- we got along without extlang for the analogous case > of de/gsw. ... (Q about filtering). For filtering, in other cases, we > specify the languages we want; if I want de and gsw, I list them. Similar > for yue and zh. > ... > > At the end. > > * Will have weekly meeting. > * We talked about assigning a scribe, or having people note what they > just said -- either way, set up something before we start next time. > * Addison will set up a collaboration tool for next time, and notify us > ahead of time. > > > > > > > > > > Google Docs -- Web word processing, presentations and spreadsheets. > -- Mark ------=_Part_16354_18061042.1196095655595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline No problem with copying it.

By the way, Martin raise an issue during the discussion which I didn't have time to address.

Q. Why not have extlang for using macrolanguages if the suggested text in http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s adds macrolanguages back into the fallback chain? (These are not Martin's words, but it was roughly that.)

A. The suggested text doesn't add it back in. It only says that IF an application wants to do extlang-equivalent fallback, the text in BCP 47 already allows for that.

We really have no idea whether using macro languages in the fallback chain is a good idea or not. Some people think it will be an advantage for a few specific examples that are cited. (Cantonese comes up, but when I tested some of the assumptions with Cantonese speakers, they didn't quite hold up.) But nobody has substantiated that it will give better results for all or most macrolanguages. Or any indication of an even rough list of those for which it will be better. Nor has anyone effectively argued that the situation between yue and zh is substantially different than the situation between gsw and de, where we get along just fine without extlang.

So the suggested text just provides it as an option, and leaves it up to the application.

In particular, extlang plays especially badly in many cases. Suppose that we have macrolanguage m1, and microlanguages x1 and x2. By the design of 639, we can't assume that a speaker of x1 can also speaker x2 or vice versa. If a user has as accept language the list <x1-Ssss-Rr, en, fr>, it works fine without extlang: she gets the fallback (A)
  1. x1-Ssss-Rr
  2. x1-Ssss
  3. x1
  4. en
  5. fr
If she also speaks/reads x2, then she can specify <x1-Ssss-Rr, x2, en, fr> or <x1-Ssss-Rr, en, fr, x2>; that is, putting x2 in the list in the position she wants it. If x2 is the predominant microlanguage, meaning that m1 is essentially always assumed to be x2, then the priority list can be <x1-Ssss-Rr, en, fr, m1>, also wherever it belongs. Thus, the user gets something she can understand, based on the list she supplied.

If we are using extlang, and x2 is the content for m1, then we get the fallback (B)
  1. m1-x1-Ssss-Rr
  2. m1-x1-Ssss
  3. m1-x1
  4. m1
  5. en
  6. fr
That has two problems: first, the script and region are lost. That can be fixed by hacking the fallback (although there is a lot of installed base that won't do this), to (C)
  1. m1-x1-Ssss-Rr
  2. m1-x1-Ssss
  3. m1-x1
  4. m1-Ssss-Rr
  5. m1-Ssss
  6. m1
  7. en
  8. fr
But even more importantly, we are disabling the user's explicit choice. If the user doesn't speak x2 (or whatever the content of m1 is), he's screwed. There is no way that he can indicate that he wants x1 but no other version of m1 because he can't understand them.
We'd have to change the fallback to be quite substantially different to get around this, with (D)
  1. m1-x1-Ssss-Rr
  2. m1-x1-Ssss
  3. m1-x1
  4. en
  5. fr
  6. m1-Ssss-Rr
  7. m1-Ssss
  8. m1
This is, however, still only appropriate if it is likely that a user of x1 speaks whatever happens to be the content for m1. That is an extremely shaky assumption.

If Peter Constable said, for each and every macrolanguage on http://www.sil.org/iso639-3/macrolanguages.asp, there is at least one microlanguage that all speakers (or even most speakers) of each of the other microlanguages would understand, I'd say: fine, let's do extlang and incorporate that information into the registry, with the "default microlanguage" for each macrolanguage. Then, for example, implementers would know that, say " fuf Pular" is understood by all the speakers of the microlanguages under "ful Fulah", so we can tell people to always have the content of "ful" be "fuf", and bake the macrolanguages in as extlang.

The point of the suggested text is that if your application wants to use macrolanguages to support extlang-equivalent fallback, there is nothing stopping you from doing so. If there are particular environments where an extlang-like fallback is right for a particular language community, it is simple to do. But we don't need to bake shaky assumptions into the structure of language tags.



And here is the suggested text from http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s, just so there is a record for the IETF.

LTRU text

Latest draft of 4646: http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-09.html
Latest draft of 4647: http://www.rfc-editor.org/rfc/bcp/bcp47.txt

[Here are additions proposed for rfc4647bis, to account for macrolanguages without extlang. ]

Add to end of 3.4.1 (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 have been, and may still be tagged with "de". 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.

In this way, the lookup process may take into account what languages people are likely to understand, given a language priority list. Similarly, the close relations between Romanian and Moldavian, Tagalog and Filipino, Serbo-Croatian and Croatian, and so on may all be useful in doing related language lookup.

This is not restricted to related languages. 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


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 there is logically 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.



On Nov 22, 2007 6:01 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Wed, Nov 21, 2007 at 03:10:28PM -0800,
 Mark Davis <mark.davis@icu-project.org> wrote
 a message of 38 lines which said:

> http://docs.google.com/Doc?id=dfqr8rd5_43dnw36c

IMHO, the IETF rules for mailing lists do not mix well with "outside"
documents, which may not be available in the future, when someone will
read the archive. So, I take the liberty to copy it here:



LTRU Telecon Notes
Felix, Randy, Martin, John, Addison, Mark

Fragmentary notes (see end)

Mark:
We could look over the suggested changes in http://docs.google.com/Doc?id=dfqr8rd5_42gzc36s to see how this would be/change depending on the choices we make.

Addison:
Mostly in agreement about difficulties with macrolanguages.
Disagreement:
 extlang is a useful mechanism, gives better results
 extlang is not a useful mechanism, gives worse results

(Someone): Conflation of macrolanguage and majority language is a mistake.

John: with extlang, should deviate from truncate from right in lookup

Mark: sole reason for extlang is for not changing the algorithm

Others: reason is to avoid need to look at registry

Mark: doesn't matter -- no big deal to look at registry. Not proposing that it be required, just optional. And practically, software can update every so often to get the cases it cares about. Not a lot of data. Even for limited-memory environments, like cellphones, can

Addision: people would be recommended to use the languages they can handle: eg zh, yue

John: have registered tags encoded with extlang style

Mark: those are not productive in tags

Addision: those were in good faith, but can deprecate and remap; have done in other cases.

Addision: lookup with extlang would look like:

zh-yue-Hant-TW
zh-yue-Hant
zh-yue
zh-hant-tw
zh-hant
zh
(default)

...
(many interesting points made, but was too involved in the conversation to keep up with the notes)
...

Martin: Why not have extlang (question about google)

Mark: Concerned with more than just Google: impacts Unicode (CLDR), ICU, Java, ... Concern is that better results overall are returned if we don't have extlang; we're inventing a mechanism and complications that we don't need. Example, zh/yue -- we got along without extlang for the analogous case of de/gsw. ... (Q about filtering). For filtering, in other cases, we specify the languages we want; if I want de and gsw, I list them. Similar for yue and zh.
...

At the end.

   * Will have weekly meeting.
   * We talked about assigning a scribe, or having people note what they just said -- either way, set up something before we start next time.
   * Addison will set up a collaboration tool for next time, and notify us ahead of time.









Google Docs -- Web word processing, presentations and spreadsheets.



--
Mark ------=_Part_16354_18061042.1196095655595-- --===============2100136103== 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 --===============2100136103==-- From ltru-bounces@ietf.org Mon Nov 26 17:09: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 1Iwm9H-0004Bk-Ud; Mon, 26 Nov 2007 17:09:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iwm9G-0004Bc-Q0 for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwm9G-0004BP-Fx for ltru@ietf.org; Mon, 26 Nov 2007 17:09:50 -0500 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwm9E-00037V-4p for ltru@ietf.org; Mon, 26 Nov 2007 17:09:50 -0500 Received: by nz-out-0506.google.com with SMTP id n1so498249nzf for ; Mon, 26 Nov 2007 14:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=yI0q4Mlu2Lh4Bjlnp/IgoeYQ0Wsi1D9i4YcJa7kovn4=; b=o2+hzV8L1CHsYZxqN6tOmGAmvXi2L3oi/oIlAMuEhKRnJrlIOha4otT3KjZ90f5+1tCfXlYd8ecKVV4BA5+XoDYliWfFDHDYRHfPoUGjEnaa9j+A1ZO0oHoQPNdhT3t2XjM4qddzCvX33Fks4mAg8qHFaeMBKQCTYdaAWmF2luA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=Q9skEsQrpfuuvwI3Vylit1bCZn6pc38gHhSaaSQ0i65PF7+wOl6BLfHhRpWJnpOOQ8JHhRp/YG7ExzOa9wmAUEiH0LmbhjLx1Oz0JHIZaK7boZJxruHQaPG7ZJUGTG3OLqzC/ZIRRmJ23dUALdVrRcpB+IOBdKP2j99mx103Y1w= Received: by 10.114.111.1 with SMTP id j1mr43110wac.1196114987281; Mon, 26 Nov 2007 14:09:47 -0800 (PST) Received: by 10.114.198.8 with HTTP; Mon, 26 Nov 2007 14:09:47 -0800 (PST) Message-ID: <30b660a20711261409k37e82a2bq19790a73f60a412b@mail.gmail.com> Date: Mon, 26 Nov 2007 14:09:47 -0800 From: "Mark Davis" To: "Doug Ewell" MIME-Version: 1.0 X-Google-Sender-Auth: e122597fcd1195a9 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: LTRU Working Group Subject: [Ltru] New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1559774112==" Errors-To: ltru-bounces@ietf.org --===============1559774112== Content-Type: multipart/alternative; boundary="----=_Part_17940_5027713.1196114987270" ------=_Part_17940_5027713.1196114987270 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have new scripts on http://www.unicode.org/iso15924/codechanges.html. Can you prepare the forms for IANA? -- Mark ------=_Part_17940_5027713.1196114987270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have new scripts on http://www.unicode.org/iso15924/codechanges.html. Can you prepare the forms for IANA?

--
Mark ------=_Part_17940_5027713.1196114987270-- --===============1559774112== 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 --===============1559774112==-- From ltru-bounces@ietf.org Mon Nov 26 17:57: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 1IwmtL-000623-20; Mon, 26 Nov 2007 17:57:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwmtK-00061c-LY for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:57:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmtK-00061E-Bs for ltru@ietf.org; Mon, 26 Nov 2007 17:57:26 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwmtE-0004CN-OP for ltru@ietf.org; Mon, 26 Nov 2007 17:57:26 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAQ3mBDk000300 for ; Mon, 26 Nov 2007 12:48:12 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4f35_417e0648_9bd2_11dc_8ed8_0014221f2a2d; Mon, 26 Nov 2007 12:47:05 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40022) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2007 12:34:56 +0900 Message-Id: <6.0.0.20.2.20071123155213.090bb270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Nov 2007 15:53:25 +0900 To: "Kent Karlsson" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.com> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think there is a big difference between the 'IW' case, which was changed upstreams, a long time ago, and 'UK', which would be dead on arrival. Regards, Martin. At 07:19 07/11/23, Kent Karlsson wrote: > >Peter Constable wrote: > >> I'll say it yet again: excluding "UK" is consistent with >> section 3.4; to wit: >> >> "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not >> conflict with existing subtags of the associated type and whose >> meaning is **not the same as an existing subtag of the same type** >> are entered into the IANA registry as new records." >> >> (Emphasis added.) > > >It seems that would not preclude including it (UK) as a deprecated >subtag with a preferred value (GB). Compare other such subtags, e.g. iw. > > /kent k > > >> Peter > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 17:57: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 1IwmtS-000644-9r; Mon, 26 Nov 2007 17:57:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwmtQ-00063o-Kt for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:57:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmtQ-00063g-BR for ltru@ietf.org; Mon, 26 Nov 2007 17:57:32 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwmtM-0004CN-GZ for ltru@ietf.org; Mon, 26 Nov 2007 17:57:32 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id lAQ3dMWj028969 for ; Mon, 26 Nov 2007 12:39:23 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 47c5_1a2a2820_9bd1_11dc_8dd4_0014221f2a2d; Mon, 26 Nov 2007 12:38:50 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40022) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2007 12:34:56 +0900 Message-Id: <6.0.0.20.2.20071123155213.090bb270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Nov 2007 15:53:25 +0900 To: "Kent Karlsson" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.com> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think there is a big difference between the 'IW' case, which was changed upstreams, a long time ago, and 'UK', which would be dead on arrival. Regards, Martin. At 07:19 07/11/23, Kent Karlsson wrote: > >Peter Constable wrote: > >> I'll say it yet again: excluding "UK" is consistent with >> section 3.4; to wit: >> >> "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not >> conflict with existing subtags of the associated type and whose >> meaning is **not the same as an existing subtag of the same type** >> are entered into the IANA registry as new records." >> >> (Emphasis added.) > > >It seems that would not preclude including it (UK) as a deprecated >subtag with a preferred value (GB). Compare other such subtags, e.g. iw. > > /kent k > > >> Peter > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 19:25: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 1IwoGi-0004Z7-GC; Mon, 26 Nov 2007 19:25:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwoGg-0004Z1-GH for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:25:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwoGg-0004Yt-64 for ltru@ietf.org; Mon, 26 Nov 2007 19:25:38 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwoGf-00016s-Gj for ltru@ietf.org; Mon, 26 Nov 2007 19:25:38 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAQ4EfGB027993 for ; Mon, 26 Nov 2007 13:16:32 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6c46_14d5a37c_9bd6_11dc_84c2_0014221f2a2d; Mon, 26 Nov 2007 13:14:28 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40022) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Nov 2007 12:34:56 +0900 Message-Id: <6.0.0.20.2.20071123155213.090bb270@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 23 Nov 2007 15:53:25 +0900 To: "Kent Karlsson" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <001501c82d55$c3160750$a651f853@streamserve.com> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <001501c82d55$c3160750$a651f853@streamserve.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a technical contributor, I think there is a big difference between the 'IW' case, which was changed upstreams, a long time ago, and 'UK', which would be dead on arrival. Regards, Martin. At 07:19 07/11/23, Kent Karlsson wrote: > >Peter Constable wrote: > >> I'll say it yet again: excluding "UK" is consistent with >> section 3.4; to wit: >> >> "8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not >> conflict with existing subtags of the associated type and whose >> meaning is **not the same as an existing subtag of the same type** >> are entered into the IANA registry as new records." >> >> (Emphasis added.) > > >It seems that would not preclude including it (UK) as a deprecated >subtag with a preferred value (GB). Compare other such subtags, e.g. iw. > > /kent k > > >> Peter > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Nov 26 23:50: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 1IwsOY-0000d4-0k; Mon, 26 Nov 2007 23:50:02 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwsOX-0000cy-Cc for ltru-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 23:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwsOX-0000cf-1z for ltru@ietf.org; Mon, 26 Nov 2007 23:50:01 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwsOV-0008JF-Ik for ltru@ietf.org; Mon, 26 Nov 2007 23:50:01 -0500 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 <20071127044959.LTTW15173.mta9.adelphia.net@DGBP7M81>; Mon, 26 Nov 2007 23:49:59 -0500 Message-ID: <000e01c830b0$f66c01f0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , References: <30b660a20711261409k37e82a2bq19790a73f60a412b@mail.gmail.com> Date: Mon, 26 Nov 2007 20:49:57 -0800 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: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 have new scripts on > http://www.unicode.org/iso15924/codechanges.html. Can you prepare the > forms for IANA? I'll send them to ietf-languages, which is where this maintenance request actually belongs. They'll have to sit there for a week before being sent to IANA. BTW, I wonder how many people would have predicted, years ago when the basic rules for script subtags were formulated, that ISO 15924 would eventually add code elements for "Mathematical notation" and "Symbols." Section 3.4 says they must be added to the Registry, no cherry-picking allowed, and that seems fine in principle, but these two are at least as irrelevant to tagging of natural-language text as are the region subtags 'AQ' and 'BV', or the language subtags 'mis' and 'und'. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Tue Nov 27 00:18: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 1IwspX-0007nN-Rn; Tue, 27 Nov 2007 00:17:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwspW-0007mx-1M for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 00:17:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwspV-0007mn-NY for ltru@ietf.org; Tue, 27 Nov 2007 00:17:53 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwspV-0005Nd-7n for ltru@ietf.org; Tue, 27 Nov 2007 00:17:53 -0500 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 <20071127051752.QOJD20513.mta11.adelphia.net@DGBP7M81> for ; Tue, 27 Nov 2007 00:17:52 -0500 Message-ID: <004b01c830b4$dc2f6800$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 26 Nov 2007 21:17:51 -0800 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: 4adaf050708fb13be3316a9eee889caa Subject: [Ltru] New subtags from exceptionally reserved 3166 codes (was) Re: The "QU" territory/region code) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org For your reference, assuming that the change in draft-4646bis-09 goes through and we open the door to exceptionally reserved ISO 3166 code elements, here are the new region subtags that would be added to the Registry. Type: region Subtag: AC Description: Ascension Island Added: 2029-09-09 %% Type: region Subtag: CP Description: Clipperton Island Added: 2029-09-09 %% Type: region Subtag: DG Description: Diego Garcia Added: 2029-09-09 %% Type: region Subtag: EA Description: Ceuta, Melilla Added: 2029-09-09 %% Type: region Subtag: EU Description: European Union Added: 2029-09-09 %% Type: region Subtag: IC Description: Canary Islands Added: 2029-09-09 %% Type: region Subtag: TA Description: Tristan da Cunha Added: 2029-09-09 -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Tue Nov 27 01:17: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 1Iwtl9-00020g-Uh; Tue, 27 Nov 2007 01:17:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iwtl8-00020K-9d for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 01:17:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwtl7-0001zX-Sp for ltru@ietf.org; Tue, 27 Nov 2007 01:17:25 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwtl5-0007NT-FA for ltru@ietf.org; Tue, 27 Nov 2007 01:17:25 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAR6HBF6008378 for ; Tue, 27 Nov 2007 15:17:11 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 7c53_6381478a_9cb0_11dc_83ef_0014221f2a2d; Tue, 27 Nov 2007 15:17:11 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46846) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Nov 2007 15:13:16 +0900 Message-Id: <6.0.0.20.2.20071123155640.090bbb90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 27 Nov 2007 15:11:30 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Preparing ourselves for IETF Last Call In-Reply-To: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Doug, [chair hat on] The style of your question-and-answer list below may suggest, at least to some that you don't agree with adding EU and 'friends'. If you indeed do, please say so clearly. As a technical contributor, I'm completely fine with adding 'EU' and friends, it makes sure we don't need another update to our work in the case 'EU' is really needed. As a chair, I also think that this change is within our current charter, unless that charter is read extremely narrowly. However, as a chair, I also want to make sure that we actually have (rough) consensus on the things we do to our drafts. So if you (or anybody else) disagrees with the change that adds 'EU' and friends, please say so clearly. (Note: This is about what we as a WG think is the right thing to do. If we as a WG, after discussing the issues, have reached a (rough) consensus, then I don't think bringing up an issue again at IETF last call will affect our drafts too much. Regards, Martin. At 04:44 07/11/23, Doug Ewell wrote: >(Apologies in advance if this message serves as troll food, but I believe it's important in conducting and focusing the business of this WG.) > >Assuming that we can come to a decision on how to support extlangs-- or more likely, how to modify 4647 *instead of* supporting extlangs -- we will eventually find ourselves submitting two (or three) new drafts for IETF Last Call. > >IETF Last Call isn't just a formality, as many LTRU members know. There are lots of people in the IETF, not only the Gen-ART reviewer but others, who will likely take a look at our charter and at our deliverables, and who may ask some tough questions when those two don't seem to match. > >The change to Section 2.2.4 to add seven ISO 3166 exceptionally reserved code elements to the Registry ("FX" is already there) may be one of those issues that raises eyebrows. Adding more region subtags is not mentioned anywhere in our charter, and people may wonder how this change got there, especially with such rapidity (eight days from mention of "QU" by Philippe Verdy on the Unicode list to submission of draft-09 allowing "EU" and others). I think we may want to prepare ourselves for the type of questioning we are likely to see from the IETF during Last Call: > > >Q: Why the change to add exceptionally reserved country codes? > >A: We wanted to permit access within language tags to regions that > have no officially assigned ISO 3166 code element. > >Q: Many of these are small, sparsely inhabited islands or areas that > don't show a distinct linguistic identity. What's the motivation > for adding them? > >A: OK, we really just wanted to add "EU" for "European Union," and > adding the others prevents us from being accused of cherry-picking. > We didn't want to claim to know the needs of tagging applications > better than the users of those applications. > >Q: Isn't it cherry-picking to exclude "UK"? > >A: Yes, but in a good way. "UK" is a duplicate of "GB". > >Q: Some rogue tagging applications currently use "UK" instead of "GB". > Do you know those applications' needs better than their users? > >A: Yes; that's not "best current practice" in the way that "EU" would > be. > >Q. What distinct language variety is associated with the EU to justify > this change to the BCP? > >A: Possible official bureaucratic terminology promulgated by EU > leadership; other as-yet unknown language variations. > >Q: Does BCP 47 normally represent bureaucratic terminology or unknown > variations by adding region subtags? > >A: No, but the EU is different. > >Q: Don't the existing numeric region subtags for Europe, Western > Europe, etc. adequately cover European language usage, without the > inherent tag instability caused by changes to EU membership? > >A: OK, this isn't just about language tagging after all. We really > want the LSR to be not only the source of language tags, but *the* > reference for stabilized, maintainable codes for languages, > scripts, and regions. > >Q: I thought that's what the ISO standards were for. > >A: We're more stable and traceable than they are. > >Q: That's a non-trivial change of scope. Is this in the LTRU's > charter? > >A: The charter does say that the WG can "make adjustments to the > registration process and the form of the registry if this is deemed > appropriate based on ongoing registration and operational > experience." Operational experience shows that projects like CLDR, > ICU, Java, etc. already use the LSR as their reference instead of > ISO standards. > >Q: How are you guys doing on adding support for ISO 639-3 code > elements? That was the main purpose for rechartering the WG. The > charter page says you were going to be ready with IETF LC drafts > back in January 2007, assuming that ISO 639-3 was approved. > >A: We still don't have that worked out yet. > > >-- >Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 >http://home.roadrunner.com/~dewell >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages $B".(B > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 02:14: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 1IwueP-00015K-Sl; Tue, 27 Nov 2007 02:14:33 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwueN-00014i-FC for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 02:14:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwueN-000148-35 for ltru@ietf.org; Tue, 27 Nov 2007 02:14:31 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwueK-0006N8-Bk for ltru@ietf.org; Tue, 27 Nov 2007 02:14:28 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAR7EHMn020224 for ; Tue, 27 Nov 2007 16:14:18 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 43ca_5d752386_9cb8_11dc_85ff_0014221fa3c9; Tue, 27 Nov 2007 16:14:16 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56099) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Nov 2007 16:10:22 +0900 Message-Id: <6.0.0.20.2.20071127152507.0ac35d70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 27 Nov 2007 15:26:41 +0900 To: "Doug Ewell" , "LTRU Working Group" , From: Martin Duerst Subject: Re: [Ltru] Re: New scripts In-Reply-To: <000e01c830b0$f66c01f0$6601a8c0@DGBP7M81> References: <30b660a20711261409k37e82a2bq19790a73f60a412b@mail.gmail.com> <000e01c830b0$f66c01f0$6601a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 13:49 07/11/27, Doug Ewell wrote: >Mark Davis wrote: > >> We have new scripts on http://www.unicode.org/iso15924/codechanges.html. Can you prepare the forms for IANA? > >I'll send them to ietf-languages, which is where this maintenance request actually belongs. They'll have to sit there for a week before being sent to IANA. > >BTW, I wonder how many people would have predicted, years ago when the basic rules for script subtags were formulated, that ISO 15924 would eventually add code elements for "Mathematical notation" and "Symbols." Section 3.4 says they must be added to the Registry, no cherry-picking allowed, and that seems fine in principle, but these two are at least as irrelevant to tagging of natural-language text as are the region subtags 'AQ' and 'BV', or the language subtags 'mis' and 'und'. Well, there are a lot of people, especially here in Japan, using little symbols or images in their emails/sms. If you want to tag these, a script subtag for symbols may come in handy :-). Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 02:14: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 1IwueZ-00018E-Fd; Tue, 27 Nov 2007 02:14:43 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwueX-000184-Sx for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 02:14:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwueX-00017v-JU for ltru@ietf.org; Tue, 27 Nov 2007 02:14:41 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwueR-0003lA-EX for ltru@ietf.org; Tue, 27 Nov 2007 02:14:41 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lAR7EHXQ020226 for ; Tue, 27 Nov 2007 16:14:17 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4405_5dd72ad6_9cb8_11dc_9d1a_0014221fa3c9; Tue, 27 Nov 2007 16:14:17 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:56099) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Nov 2007 16:10:23 +0900 Message-Id: <6.0.0.20.2.20071127152654.0ac33b00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 27 Nov 2007 15:29:44 +0900 To: LTRU Working Group From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ltru] Teleconference 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 Dear LTRU members, We will have a teleconference again this week to try to make some more progress on extlangs. The times will be as follows: 14:00 Pacific (Wednesday, Nov. 28) 22:00 London/UTC (Wednesday, Nov. 28) 09:00 Sydney (Thursday, Nov. 29) 07:00 Tokyo (Thursday, Nov. 29) 17:00 Toronto (Wednesday, Nov. 28) Addison, can you make a bridge reservation and send us the details? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 03:53: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 1IwwCB-0001uK-Iu; Tue, 27 Nov 2007 03:53:31 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IwwCA-0001oa-Eg for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:53:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwCA-0001cg-47 for ltru@ietf.org; Tue, 27 Nov 2007 03:53:30 -0500 Received: from [133.2.253.16] (helo=scmse1.scbb.aoyama.ac.jp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwwC7-0007UR-Qs for ltru@ietf.org; Tue, 27 Nov 2007 03:53:28 -0500 Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 7a97_6520a630_9cb0_11dc_9d47_0014221fa3c9; Tue, 27 Nov 2007 15:17:13 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46846) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 27 Nov 2007 15:13:19 +0900 Message-Id: <6.0.0.20.2.20071127115041.0912ec40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 27 Nov 2007 11:51:49 +0900 To: Stephane Bortzmeyer , Mark Davis From: Martin Duerst Subject: Re: [Ltru] Re: Fragmentary notes from telecon In-Reply-To: <20071122140113.GB23416@laperouse.bortzmeyer.org> References: <30b660a20711211510u78e3c55bw647b77cd4c63ed82@mail.gmail.com> <20071122140113.GB23416@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) 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 At 23:01 07/11/22, Stephane Bortzmeyer wrote: >On Wed, Nov 21, 2007 at 03:10:28PM -0800, > Mark Davis wrote > a message of 38 lines which said: > >> http://docs.google.com/Doc?id=dfqr8rd5_43dnw36c > >IMHO, the IETF rules for mailing lists do not mix well with "outside" >documents, which may not be available in the future, when someone will >read the archive. So, I take the liberty to copy it here: Yes indeed. In the future, please send a copy of such notes, not just a pointer. This also makes it much easier for people to comment inline. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 11:12: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 1Ix33H-0006Jm-CI; Tue, 27 Nov 2007 11:12:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix33F-0006JO-Ka for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:12:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix33E-0006J6-Sz for ltru@ietf.org; Tue, 27 Nov 2007 11:12:45 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix33D-0006Yz-3F for ltru@ietf.org; Tue, 27 Nov 2007 11:12:44 -0500 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 <20071127161242.YOBQ20513.mta11.adelphia.net@DGBP7M81>; Tue, 27 Nov 2007 11:12:42 -0500 Message-ID: <015501c83110$56f89ab0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00b101c82d40$1d438420$6601a8c0@DGBP7M81> <6.0.0.20.2.20071123155640.090bbb90@localhost> Subject: Re: [Ltru] Preparing ourselves for IETF Last Call Date: Tue, 27 Nov 2007 08:12:41 -0800 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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > The style of your question-and-answer list below may suggest, at least > to some that you don't agree with adding EU and 'friends'. If you > indeed do, please say so clearly. It's well known that I don't agree with adding EU. I've said so many times; for examples, see: http://www1.ietf.org/mail-archive/web/ltru/current/msg08786.html from the current debate, and: http://www.alvestrand.no/pipermail/ietf-languages/2006-January/003846.html from the first time this was brought up. To restate: EU represents not a country or dependency or protectorate, but a constantly-growing (hence unstable from a tagging standpoint) collection of countries that exhibit considerable national linguistic variation, wholly unrelated to their membership in the EU. The claim that an "official EU bureaucratese" may need to be tagged in the future does not indicate a need for us to change the rules to add a special geographical region subtag; it is exactly the kind of thing for which variant subtags were invented. If EU were already assigned in ISO 3166, I would have no objection to putting it in the LSR like any other ISO 3166 code element. That would be following the normal rules. But to change our rules for the purpose of admitting EU implies a compelling need for EU *in language tags*, and that need is not demonstrated IMHO. I still believe that the purpose of the LSR is to specify the components that can be used in *language tags*, not for every other purpose for which a stabilized profile of ISO standards is required. The only problem I have with the "friends," which at least identify stable and well-defined geographic areas, is that they are also not ISO 3166 assigned code elements, and adding the exceptionally reserved ones potentially opens the door for other types of "reserved" code elements. What about AP for the African Regional Industrial Property Organization, or WO for the World Intellectual Property Organization? They're sure to have some specialized bureaucratic jargon too. If we don't limit the LSR to officially assigned ISO codes, why should we stop at the exceptionally reserved ones? > As a technical contributor, I'm completely fine with adding 'EU' and > friends, And so is everyone else apparently, except Frank, and so I don't intend to try to stop progress on the drafts over this issue. I'm just surprised it wasn't already clear what my view was. > it makes sure we don't need another update to our work in the case > 'EU' is really needed. That hypothetical future case hasn't been explained to my satisfaction, but whatever. > If we as a WG, after discussing the issues, have reached a (rough) > consensus, then I don't think bringing up an issue again at IETF last > call will affect our drafts too much. And that was my original point: to ask the tough questions in a tough way, as they will be asked during IETF Last Call, and to show that we may need firmer and better-principled answers than the ones I've heard so far if we want to avoid looking silly. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Tue Nov 27 11:15: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 1Ix36B-000831-Cx; Tue, 27 Nov 2007 11:15:47 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix36A-00082s-Kt for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:15:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix36A-00082i-Al for ltru@ietf.org; Tue, 27 Nov 2007 11:15:46 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix369-0001W8-WF for ltru@ietf.org; Tue, 27 Nov 2007 11:15:46 -0500 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 <20071127161545.YXEJ20513.mta11.adelphia.net@DGBP7M81> for ; Tue, 27 Nov 2007 11:15:45 -0500 Message-ID: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 27 Nov 2007 08:15:44 -0800 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: 2409bba43e9c8d580670fda8b695204a Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >> BTW, I wonder how many people would have predicted, years ago when >> the basic rules for script subtags were formulated, that ISO 15924 >> would eventually add code elements for "Mathematical notation" and >> "Symbols." Section 3.4 says they must be added to the Registry, no >> cherry-picking allowed, and that seems fine in principle, but these >> two are at least as irrelevant to tagging of natural-language text as >> are the region subtags 'AQ' and 'BV', or the language subtags 'mis' >> and 'und'. > > Well, there are a lot of people, especially here in Japan, using > little symbols or images in their emails/sms. If you want to tag > these, a script subtag for symbols may come in handy :-). Is anyone really going to tag them separately from the surrounding text? Anyway, after my rant about EU I'm certainly not going to argue in favor of changing the rules to prohibit these things. But they will look somewhat ridiculous to LSR newcomers. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Tue Nov 27 11:52: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 1Ix3fM-0001pv-Q6; Tue, 27 Nov 2007 11:52:08 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix3fK-0001pV-UN for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:52:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3fK-0001pH-Bg for ltru@lists.ietf.org; Tue, 27 Nov 2007 11:52:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3fI-0006tA-2t for ltru@lists.ietf.org; Tue, 27 Nov 2007 11:52:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ix3dR-00063N-5v for ltru@lists.ietf.org; Tue, 27 Nov 2007 16:50:09 +0000 Received: from c-134-89-47.hh.dial.de.ignite.net ([62.134.89.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Nov 2007 16:50:09 +0000 Received: from nobody by c-134-89-47.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Nov 2007 16:50:09 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Tue, 27 Nov 2007 17:48:33 +0100 Organization: Lines: 27 Message-ID: References: <015701c83110$c3e87b90$6601a8c0@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: c-134-89-47.hh.dial.de.ignite.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: > after my rant about EU I'm certainly not going to argue in favor=20 > of changing the rules to prohibit these things. But they will > look somewhat ridiculous to LSR newcomers. For Zsym and similar oddities it's not the fault of BCP 47, for fonipa + fonupa it's less clear why there's no Lati and Latu if Zmth and Latf are okay. =20 For EU it would be the fault of the IETF, and EU isn't the worst case in this zoo. EA is in a certain sense a disputed territory, IIRC DG is a subset of IO and was (or is) a court case in the UK (aka GB on this list), IC might be another can of worms, and a fourth fantasy island was exceptionally reserved by the UPU, do they need language tags for their stamps ? If Spain wants EA and IC as country codes let them, Debbie has demonstrated that it is possible if necessary. Besides EU does not really help CLDR, they could use it anyway if they want it, and even if they replace QU by EU they still have QO. =20 Last but not least EU isn't stable, it's also not sure that the EU will only grow, maybe some members like UK (GB) + DK + SE=20 will split and start their own alliance. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 12:13: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 1Ix40B-00021u-90; Tue, 27 Nov 2007 12:13:39 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix409-0001x6-Uk for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:13:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix409-0001wO-Dt for ltru@lists.ietf.org; Tue, 27 Nov 2007 12:13:37 -0500 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix407-000335-Jz for ltru@lists.ietf.org; Tue, 27 Nov 2007 12:13:37 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 27 Nov 2007 09:13:03 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 27 Nov 2007 09:13:35 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Tue, 27 Nov 2007 09:13:32 -0800 Subject: RE: [Ltru] Re: New scripts Thread-Topic: [Ltru] Re: New scripts Thread-Index: AcgxFdx1j0j3tFvTTAWYHJEpiA+sfQAAlmOA Message-ID: References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> In-Reply-To: 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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="===============0804396358==" Errors-To: ltru-bounces@ietf.org --===============0804396358== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBGcmFuayBFbGxlcm1hbm4gW21haWx0bzpub2JvZHlAeHl6enkuY2xhcmFuZXQuZGVd DQoNCj4gTGFzdCBidXQgbm90IGxlYXN0IEVVIGlzbid0IHN0YWJsZSwgaXQncyBhbHNvIG5vdCBz dXJlIHRoYXQgdGhlDQo+IEVVIHdpbGwgb25seSBncm93LCBtYXliZSBzb21lIG1lbWJlcnMgbGlr ZSBVSyAoR0IpICsgREsgKyBTRQ0KPiB3aWxsIHNwbGl0IGFuZCBzdGFydCB0aGVpciBvd24gYWxs aWFuY2UuDQoNClRoYXQgZG9lcyBub3QgcnVsZSBvdXQgYSBwb3NzaWJsZSBzY2VuYXJpbyBpbiB3 aGljaCAoZS5nLikgdGhlIEVVIGRlZmluZXMgc3BlbGxpbmcgY29udmVudGlvbnMgZm9yIEVuZ2xp c2ggZm9yIHVzZSBpbiBFVSBkb2N1bWVudHMgdGhhdCBkbyBub3QgZXhhY3RseSBtYXRjaCB1c3Vh bCBjb252ZW50aW9ucyBpbiB0aGUgVUsuIENoYW5nZXMgaW4gdGhlIGNvbXBvc2l0aW9uIG9mIHRo ZSBFVSBpbiBlaXRoZXIgZGlyZWN0aW9uIHdvdWxkIG5vdCBsaWtlbHkgYWZmZWN0IHN1Y2ggc3Bl bGxpbmcgY29udmVudGlvbnMuDQoNCklmIHNvbWVvbmUgZG9lc24ndCBmaW5kICJFVSIgdXNlZnVs IGZvciB0YWdnaW5nIGRvY3VtZW50cywgdGhleSBkb24ndCBoYXZlIHRvIHVzZSBpdC4gVGhlIGlu Y2x1c2lvbiBvZiBhIHN1YnRhZyBpbiB0aGUgTFNSIGlzIG5vdCBvZiBpdHNlbGYgYSByZWNvbW1l bmRhdGlvbiB0aGF0IHRoZSBzdWJ0YWcgYmUgdXNlZCBpbiBhbnkgcGFydGljdWxhciB3YXk7IGl0 IG1lcmVseSBjcmVhdGVzIHRoZSBvcHBvcnR1bml0eSBmb3IgdXNlLg0KDQoNCg0KUGV0ZXINCg== --===============0804396358== 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 --===============0804396358==-- From ltru-bounces@ietf.org Tue Nov 27 12:20: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 1Ix46c-00079v-Uj; Tue, 27 Nov 2007 12:20:18 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix46b-00079e-E4 for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix46b-00079H-3a for ltru@ietf.org; Tue, 27 Nov 2007 12:20:17 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix46Z-0004Lq-Oj for ltru@ietf.org; Tue, 27 Nov 2007 12:20:17 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1950756wah for ; Tue, 27 Nov 2007 09:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=+kzhDCjHdMuBqgBjBlQSrj9ngOhIsv5ejUXH/z3FmPA=; b=noc8pkjRSpV+Y5cb9QUr5dl9dEI0Dj5oGZQ6WQBIrI3C4FK5azJTzDVh8AeXpg59/aYoaudaVgw7781zuj/yuy6OzRTfkxP9s58rN7L49OBRdHs6SFRO07/ggyvh2Zy5MzDUd8LjYmOkeWmiw72ZZ/mE8uID6y68Bh/eSzT85as= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=m8mGYVG1f7Z6SCiC2awNtR8+khduVlwO+C3N/nAutvNEWxYXTlBeHcUFz2r0hbsBoHXuC3I0XR+fN4zgI0BGinXQN2Gq+ltcr1Jqwjm7gopVGqM/+lUG6QbGQHx6Ct/ApzSyp2Sceg+8Cr5MOhz8wF4cMMG5r77FsrfbARgOOiQ= Received: by 10.114.14.1 with SMTP id 1mr476452wan.1196184014388; Tue, 27 Nov 2007 09:20:14 -0800 (PST) Received: by 10.114.198.8 with HTTP; Tue, 27 Nov 2007 09:20:14 -0800 (PST) Message-ID: <30b660a20711270920o7759c734ifab81109ad0e9c30@mail.gmail.com> Date: Tue, 27 Nov 2007 09:20:14 -0800 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: New scripts In-Reply-To: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> MIME-Version: 1.0 References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> X-Google-Sender-Auth: 9e2786a1086a06a6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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="===============0244721084==" Errors-To: ltru-bounces@ietf.org --===============0244721084== Content-Type: multipart/alternative; boundary="----=_Part_22205_20167151.1196184014378" ------=_Part_22205_20167151.1196184014378 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VG8gcmVwZWF0IHdoYXQgSSBzYWlkIGVhcmxpZXI6CgpJIGZpcm1seSBhZ3JlZS4gQkNQIDQ3IGlz IG5vdCBvbmx5IHRoZSBzb3VyY2Ugb2YgbGFuZ3VhZ2UgdGFnczsgaXQgaXMKKnRoZSAqcmVmZXJl bmNlCmZvciBzdGFiaWxpemVkLCBtYWludGFpbmFibGUgY29kZXMgZm9yIGxhbmd1YWdlcywgc2Ny aXB0cywgYW5kIHJlZ2lvbnMuClNvbWVvbmUgY2l0aW5nICJyZWdpb25zIGFzIGRlZmluZWQgYnkg QkNQIDQ3IiwgZXZlbiB3aGVuIG5vdCB1c2VkIGluCmxhbmd1YWdlIGNvZGVzLCBoYXMgYSBzdGFi bGUsIHdlbGwtZGVmaW5lZCwgbWFpbnRhaW5hYmxlIGNvZGUgdGhhdCBhbHNvCmVuY29tcGFzc2Vz IFVOIE0uNDkgcmVnaW9ucy4gQW5kIHRoaXMgaXMgYSBnb29kIHRoaW5nLCBzaW5jZSBpdCBwcm9t b3RlcyB0aGUKdXNlICphbmQgaW50ZXJ3b3JrYWJpbGl0eSAqd2l0aCBCQ1AgNDcsIGFuZCBzb2Z0 d2FyZSBpbnRlcm5hdGlvbmFsaXphdGlvbgpvdmVyYWxsLgoKQnkgZXhjbHVkaW5nIGVkZ2UgY2Fz ZXMgbGlrZSBFVSwgd2UganVzdCBtYWtlIGl0IGhhcmRlciBmb3IgcGVvcGxlIHRvIHVzZQpCQ1Ag NDcgYXMgaXMsIGFuZCBmb3JjZSB0aGUgcHJvbGlmZXJhdGlvbiBvZiBwcml2YXRlIHVzZSBjb2Rl cyAob3Igd29yc2UKeWV0LCBub24tQkNQNDcgY29kZXMpLgoKQnkgYmVpbmcgcHJhZ21hdGljLCBh bmQgaGFuZGxpbmcganVzdCBhIGZldyBrZXkgY2FzZXMgdGhhdCBhcmUgaW1wb3J0YW50IGZvcgpp bXBsZW1lbnRhdGlvbnMsIHdlIG1ha2UgaXQgZmFyIGVhc2llciBmb3IgcGVvcGxlIHRvIGFkb3B0 IGFuZCB1c2UgQkNQIDQ3LgpBZGRpbmcgIkVVIiB0byA0NjQ2YmlzIHdvdWxkIGJlIG9uZSBvZiB0 aG9zZSBrZXkgY2FzZXMuIEl0IGRvZXNuJ3QgaHVydCB0bwpoYXZlIEVVIGFzIGEgY29kZSBpbiBC Q1AgNDcsIG5vIG1vcmUgdGhhbiBpdCBodXJ0cyB0byBoYXZlIEJWIGFzIGEgY29kZS4gQW5kCnRo ZSBFVSBpcyBhIGRhcm4nZCBzaWdodCBtb3JlIGltcG9ydGFudCB0aGFuIGEgc2xldyBvZiB0aGUg cmVnaW9uIGNvZGVzIHdlCmFscmVhZHkgaGF2ZSAtLSB3aGV0aGVyIGluIGxhbmd1YWdlIGNvZGVz IG9yIGluIGludGVyd29ya2luZyB3aXRoIHRoZW0hCgpJIGFncmVlIHdpdGggQWRkaXNvbidzIHBy b3Bvc2VkIHRleHQuCgpCQ1AgNDcgaGFzIG1hbnkgc3VidGFncyB0aGF0IG1heSBub3QgYmUgb2Yg cGFydGljdWxhcmx5IGhpZ2ggdmFsdWUgdG8gYW55CnBhcnRpY3VsYXIgaW1wbGVtZW50b3IgaW4g Y29tYmluYXRpb24gb3IgZXZlbiBpbiBpc29sYXRpb24sIHN1Y2ggYXMgQlYgb3IKQVEuIFRoZSBF VSBhcyBhIHJlZ2lvbiBjb2RlIGlzIGZhciBtb3JlIHVzZWZ1bCB0aGFuIGEgZ3JlYXQgbWFueSBv dGhlcgpyZWdpb24gY29kZXMgZXZlbiBwdXJlbHkgaW4gdGVybXMgb2YgbGFuZ3VhZ2VzOyBlbi1F VSBpcyBtb3JlIHVzZWZ1bCB0aGFuCmphLUFRLgoKSWYgd2UgbG9vayBhdCB0aGUgbGFuZ3VhZ2Ug dGFncyB0aGF0IGFyZSBwZXJtaXR0ZWQsIHdlIGhhdmUgY3VycmVudGx5IG9uIHRoZQpvcmRlciBv ZgpsYW5ndWFnZTogICAgNDkwCnNjcmlwdDogICAgMTIxCnJlZ2lvbjogICAgMjgxCm5vdCBldmVu IGNvdW50aW5nIHZhcmlhbnRzLCBkZXByZWNhdGVkLCBncmFuZGZhdGhlcmVkLCBhbmQgcHJpdmF0 ZSB1c2UKY29kZXMuCgpUaGF0IG1lYW5zIHRoYXQgb25lIGNhbiBoYXZlIDM0LDAwMCBkaWZmZXJl bnQgdGFncyBmb3IgSmFwYW5lc2UsIGZvcgpleGFtcGxlLCBtb3N0IG9mIHdoaWNoIHdpbGwgbmV2 ZXIgYmUgbmVjZXNzYXJ5LiBBIGtleSBmZWF0dXJlIG9mIHRoZQpzdGFuZGFyZCBpcyB0aGF0IHdl IGdpdmUgcGVvcGxlIHRoZSB0b29scyB0aGV5IG5lZWQgdG8gbWFrZSB0aGUgZGlzdGluY3Rpb25z CnRoZXkgbmVlZDsgaXQgaXMgdXAgdG8gdGhlbSB0byBhdm9pZCB1bm5lY2Vzc2FyeSBkaXN0aW5j dGlvbnMgZm9yIHRoZSB0YXNrcwphdCBoYW5kLgoKV2hpbGUgd2UgKHNwZWFraW5nIGluIGFueSBv ZiBteSBwcm9mZXNzaW9uYWwgY2FwYWNpdGllcykgaGF2ZSBubyByZWFsIG5lZWQKZm9yIHRoZSBu ZXcgc2NyaXB0IGNvZGVzLCB0aGUgbWVhbmluZyBpcyByZWFzb25hYmx5IGNsZWFyLCBhbmQgSSBj YW4gd2VsbAp1bmRlcnN0YW5kIHRoYXQgb3RoZXJzIG1heSBoYXZlIHNvbWUgcmVxdWlyZW1lbnRz IGZvciB0aGVtOiB3ZSBzaG91bGQgbm90CnN0YW5kIGluIHRoZSB3YXkuIEFzIFBldGVyIHNhaWQg ZWFybGllciBhYm91dCBFVToKCldlbGwsIEknbSBub3Qgb3Bwb3NlZCB0byBxdWVzdGlvbnMgb2Yg d2hhdCBtYWtlcyBzZW5zZSBmb3IgYW4gZWNvc3lzdGVtIG9mCmNsb3NlbHkgcmVsYXRlZCB0YWdn aW5nIHNjaGVtZXMuIE5vYm9keSB3b3VsZCBiZSBzZXJ2ZWQgaW4gdGhlIGxvbmcgcnVuIGlmCndl IGhhZCB0byBoYXZlIGNvbXBsZXRlbHkgc2VwYXJhdGUgc2NoZW1lcyBhbmQgaW5mcmFzdHJ1Y3R1 cmVzIGZvciB0aGluZ3MKdGhhdCBvdmVybGFwIDk1JSwgc28gaXQgbWF5IG1ha2Ugc2Vuc2UgdG8g YWxsb3cgYSAyJSBjb21wcm9taXNlIG9mIHNjb3BlIGluCm9uZSBwbGFjZSBvciBhbm90aGVyIHRv IHByb3ZpZGUgYSBzaW5nbGUsIGNvaGVyZW50IGVjb3N5c3RlbSBvZiByZWxhdGVkCnNjaGVtZXMu CgpNYXJrCgpPbiBOb3YgMjcsIDIwMDcgODoxNSBBTSwgRG91ZyBFd2VsbCA8ZGV3ZWxsQHJvYWRy dW5uZXIuY29tPiB3cm90ZToKCj4gTWFydGluIER1ZXJzdCA8ZHVlcnN0IGF0IGl0IGRvdCBhb3lh bWEgZG90IGFjIGRvdCBqcD4gd3JvdGU6Cj4KPiA+PiBCVFcsIEkgd29uZGVyIGhvdyBtYW55IHBl b3BsZSB3b3VsZCBoYXZlIHByZWRpY3RlZCwgeWVhcnMgYWdvIHdoZW4KPiA+PiB0aGUgYmFzaWMg cnVsZXMgZm9yIHNjcmlwdCBzdWJ0YWdzIHdlcmUgZm9ybXVsYXRlZCwgdGhhdCBJU08gMTU5MjQK PiA+PiB3b3VsZCBldmVudHVhbGx5IGFkZCBjb2RlIGVsZW1lbnRzIGZvciAiTWF0aGVtYXRpY2Fs IG5vdGF0aW9uIiBhbmQKPiA+PiAiU3ltYm9scy4iIFNlY3Rpb24gMy40IHNheXMgdGhleSBtdXN0 IGJlIGFkZGVkIHRvIHRoZSBSZWdpc3RyeSwgbm8KPiA+PiBjaGVycnktcGlja2luZyBhbGxvd2Vk LCBhbmQgdGhhdCBzZWVtcyBmaW5lIGluIHByaW5jaXBsZSwgYnV0IHRoZXNlCj4gPj4gdHdvIGFy ZSBhdCBsZWFzdCBhcyBpcnJlbGV2YW50IHRvIHRhZ2dpbmcgb2YgbmF0dXJhbC1sYW5ndWFnZSB0 ZXh0IGFzCj4gPj4gYXJlIHRoZSByZWdpb24gc3VidGFncyAnQVEnIGFuZCAnQlYnLCBvciB0aGUg bGFuZ3VhZ2Ugc3VidGFncyAnbWlzJwo+ID4+IGFuZCAndW5kJy4KPiA+Cj4gPiBXZWxsLCB0aGVy ZSBhcmUgYSBsb3Qgb2YgcGVvcGxlLCBlc3BlY2lhbGx5IGhlcmUgaW4gSmFwYW4sIHVzaW5nCj4g PiBsaXR0bGUgc3ltYm9scyBvciBpbWFnZXMgaW4gdGhlaXIgZW1haWxzL3Ntcy4gSWYgeW91IHdh bnQgdG8gdGFnCj4gPiB0aGVzZSwgYSBzY3JpcHQgc3VidGFnIGZvciBzeW1ib2xzIG1heSBjb21l IGluIGhhbmR5IDotKS4KPgo+IElzIGFueW9uZSByZWFsbHkgZ29pbmcgdG8gdGFnIHRoZW0gc2Vw YXJhdGVseSBmcm9tIHRoZSBzdXJyb3VuZGluZyB0ZXh0Pwo+Cj4gQW55d2F5LCBhZnRlciBteSBy YW50IGFib3V0IEVVIEknbSBjZXJ0YWlubHkgbm90IGdvaW5nIHRvIGFyZ3VlIGluIGZhdm9yCj4g b2YgY2hhbmdpbmcgdGhlIHJ1bGVzIHRvIHByb2hpYml0IHRoZXNlIHRoaW5ncy4gIEJ1dCB0aGV5 IHdpbGwgbG9vawo+IHNvbWV3aGF0IHJpZGljdWxvdXMgdG8gTFNSIG5ld2NvbWVycy4KPgo+IC0t Cj4gRG91ZyBFd2VsbCAgKiAgRnVsbGVydG9uLCBDYWxpZm9ybmlhLCBVU0EgICogIFJGQyA0NjQ1 ICAqICBVVE4gIzE0Cj4gaHR0cDovL2hvbWUucm9hZHJ1bm5lci5jb20vfmRld2VsbCA8aHR0cDov L2hvbWUucm9hZHJ1bm5lci5jb20vJTdFZGV3ZWxsPgo+IGh0dHA6Ly93d3cxLmlldGYub3JnL2h0 bWwuY2hhcnRlcnMvbHRydS1jaGFydGVyLmh0bWwKPiBodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8v bWFpbG1hbi9saXN0aW5mby9pZXRmLWxhbmd1YWdlcyAgy4YKPgo+Cj4KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4g THRydUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0 cnUKPgoKCgotLSAKTWFyawo= ------=_Part_22205_20167151.1196184014378 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VG8gcmVwZWF0IHdoYXQgSSBzYWlkIGVhcmxpZXI6PGJyPjxicj48ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDogNDBweDsiPkkgZmlybWx5IGFncmVlLiBCQ1AgNDcgaXMgbm90IG9ubHkgdGhlIHNvdXJj ZSBvZiBsYW5ndWFnZSB0YWdzOyBpdCBpcyA8Yj50aGUgPC9iPnJlZmVyZW5jZQpmb3Igc3RhYmls aXplZCwgbWFpbnRhaW5hYmxlIGNvZGVzIGZvciBsYW5ndWFnZXMsIHNjcmlwdHMsIGFuZCByZWdp b25zLgpTb21lb25lIGNpdGluZyAmcXVvdDtyZWdpb25zIGFzIGRlZmluZWQgYnkgQkNQIDQ3JnF1 b3Q7LCBldmVuIHdoZW4gbm90IHVzZWQgaW4KbGFuZ3VhZ2UgY29kZXMsIGhhcyBhIHN0YWJsZSwg d2VsbC1kZWZpbmVkLCBtYWludGFpbmFibGUgY29kZSB0aGF0IGFsc28KZW5jb21wYXNzZXMgVU4g TS40OSByZWdpb25zLiBBbmQgdGhpcyBpcyBhIGdvb2QgdGhpbmcsIHNpbmNlIGl0CnByb21vdGVz IHRoZSB1c2UgPGI+PGk+YW5kIGludGVyd29ya2FiaWxpdHkgPC9pPjwvYj53aXRoIEJDUCA0Nywg YW5kIHNvZnR3YXJlIGludGVybmF0aW9uYWxpemF0aW9uIG92ZXJhbGwuPGJyPjxicj5CeSBleGNs dWRpbmcgZWRnZSBjYXNlcyBsaWtlIDxzcGFuIGNsYXNzPSJuZmFrUGUiPkVVPC9zcGFuPiwKd2Ug anVzdCBtYWtlIGl0IGhhcmRlciBmb3IgcGVvcGxlIHRvIHVzZSBCQ1AgNDcgYXMgaXMsIGFuZCBm b3JjZSB0aGUKcHJvbGlmZXJhdGlvbiBvZiBwcml2YXRlIHVzZSBjb2RlcyAob3Igd29yc2UgeWV0 LCBub24tQkNQNDcgY29kZXMpLgo8YnI+PGJyPkJ5IGJlaW5nIHByYWdtYXRpYywgYW5kIGhhbmRs aW5nIGp1c3QgYSBmZXcga2V5IGNhc2VzIHRoYXQgYXJlCmltcG9ydGFudCBmb3IgaW1wbGVtZW50 YXRpb25zLCB3ZSBtYWtlIGl0IGZhciBlYXNpZXIgZm9yIHBlb3BsZSB0bwphZG9wdCBhbmQgdXNl IEJDUCA0Ny4gQWRkaW5nICZxdW90OzxzcGFuIGNsYXNzPSJuZmFrUGUiPkVVPC9zcGFuPiZxdW90 OyB0byA0NjQ2YmlzIHdvdWxkIGJlIG9uZSBvZiB0aG9zZSBrZXkgY2FzZXMuIEl0IGRvZXNuJiMz OTt0IGh1cnQgdG8gaGF2ZSA8c3BhbiBjbGFzcz0ibmZha1BlIj5FVTwvc3Bhbj4gYXMgYSBjb2Rl IGluIEJDUCA0Nywgbm8gbW9yZSB0aGFuIGl0IGh1cnRzIHRvIGhhdmUgQlYgYXMgYSBjb2RlLiBB bmQgdGhlIAo8c3BhbiBjbGFzcz0ibmZha1BlIj5FVTwvc3Bhbj4KaXMgYSBkYXJuJiMzOTtkIHNp Z2h0IG1vcmUgaW1wb3J0YW50IHRoYW4gYSBzbGV3IG9mIHRoZSByZWdpb24gY29kZXMgd2UKYWxy ZWFkeSBoYXZlIC0tIHdoZXRoZXIgaW4gbGFuZ3VhZ2UgY29kZXMgb3IgaW4gaW50ZXJ3b3JraW5n IHdpdGggdGhlbSEKPGJyPjxicj5JIGFncmVlIHdpdGggQWRkaXNvbiYjMzk7cyBwcm9wb3NlZCB0 ZXh0LjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+QkNQIDQ3IGhhcyBtYW55IHN1 YnRhZ3MgdGhhdCBtYXkgbm90IGJlIG9mIHBhcnRpY3VsYXJseSBoaWdoIHZhbHVlIHRvIGFueSBw YXJ0aWN1bGFyIGltcGxlbWVudG9yIGluIGNvbWJpbmF0aW9uIG9yIGV2ZW4gaW4gaXNvbGF0aW9u LCBzdWNoIGFzIEJWIG9yIEFRLiBUaGUgRVUgYXMgYSByZWdpb24gY29kZSBpcyBmYXIgbW9yZSB1 c2VmdWwgdGhhbiBhIGdyZWF0IG1hbnkgb3RoZXIgcmVnaW9uIGNvZGVzIGV2ZW4gcHVyZWx5IGlu IHRlcm1zIG9mIGxhbmd1YWdlczsgZW4tRVUgaXMgbW9yZSB1c2VmdWwgdGhhbiBqYS1BUS4KPGJy Pjxicj5JZiB3ZSBsb29rIGF0IHRoZSBsYW5ndWFnZSB0YWdzIHRoYXQgYXJlIHBlcm1pdHRlZCwg d2UgaGF2ZSBjdXJyZW50bHkgb24gdGhlIG9yZGVyIG9mIDxicj48ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDogNDBweDsiPmxhbmd1YWdlOiZuYnNwOyZuYnNwOyZuYnNwOyA0OTA8YnI+c2NyaXB0OiZu YnNwOyZuYnNwOyZuYnNwOyAxMjE8YnI+cmVnaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyAyODE8YnI+ PC9kaXY+bm90IGV2ZW4gY291bnRpbmcgdmFyaWFudHMsIGRlcHJlY2F0ZWQsIGdyYW5kZmF0aGVy ZWQsIGFuZCBwcml2YXRlIHVzZSBjb2Rlcy4KPGJyPjxicj5UaGF0IG1lYW5zIHRoYXQgb25lIGNh biBoYXZlIDM0LDAwMCBkaWZmZXJlbnQgdGFncyBmb3IgSmFwYW5lc2UsIGZvciBleGFtcGxlLCBt b3N0IG9mIHdoaWNoIHdpbGwgbmV2ZXIgYmUgbmVjZXNzYXJ5LiBBIGtleSBmZWF0dXJlIG9mIHRo ZSBzdGFuZGFyZCBpcyB0aGF0IHdlIGdpdmUgcGVvcGxlIHRoZSB0b29scyB0aGV5IG5lZWQgdG8g bWFrZSB0aGUgZGlzdGluY3Rpb25zIHRoZXkgbmVlZDsgaXQgaXMgdXAgdG8gdGhlbSB0byBhdm9p ZCB1bm5lY2Vzc2FyeSBkaXN0aW5jdGlvbnMgZm9yIHRoZSB0YXNrcyBhdCBoYW5kLgo8YnI+PGJy PldoaWxlIHdlIChzcGVha2luZyBpbiBhbnkgb2YgbXkgcHJvZmVzc2lvbmFsIGNhcGFjaXRpZXMp IGhhdmUgbm8gcmVhbCBuZWVkIGZvciB0aGUgbmV3IHNjcmlwdCBjb2RlcywgdGhlIG1lYW5pbmcg aXMgcmVhc29uYWJseSBjbGVhciwgYW5kIEkgY2FuIHdlbGwgdW5kZXJzdGFuZCB0aGF0IG90aGVy cyBtYXkgaGF2ZSBzb21lIHJlcXVpcmVtZW50cyBmb3IgdGhlbTogd2Ugc2hvdWxkIG5vdCBzdGFu ZCBpbiB0aGUgd2F5LiBBcyBQZXRlciBzYWlkIGVhcmxpZXIgYWJvdXQgRVU6Cjxicj48YnI+PGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6IDQwcHg7Ij5XZWxsLCBJJiMzOTttIG5vdCBvcHBvc2VkIHRv IHF1ZXN0aW9ucyBvZiB3aGF0IG1ha2VzIHNlbnNlIGZvciBhbiBlY29zeXN0ZW0Kb2YgY2xvc2Vs eSByZWxhdGVkIHRhZ2dpbmcgc2NoZW1lcy4gTm9ib2R5IHdvdWxkIGJlIHNlcnZlZCBpbiB0aGUg bG9uZwpydW4gaWYgd2UgaGFkIHRvIGhhdmUgY29tcGxldGVseSBzZXBhcmF0ZSBzY2hlbWVzIGFu ZCBpbmZyYXN0cnVjdHVyZXMKZm9yIHRoaW5ncyB0aGF0IG92ZXJsYXAgOTUlLCBzbyBpdCBtYXkg bWFrZSBzZW5zZSB0byBhbGxvdyBhIDIlCmNvbXByb21pc2Ugb2Ygc2NvcGUgaW4gb25lIHBsYWNl IG9yIGFub3RoZXIgdG8gcHJvdmlkZSBhIHNpbmdsZSwKY29oZXJlbnQgZWNvc3lzdGVtIG9mIHJl bGF0ZWQgc2NoZW1lcy48YnI+PC9kaXY+PGJyPk1hcms8YnI+PGJyPk9uIE5vdiAyNywgMjAwNyA4 OjE1IEFNLCBEb3VnIEV3ZWxsICZsdDs8YSBocmVmPSJtYWlsdG86ZGV3ZWxsQHJvYWRydW5uZXIu Y29tIj5kZXdlbGxAcm9hZHJ1bm5lci5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0 LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4 OyI+CjxkaXYgY2xhc3M9IkloMkUzZCI+TWFydGluIER1ZXJzdCAmbHQ7ZHVlcnN0IGF0IGl0IGRv dCBhb3lhbWEgZG90IGFjIGRvdCBqcCZndDsgd3JvdGU6PGJyPjxicj4mZ3Q7Jmd0OyBCVFcsIEkg d29uZGVyIGhvdyBtYW55IHBlb3BsZSB3b3VsZCBoYXZlIHByZWRpY3RlZCwgeWVhcnMgYWdvIHdo ZW48YnI+Jmd0OyZndDsgdGhlIGJhc2ljIHJ1bGVzIGZvciBzY3JpcHQgc3VidGFncyB3ZXJlIGZv cm11bGF0ZWQsIHRoYXQgSVNPIDE1OTI0Cjxicj4mZ3Q7Jmd0OyB3b3VsZCBldmVudHVhbGx5IGFk ZCBjb2RlIGVsZW1lbnRzIGZvciAmcXVvdDtNYXRoZW1hdGljYWwgbm90YXRpb24mcXVvdDsgYW5k PGJyPiZndDsmZ3Q7ICZxdW90O1N5bWJvbHMuJnF1b3Q7IFNlY3Rpb24gMy40IHNheXMgdGhleSBt dXN0IGJlIGFkZGVkIHRvIHRoZSBSZWdpc3RyeSwgbm88YnI+Jmd0OyZndDsgY2hlcnJ5LXBpY2tp bmcgYWxsb3dlZCwgYW5kIHRoYXQgc2VlbXMgZmluZSBpbiBwcmluY2lwbGUsIGJ1dCB0aGVzZQo8 YnI+Jmd0OyZndDsgdHdvIGFyZSBhdCBsZWFzdCBhcyBpcnJlbGV2YW50IHRvIHRhZ2dpbmcgb2Yg bmF0dXJhbC1sYW5ndWFnZSB0ZXh0IGFzPGJyPiZndDsmZ3Q7IGFyZSB0aGUgcmVnaW9uIHN1YnRh Z3MgJiMzOTtBUSYjMzk7IGFuZCAmIzM5O0JWJiMzOTssIG9yIHRoZSBsYW5ndWFnZSBzdWJ0YWdz ICYjMzk7bWlzJiMzOTs8YnI+Jmd0OyZndDsgYW5kICYjMzk7dW5kJiMzOTsuPGJyPgomZ3Q7PGJy PjwvZGl2PjxkaXYgY2xhc3M9IkloMkUzZCI+Jmd0OyBXZWxsLCB0aGVyZSBhcmUgYSBsb3Qgb2Yg cGVvcGxlLCBlc3BlY2lhbGx5IGhlcmUgaW4gSmFwYW4sIHVzaW5nPGJyPiZndDsgbGl0dGxlIHN5 bWJvbHMgb3IgaW1hZ2VzIGluIHRoZWlyIGVtYWlscy9zbXMuIElmIHlvdSB3YW50IHRvIHRhZzxi cj4mZ3Q7IHRoZXNlLCBhIHNjcmlwdCBzdWJ0YWcgZm9yIHN5bWJvbHMgbWF5IGNvbWUgaW4gaGFu ZHkgOi0pLgo8YnI+PGJyPjwvZGl2PklzIGFueW9uZSByZWFsbHkgZ29pbmcgdG8gdGFnIHRoZW0g c2VwYXJhdGVseSBmcm9tIHRoZSBzdXJyb3VuZGluZyB0ZXh0Pzxicj48YnI+QW55d2F5LCBhZnRl ciBteSByYW50IGFib3V0IEVVIEkmIzM5O20gY2VydGFpbmx5IG5vdCBnb2luZyB0byBhcmd1ZSBp biBmYXZvcjxicj5vZiBjaGFuZ2luZyB0aGUgcnVsZXMgdG8gcHJvaGliaXQgdGhlc2UgdGhpbmdz LiAmbmJzcDtCdXQgdGhleSB3aWxsIGxvb2sKPGJyPnNvbWV3aGF0IHJpZGljdWxvdXMgdG8gTFNS IG5ld2NvbWVycy48YnI+PGRpdiBjbGFzcz0iSWgyRTNkIj48YnI+LS08YnI+RG91ZyBFd2VsbCAm bmJzcDsqICZuYnNwO0Z1bGxlcnRvbiwgQ2FsaWZvcm5pYSwgVVNBICZuYnNwOyogJm5ic3A7UkZD IDQ2NDUgJm5ic3A7KiAmbmJzcDtVVE4gIzE0PGJyPjxhIGhyZWY9Imh0dHA6Ly9ob21lLnJvYWRy dW5uZXIuY29tLyU3RWRld2VsbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9ob21lLnJvYWRydW5u ZXIuY29tL35kZXdlbGwKPC9hPjxicj48YSBocmVmPSJodHRwOi8vd3d3MS5pZXRmLm9yZy9odG1s LmNoYXJ0ZXJzL2x0cnUtY2hhcnRlci5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dzEu aWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sdHJ1LWNoYXJ0ZXIuaHRtbDwvYT48YnI+PC9kaXY+PGEg aHJlZj0iaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4vbGlzdGluZm8vaWV0Zi1sYW5n dWFnZXMiIHRhcmdldD0iX2JsYW5rIj4KaHR0cDovL3d3dy5hbHZlc3RyYW5kLm5vL21haWxtYW4v bGlzdGluZm8vaWV0Zi1sYW5ndWFnZXM8L2E+ICZuYnNwO8uGPGJyPjxkaXY+PGRpdj48L2Rpdj48 ZGl2IGNsYXNzPSJXajNDN2MiPjxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1h aWx0bzpMdHJ1QGlldGYub3JnIj5MdHJ1QGlldGYub3JnCjwvYT48YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjwvZGl2Pjwv ZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TWFy awo= ------=_Part_22205_20167151.1196184014378-- --===============0244721084== 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 --===============0244721084==-- From ltru-bounces@ietf.org Tue Nov 27 13:08: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 1Ix4qk-0005Xx-Rp; Tue, 27 Nov 2007 13:07:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix4qj-0005Xd-4l for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4qi-0000hN-0k for ltru@lists.ietf.org; Tue, 27 Nov 2007 13:07:56 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix4qS-0006qg-M8 for ltru@lists.ietf.org; Tue, 27 Nov 2007 13:07:43 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ix4qD-0001C5-Gn for ltru@lists.ietf.org; Tue, 27 Nov 2007 18:07:25 +0000 Received: from c-134-89-47.hh.dial.de.ignite.net ([62.134.89.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Nov 2007 18:07:25 +0000 Received: from nobody by c-134-89-47.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 27 Nov 2007 18:07:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Tue, 27 Nov 2007 19:09:04 +0100 Organization: Lines: 24 Message-ID: References: <015701c83110$c3e87b90$6601a8c0@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: c-134-89-47.hh.dial.de.ignite.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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: =20 > That does not rule out a possible scenario in which (e.g.) the EU > defines spelling conventions for English for use in EU documents > that do not exactly match usual conventions in the UK. Yes, but spelling conventions are better covered by a variant than a region. The tag en-EU is not necessarily what you describe, an "official" EU spelling convention. =20 > If someone doesn't find "EU" useful for tagging documents, they > don't have to use it. The inclusion of a subtag in the LSR is not > of itself a recommendation that the subtag be used in any=20 > particular way; it merely creates the opportunity for use. "Not useful" isn't the same as "potentially harmful", all here wen't to great lengths to guarantee stability especially for region codes after the various CS disasters. If stability isn't relevant anymore we can trim 4646 significantly, picking "whatever ISO 3166 currently says", as it was the case for RFC 1766 + 3066. No weird rules about UN codes as fallbacks, just a short note "you get what you paid for with region codes, there be dragons, they might bite after 50 years". Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 13:31: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 1Ix5DS-0005Ks-4x; Tue, 27 Nov 2007 13:31:26 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix5DQ-0005K8-L9 for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:31:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5DQ-0005Jy-BJ for ltru@lists.ietf.org; Tue, 27 Nov 2007 13:31:24 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix5DP-0001rV-N3 for ltru@lists.ietf.org; Tue, 27 Nov 2007 13:31:24 -0500 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.222.3; Tue, 27 Nov 2007 10:30:51 -0800 Received: from NA-EXMSG-C116.redmond.corp.microsoft.com ([157.54.62.41]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Tue, 27 Nov 2007 10:31:22 -0800 From: Shawn Steele To: Frank Ellermann , "ltru@lists.ietf.org" Importance: low Date: Tue, 27 Nov 2007 10:31:21 -0800 Subject: RE: [Ltru] Re: New scripts Thread-Topic: [Ltru] Re: New scripts Thread-Index: AcgxIHOFDRh6fHy0TJarHvHe9AUxuAAAtEqA Message-ID: References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> In-Reply-To: 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: 6d62ab47271805379d7172ee693a45db 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="===============0223403680==" Errors-To: ltru-bounces@ietf.org --===============0223403680== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Ii4uLnRoZXJlIGJlIGRyYWdvbnMsIHRoZXkgbWlnaHQgYml0ZSBhZnRlciA1MCB5ZWFycyIuDQoN CkknbSBzdXJlIHRoYXQgcmVnYXJkbGVzcyBvZiB0aGUgc3BlY2lmaWNzLCB0aGUgZHJhZ29ucyBh cmUgZ29pbmcgdG8gYml0ZSBwZW9wbGUgbXVjaCBzb29uZXIgdGhhbiB0aGF0IDopICBUaGVyZSdz IHRvbyBtdWNoIGluc3RhYmlsaXR5IGluIHRoZSBnZW9wb2xpdGljYWwgd29ybGQuDQoNCi0gU2hh d24NCg== --===============0223403680== 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 --===============0223403680==-- From ltru-bounces@ietf.org Tue Nov 27 13:54: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 1Ix5Zc-0005DJ-CW; Tue, 27 Nov 2007 13:54:20 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix5Za-0005D8-TC for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:54:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5Za-0005Cz-Jb for ltru@lists.ietf.org; Tue, 27 Nov 2007 13:54:18 -0500 Received: from ag-out-0708.google.com ([72.14.246.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix5ZY-0004Rs-IC for ltru@lists.ietf.org; Tue, 27 Nov 2007 13:54:18 -0500 Received: by ag-out-0708.google.com with SMTP id 5so1296237agb for ; Tue, 27 Nov 2007 10:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=zi/luI+PhtZQLA/qP/i92G4w8ctki6p00LDOnwEu4ZQ=; b=QmWlAIsoWqheoRIddJkDSaKv0IveP7p4QuTnjyncoSkn5b2Zs7WRwFhpp0n3FvDyuWF7AQrVrOQfxitE4cudtBTAKahytIRs+L7BkgJMb9TEt5SkoM9gY/Zq4CTuzSPOVxMqXo9seUEKKuknauAjx9lvCcBm29vEifZ+ZAmDSFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZnswAr/G+0jf8/9IEOGyYdsBfW/KPbqj4E3YlVicRNpruoPo+LnhFwEJ26K2ESmXG9yTn1iOVKB1ewpM234kEuzJPW38BfSZvc0SMqTsYHUMV0HjeEeDPPqmMKkoZNMKBpFQn6oZ9oZFH/+UshV9WYEjkC6Dm/jCC9Gz2YilPIA= Received: by 10.114.254.1 with SMTP id b1mr20383wai.1196189647728; Tue, 27 Nov 2007 10:54:07 -0800 (PST) Received: by 10.114.198.8 with HTTP; Tue, 27 Nov 2007 10:54:07 -0800 (PST) Message-ID: <30b660a20711271054v28aea35dg7c6e6b600687dc46@mail.gmail.com> Date: Tue, 27 Nov 2007 10:54:07 -0800 From: "Mark Davis" To: "Shawn Steele" Subject: Re: [Ltru] Re: New scripts In-Reply-To: MIME-Version: 1.0 References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> X-Google-Sender-Auth: fe4429ede5de25ab X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Frank Ellermann , "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2014759813==" Errors-To: ltru-bounces@ietf.org --===============2014759813== Content-Type: multipart/alternative; boundary="----=_Part_22731_8787188.1196189647726" ------=_Part_22731_8787188.1196189647726 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. We have and make no guarantees regarding the stability of geographic areas associated with the territory codes. If the Pacific states of the US secede and then join Canada, it would make no difference in the codes we use, although there would be a major change in territory. Any number of more realistic territorial changes could happen over time; the EU might change somewhat more rapidly than most, but who knows what the future will bring. The reason that the political divisions are often useful in discriminating among language variants is that there are often common linguistic features that are associated with those political entities. And insofar as languages form the basis for locales -- a major usage -- they are, of course also important. And even if we had some (bizarre) scheme for precise geographic location (en-l-p3706-n9568-p3545-n ... for the language spoken within a polygon starting at latitude 37.06 and longitude -95.68 and so on ...), we have no assurances that people don't move over time, or that language variants don't change or develop over time. We live in an imperfect, changing world, and we have to be pragmatic in considering what tools are useful, even when there is some degree of imprecision. Mark On Nov 27, 2007 10:31 AM, Shawn Steele wrote: > "...there be dragons, they might bite after 50 years". > > I'm sure that regardless of the specifics, the dragons are going to bite > people much sooner than that :) There's too much instability in the > geopolitical world. > > - Shawn > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_22731_8787188.1196189647726 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree. We have and make no guarantees regarding the stability of geographic areas associated with the territory codes.

If the Pacific states of the US secede and then join Canada, it would make no difference in the codes we use, although there would be a major change in territory. Any number of more realistic territorial changes could happen over time; the EU might change somewhat more rapidly than most, but who knows what the future will bring.

The reason that the political divisions are often useful in discriminating among language variants is that there are often common linguistic features that are associated with those political entities. And insofar as languages form the basis for locales -- a major usage -- they are, of course also important.

And even if we had some (bizarre) scheme for precise geographic location (en-l-p3706-n9568-p3545-n ... for the language spoken within a polygon starting at latitude 37.06 and longitude -95.68 and so on ...), we have no assurances that people don't move over time, or that language variants don't change or develop over time.

We live in an imperfect, changing world, and we have to be pragmatic in considering what tools are useful, even when there is some degree of imprecision.

Mark

On Nov 27, 2007 10:31 AM, Shawn Steele < Shawn.Steele@microsoft.com> wrote:
"...there be dragons, they might bite after 50 years".

I'm sure that regardless of the specifics, the dragons are going to bite people much sooner than that :)  There's too much instability in the geopolitical world.

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




--
Mark ------=_Part_22731_8787188.1196189647726-- --===============2014759813== 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 --===============2014759813==-- From ltru-bounces@ietf.org Tue Nov 27 14:17: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 1Ix5vy-0002ZW-EH; Tue, 27 Nov 2007 14:17:26 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix5vx-0002SJ-Dx for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix5vx-0002Qt-3R for ltru@lists.ietf.org; Tue, 27 Nov 2007 14:17:25 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix5vw-00077n-QU for ltru@lists.ietf.org; Tue, 27 Nov 2007 14:17:25 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 27 Nov 2007 11:16:53 -0800 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; Tue, 27 Nov 2007 11:17:20 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Tue, 27 Nov 2007 11:17:19 -0800 Subject: RE: [Ltru] Re: New scripts Thread-Topic: [Ltru] Re: New scripts Thread-Index: AcgxIHN5oJhdSX4JQg24ZWM+gVcqWwACOR5A Message-ID: References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> In-Reply-To: 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: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1697732538==" Errors-To: ltru-bounces@ietf.org --===============1697732538== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBGcmFuayBFbGxlcm1hbm4gW21haWx0bzpub2JvZHlAeHl6enkuY2xhcmFuZXQuZGVd DQoNCj4gIk5vdCB1c2VmdWwiIGlzbid0IHRoZSBzYW1lIGFzICJwb3RlbnRpYWxseSBoYXJtZnVs IiwgYWxsIGhlcmUgd2VuJ3QNCj4gdG8gZ3JlYXQgbGVuZ3RocyB0byBndWFyYW50ZWUgc3RhYmls aXR5IGVzcGVjaWFsbHkgZm9yIHJlZ2lvbiBjb2Rlcw0KPiBhZnRlciB0aGUgdmFyaW91cyBDUyBk aXNhc3RlcnMuDQoNClRoZXJlJ3MgYSBjYXRlZ29yaWNhbCBkaWZmZXJlbmNlIGJldHdlZW4gc3Rh YmlsaXR5IG9mIHRoZSBzZW1hbnRpYyBkZW5vdGF0aW9uIG9mIGFuIElEIGxpa2UgIkNTIiwgd2hp Y2ggYXJlIHRoaW5ncyBsaWtlIG5hdGlvbiBzdGF0ZXMsIGFuZCB0aGUgc3RhYmlsaXR5IG9mIHRo ZSBnZW9ncmFwaGljIHJlZ2lvbiB1bmRlciB0aGUganVyaXNkaWN0aW9uIG9mIGVudGl0aWVzIHN1 Y2ggYXMgbmF0aW9uIHN0YXRlcy4gSWYgdGhlIFVTIHdlcmUgdG8gY2VkZSBNYWluZSB0byBDYW5h ZGEsIHRoYXQgd291bGQgbm90IHJlcXVpcmUgdXMgdG8gc3RvcCB1c2luZyAiZW4tVVMiIG9yICJl bi1DQSIgb2Ygc3RhYmlsaXR5IGNvbmNlcm5zLiBJZiAiRVUiIHdlcmUgdG8gbWVhbiAiRXVyb3Bl YW4gVW5pb24iIHRvZGF5IGJ1dCAiRXVnb3NsYXZpYSIgdHdlbnR5IHllYXJzIGZyb20gbm93LCB0 aGF0IHdvdWxkIGJlIGEgc3RhYmlsaXR5IHByb2JsZW07IGJ1dCBjb3VudHJpZXMgam9pbmluZyBv ciBsZWF2aW5nIHRoZSBFdXJvcGVhbiBVbmlvbiBkb2VzIG5vdCBhbHRlciB0aGUgaWRlbnRpdHkg b2YgYW4gZW50aXR5IGtub3duIGFzIHRoZSBFdXJvcGVhbiBVbmlvbiwgYW5kIGxhbmd1YWdlIHVz YWdlIHRoYXQgaXMgbGlrZWx5IHRvIGNvcnJlc3BvbmQgdG8gaXQuDQoNCg0KDQpQZXRlcg0K --===============1697732538== 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 --===============1697732538==-- From ltru-bounces@ietf.org Tue Nov 27 14:34: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 1Ix6CY-00072y-Gx; Tue, 27 Nov 2007 14:34:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix6CX-00072p-MV for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:34:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6CX-00072f-Co for ltru@lists.ietf.org; Tue, 27 Nov 2007 14:34:33 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix6CV-0000hP-LH for ltru@lists.ietf.org; Tue, 27 Nov 2007 14:34:33 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ix6CT-0008Le-TM; Tue, 27 Nov 2007 14:34:29 -0500 Date: Tue, 27 Nov 2007 14:34:29 -0500 To: Peter Constable Subject: Re: [Ltru] Re: New scripts Message-ID: <20071127193429.GH8712@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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "ltru@lists.ietf.org" X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > There's a categorical difference between stability of the semantic > denotation of an ID like "CS", which are things like nation states, > and the stability of the geographic region under the jurisdiction > of entities such as nation states. If the US were to cede Maine to > Canada, that would not require us to stop using "en-US" or "en-CA" > of stability concerns. In the case of more radical realignments such as contemplated at http://www.tbray.org/ongoing/When/200x/2004/11/04/NewNorthAmerica , M.49 can and does issue new numeric codes, and the 3166/MA can change things accordingly. > but countries joining or leaving the European Union does not alter > the identity of an entity known as the European Union, and language > usage that is likely to correspond to it. *What* language usage that is likely to correspond to it? That's the issue. -- At the end of the Metatarsal Age, the dinosaurs John Cowan abruptly vanished. The theory that a single cowan@ccil.org catastrophic event may have been responsible http://www.ccil.org/~cowan has been strengthened by the recent discovery of a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 14:51: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 1Ix6SV-000762-Er; Tue, 27 Nov 2007 14:51:03 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix6ST-00074W-W9 for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 14:51:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6ST-000748-M2 for ltru@ietf.org; Tue, 27 Nov 2007 14:51:01 -0500 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix6SS-0002UI-6r for ltru@ietf.org; Tue, 27 Nov 2007 14:51:01 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jPlQa8kfWoHqC43nSq2VDtEIuzwFea5iqJ93YoZkL3Df/0ALYUaZ7M7zCqw0tBox; 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.82.23] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ix6SR-0001PM-JN for ltru@ietf.org; Tue, 27 Nov 2007 14:50:59 -0500 Message-ID: <009401c8312f$1053a400$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20071127193429.GH8712@mercury.ccil.org> Subject: Re: [Ltru] Re: New scripts Date: Tue, 27 Nov 2007 11:52:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a425e77d7f109718deeb8ae5451f9414a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.82.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... > From: "John Cowan" > To: "Peter Constable" > Cc: > Sent: Tuesday, November 27, 2007 11:34 AM > Subject: Re: [Ltru] Re: New scripts ... > > but countries joining or leaving the European Union does not alter > > the identity of an entity known as the European Union, and language > > usage that is likely to correspond to it. > > *What* language usage that is likely to correspond to it? That's > the issue. ... The only example I recall was, for lack of a better word, "bureaucratese," meaning the peculiar varieties of language preferred by the governmental and quasi-governmental officials associated with the EU. I have heard it facetiously called "mandarin English". As a co-chair - I don't know whether uch varieties really exist, or are merely urban legends. *That* would be a question for ietf-languages@iana.org, rather than this working group. Our job here is merely to decide whether this sort of thing is possible, and consequently should be supported by our procedures. Of course, someday someone might decide that EU really should have a country code, and solve the problem for us. It's just a question of which will happen first. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 15: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 1Ix7Kv-0000go-KJ; Tue, 27 Nov 2007 15:47:17 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix7Ku-0000gW-Qq for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 15:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Ku-0000gL-H9 for ltru@ietf.org; Tue, 27 Nov 2007 15:47:16 -0500 Received: from netc-relay-1m.netcourrier.com ([194.158.104.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7Ks-0006pU-U8 for ltru@ietf.org; Tue, 27 Nov 2007 15:47:16 -0500 Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-1m.netcourrier.com (Postfix) with SMTP id 0A78B38A98 for ; Tue, 27 Nov 2007 21:47:04 +0100 (CET) Received: from [89.2.186.89] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Date: Tue, 27 Nov 2007 21:46:57 +0100 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Swiss German and Alsatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello = There is no detail in = http://www.iana.org/assignments/language-subtag-registry http://www.loc.gov/standards/iso639-2/php/code=5Flist.php http://www.sil.org/iso639-3/documentation.asp?id=3Dgsw http://tools.ietf.org/html/draft-ietf-ltru-4645bis-02 http://www.langtag.net/registries/lsr-language.txt http://www.langtag.net/registries/registry-html/language/gsw.html if Alsatian is included in gsw (Swiss German, Schwyzerd=FCtsch), = apart the =22Alemannic=22. = http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw show =22Called 'Schwyzerd=FCtsch' in Switzerland, and 'Alsatian' in France= =2E=22 Is this right? = If yes, please add Alsatian in the official registry, or at least in = http://www.langtag.net/registries/registry-html/language/gsw.html If no, please add a comment somewhere oxplaining that gsw is only for = Swiss Alemannic. = _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 16:00: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 1Ix7Xf-0002MR-0y; Tue, 27 Nov 2007 16:00:27 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix7Xd-0002MD-Dz for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 16:00:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Xd-0002M4-3h for ltru@ietf.org; Tue, 27 Nov 2007 16:00:25 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix7Xc-0004t7-PU for ltru@ietf.org; Tue, 27 Nov 2007 16:00:25 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ix7XY-0006vW-8C; Tue, 27 Nov 2007 16:00:20 -0500 Date: Tue, 27 Nov 2007 16:00:20 -0500 To: Nicolas Krebs Subject: Re: [Ltru] Swiss German and Alsatian Message-ID: <20071127210020.GA20488@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicolas Krebs scripsit: > http://www.ethnologue.com/show_language.asp?code=gsw > show "Called 'Schwyzerdtsch' in Switzerland, and 'Alsatian' in France." > Is this right? It is right, because BCP 47 defers to ISO 639 for language subtags, and ISO 639 defers to Ethnologue for the definitions of currently spoken natural languages. > If yes, please add Alsatian in the official registry, This appeal should properly be addressed to ISO 639-2/RA by email at iso639-2@loc.gov, and/or to ISO 639-3/RA by following the instructions at http://www.sil.org/iso639-3/submit_changes.asp . No one else can help you -- in particular, this mailing list cannot. -- Dream projects long deferred John Cowan usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 16:06:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7dE-0000nH-AI; Tue, 27 Nov 2007 16:06:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix7dD-0000n7-PD for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 16:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7dD-0000mt-DZ for ltru@ietf.org; Tue, 27 Nov 2007 16:06:11 -0500 Received: from netc-relay-3m.netcourrier.com ([194.158.104.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7dC-0003MC-Oz for ltru@ietf.org; Tue, 27 Nov 2007 16:06:11 -0500 Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-3m.netcourrier.com (Postfix) with SMTP id 96BC734842 for ; Tue, 27 Nov 2007 22:06:09 +0100 (CET) Received: from [89.2.186.89] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Date: Tue, 27 Nov 2007 22:06:03 +0100 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ltru] Re: Alemanic & Swiss German X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 my previous message and the double post. = A year ago, Mark Davis started a discussion about Alemanic & Swiss German = > ISO 639-2 (on http://www.loc.gov/standards/iso639-2/php/code=5Flist.php)= = > lists the following: > = > gsw Alemani; Swiss German al=E9manique > = > However, there is a =22c=22 missing from Alemanic, and Swiss German is = > not the same as Alemanic: Swiss German is a type of Alemanic, but = > there are other types that are not the same as Swiss German. Current http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw show =22Called 'Schwyzerd=FCtsch' in Switzerland, and 'Alsatian' in France= =2E=22 which may/might suppose that gsw include Alsatian, and that gsw = encompass Schwyzerd=FCtsch and Alsatian. = References: = http://www.iana.org/assignments/language-subtag-registry http://www.loc.gov/standards/iso639-2/php/code=5Flist.php http://www.sil.org/iso639-3/documentation.asp?id=3Dgsw http://tools.ietf.org/html/draft-ietf-ltru-4645bis-02 http://www.langtag.net/registries/lsr-language.txt http://www.langtag.net/registries/registry-html/language/gsw.html http://www.ethnologue.com/show=5Flanguage.asp?code=3Dgsw http://article.gmane.org/gmane.ietf.languages/3485 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 16:09: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 1Ix7gH-00032y-Gt; Tue, 27 Nov 2007 16:09:21 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix7gG-00032o-Rd for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 16:09:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7gG-00030f-Gq for ltru@ietf.org; Tue, 27 Nov 2007 16:09:20 -0500 Received: from netc-relay-1m.netcourrier.com ([194.158.104.107]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix7gF-0007Hc-Mx for ltru@ietf.org; Tue, 27 Nov 2007 16:09:19 -0500 Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-1m.netcourrier.com (Postfix) with SMTP id 5EBF138AB1 for ; Tue, 27 Nov 2007 22:09:18 +0100 (CET) Received: from [89.2.186.89] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: ltru@ietf.org Date: Tue, 27 Nov 2007 22:09:15 +0100 Mime-Version: 1.0 X-Priority: 5 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Italy and Eastern Armenian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Nicolas Krebs > > Title : Tags for Identifying Languages > > Author(s) : A. Phillips, M. Davis > > Filename : draft-ietf-ltru-4646bis-03.txt > > Pages : 66 > > Date : 2007-3-29 > = > I see > =22hy-Latn-IT-arevela (Eastern Armenian written in Latin script, as > used in Italy)=22 > Should't it be Western Armenian ? = > (=22hy-Latn-IT-arevmda (Western Armenian written in Latin script, as=22) Still in urn:ietf:id:draft-ietf-ltru-4646bis-09 http://tools.ietf.org/html/draft-ietf-ltru-4646bis-09=23appendix-B _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 16:17: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 1Ix7ny-0000L8-48; Tue, 27 Nov 2007 16:17:18 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix7nx-0000Kz-JE for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 16:17:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7nx-0000Kp-9U for ltru@ietf.org; Tue, 27 Nov 2007 16:17:17 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7nt-0006GK-MH for ltru@ietf.org; Tue, 27 Nov 2007 16:17:17 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BE63B24080E; Tue, 27 Nov 2007 21:16:57 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id D69AF110A4; Tue, 27 Nov 2007 22:12:55 +0100 (CET) Date: Tue, 27 Nov 2007 22:12:55 +0100 From: Stephane Bortzmeyer To: Nicolas Krebs Message-ID: <20071127211255.GA23774@sources.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org Subject: [Ltru] Re: Swiss German and Alsatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Nov 27, 2007 at 09:46:57PM +0100, Nicolas Krebs wrote=20 a message of 26 lines which said: > There is no detail in=20 > http://www.iana.org/assignments/language-subtag-registry No, the registry is not an encyclopedia, there are never details. > http://www.loc.gov/standards/iso639-2/php/code_list.php > http://www.sil.org/iso639-3/documentation.asp?id=3Dgsw This is something you should report to LOC and SIL. > http://www.langtag.net/registries/lsr-language.txt > http://www.langtag.net/registries/registry-html/language/gsw.html The files in www.langtag.net/registries are automatically produced from the registry so they cannot contain more information. > if Alsatian is included in gsw (Swiss German, Schwyzerd=FCtsch),=20 Well, while I'm of alsatian descent, I'm not an authority on it but I would vote for inclusion in alemanic (alsatian is just a dialect). That's also the opinion of Wikipedia: http://fr.wikipedia.org/wiki/Alsacien http://en.wikipedia.org/wiki/Alsatian_language (the "en" version does not include the ISO code) Which means that you can ask ietf-languages to register variant "alsatian" with prefix "gsw" :-) Or a comment but my personal opinion is that a variant reflects more the reality of alsatian. > If yes, please add Alsatian in the official registry,=20 The regular procedure is described here and alsatian is mentioned as an example :-) http://www.langtag.net/register-new-subtag.html _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 16:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8Qb-0000HB-Bp; Tue, 27 Nov 2007 16:57:13 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix8QZ-0000Gm-T9 for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 16:57:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8QZ-0000Gc-JZ for ltru@lists.ietf.org; Tue, 27 Nov 2007 16:57:11 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix8QZ-0008Ac-AR for ltru@lists.ietf.org; Tue, 27 Nov 2007 16:57:11 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7160E24080E; Tue, 27 Nov 2007 21:56:57 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id AC9B512DF7; Tue, 27 Nov 2007 22:52:13 +0100 (CET) Date: Tue, 27 Nov 2007 22:52:13 +0100 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20071127215213.GA2836@sources.org> References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> <30b660a20711271054v28aea35dg7c6e6b600687dc46@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20711271054v28aea35dg7c6e6b600687dc46@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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@lists.ietf.org Subject: [Ltru] Countries and languages (Was: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Nov 27, 2007 at 10:54:07AM -0800, Mark Davis wrote a message of 87 lines which said: > The reason that the political divisions are often useful in > discriminating among language variants is that there are often > common linguistic features that are associated with those political > entities. I suspect that it is true only for Europe. In Africa, at least, countries are quite meaningless, linguistically speaking. It seems too easy to find a lot of counter-examples where the country does not give any indication on the variant spoken or written (what is es-US, for instance?) The idea to have countries in language tags (not in locales, where things like currencies and holidays obviously depend on the country) is questionable and seems to come from a traditional "Nation-State" mind. (Of course, in the name of stability, I do not suggest that we drop them, just that we keep in mind that they are most often not a good discriminant for languages.) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 17:01: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 1Ix8UQ-0001fq-8v; Tue, 27 Nov 2007 17:01:10 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix8UP-0001fR-5U for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 17:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8UO-0001fH-Rv for ltru@lists.ietf.org; Tue, 27 Nov 2007 17:01:08 -0500 Received: from el-out-1112.google.com ([209.85.162.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix8UO-0000no-KD for ltru@lists.ietf.org; Tue, 27 Nov 2007 17:01:08 -0500 Received: by el-out-1112.google.com with SMTP id j27so488377elf for ; Tue, 27 Nov 2007 14:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=Cy5P4HBX/nfNmyHvunOXsx1qUMIHQwNTnRv4XpHVhzE=; b=xkKz1c4+OvLx+z4HPwZFV2yOVP9WZWz5LjYjQ6tDhTlbEZV2MflvciZNWXMQ5i8MWcF3KX6mriRgedKHtWzPtZVtpqVap+1xDroKEhiQ7TD2lyGXASRwPsbt1JxRmqnaAMGxUGUV5bdQkiyNXv6WFwRG0siGJPJ5alhcuRTZ708= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hdUEBepSA0AiEz3xpQq7m1DxqvzaaBR44jko4LCvgMROIiwhTdAPbXpf6ei4rzTdAMeC3ORv/zrurJyWUQFewvgO5j93Inrgt/gfja8pZUGcwe0aP9jbiaEmKyWLl9ZSec89uXDkXDxJcad//v8ZdTkaYCqbO8Gdn/HKxjzcpjM= Received: by 10.115.15.1 with SMTP id s1mr584432wai.1196200867081; Tue, 27 Nov 2007 14:01:07 -0800 (PST) Received: by 10.114.198.8 with HTTP; Tue, 27 Nov 2007 14:01:06 -0800 (PST) Message-ID: <30b660a20711271401q5b1244b9q95d5f99a1a107d0c@mail.gmail.com> Date: Tue, 27 Nov 2007 14:01:06 -0800 From: "Mark Davis" To: "Stephane Bortzmeyer" In-Reply-To: <20071127215213.GA2836@sources.org> MIME-Version: 1.0 References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> <30b660a20711271054v28aea35dg7c6e6b600687dc46@mail.gmail.com> <20071127215213.GA2836@sources.org> X-Google-Sender-Auth: 328b5fa77c38f19f X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Countries and languages (Was: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1394348648==" Errors-To: ltru-bounces@ietf.org --===============1394348648== Content-Type: multipart/alternative; boundary="----=_Part_748_13826347.1196200867068" ------=_Part_748_13826347.1196200867068 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > ... we keep in mind that they are most often not a good > discriminant for languages.) no disagreement. ------=_Part_748_13826347.1196200867068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
... we keep in mind that they are most often not a good
discriminant for languages.)

no disagreement.
------=_Part_748_13826347.1196200867068-- --===============1394348648== 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 --===============1394348648==-- From ltru-bounces@ietf.org Tue Nov 27 17:22: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 1Ix8pR-0007Cj-78; Tue, 27 Nov 2007 17:22:53 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ix8pP-00078r-Jm for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 17:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8pO-00078Z-UL for ltru@lists.ietf.org; Tue, 27 Nov 2007 17:22:50 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix8pO-0007SN-JX for ltru@lists.ietf.org; Tue, 27 Nov 2007 17:22:50 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ix8pM-00064p-9L; Tue, 27 Nov 2007 17:22:48 -0500 Date: Tue, 27 Nov 2007 17:22:48 -0500 To: Stephane Bortzmeyer Subject: Re: [Ltru] Countries and languages (Was: New scripts Message-ID: <20071127222248.GB20488@mercury.ccil.org> References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81> <30b660a20711271054v28aea35dg7c6e6b600687dc46@mail.gmail.com> <20071127215213.GA2836@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071127215213.GA2836@sources.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer scripsit: > The idea to have countries in language tags (not in locales, where > things like currencies and holidays obviously depend on the country) > is questionable and seems to come from a traditional "Nation-State" > mind. It is indeed questionable. However, we get them for free, and it is often the case that orthographies (for languages less autonomous than English) are set by national bodies of one sort or another, or if not, then by national conventions like those which distinguish en-US from en-GB from en-CA from en-AU .... -- John Cowan cowan@ccil.org http://ccil.org/~cowan If he has seen farther than others, it is because he is standing on a stack of dwarves. --Mike Champion, describing Tim Berners-Lee (adapted) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Nov 27 19:02: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 1IxANR-00080P-47; Tue, 27 Nov 2007 19:02:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxANQ-00080H-4D for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 19:02:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxANP-000801-QH for ltru@ietf.org; Tue, 27 Nov 2007 19:02:03 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxANP-000732-BS for ltru@ietf.org; Tue, 27 Nov 2007 19:02:03 -0500 Received: from [172.21.233.205] (wlanvpn-abc-233-205.corp.yahoo.com [172.21.233.205]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAS01xT6094153 for ; Tue, 27 Nov 2007 16:01:59 -0800 (PST) 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=0NzjtlH9TrLlelZDALiqYYeRqe5B41XHTW5rlBRP/tzX6WnXf3Ofc7koP1GWhRnc Message-ID: <474CAFF7.2080101@yahoo-inc.com> Date: Tue, 27 Nov 2007 16:01:59 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Ltru] Telecon Reminder/Info for 28 NOVEMBER 22:00 UTC (tomorrow)] X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, Tomorrow's teleconference will occur at: 14:00 Pacific (Wednesday, Nov. 21) 22:00 London (Wednesday, Nov. 21) 09:00 Sydney (Thursday, Nov. 22) 07:00 Tokyo (Thursday, Nov. 22) 17:00 Toronto (Wednesday, Nov. 21) Or Find Your Local Time Here: http://tinyurl.com/2a6vtn Dial In Information * USA: 1-888-371-8922 * International: +1.617.224.4792 Random Other Countries: * Austria: (0) 1.7957.6003 * France: (0) 1.71230263 * Germany: 06950.072802 * Ireland: 012421577 * Italy: 0.269.6828.47 * Netherlands: 0202013357 * Spain: 9.1270268.8 * UK: (0) 207.365.0742 * Japan: 0335708092 Participant Passcode: 58371972 I'm still setting up a note-taking and sharing system. Will send a note about that later. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Chair -- W3C Internationalization Core WG Internationalization is an architecture. It is not a feature. -- 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 Nov 27 19: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 1IxAjN-00045M-Mx; Tue, 27 Nov 2007 19:24:45 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxAjL-000459-NM for ltru-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 19:24:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAjL-00044y-DE for ltru@ietf.org; Tue, 27 Nov 2007 19:24:43 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxAjK-0007E4-QY for ltru@ietf.org; Tue, 27 Nov 2007 19:24:43 -0500 Received: from [172.21.232.80] (wlanvpn-abc-232-80.corp.yahoo.com [172.21.232.80]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lAS0OU4D095487; Tue, 27 Nov 2007 16:24:30 -0800 (PST) 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=YmqdQnvCRG5b4MmAWE+vzl2ESGjod1DILKMS0HkkbEQnyZkoGdgK6hMPJoMfduQN Message-ID: <474CB53E.5080502@yahoo-inc.com> Date: Tue, 27 Nov 2007 16:24:30 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Swiss German and Alsatian References: <20071127210020.GA20488@mercury.ccil.org> In-Reply-To: <20071127210020.GA20488@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp2.corp.yahoo.com id lAS0OU4D095487 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Nicolas Krebs scripsit: >=20 >> http://www.ethnologue.com/show_language.asp?code=3Dgsw >> show "Called 'Schwyzerd=C3=BCtsch' in Switzerland, and 'Alsatian' in F= rance." >> Is this right?=20 >=20 > It is right, because BCP 47 defers to ISO 639 for language subtags, > and ISO 639 defers to Ethnologue for the definitions of currently spoke= n > natural languages. >=20 >> If yes, please add Alsatian in the official registry,=20 >=20 > This appeal should properly be addressed to ISO 639-2/RA by email at > iso639-2@loc.gov, and/or to ISO 639-3/RA by following the instructions > at http://www.sil.org/iso639-3/submit_changes.asp . No one else can > help you -- in particular, this mailing list cannot. >=20 In addition, you can use the ietf-languages list and the instructions in=20 RFC 4646 to register additional information using Comments fields. 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 Wed Nov 28 06:09: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 1IxKmq-0004H8-BG; Wed, 28 Nov 2007 06:09:00 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxKmp-0004H3-Ec for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 06:08:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKmj-0004G6-Cw for ltru@ietf.org; Wed, 28 Nov 2007 06:08:53 -0500 Received: from [133.2.253.17] (helo=scmse2.scbb.aoyama.ac.jp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxKmi-0003OM-Ll for ltru@ietf.org; Wed, 28 Nov 2007 06:08:53 -0500 Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 33ed_4b905d94_9da2_11dc_9b4d_0014221f2a2d; Wed, 28 Nov 2007 20:08:49 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53264) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 28 Nov 2007 20:04:54 +0900 Message-Id: <6.0.0.20.2.20071128154157.0aeb4820@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 28 Nov 2007 15:43:05 +0900 To: Stephane Bortzmeyer , Nicolas Krebs From: Martin Duerst Subject: Re: [Ltru] Re: Swiss German and Alsatian In-Reply-To: <20071127211255.GA23774@sources.org> References: <20071127211255.GA23774@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 06:12 07/11/28, Stephane Bortzmeyer wrote: >Well, while I'm of alsatian descent, I'm not an authority on it but I >would vote for inclusion in alemanic (alsatian is just a >dialect). That's also the opinion of Wikipedia: > >http://fr.wikipedia.org/wiki/Alsacien >http://en.wikipedia.org/wiki/Alsatian_language (the "en" version does >not include the ISO code) > >Which means that you can ask ietf-languages to register variant >"alsatian" with prefix "gsw" :-) Or a comment but my personal opinion >is that a variant reflects more the reality of alsatian. Wouldn't gsw-fr be pretty clear for Alsatian? 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 Nov 28 08:23: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 1IxMt4-00081b-9E; Wed, 28 Nov 2007 08:23:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxMt3-00081H-5x for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:23:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMt2-000817-SK for ltru@lists.ietf.org; Wed, 28 Nov 2007 08:23:32 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxMt1-0008QU-9t for ltru@lists.ietf.org; Wed, 28 Nov 2007 08:23:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxMsq-0004Vz-Db for ltru@lists.ietf.org; Wed, 28 Nov 2007 13:23:20 +0000 Received: from c-180-160-166.hh.dial.de.ignite.net ([62.180.160.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 13:23:20 +0000 Received: from nobody by c-180-160-166.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 13:23:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 28 Nov 2007 14:25:13 +0100 Organization: Lines: 9 Message-ID: References: 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: c-180-160-166.hh.dial.de.ignite.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: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: Italy and Eastern Armenian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Nicolas Krebs wrote: > Should't it be Western Armenian ?=20 Both variants exist. Is your objection about the plausibility of Latin arevela in Italy, is arevmda a better language-script-region-variant example ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 28 09:19: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 1IxNl4-0004zR-DA; Wed, 28 Nov 2007 09:19:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxNl3-0004z7-9Y for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNl3-0004yx-01 for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:19:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNl2-0005fF-Ep for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:19:20 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxNkg-0006PZ-9F for ltru@lists.ietf.org; Wed, 28 Nov 2007 14:18:58 +0000 Received: from c-180-160-166.hh.dial.de.ignite.net ([62.180.160.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 14:18:58 +0000 Received: from nobody by c-180-160-166.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 14:18:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 28 Nov 2007 15:19:53 +0100 Organization: Lines: 10 Message-ID: References: <20071127211255.GA23774@sources.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: c-180-160-166.hh.dial.de.ignite.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: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: Swiss German and Alsatian X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: > http://en.wikipedia.org/wiki/Alsatian_language=20 > (the "en" version does not include the ISO code) They now redirect Template:Sofixit to Template:Bebold, I've boldly tried to fix it, but found no good place for [[fr:Alsacien|]] in Template:Language :-( Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 28 09:45: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 1IxOAk-0000nv-0o; Wed, 28 Nov 2007 09:45:54 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxOAi-0000eu-IU for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:45:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOAi-0000a7-1s for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:45:52 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOAg-0001Ze-EF for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:45:52 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxOAd-0002rC-RA for ltru@lists.ietf.org; Wed, 28 Nov 2007 14:45:47 +0000 Received: from c-180-160-166.hh.dial.de.ignite.net ([62.180.160.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 14:45:47 +0000 Received: from nobody by c-180-160-166.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 14:45:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 28 Nov 2007 15:47:23 +0100 Organization: Lines: 12 Message-ID: References: <015701c83110$c3e87b90$6601a8c0@DGBP7M81><30b660a20711271054v28aea35dg7c6e6b600687dc46@mail.gmail.com> <20071127215213.GA2836@sources.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: c-180-160-166.hh.dial.de.ignite.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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Countries and languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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: =20 > Of course, in the name of stability, I do not suggest that we drop > them, just that we keep in mind that they are most often not a good > discriminant for languages. "Keep in mind" could be a "SHOULD" in 4646bis, that would also remove a reason for the the sudden rush to add codes of potentially disputed territories such as EA to the *language* subtag registry. Likely (?) CLDR also doesn't need EA and similar codes. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 28 09:57: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 1IxOM9-00073B-Dl; Wed, 28 Nov 2007 09:57:41 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxOM8-0006tx-5w for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOM7-0006s7-Ru for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:57:39 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOM6-0003v4-FF for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:57:39 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxOLy-0005AZ-Dm for ltru@lists.ietf.org; Wed, 28 Nov 2007 14:57:30 +0000 Received: from c-180-160-166.hh.dial.de.ignite.net ([62.180.160.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 14:57:30 +0000 Received: from nobody by c-180-160-166.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Nov 2007 14:57:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Wed, 28 Nov 2007 15:59:18 +0100 Organization: Lines: 24 Message-ID: References: <20071127193429.GH8712@mercury.ccil.org> <009401c8312f$1053a400$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: c-180-160-166.hh.dial.de.ignite.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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > The only example I recall was, for lack of a better word, > "bureaucratese," meaning the peculiar varieties of language > preferred by the governmental and quasi-governmental > officials associated with the EU. I have heard it facetiously > called "mandarin English". IIRC I used "eurocrat" as *example* here or on the review list months ago, nobody ever tried to register a variant for this. > Our job here is merely to decide whether this sort of thing > is possible, and consequently should be supported by our > procedures. Possible, supported by the 4646 rules (variant or official 3166 registration), no need to change this part of BCP 47. Especially not disguised by a simultaneous introduction of=20 exceptionally reserved codes, excluding the only arguably relevant code UK. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 28 13:37: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 1IxRmF-0001rr-Go; Wed, 28 Nov 2007 13:36:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxRmE-0001rW-8Y for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 13:36:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRmD-0001rL-EE for ltru@ietf.org; Wed, 28 Nov 2007 13:36:49 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxRmC-000498-6i for ltru@ietf.org; Wed, 28 Nov 2007 13:36:49 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Kuvq5Hf0vjXe+PzCEuJpLaeHbjGWDCe0j6sNAZ0p55DW2Kr8hJTaN4ws1t1Wuf1d; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.82.144] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IxRm8-0003ei-IZ for ltru@ietf.org; Wed, 28 Nov 2007 13:36:45 -0500 Message-ID: <006c01c831ed$dbefdfc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 28 Nov 2007 10:38:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a7132ae6c5312222423483e4b5070edb7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.82.144 X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [Ltru] Fw: trying to comment draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - I'm forwarding this posting from a list subscriber whose messages are somehow not making it to the liast software. Randy ------------------------------------- Status: U Return-Path: Received: from noehlo.host ([127.0.0.1]) by watson.mail.atl.earthlink.net (EarthLink SMTP Server) with SMTP id 1iXplX3k73Nl3qW0; Wed, 28 Nov 2007 11:01:33 -0500 (EST) Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by watson.mail.atl.earthlink.net (EarthLink SMTP Server) with ESMTP id 1iXplW7CD3Nl3qW0 for ; Wed, 28 Nov 2007 11:01:32 -0500 (EST) Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id RAA25243; Wed, 28 Nov 2007 17:00:10 +0100 (MET) Date: Wed, 28 Nov 2007 17:00:10 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281600.RAA25243@balsa.cetp.ipsl.fr> To: addison@yahoo-inc.com (Addison Phillips), duerst@it.aoyama.ac.jp.Martin.Duers, mark.davis@icu-project.org (Mark Davis), randy_presuhn@mindspring.com (Randy Presuhn) Cc: elisabeth.porteneuve@cetp.ipsl.fr Subject: trying to comment draft-ietf-ltru-4646bis-09.txt X-ELNK-Received-Info: spv=0; X-ELNK-AV: 0 X-ELNK-Info: sbv=0; sbrc=.0; sbf=00; sbw=000; Greetings, I wish to comment on draft-ietf-ltru-4646bis-09.txt, however my email does not get to the list, neither shows in archives. There is no greylisting on my side. Apparently the IETF archives are not synchronised with posts from members - I got Frank Ellermann's posts a long time before those made to archives. It's strange to not being able to communicate to an IETF group, therefore this individual post. Sorry. Kind regards, Elisabeth Porteneuve Nov 28 15:23:35 balsa sendmail[24793]: PAA24791: to=ltru@ietf.org, ctladdr=porteneu (5209/5027), delay=00:00:04, xdelay=00:00:04, mailer=esmtp, relay=stiedprmail1.ietf.org. [156.154.16.150], stat=Sent (OK id=1IxNp6-0006EC-PJ) Nov 28 15:35:02 balsa sendmail[24873]: PAA24871: to=ltru@lists.ietf.org, ctladdr=porteneu (5209/5027), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, relay=stiedprmail1.ietf.org. [156.154.16.150], stat=Sent (OK id=1IxO0D-0007uA-Gh) --- From porteneu Wed Nov 28 15:23:31 2007 To: ltru@ietf.org Subject: Re: draft-ietf-ltru-4646bis-09.txt Content-Length: 8142 Status: RO Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the UN and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368 < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Nov 28 17:03: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 1IxUzz-0005p4-VA; Wed, 28 Nov 2007 17:03:15 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxUzy-0005o3-U6 for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:03:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUzy-0005no-8R for ltru@ietf.org; Wed, 28 Nov 2007 17:03:14 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxUzx-00028Z-QX for ltru@ietf.org; Wed, 28 Nov 2007 17:03:14 -0500 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lASM3Bwr003698 for ; Wed, 28 Nov 2007 14:03:11 -0800 (PST) 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: references:in-reply-to:content-type:content-transfer-encoding; b=A5sGN85cwxI9W3gzUWNgVeEBm18lraNpyyv8u7OvD206dZt1mx28l7zQHf7kum8e Message-ID: <474DE59F.5020207@yahoo-inc.com> Date: Wed, 28 Nov 2007 14:03:11 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "'LTRU Working Group'" Subject: Re: [Ltru] Telecon Reminder/Info for 28 NOVEMBER 22:00 UTC (tomorrow)] References: <474CAFF7.2080101@yahoo-inc.com> In-Reply-To: <474CAFF7.2080101@yahoo-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org ... which would be about two minutes ago :-) Addison Addison Phillips wrote: > All, > > Tomorrow's teleconference will occur at: > > 14:00 Pacific (Wednesday, Nov. 21) > 22:00 London (Wednesday, Nov. 21) > 09:00 Sydney (Thursday, Nov. 22) > 07:00 Tokyo (Thursday, Nov. 22) > 17:00 Toronto (Wednesday, Nov. 21) > > Or Find Your Local Time Here: > > http://tinyurl.com/2a6vtn > > Dial In Information > > * USA: 1-888-371-8922 > * International: +1.617.224.4792 > > Random Other Countries: > > * Austria: (0) 1.7957.6003 > * France: (0) 1.71230263 > * Germany: 06950.072802 > * Ireland: 012421577 > * Italy: 0.269.6828.47 > * Netherlands: 0202013357 > * Spain: 9.1270268.8 > * UK: (0) 207.365.0742 > * Japan: 0335708092 > > Participant Passcode: 58371972 > > I'm still setting up a note-taking and sharing system. Will send a note > about that later. > > 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 Nov 28 17: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 1IxVAc-0004rH-IJ; Wed, 28 Nov 2007 17:14:14 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxVAb-0004qt-CK for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:14:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVAb-0004qk-1z for ltru@lists.ietf.org; Wed, 28 Nov 2007 17:14:13 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVAX-0006Xm-79 for ltru@lists.ietf.org; Wed, 28 Nov 2007 17:14:13 -0500 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.222.3; Wed, 28 Nov 2007 14:13:36 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Wed, 28 Nov 2007 14:14:04 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Wed, 28 Nov 2007 14:14:03 -0800 Thread-Topic: some issues Thread-Index: AcgyC/wn2+1YZuIKQ9WKB8MC2673tg== 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: -8.0 (--------) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: Subject: [Ltru] some issues X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0389911011==" Errors-To: ltru-bounces@ietf.org --===============0389911011== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB653NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB653NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was replying to mail yesterday from someone at my company raising concern= s with language-identification issues. His understanding was not at all up = to date, so I was trying to fill him in on some things. I tried to think of= a cross-section of issues we (mainly MS) are facing with representative ca= ses and though of the following off the top of my head. Just thought I'd sh= are it: 1. We have to distinguish between different written forms for a langu= age (script or orthography differences - e.g. Serbian in Cyrillic versus La= tin script; English with US versus UK spelling). 2. We have to support dialect distinctions in some cases (e.g. Brazil= ian vs. Iberian Portuguese). 3. We have to recognize language differences that for years have been= glossed over (e.g. "Chinese" really encompasses multiple, distinct languag= es, including Mandarin versus Cantonese). 4. We occasionally have to support quasi-dialectal variations - resou= rces tailored to cover multiple markets but not really corresponding to a p= articular dialect (e.g. Latin American Spanish) 5. We are starting to support some neo-development languages in cases= where there's a chain of closely related languages but we have to identify= a particular language in our product, yet history is yet to unfold as to w= hich varieties will become more developed than the others (e.g. Quechua). 6. Changing geo-politics that sometimes carry language-identity issue= s (but with dubious linguistic bases for differentiation, at least at prese= nt) in their wake (e.g. "Montenegrin") 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_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB653NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was replying to mail yesterday from someone at my co= mpany raising concerns with language-identification issues. His understanding was= not at all up to date, so I was trying to fill him in on some things. I tried t= o think of a cross-section of issues we (mainly MS) are facing with representative cases and though of the following off the top of my head. Ju= st thought I’d share it:

 

1.       We have to distinguish between different written forms for a language (script = or orthography differences – e.g. Serbian in Cyrillic versus Latin scrip= t; English with US versus UK spelling).

2.       We have to support dialect distinctions in some cases (e.g. Brazilian vs. Iber= ian Portuguese).

3.       We have to recognize language differences that for years have been glossed ove= r (e.g. “Chinese” really encompasses multiple, distinct languages= , including Mandarin versus Cantonese).

4.       We occasionally have to support quasi-dialectal variations – resources tailored to cover multiple markets but not really corresponding to a partic= ular dialect (e.g. Latin American Spanish)

5.       We are starting to support some neo-development languages in cases where there’s a chain of closely related languages but we have to identify = a particular language in our product, yet history is yet to unfold as to whic= h varieties will become more developed than the others (e.g. Quechua).

6.       Changing geo-politics that sometimes carry language-identity issues (but with dubiou= s linguistic bases for differentiation, at least at present) in their wake (e= .g. “Montenegrin”)

 

 

 

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/search/details.as= px?JobID=3D69CF50EA-5FB5-47C8-9083-FCE0EF9CF547

 

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB653NAEXMSGC117re_-- --===============0389911011== 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 --===============0389911011==-- From ltru-bounces@ietf.org Wed Nov 28 17:50: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 1IxVjd-0000Ix-Gs; Wed, 28 Nov 2007 17:50:25 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxVjc-0000Ir-Tu for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:50:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVjc-0000Ii-A3 for ltru@lists.ietf.org; Wed, 28 Nov 2007 17:50:24 -0500 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVjW-0007yL-L8 for ltru@lists.ietf.org; Wed, 28 Nov 2007 17:50:24 -0500 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.3) with ESMTP id md50007508208.msg for ; Wed, 28 Nov 2007 22:55:04 +0000 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Wed, 28 Nov 2007 22:50:10 +0000 From: "Debbie Garside" To: , References: Subject: RE: [Ltru] some issues Date: Wed, 28 Nov 2007 22:49:34 -0000 Message-ID: <00b101c83210$f3d335b0$0d00a8c0@CPQ86763045110> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgyC/wn2+1YZuIKQ9WKB8MC2673tgAA+9IQ X-MDHeloLookup-Result: pass smtp.helo=145.nexbyte.net (ip=62.197.41.145) (mx1.nexbyte.net) X-MDMailLookup-Result: pass smtp.mail=debbie@ictmarketing.co.uk (ip=62.197.41.145) (mx1.nexbyte.net) X-Spam-Processed: mx1.nexbyte.net, Wed, 28 Nov 2007 22:55:04 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=185224a1ca=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, Wed, 28 Nov 2007 22:55:04 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 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="===============2008776868==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============2008776868== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B2_01C83210.F3D4BC50" This is a multi-part message in MIME format. ------=_NextPart_000_00B2_01C83210.F3D4BC50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Peter As you know many of these will be facilitated by ISO 639-6 which will be submitted for FDIS vote before end of December 2007. There is scope to discuss the inclusion of ISO 639-6 within RFC4646bis according to the charter. I don't see any harm in having a discussion on this but as far as inclusion within RFC4646bis is concerned I think publication as IS will be too late; in any case, I know people here don't want to hold up the inclusion of ISO 639-3. IMHO, the WG should be rechartered after publication of RFC4646bis to include ISO 639-6 once published. Best regards Debbie _____ From: Peter Constable [mailto:petercon@microsoft.com] Sent: 28 November 2007 22:14 To: ltru@lists.ietf.org Subject: [Ltru] some issues I was replying to mail yesterday from someone at my company raising concerns with language-identification issues. His understanding was not at all up to date, so I was trying to fill him in on some things. I tried to think of a cross-section of issues we (mainly MS) are facing with representative cases and though of the following off the top of my head. Just thought I'd share it: 1. We have to distinguish between different written forms for a language (script or orthography differences - e.g. Serbian in Cyrillic versus Latin script; English with US versus UK spelling). 2. We have to support dialect distinctions in some cases (e.g. Brazilian vs. Iberian Portuguese). 3. We have to recognize language differences that for years have been glossed over (e.g. "Chinese" really encompasses multiple, distinct languages, including Mandarin versus Cantonese). 4. We occasionally have to support quasi-dialectal variations - resources tailored to cover multiple markets but not really corresponding to a particular dialect (e.g. Latin American Spanish) 5. We are starting to support some neo-development languages in cases where there's a chain of closely related languages but we have to identify a particular language in our product, yet history is yet to unfold as to which varieties will become more developed than the others (e.g. Quechua). 6. Changing geo-politics that sometimes carry language-identity issues (but with dubious linguistic bases for differentiation, at least at present) in their wake (e.g. "Montenegrin") 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=69CF50EA-5FB5 -47C8-9083-FCE0EF9CF547 ------=_NextPart_000_00B2_01C83210.F3D4BC50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Peter
 
As you know many of these will be facilitated by ISO 639-6 = which will be=20 submitted for FDIS vote before end of December 2007.  There is = scope=20 to discuss the inclusion of ISO 639-6 within RFC4646bis according to the = charter.
 
I=20 don't see any harm in having a discussion on this but as far as = inclusion within=20 RFC4646bis is concerned I think publication as IS will be too late; in = any case,=20 I know people here don't want to hold up the inclusion of ISO=20 639-3.
 
IMHO, the WG should be rechartered after publication of = RFC4646bis=20 to include ISO 639-6 once published.
 
Best regards
 
Debbie
 
 

From: Peter Constable=20 [mailto:petercon@microsoft.com]
Sent: 28 November 2007=20 22:14
To: ltru@lists.ietf.org
Subject: [Ltru] some = issues

I was replying to mail yesterday from someone at = my company=20 raising concerns with language-identification issues. His = understanding was=20 not at all up to date, so I was trying to fill him in on some things. = I tried=20 to think of a cross-section of issues we (mainly MS) are facing with=20 representative cases and though of the following off the top of my = head. Just=20 thought I’d share it:

 

1.      =20 We have to distinguish between different = written forms=20 for a language (script or orthography differences – e.g. Serbian = in Cyrillic=20 versus Latin script; English with US versus UK=20 spelling).

2.      =20 We have to support dialect distinctions in = some cases=20 (e.g. Brazilian vs. Iberian Portuguese).

3.      =20 We have to recognize language differences = that for=20 years have been glossed over (e.g. “Chinese” really = encompasses multiple,=20 distinct languages, including Mandarin versus=20 Cantonese).

4.      =20 We occasionally have to support = quasi-dialectal=20 variations – resources tailored to cover multiple markets but = not really=20 corresponding to a particular dialect (e.g. Latin American=20 Spanish)

5.      =20 We are starting to support some = neo-development=20 languages in cases where there’s a chain of closely related = languages but we=20 have to identify a particular language in our product, yet history is = yet to=20 unfold as to which varieties will become more developed than the = others (e.g.=20 Quechua).

6.      =20 Changing geo-politics that sometimes carry=20 language-identity issues (but with dubious linguistic bases for=20 differentiation, at least at present) in their wake (e.g.=20 “Montenegrin”)

 

 

 

Peter

 

Microsoft has=20 an open Program Management position working on international text and = fonts.=20 For details, go to:

http://members.microsoft.com/careers/search/details.aspx?JobID=3D69= CF50EA-5FB5-47C8-9083-FCE0EF9CF547

 

------=_NextPart_000_00B2_01C83210.F3D4BC50-- --===============2008776868== 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 --===============2008776868==-- From ltru-bounces@ietf.org Wed Nov 28 18:46: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 1IxWbW-0008IK-Vp; Wed, 28 Nov 2007 18:46:06 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxWbV-0008GV-BM for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWbV-0008GN-1U for ltru@lists.ietf.org; Wed, 28 Nov 2007 18:46:05 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWbQ-0001aT-Q4 for ltru@lists.ietf.org; Wed, 28 Nov 2007 18:46:05 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 28 Nov 2007 15:45:24 -0800 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; Wed, 28 Nov 2007 15:45:57 -0800 From: Peter Constable To: "debbie@ictmarketing.co.uk" , "ltru@lists.ietf.org" Date: Wed, 28 Nov 2007 15:45:56 -0800 Subject: RE: [Ltru] some issues Thread-Topic: [Ltru] some issues Thread-Index: AcgyC/wn2+1YZuIKQ9WKB8MC2673tgAA+9IQAAEhrFA= Message-ID: References: <00b101c83210$f3d335b0$0d00a8c0@CPQ86763045110> In-Reply-To: <00b101c83210$f3d335b0$0d00a8c0@CPQ86763045110> 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: 94962611154c8404498b19f744990308 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="===============1013515086==" Errors-To: ltru-bounces@ietf.org --===============1013515086== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB73BNAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB73BNAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's not at all obvious to me how ISO 639-6 of itself can facilitate soluti= ons to issues 4, 5 or 6. Peter. From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] Sent: Wednesday, November 28, 2007 2:50 PM To: Peter Constable; ltru@lists.ietf.org Subject: RE: [Ltru] some issues Hi Peter As you know many of these will be facilitated by ISO 639-6 which will be su= bmitted for FDIS vote before end of December 2007. There is scope to discu= ss the inclusion of ISO 639-6 within RFC4646bis according to the charter. I don't see any harm in having a discussion on this but as far as inclusion= within RFC4646bis is concerned I think publication as IS will be too late;= in any case, I know people here don't want to hold up the inclusion of ISO= 639-3. IMHO, the WG should be rechartered after publication of RFC4646bis to inclu= de ISO 639-6 once published. Best regards Debbie ________________________________ From: Peter Constable [mailto:petercon@microsoft.com] Sent: 28 November 2007 22:14 To: ltru@lists.ietf.org Subject: [Ltru] some issues I was replying to mail yesterday from someone at my company raising concern= s with language-identification issues. His understanding was not at all up = to date, so I was trying to fill him in on some things. I tried to think of= a cross-section of issues we (mainly MS) are facing with representative ca= ses and though of the following off the top of my head. Just thought I'd sh= are it: 1. We have to distinguish between different written forms for a langu= age (script or orthography differences - e.g. Serbian in Cyrillic versus La= tin script; English with US versus UK spelling). 2. We have to support dialect distinctions in some cases (e.g. Brazil= ian vs. Iberian Portuguese). 3. We have to recognize language differences that for years have been= glossed over (e.g. "Chinese" really encompasses multiple, distinct languag= es, including Mandarin versus Cantonese). 4. We occasionally have to support quasi-dialectal variations - resou= rces tailored to cover multiple markets but not really corresponding to a p= articular dialect (e.g. Latin American Spanish) 5. We are starting to support some neo-development languages in cases= where there's a chain of closely related languages but we have to identify= a particular language in our product, yet history is yet to unfold as to w= hich varieties will become more developed than the others (e.g. Quechua). 6. Changing geo-politics that sometimes carry language-identity issue= s (but with dubious linguistic bases for differentiation, at least at prese= nt) in their wake (e.g. "Montenegrin") 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_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB73BNAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s not at all ob= vious to me how ISO 639-6 of itself can facilitate solutions to issues 4, 5 or 6.

 =

 =

Peter.=

&nb= sp;

 =

From: Debbie Garsid= e [mailto:debbie@ictmarketing.co.uk]
Sent: Wednesday, November 28, 2007 2:50 PM
To: Peter Constable; ltru@lists.ietf.org
Subject: RE: [Ltru] some issues

 

Hi Peter

 

As you know many of these will be facilitated by ISO 639-6 which will be submi= tted for FDIS vote before end of December 2007.  There is scope to dis= cuss the inclusion of ISO 639-6 within RFC4646bis according to the charter.

 

I don't see any harm in having a discussion on this but as far as inclusion within RFC4646bis is concerned I think publication as IS will be too late; = in any case, I know people here don't want to hold up the inclusion of ISO 639= -3.

 

IMHO, the WG should be rechartered after publication of RFC4646bis to includ= e ISO 639-6 once published.

 

Best regards

 

Debbie

 

 

 

From: Peter Constable [mailto:petercon@microsoft.com]
Sent: 28 November 2007 22:14
To: ltru@lists.ietf.org
Subject: [Ltru] some issues

I was replying to mail yesterday from someone at my co= mpany raising concerns with language-identification issues. His understanding was= not at all up to date, so I was trying to fill him in on some things. I tried t= o think of a cross-section of issues we (mainly MS) are facing with representative cases and though of the following off the top of my head. Ju= st thought I’d share it:

 

1.       We have to distinguish between differe= nt written forms for a language (script or orthography differences – e.g= . Serbian in Cyrillic versus Latin script; English with US versus UK spelling= ).

2.       We have to support dialect distinction= s in some cases (e.g. Brazilian vs. Iberian Portuguese).

3.       We have to recognize language differen= ces that for years have been glossed over (e.g. “Chinese” really encompasses multiple, distinct languages, including Mandarin versus Cantone= se).

4.       We occasionally have to support quasi-dialectal variations – resources tailored to cover multiple mar= kets but not really corresponding to a particular dialect (e.g. Latin American Spanish)

5.       We are starting to support some neo-development languages in cases where there’s a chain of closely related languages but we have to identify a particular language in our prod= uct, yet history is yet to unfold as to which varieties will become more develop= ed than the others (e.g. Quechua).

6.       Changing geo-politics that sometimes c= arry language-identity issues (but with dubious linguistic bases for differentiation, at least at present) in their wake (e.g. “Montenegrin”)

 

 

 

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/se= arch/details.aspx?JobID=3D69CF50EA-5FB5-47C8-9083-FCE0EF9CF547

 

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB73BNAEXMSGC117re_-- --===============1013515086== 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 --===============1013515086==-- From ltru-bounces@ietf.org Wed Nov 28 18:57: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 1IxWmL-0003ld-GB; Wed, 28 Nov 2007 18:57:17 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxWmK-0003lN-MI for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWmK-0003kT-CE for ltru@lists.ietf.org; Wed, 28 Nov 2007 18:57:16 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWmH-0001zJ-G9 for ltru@lists.ietf.org; Wed, 28 Nov 2007 18:57:16 -0500 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.222.3; Wed, 28 Nov 2007 15:56:40 -0800 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; Wed, 28 Nov 2007 15:57:13 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Wed, 28 Nov 2007 15:57:11 -0800 Thread-Topic: action item: "other" collections in 639 Thread-Index: AcgyGmRPmfRBEGk4Rq+jYeIDNeCX8A== 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: -8.0 (--------) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Subject: [Ltru] action item: "other" collections in 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0704469946==" Errors-To: ltru-bounces@ietf.org --===============0704469946== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB756NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB756NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In our teleconf, I took an action to push the ISO 639 JAC for action on get= ting rid of "other" collections. Last status was that I raised the issue within the JAC back in April. There= was a bit of discussion, but I had also raised the "mis" issue at the same= time, and that got all the attention. There were just a couple of comments= wrt "other": someone from LOC mentioned that "other" was still meaningful = for those using 639-2 and not 639-3 (implying a desire not to change). I su= ggested that that was an issue to be handled by applications of a 639 stand= ard. Another member replied that, in the context of 639 as a whole, there c= an be applications using different subsets, and so "other" would need to be= defined in the context of the particular subset. Also relevant here is that the code table in ISO/FDIS 639-5 does not includ= e "other" in *any* of the entries (which are a superset of the collections = in 639-2). That itself suggests to me that getting rid of "other" is very l= ikely to happen and that it's just a matter of how long it takes for that t= o get reflected in data tables provided by either LOC or SIL. At any rate, I have restarted discussion on this within the JAC and will tr= y to push for quick action. 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_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB756NAEXMSGC117re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In our teleconf, I took an action to push the ISO 639 = JAC for action on getting rid of “other” collections.

 

Last status was that I raised the issue within the JAC= back in April. There was a bit of discussion, but I had also raised the “m= is” issue at the same time, and that got all the attention. There were just a couple of comments wrt “other”: someone from LOC mentioned that= “other” was still meaningful for those using 639-2 and not 639-3 (implying a desire= not to change). I suggested that that was an issue to be handled by application= s of a 639 standard. Another member replied that, in the context of 639 as a who= le, there can be applications using different subsets, and so “other̶= 1; would need to be defined in the context of the particular subset.

 

Also relevant here is that the code table in ISO/FDIS = 639-5 does not include “other” in *any* of the entries (which are a= superset of the collections in 639-2). That itself suggests to me that getting rid o= f “other” is very likely to happen and that it’s just a matter of how long it t= akes for that to get reflected in data tables provided by either LOC or SIL.

 

At any rate, I have restarted discussion on this withi= n the JAC and will try to push for quick action.

 

 

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/search/details.as= px?JobID=3D69CF50EA-5FB5-47C8-9083-FCE0EF9CF547

 

--_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB756NAEXMSGC117re_-- --===============0704469946== 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 --===============0704469946==-- From ltru-bounces@ietf.org Wed Nov 28 19:05: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 1IxWtt-0007Mn-UP; Wed, 28 Nov 2007 19:05:05 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxWts-0007Mf-Jq for ltru-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 19:05:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWts-0007MW-9l for ltru@lists.ietf.org; Wed, 28 Nov 2007 19:05:04 -0500 Received: from ag-out-0708.google.com ([72.14.246.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWtr-0002Ge-Ng for ltru@lists.ietf.org; Wed, 28 Nov 2007 19:05:04 -0500 Received: by ag-out-0708.google.com with SMTP id 5so2102386agb for ; Wed, 28 Nov 2007 16:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=OcAUp9MVm4yHXx2qMz+xwtmZGS1rpmrBqjsAlQb4Ils=; b=jbetzDFOxnB9yL/yDvOBxaxGjVGenvWnx83DbMJ6+oJUo/zUYHO8TKWz27qfhGB5iB5ZYmaXB+0LviVFCKPyACAZXtD1L3M0F3U+rGsCbCNokOoh8nzd7YP+Z8AMUg3C39nLWjD/Ztf+lPG4IKGHQs//4VmeJvWDJ2m+LwTMjPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=V5x1qL+GocuTW7wdhEZcMyuqkTsJfSWYA0Fec28UUSmGJ4d/Qc1yz8T6BbbREJTM5DA/8PQM6QrlrSrIrx5kxCWROY7GaHXZXxs2DHWnjV8nzY0S1Jt7/RNHF5bvB3GcQUqnxa5O2uWqM603fM8JN6sbhnExp1ruVKXveSUp36k= Received: by 10.114.27.20 with SMTP id a20mr283623waa.1196294702905; Wed, 28 Nov 2007 16:05:02 -0800 (PST) Received: by 10.114.198.8 with HTTP; Wed, 28 Nov 2007 16:05:02 -0800 (PST) Message-ID: <30b660a20711281605p52608b2bg3a5308caeca6aa05@mail.gmail.com> Date: Wed, 28 Nov 2007 16:05:02 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] action item: "other" collections in 639 In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: a25276a951f65a5a X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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="===============1830743438==" Errors-To: ltru-bounces@ietf.org --===============1830743438== Content-Type: multipart/alternative; boundary="----=_Part_7518_3289870.1196294702900" ------=_Part_7518_3289870.1196294702900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That'd be great. Thanks, Peter. On Nov 28, 2007 3:57 PM, Peter Constable wrote: > In our teleconf, I took an action to push the ISO 639 JAC for action on > getting rid of "other" collections. > > > > Last status was that I raised the issue within the JAC back in April. > There was a bit of discussion, but I had also raised the "mis" issue at the > same time, and that got all the attention. There were just a couple of > comments wrt "other": someone from LOC mentioned that "other" was still > meaningful for those using 639-2 and not 639-3 (implying a desire not to > change). I suggested that that was an issue to be handled by applications of > a 639 standard. Another member replied that, in the context of 639 as a > whole, there can be applications using different subsets, and so "other" > would need to be defined in the context of the particular subset. > > > > Also relevant here is that the code table in ISO/FDIS 639-5 does not > include "other" in **any** of the entries (which are a superset of the > collections in 639-2). That itself suggests to me that getting rid of > "other" is very likely to happen and that it's just a matter of how long it > takes for that to get reflected in data tables provided by either LOC or > SIL. > > > > At any rate, I have restarted discussion on this within the JAC and will > try to push for quick action. > > > > > > 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=69CF50EA-5FB5-47C8-9083-FCE0EF9CF547 > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- Mark ------=_Part_7518_3289870.1196294702900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That'd be great. Thanks, Peter.

On Nov 28, 2007 3:57 PM, Peter Constable <petercon@microsoft.com> wrote:

In our teleconf, I took an action to push the ISO 639 JAC for action on getting rid of "other" collections.

 

Last status was that I raised the issue within the JAC back in April. There was a bit of discussion, but I had also raised the "mis" issue at the same time, and that got all the attention. There were just a couple of comments wrt "other": someone from LOC mentioned that "other" was still meaningful for those using 639-2 and not 639-3 (implying a desire not to change). I suggested that that was an issue to be handled by applications of a 639 standard. Another member replied that, in the context of 639 as a whole, there can be applications using different subsets, and so "other" would need to be defined in the context of the particular subset.

 

Also relevant here is that the code table in ISO/FDIS 639-5 does not include "other" in *any* of the entries (which are a superset of the collections in 639-2). That itself suggests to me that getting rid of "other" is very likely to happen and that it's just a matter of how long it takes for that to get reflected in data tables provided by either LOC or SIL.

 

At any rate, I have restarted discussion on this within the JAC and will try to push for quick action.

 

 

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=69CF50EA-5FB5-47C8-9083-FCE0EF9CF547

 


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




--
Mark ------=_Part_7518_3289870.1196294702900-- --===============1830743438== 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 --===============1830743438==-- From ltru-bounces@ietf.org Thu Nov 29 01: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 1IxdAG-0007K0-NM; Thu, 29 Nov 2007 01:46:24 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxdAG-0007HO-5t for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:46:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdAF-0007Ex-P4 for ltru@ietf.org; Thu, 29 Nov 2007 01:46:23 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxdAF-0005eH-C6 for ltru@ietf.org; Thu, 29 Nov 2007 01:46:23 -0500 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 <20071129064622.YXQQ13553.mta13.adelphia.net@DGBP7M81> for ; Thu, 29 Nov 2007 01:46:22 -0500 Message-ID: <003301c83253$8e31ec90$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 28 Nov 2007 22:46:22 -0800 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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 only example I recall was, for lack of a better word, >> "bureaucratese," meaning the peculiar varieties of language >> preferred by the governmental and quasi-governmental >> officials associated with the EU. I have heard it facetiously >> called "mandarin English". > > IIRC I used "eurocrat" as *example* here or on the review > list months ago, nobody ever tried to register a variant > for this. In June 2003 there was a serious proposal to register a variant tag for Newspeak, as described in Orwell's "1984." The proposal was quite sensibly rejected. I can hardly believe that four years later, and supposedly four years wiser, we have arrived at the point where, having identified a brand of jargon much less radical than Newspeak, and not nearly as well defined, we wish not merely to register a variant subtag for it, but to change the registration rules to permit the addition of a *region* subtag for it. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Thu Nov 29 01:50: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 1IxdDs-0002km-T7; Thu, 29 Nov 2007 01:50:08 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxdDr-0002kf-9h for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdDq-0002kW-Ub for ltru@ietf.org; Thu, 29 Nov 2007 01:50:06 -0500 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 1IxdDq-0008Bb-FB for ltru@ietf.org; Thu, 29 Nov 2007 01:50:06 -0500 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 <20071129065005.ETJD13145.mta15.adelphia.net@DGBP7M81> for ; Thu, 29 Nov 2007 01:50:05 -0500 Message-ID: <003b01c83254$13459cb0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 28 Nov 2007 22:50:05 -0800 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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ltru] Re: trying to comment draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Elisabeth Porteneuve that we should be referencing the 2006 version of ISO 3166, and not the 1997 version. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Thu Nov 29 01:55: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 1IxdJM-00009p-0W; Thu, 29 Nov 2007 01:55:48 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxdJK-0008Vi-Q7 for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:55:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdJK-0008VY-GU for ltru@ietf.org; Thu, 29 Nov 2007 01:55:46 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxdJK-00007U-4y for ltru@ietf.org; Thu, 29 Nov 2007 01:55:46 -0500 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 <20071129065545.JGFV6607.mta11.adelphia.net@DGBP7M81> for ; Thu, 29 Nov 2007 01:55:45 -0500 Message-ID: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Wed, 28 Nov 2007 22:55:45 -0800 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: action item: "other" collections in 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > In our teleconf, I took an action to push the ISO 639 JAC for action > on getting rid of "other" collections. By "getting rid of" I take it you mean "withdrawing" them. That would have the effect of allowing us to deprecate them in the Registry, but of course they could not actually be deleted from the Registry; we've promised never to do that. Of course, if we're ready to add the exceptionally reserved 3166 codes, it wouldn't be that much of a stretch to make another change to 4646bis to deprecate all language subtags based on codes not in 639-3, which basically means all the collection codes. That way we wouldn't have to wait for the JAC, just as we've chosen not to wait for 3166/MA. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Thu Nov 29 02:02: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 1IxdPx-0007Ww-SZ; Thu, 29 Nov 2007 02:02:37 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxdPw-0007Wk-Uy for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 02:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdPw-0007Wb-EM for ltru@ietf.org; Thu, 29 Nov 2007 02:02:36 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxdPv-0000ev-W5 for ltru@ietf.org; Thu, 29 Nov 2007 02:02:36 -0500 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.222.3; Wed, 28 Nov 2007 23:02:02 -0800 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, 28 Nov 2007 23:02:35 -0800 From: Peter Constable To: LTRU Working Group Date: Wed, 28 Nov 2007 23:02:33 -0800 Subject: RE: [Ltru] Re: action item: "other" collections in 639 Thread-Topic: [Ltru] Re: action item: "other" collections in 639 Thread-Index: AcgyVODdD1k2CPy/RZ2LGOLo/INd/QAABw4Q Message-ID: References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> In-Reply-To: <003d01c83254$ddd0cef0$6601a8c0@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: -8.0 (--------) 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: , Content-Type: multipart/mixed; boundary="===============0368823962==" Errors-To: ltru-bounces@ietf.org --===============0368823962== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQHJvYWRydW5uZXIuY29tXQ0KDQo+ID4g SW4gb3VyIHRlbGVjb25mLCBJIHRvb2sgYW4gYWN0aW9uIHRvIHB1c2ggdGhlIElTTyA2MzkgSkFD IGZvciBhY3Rpb24NCj4gPiBvbiBnZXR0aW5nIHJpZCBvZiAib3RoZXIiIGNvbGxlY3Rpb25zLg0K Pg0KPiBCeSAiZ2V0dGluZyByaWQgb2YiIEkgdGFrZSBpdCB5b3UgbWVhbiAid2l0aGRyYXdpbmci IHRoZW0uDQoNCk9oLCBteSEgTm8hIEkgZGlkbid0IGV4cHJlc3MgdGhhdCB2ZXJ5IGNsZWFybHk6 IEkgbWVhbiBkZWxldGluZyAiKE90aGVyKSIgZnJvbSBsYW5ndWFnZSBuYW1lcyBzbyB0aGF0IGFs bCBjb2xsZWN0aW9ucyBpbiBJU08gNjM5IGFyZSBub21pbmFsbHkgaW5jbHVzaXZlICh0aG91Z2gg YW55IGFwcGxpY2F0aW9uLCBwYXJ0aWN1bGFyIHRob3NlIHVzaW5nIGEgc3Vic2V0IG9mIGFsbCA2 MzkgZW50aXRpZXMsIGNhbiB0cmVhdCBjZXJ0YWluIGNvbGxlY3Rpb25zIGFzIGV4Y2x1c2l2ZSwg InJlbWFpbmRlciBvbmx5IiBncm91cHMpLg0KDQoNCj4gT2YgY291cnNlLCBpZiB3ZSdyZSByZWFk eSB0byBhZGQgdGhlIGV4Y2VwdGlvbmFsbHkgcmVzZXJ2ZWQgMzE2NiBjb2RlcywNCj4gaXQgd291 bGRuJ3QgYmUgdGhhdCBtdWNoIG9mIGEgc3RyZXRjaCB0byBtYWtlIGFub3RoZXIgY2hhbmdlIHRv IDQ2NDZiaXMNCj4gdG8gZGVwcmVjYXRlIGFsbCBsYW5ndWFnZSBzdWJ0YWdzIGJhc2VkIG9uIGNv ZGVzIG5vdCBpbiA2MzktMywgd2hpY2gNCj4gYmFzaWNhbGx5IG1lYW5zIGFsbCB0aGUgY29sbGVj dGlvbiBjb2Rlcy4gIFRoYXQgd2F5IHdlIHdvdWxkbid0IGhhdmUgdG8NCj4gd2FpdCBmb3IgdGhl IEpBQywganVzdCBhcyB3ZSd2ZSBjaG9zZW4gbm90IHRvIHdhaXQgZm9yIDMxNjYvTUEuDQoNCkkn dmUgc3VnZ2VzdGVkIGluIHRoZSBwYXN0IHRoYXQgcmVtb3ZpbmcgY29sbGVjdGlvbiBJRHMgZnJv bSBCQ1A0NyBtaWdodCBub3QgYmUgYSBiYWQgaWRlYSwgYnV0IG9uIHNldmVyYWwgb2NjYXNpb25z IHBlb3BsZSBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgd2lzaCB0byBoYXZlIHRoZSBjb2xsZWN0 aW9ucyBrZXB0Lg0KDQoNCg0KUGV0ZXINCg== --===============0368823962== 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 --===============0368823962==-- From ltru-bounces@ietf.org Thu Nov 29 05:17:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgSG-0003bV-BZ; Thu, 29 Nov 2007 05:17:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxgSE-0003b2-TA for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgSE-0003ap-GK for ltru@ietf.org; Thu, 29 Nov 2007 05:17:10 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxgSE-00014h-0F for ltru@ietf.org; Thu, 29 Nov 2007 05:17:10 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6FC831C011E for ; Thu, 29 Nov 2007 11:17:09 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 6C4D21C00F0 for ; Thu, 29 Nov 2007 11:17:09 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 603BB58ECBE for ; Thu, 29 Nov 2007 11:17:09 +0100 (CET) Date: Thu, 29 Nov 2007 11:17:09 +0100 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20071129101709.GA25814@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-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Ltru] Language tags in the future version of HTTP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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's relevant to us, I believe. Working Group httpbis is working on it: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHp-0006Ob-V5; Thu, 29 Nov 2007 07:14:33 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006GC-NS for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006D1-6c for ltru@ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNp9-0004H4-1g for ltru@ietf.org; Wed, 28 Nov 2007 09:23:35 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNp6-0006EC-PJ for ltru@ietf.org; Wed, 28 Nov 2007 09:23:35 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id PAA24791 for ltru@ietf.org; Wed, 28 Nov 2007 15:23:31 +0100 (MET) Date: Wed, 28 Nov 2007 15:23:31 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281423.PAA24791@balsa.cetp.ipsl.fr> To: ltru@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 Subject: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the UN and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368 < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHq-0006Of-1O; Thu, 29 Nov 2007 07:14:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006GE-Nd for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Dc-8m for ltru@lists.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO0E-0004qp-KI for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:35:02 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxO0D-0007uA-Gh for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:35:02 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id PAA24871 for ltru@lists.ietf.org; Wed, 28 Nov 2007 15:35:00 +0100 (MET) Date: Wed, 28 Nov 2007 15:35:00 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281435.PAA24871@balsa.cetp.ipsl.fr> To: ltru@lists.ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 Cc: Subject: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the UN and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHp-0006Ob-V5; Thu, 29 Nov 2007 07:14:33 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006GC-NS for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006D1-6c for ltru@ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNp9-0004H4-1g for ltru@ietf.org; Wed, 28 Nov 2007 09:23:35 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNp6-0006EC-PJ for ltru@ietf.org; Wed, 28 Nov 2007 09:23:35 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id PAA24791 for ltru@ietf.org; Wed, 28 Nov 2007 15:23:31 +0100 (MET) Date: Wed, 28 Nov 2007 15:23:31 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281423.PAA24791@balsa.cetp.ipsl.fr> To: ltru@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 Subject: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the U < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHq-0006Ok-6x; Thu, 29 Nov 2007 07:14:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Gq-Qz for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Du-Af for ltru@ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTDS-0001CQ-23 for ltru@ietf.org; Wed, 28 Nov 2007 15:09:02 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTDQ-0005KH-Fa for ltru@ietf.org; Wed, 28 Nov 2007 15:09:02 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id VAA26080; Wed, 28 Nov 2007 21:08:59 +0100 (MET) Date: Wed, 28 Nov 2007 21:08:59 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711282008.VAA26080@balsa.cetp.ipsl.fr> To: ltru@ietf.org, randy_presuhn@mindspring.com Subject: Re: [Ltru] Fw: trying to comment draft-ietf-ltru-4646bis-09.txt X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 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 Many thanks Randy. Elisabeth Porteneuve _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru N and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368 < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHq-0006Of-1O; Thu, 29 Nov 2007 07:14:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006GE-Nd for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Dc-8m for ltru@lists.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO0E-0004qp-KI for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:35:02 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxO0D-0007uA-Gh for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:35:02 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id PAA24871 for ltru@lists.ietf.org; Wed, 28 Nov 2007 15:35:00 +0100 (MET) Date: Wed, 28 Nov 2007 15:35:00 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281435.PAA24871@balsa.cetp.ipsl.fr> To: ltru@lists.ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 Cc: Subject: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the UN and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368 < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHq-0006Ok-6x; Thu, 29 Nov 2007 07:14:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Gq-Qz for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Du-Af for ltru@ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTDS-0001CQ-23 for ltru@ietf.org; Wed, 28 Nov 2007 15:09:02 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTDQ-0005KH-Fa for ltru@ietf.org; Wed, 28 Nov 2007 15:09:02 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id VAA26080; Wed, 28 Nov 2007 21:08:59 +0100 (MET) Date: Wed, 28 Nov 2007 21:08:59 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711282008.VAA26080@balsa.cetp.ipsl.fr> To: ltru@ietf.org, randy_presuhn@mindspring.com Subject: Re: [Ltru] Fw: trying to comment draft-ietf-ltru-4646bis-09.txt X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 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 Many thanks Randy. Elisabeth Porteneuve _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHp-0006Ob-V5; Thu, 29 Nov 2007 07:14:33 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006GC-NS for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006D1-6c for ltru@ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNp9-0004H4-1g for ltru@ietf.org; Wed, 28 Nov 2007 09:23:35 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNp6-0006EC-PJ for ltru@ietf.org; Wed, 28 Nov 2007 09:23:35 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id PAA24791 for ltru@ietf.org; Wed, 28 Nov 2007 15:23:31 +0100 (MET) Date: Wed, 28 Nov 2007 15:23:31 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281423.PAA24791@balsa.cetp.ipsl.fr> To: ltru@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 Subject: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the UN and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368 < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHq-0006Of-1O; Thu, 29 Nov 2007 07:14:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006GE-Nd for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Dc-8m for ltru@lists.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxO0E-0004qp-KI for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:35:02 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxO0D-0007uA-Gh for ltru@lists.ietf.org; Wed, 28 Nov 2007 09:35:02 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id PAA24871 for ltru@lists.ietf.org; Wed, 28 Nov 2007 15:35:00 +0100 (MET) Date: Wed, 28 Nov 2007 15:35:00 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711281435.PAA24871@balsa.cetp.ipsl.fr> To: ltru@lists.ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 Cc: Subject: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Re: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-09.txt Greetings, Allow me to comment the LTRU draft (I am not on your list), and provide a diff with proposed corrections. I read the above draft, and found it very confusing with regards to ISO 3166. The draft uses the term "ISO 3166" indifferently to design (1) Maintenance Agency, (2) all ISO 3166 standards, and (3) the specific ISO 3166-1 alpha-2 list. Furthermore the draft points to the ISO 3166-1:1997 edition in 9.1 "Normative References", instead of its successor ISO 3166-1:2006 - which makes its own example for Serbia out of context (the "RS" code was added in 2006 edition). Quoting ISO 3166-1:2006 document: This second edition of ISO 3166-1 cancels and replaces ISO 3166-1:1997, of which it constitutes a complete revision. The International Standard was previously published in 1974, 1981, 1988 and 1993 as ISO 3166. In 1997, it was split into three parts. Eventually I would stress out that a compilation of language subtags MUST provide information on date of its ISO's sources, at least as far as ISO 3166-1 table is concerned. There is a number of very different reasons for which "exceptionally reserved" exist, it is not good to consider them equal with regards to the subtag list, cf. http://www.iso.org/iso/iso-3166-1_decoding_table It's much better IMHO to state clear subtag exceptions (EU, UK). Finally the IETF draft makes a provision to synchronise the ISO-3166 tables with UN M.49 ones, assuming or suggesting that those two organisations does not check together. The fact is that the ISO 3166-1 table is made, among other, with alpha-2, alpha-3 and M.49 codes. Specifically: Re 2.2.4: 2 and 3: "ISO 3166 maintenance agency or governing standardization bodies" - what is "governing standardization body?" 3.C: "ambiguous ISO 3166 alpha-2 codes" - what does it mean "ambiguous" in ISO 3166 context? 4. Note in parenthesis is twice undefined: "the time of this document was created" and the edition of ISO 3166-1. Re 3.4.17: Does it describe how the-code-is-the-law will diverge from the UN and the sovereign nations if the world decide any change? Kind regards, Elisabeth Porteneuve 305c305 < region = 2ALPHA ; ISO 3166-1 alpha-2 code --- > region = 2ALPHA ; ISO 3166 code 706c706 < "exceptionally reserved" (as opposed to "assigned") in [ISO3166-1] --- > "exceptionally reserved" (as opposed to "assigned") in ISO 3166-1 722c722 < ISO 3166-1 alpha-2 code and represent supra-national areas, --- > ISO 3166 alpha-2 code and represent supra-national areas, 739c739 < 3166-1 alpha-2 codes, when entered into the registry, MUST be --- > 3166 alpha-2 codes, when entered into the registry, MUST be 745c745 < associated ISO 3166-1 alpha-2 code in the registry MUST NOT be --- > associated ISO 3166 alpha-2 code in the registry MUST NOT be 747c747 < language tags. Note that the ISO 3166-1 based subtag in the --- > language tags. Note that the ISO 3166-based subtag in the 751c751 < E. UN numeric codes and ISO 3166-1 alpha-2 codes for countries or --- > E. UN numeric codes and ISO 3166 alpha-2 codes for countries or 758c758 < have an associated ISO 3166-1 alpha-2 code MUST NOT be entered --- > have an associated ISO 3166 alpha-2 code MUST NOT be entered 765c765 < these values matched the ISO 3166-1 alpha-2 codes.) --- > these values matched the ISO 3166 alpha-2 codes.) 773c773 < correspond to codes reserved by ISO 3166/MA in ISO 3166-1 alpha-2 list for private use. These --- > correspond to codes reserved by ISO 3166 for private use. These 1298c1298 < numeric region subtags defined by ISO 3166/MA in ISO 3166-1 alpha-2 list) MUST use uppercase. --- > numeric region subtags defined by ISO 3166) MUST use uppercase. 1354c1354 < ISO 15924, ISO 3166-1, or UN M.49 codes are intended only to indicate --- > ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate 1368c1368 < ISO 3166/MA, withdrawing a code. In some historical cases, it might not --- > ISO 3166, withdrawing a code. In some historical cases, it might not 1387c1387 < 2. ISO 3166-1 alpha-2 region codes that have been withdrawn in favor of a new --- > 2. ISO 3166 region codes that have been withdrawn in favor of a new 1578c1578 < withdrawn by ISO 639, ISO 15924, ISO 3166/MA, and UN M.49, the Language --- > withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language 1605c1605 < 15924, ISO 3166/MA, and UN M.49 are reflected in the IANA Language --- > 15924, ISO 3166, and UN M.49 are reflected in the IANA Language 1704c1704 < 14. Codes assigned by ISO 15924 and ISO 3166/MA in ISO 3166-1 alpha-2 list that do not conflict --- > 14. Codes assigned by ISO 15924 and ISO 3166 that do not conflict 1709c1709 < 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that are --- > 15. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are 1726c1726 < 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166/MA in ISO 3166-1 alpha-2 list that conflict --- > 16. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict 1751c1751 < standard (that is, by ISO 639, ISO 15924, ISO 3166-1, or UN --- > standard (that is, by ISO 639, ISO 15924, ISO 3166, or UN 1771c1771 < D. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > D. For ISO 3166 codes, if the newly assigned code's meaning is 1776c1776 < indicating the relationship to the new ISO 3166-1 code. --- > indicating the relationship to the new ISO 3166 code. 1778c1778 < E. For ISO 3166-1 codes, if the newly assigned code's meaning is --- > E. For ISO 3166 codes, if the newly assigned code's meaning is 1785c1785 < F. For ISO 3166-1 codes, if there is no associated UN numeric --- > F. For ISO 3166 codes, if there is no associated UN numeric 1808,1809c1808,1809 < there is no corresponding ISO 3166-1 code SHOULD NOT be < registered, except as a surrogate for an ISO 3166-1 code that is --- > there is no corresponding ISO 3166 code SHOULD NOT be > registered, except as a surrogate for an ISO 3166 code that is 1811c1811 < becomes necessary, then the registration authority for ISO 3166-1 --- > becomes necessary, then the registration authority for ISO 3166 1813c1813 < the petition for a code assignment by ISO 3166/MA is refused or not --- > the petition for a code assignment by ISO 3166 is refused or not 1817c1817 < value of last resort in cases where ISO 3166/MA reassigns a --- > value of last resort in cases where ISO 3166 reassigns a 1871c1871 < with ISO 639, ISO 15924, ISO 3166-1, and UN M.49 within the limits --- > with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits 2147c2147 < to reflect assignments made by ISO 639, ISO 15924, ISO 3166/MA, and --- > to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and 2198c2198 < The maintenance agency for ISO 3166-1 (country codes) is: --- > The maintenance agency for ISO 3166 (country codes) is: 3008c3008 < 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166-1 alpha-2 private use codes) MAY --- > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY 3547,3550c3547,3549 < International Organization for Standardization, "ISO < 3166-1. Codes for the representation of names of countries < and their subdivisions -- Part 1: Country codes". < Second edition ISO 3166-1:2006, November 2006. --- > International Organization for Standardization, "ISO 3166- > 1:1997. Codes for the representation of names of countries > and their subdivisions -- Part 1: Country codes", 1997. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 07:14: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 1IxiHq-0006Ok-6x; Thu, 29 Nov 2007 07:14:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Gq-Qz for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxiHo-0006Du-Af for ltru@ietf.org; Thu, 29 Nov 2007 07:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTDS-0001CQ-23 for ltru@ietf.org; Wed, 28 Nov 2007 15:09:02 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTDQ-0005KH-Fa for ltru@ietf.org; Wed, 28 Nov 2007 15:09:02 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id VAA26080; Wed, 28 Nov 2007 21:08:59 +0100 (MET) Date: Wed, 28 Nov 2007 21:08:59 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711282008.VAA26080@balsa.cetp.ipsl.fr> To: ltru@ietf.org, randy_presuhn@mindspring.com Subject: Re: [Ltru] Fw: trying to comment draft-ietf-ltru-4646bis-09.txt X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-TMDA-Released: Thu, 29 Nov 2007 07:14:32 -0500 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 Many thanks Randy. Elisabeth Porteneuve _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 08:21: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 1IxjKM-0001E5-Ck; Thu, 29 Nov 2007 08:21:14 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxjKL-0001Dn-6g for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 08:21:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjKK-0001Da-SA for ltru@ietf.org; Thu, 29 Nov 2007 08:21:12 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxjKK-0001nY-J2 for ltru@ietf.org; Thu, 29 Nov 2007 08:21:12 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IxjKJ-0005Dg-T8; Thu, 29 Nov 2007 08:21:11 -0500 Date: Thu, 29 Nov 2007 08:21:11 -0500 To: Stephane Bortzmeyer Subject: Re: [Ltru] Language tags in the future version of HTTP Message-ID: <20071129132111.GB32134@mercury.ccil.org> References: <20071129101709.GA25814@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129101709.GA25814@nic.fr> 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 Stephane Bortzmeyer scripsit: > That's relevant to us, I believe. Working Group httpbis is working on it: > > http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13 Looks like all's going well. Since you're on that list, could you persuade them to use "BCP 47" as the reference rather than "RFC 4646"? Emphasize if necessary that "once a valid tag, always a valid tag" so they need not fear automatically incorporating our updates. In addition, ideally the discussion of language-tag matching in Section 14.4 should also defer to BCP 47. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a cowan@ccil.org great strength of will to turn it to other http://ccil.org/~cowan purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 09: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 1IxkXy-0001na-LO; Thu, 29 Nov 2007 09:39:22 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxkXy-0001nF-7C for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 09:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkXx-0001n5-Tz for ltru@ietf.org; Thu, 29 Nov 2007 09:39:21 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxkXx-0004Mg-4u for ltru@ietf.org; Thu, 29 Nov 2007 09:39:21 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IxkXw-0003lD-TW for ltru@ietf.org; Thu, 29 Nov 2007 09:39:20 -0500 Date: Thu, 29 Nov 2007 09:39:20 -0500 To: ltru@ietf.org Message-ID: <20071129143920.GC32134@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Ltru] John Cowan throws in the towel on extlangs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org After yesterday's telcon, it became clear to me that we had no movement toward reconciling the extlang-yes and the extlang-no factions, and that if we were ever to make progress, someone would have to concede. That turns out to be me. No one else has been actually defending the use of extlangs, and several people are either mildly or strongly against them, so all I am doing now is blocking consensus to no purpose. Therefore, I have reluctantly ceased to block it. The strongest argument against extlang tags is that our simple remove-from-right lookup algorithm ends up losing too much information. If you ask for "zh-yue-Hant", and there are no Cantonese resources, then by the time you have truncated the tag to just "zh" you have forgotten that Traditional Han script was required. In order to prevent it, we would have to change 4647 to specify a sequence like zh-yue-Hant > zh-yue > zh-Hant > zh, where the extlang tag is treated magically; in essence, stripping it restores all other tags. That would be fine, except that no one actually does it or is likely to for some time to come. Everything else is more or less symmetrical. For example, almost all content tagged 'zh' is in fact Mandarin, as an uncontroversial consequence of the fact that almost all tagged content is written, and almost all written Chinese is in fact Mandarin. There will be a problem in getting good matches if people use the new 'cmn' subtag, as naive matchers will not know its relationship to 'zh', but no worse than the problems shown above for Cantonese. In practical terms, this means that (unless someone else wants to take up the cause on the LTRU mailing list and see Bonnie Prince Charlie come into his own again) that we will allow all 639-3 code elements to be language subtags, and deprecate all the grandfathered forms like "zh-yue" (Cantonese) in favor of just 'yue'. Similarly, the currently redundant sign languages like "sgn-US" will be deprecated in favor of 'ase' and friends. The existing language tags representing macrolanguages of course remain intact. IMO we should strongly consider adding a new informative (and mutable) "Fallback" header in the registry which will inform people about problematic cases like "cmn" and "arb" (Standard Arabic), instructing them which language subtag to fall back to in cases of match failure. These will have to be cherry-picked, like Suppress-Script, but Peter Constable has estimated that there are no more than 15 such cases actually in wide use. For some macrolanguages, there is no dominant variety, and no special consideration is as yet required; if new dominant varieties come to exist in future, new Fallback headers can be added. RFC 4647bis can then be revised to explain how this header MAY be used to enhance matching. -- 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 Thu Nov 29 10:24: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 1IxlFZ-0008Iz-7q; Thu, 29 Nov 2007 10:24:25 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxlFY-0008I1-Dc for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:24:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlFY-0008HZ-3J for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:24:24 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxlFV-00086n-Rp for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:24:24 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxlFG-0006Fc-1u for ltru@lists.ietf.org; Thu, 29 Nov 2007 15:24:06 +0000 Received: from c-134-88-105.hh.dial.de.ignite.net ([62.134.88.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 15:24:06 +0000 Received: from nobody by c-134-88-105.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 15:24:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 29 Nov 2007 16:25:58 +0100 Organization: Lines: 10 Message-ID: References: <003d01c83254$ddd0cef0$6601a8c0@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: c-134-88-105.hh.dial.de.ignite.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: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: action item: "other" collections in 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: =20 > I've suggested in the past that removing collection IDs from > BCP47 might not be a bad idea, but on several occasions people > have indicated that they wish to have the collections kept. "Removing" can't fly. Do you mean "not add new" (in the 4645bis bulk update), "deprecate old", or both ? =20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 10:30: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 1IxlLp-0001hJ-CA; Thu, 29 Nov 2007 10:30:53 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxlLo-0001h7-92 for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlLn-0001gr-VE for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:30:51 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxlLm-0000on-Jt for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:30:51 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxlLg-0007hm-Je for ltru@lists.ietf.org; Thu, 29 Nov 2007 15:30:44 +0000 Received: from c-134-88-105.hh.dial.de.ignite.net ([62.134.88.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 15:30:44 +0000 Received: from nobody by c-134-88-105.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 15:30:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 29 Nov 2007 16:32:38 +0100 Organization: Lines: 10 Message-ID: References: <003b01c83254$13459cb0$6601a8c0@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: c-134-88-105.hh.dial.de.ignite.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: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] Re: trying to comment draft-ietf-ltru-4646bis-09.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > we should be referencing the 2006 version of ISO 3166,=20 > and not the 1997 version. Ugh, the approved Netnews RFC also still has 1997. Does the 2006 version already specify an expiration period of at least 50 years ? Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 10:33: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 1IxlOL-0005Eo-Qg; Thu, 29 Nov 2007 10:33:29 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxlOK-0005Cw-9Q for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:33:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlOJ-0005Cl-VS for ltru@ietf.org; Thu, 29 Nov 2007 10:33:27 -0500 Received: from earth.ccil.org ([192.190.237.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxlOJ-0000Pn-Fk for ltru@ietf.org; Thu, 29 Nov 2007 10:33:27 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IxlOI-0008Bp-Ti; Thu, 29 Nov 2007 10:33:26 -0500 Date: Thu, 29 Nov 2007 10:33:26 -0500 To: Elisabeth Porteneuve Subject: Re: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt Message-ID: <20071129153326.GD32134@mercury.ccil.org> References: <200711281423.PAA24791@balsa.cetp.ipsl.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711281423.PAA24791@balsa.cetp.ipsl.fr> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Elisabeth Porteneuve scripsit: > Eventually I would stress out that a compilation of language subtags > MUST provide information on date of its ISO's sources, at least as far as > ISO 3166-1 table is concerned. I agree that these editorial issues should be fixed. > Finally the IETF draft makes a provision to synchronise the ISO-3166 tables > with UN M.49 ones, assuming or suggesting that those two organisations does > not check together. The fact is that the ISO 3166-1 table is made, among other, > with alpha-2, alpha-3 and M.49 codes. The point here is that the alpha-2 tags are a very scarce resource, and as countries change names, the alpha-2 tags change with them. Eventually (despite the 50-year delay) tags will have to be reused; since we do not wish to allow this, we make provision for using M.49 codes instead of reusing existing codes. -- John Cowan cowan@ccil.org ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 10:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxleW-0004RP-Rn; Thu, 29 Nov 2007 10:50:12 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxleW-0004RE-4F for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxleV-0004R4-QX for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:50:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxleT-00047a-Ht for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:50:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IxleN-0003R6-4f for ltru@lists.ietf.org; Thu, 29 Nov 2007 15:50:03 +0000 Received: from c-134-88-105.hh.dial.de.ignite.net ([62.134.88.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 15:50:03 +0000 Received: from nobody by c-134-88-105.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 15:50:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: "Frank Ellermann" Date: Thu, 29 Nov 2007 16:51:56 +0100 Organization: Lines: 26 Message-ID: References: <003301c83253$8e31ec90$6601a8c0@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: c-134-88-105.hh.dial.de.ignite.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: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] Re: New scripts X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Ellermann List-Id: 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 > I can hardly believe that four years later, and supposedly four=20 > years wiser, we have arrived at the point where, having identified > a brand of jargon much less radical than Newspeak, and not nearly > as well defined, we wish not merely to register a variant subtag > for it, but to change the registration rules to permit the > addition of a *region* subtag for it. Oops, so far I thought this EU business was about getting rid of QU in CLDR, completely unrelated to any practical language tagging needs. Something in the CLDR rules must be odd if they can't just use EU for their purposes without prior "permission" in a language subtag registry. =20 I can guess good reasons why ISO 3166 won't add it, it could cause problems if one location has more than one corresponding region code. And unlike UK + GB, where one could be deprecated in favour of the other as workaround permitting both, this trick can't work for say BE + EU. Of course "we" have more than one code for various locations with the additional UN codes, but "our" needs are also different from=20 ISO 3166. And different from CLDR, I think. =20 Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 10:51: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 1Ixlfx-0007Gn-UM; Thu, 29 Nov 2007 10:51:41 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixlfw-0007CD-Kd for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:51:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlfw-0007Br-AT for ltru@ietf.org; Thu, 29 Nov 2007 10:51:40 -0500 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixlfv-0004OO-FL for ltru@ietf.org; Thu, 29 Nov 2007 10:51:40 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1459827nzf for ; Thu, 29 Nov 2007 07:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=esNqqrTA9fQnAlkSzO9jtKDQGoj85u29ZtnW1UL6KeY=; b=Hwwr1FUS0+T3pZCicioq3ZTUf0yPYJRlOTCqbgq2sZkyHXuqFeAePeum+bm/Dte/MgTAC1YMKCVI8FMcAnR5mwMtuvu1P0ldt64FcdGuY5eJXltqeevEgC8et5VlymCoU7mNcw13MkD/CNe034U6e74emR72sAM+d4aG4w8U2Nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=EeJg72EB8/TA2IwY9vqFxlYGOPQWXbr/CaewtFQ8MAmB7e3VK+ysij8PWiRmLIK1G47Bi2eG/5dPeYa3XENsU+WRY2ndO57jm/g5C7PYOJFbtH2Yf79jBJ12riFVjeeCN+VXNqZ1CbG1ygWMHA9BKs1mWvqLeeoECE2F7VUDsHE= Received: by 10.114.146.1 with SMTP id t1mr682634wad.1196351498240; Thu, 29 Nov 2007 07:51:38 -0800 (PST) Received: by 10.114.198.8 with HTTP; Thu, 29 Nov 2007 07:51:38 -0800 (PST) Message-ID: <30b660a20711290751k4265ca66y91dd13c2ee186578@mail.gmail.com> Date: Thu, 29 Nov 2007 07:51:38 -0800 From: "Mark Davis" To: "LTRU Working Group" MIME-Version: 1.0 X-Google-Sender-Auth: 56701140a0297749 X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Subject: [Ltru] telecon notes for 2007-11-28 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0090250032==" Errors-To: ltru-bounces@ietf.org --===============0090250032== Content-Type: multipart/alternative; boundary="----=_Part_11043_10397011.1196351498228" ------=_Part_11043_10397011.1196351498228 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline LTRU Telecon Notes * 2007-11-28 Meeting* Martin, John, Addison, Mark, Peter (notes are somewhat fragmented, as sometimes too involved in the conversation to copy) message - Issue on usability of extlang (Nov 26) Martin - right truncation assumes people speak the right most Mark - that's the reason for doing extlang, because they would work with truncation. Otherwise, just treat them as units; yue instead of zh-yue. Peter - my idea born out of dealing with the misalignment between things already in -2 and -3, plus existing practice (zh-hakka). That was the idea. Not a fully baked idea. No analysis to make sure that it makes sense for all of these cases. John - must have been some degree of analysis Peter - there was some. Would love to have had the JAC analyse and say which worked and which didn't. But that didn't happen. Not realistic expectation. Individuals didn't have the expertise. Peter could devote his day job to this. Never had in mind that we'd be having language tags John - did want French creole with tags. Peter -- didn't happen. Don't see the value of having a hierarchy. For language resources, what does it buy you. Having a tag for all Filipine languages doesn't buy you anything. John - clear that 636-2 was empirical, based on looking at books, without deep knowledge. BTW, is the move to get rid of "(Other)" still alive in 639? Peter - still alive. Will have to review. *Peter takes the action.* Peter - there was a thought that you could have a hierarchy. We had consensus in general that we didn't want a full hierarchy. The question is whether we want a limited hierarchy. "zh" is unique. [discussion of "no" and "ar"] Glancing down the list, there are maybe 15 if that where the macrolanguage has widespread use. Not much electronic content with many tags. The macrolanguages are not the same. John - some have dominant, some not; some many members, some not. Addision -- no real exciting revelations. We have certain languages with existing practices; how do we deal with it best. Could flip a coin. Addison - something has to inhabit zh. It could be Mandarin or Cantonese, but it can't be both. When it is an incompatible set, it has to be one choice. If you don't use extlang, you don't have to have have single content. John -- you still have the issue. Addision - yes, the problem still exists, but it isn't reflected in the tags. John - almost willing to throw in the towel. We would need to do the lookup algorithm. BUT, absolutely oppose making items equivalent (zh = cmn). Addison - ok. Mark - ok. John - so you're ok with not banning arb, cmn, etc. Addision - ok Mark - ok Martin - sorry for debate, but how do I tag written Chinese; what is the answer - zh or cmn? Addison - should use zh for compatibility Martin - in the document, or depend on others Addision - yes, in the document. Similar to the examples we already have. John - wouldn't mind looking through Peter's 15 to offer specific advice. Martin - so will have zh and cmn that are almost the same. John - yes, but as a result of empirical fact. The denotation is different. Is error to tag non-mandarin as mandarin, but not an error to tag as zh. Martin - what do we do with sign language? Addison - sgn never part of macrolanguage John - perfectly glad to deprecate sgn-region - *General consensus to deprecate this.* *General consensus to deprecate extlang, and grandfather tags of that form.* -- Mark ------=_Part_11043_10397011.1196351498228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

LTRU Telecon Notes

2007-11-28 Meeting

Martin, John, Addison, Mark, Peter

(notes are somewhat fragmented, as sometimes too involved in the conversation to copy)

message - Issue on usability of extlang (Nov 26)


Martin - right truncation assumes people speak the right most


Mark - that's the reason for doing extlang, because they would work with truncation. Otherwise, just treat them as units; yue instead of zh-yue.


Peter - my idea born out of dealing with the misalignment between things already in -2 and -3, plus existing practice (zh-hakka). That was the idea. Not a fully baked idea. No analysis to make sure that it makes sense for all of these cases.


John - must have been some degree of analysis


Peter - there was some. Would love to have had the JAC analyse and say which worked and which didn't. But that didn't happen. Not realistic expectation. Individuals didn't have the expertise. Peter could devote his day job to this. Never had in mind that we'd be having language tags


John - did want French creole with tags.


Peter -- didn't happen. Don't see the value of having a hierarchy. For language resources, what does it buy you. Having a tag for all Filipine languages doesn't buy you anything.


John - clear that 636-2 was empirical, based on looking at books, without deep knowledge. BTW, is the move to get rid of "(Other)" still alive in 639?


Peter - still alive. Will have to review. Peter takes the action.


Peter - there was a thought that you could have a hierarchy. We had consensus in general that we didn't want a full hierarchy. The question is whether we want a limited hierarchy. "zh" is unique. [discussion of "no" and "ar"] Glancing down the list, there are maybe 15 if that where the macrolanguage has widespread use. Not much electronic content with many tags. The macrolanguages are not the same.


John - some have dominant, some not; some many members, some not.


Addision -- no real exciting revelations. We have certain languages with existing practices; how do we deal with it best. Could flip a coin.


Addison - something has to inhabit zh. It could be Mandarin or Cantonese, but it can't be both. When it is an incompatible set, it has to be one choice. If you don't use extlang, you don't have to have have single content.


John -- you still have the issue.


Addision - yes, the problem still exists, but it isn't reflected in the tags.

John - almost willing to throw in the towel. We would need to do the lookup algorithm. BUT, absolutely oppose making items equivalent (zh = cmn).

Addison - ok.
Mark - ok.

John - so you're ok with not banning arb, cmn, etc.

Addision - ok
Mark - ok

Martin - sorry for debate, but how do I tag written Chinese; what is the answer - zh or cmn?

Addison - should use zh for compatibility

Martin - in the document, or depend on others

Addision - yes, in the document. Similar to the examples we already have.

John - wouldn't mind looking through Peter's 15 to offer specific advice.

Martin - so will have zh and cmn that are almost the same.

John - yes, but as a result of empirical fact. The denotation is different. Is error to tag non-mandarin as mandarin, but not an error to tag as zh.

Martin - what do we do with sign language?

Addison - sgn never part of macrolanguage

John - perfectly glad to deprecate sgn-region - General consensus to deprecate this.


General consensus to deprecate extlang, and grandfather tags of that form.

--
Mark ------=_Part_11043_10397011.1196351498228-- --===============0090250032== 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 --===============0090250032==-- From ltru-bounces@ietf.org Thu Nov 29 10:52: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 1Ixlgo-0000y8-VB; Thu, 29 Nov 2007 10:52:34 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixlgn-0000xc-MB for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlgn-0000xU-Ch for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:52:33 -0500 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixlgm-0004Wk-SO for ltru@lists.ietf.org; Thu, 29 Nov 2007 10:52:33 -0500 Received: by wa-out-1112.google.com with SMTP id j4so2262495wah for ; Thu, 29 Nov 2007 07:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=/XxoeignpsSnuEU0ymYxeFg1bWqdVaE3sXVPdIZYktM=; b=ISi2hQN/LEvvDZqsaHhiuSa0buecniRE0pgAmYYhX/BSwLzJ8jxgeTbm5gtfNgrGn5MfPmQ/FkQkXJkHiz9wLPRIPfcJyfNwa+Ncpb6ZApzNOwoyg4xSWrtvtGMvq0Re47/1fUvjstotu36z6ogre60AdplRNmdAYBpq81oFXqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TL/Ts6SBO4So0cVUP0qGJaZSHLbN8MIORRvFkpJgosR+sc+z8zPjsklTglzNYFrEFkyr0VdbcR/43lIMycrcQU+suOArdmboMef+ogxMKXcZjyINJlRuPwAoFOHJfDCzeMK8SKNtxLGkTxOAGqASo4jY87Z1YhUYc28ork9DmAM= Received: by 10.115.59.4 with SMTP id m4mr595493wak.1196351550125; Thu, 29 Nov 2007 07:52:30 -0800 (PST) Received: by 10.114.198.8 with HTTP; Thu, 29 Nov 2007 07:52:30 -0800 (PST) Message-ID: <30b660a20711290752l1461e009h53dce8c0244962cd@mail.gmail.com> Date: Thu, 29 Nov 2007 07:52:30 -0800 From: "Mark Davis" To: "Frank Ellermann" Subject: Re: [Ltru] Re: action item: "other" collections in 639 In-Reply-To: MIME-Version: 1.0 References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> X-Google-Sender-Auth: a75e685cc43a5a10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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="===============1467441700==" Errors-To: ltru-bounces@ietf.org --===============1467441700== Content-Type: multipart/alternative; boundary="----=_Part_11048_27576645.1196351550122" ------=_Part_11048_27576645.1196351550122 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Nobody is calling for removing. Peter's action was to take "(Other)" out of the names, that's all. Mark On Nov 29, 2007 7:25 AM, Frank Ellermann wrote: > Peter Constable wrote: > > > I've suggested in the past that removing collection IDs from > > BCP47 might not be a bad idea, but on several occasions people > > have indicated that they wish to have the collections kept. > > "Removing" can't fly. Do you mean "not add new" (in the 4645bis > bulk update), "deprecate old", or both ? > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- Mark ------=_Part_11048_27576645.1196351550122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Nobody is calling for removing. Peter's action was to take "(Other)" out of the names, that's all.

Mark

On Nov 29, 2007 7:25 AM, Frank Ellermann < nobody@xyzzy.claranet.de> wrote:
Peter Constable wrote:

> I've suggested in the past that removing collection IDs from
> BCP47 might not be a bad idea, but on several occasions people
> have indicated that they wish to have the collections kept.

"Removing" can't fly.  Do you mean "not add new" (in the 4645bis
bulk update), "deprecate old", or both ?

 Frank



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



--
Mark ------=_Part_11048_27576645.1196351550122-- --===============1467441700== 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 --===============1467441700==-- From ltru-bounces@ietf.org Thu Nov 29 11:04: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 1Ixlso-0008Bb-Sz; Thu, 29 Nov 2007 11:04:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixlsn-0008BD-9o for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:04:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlsn-0008B4-0B for ltru@lists.ietf.org; Thu, 29 Nov 2007 11:04:57 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixlsm-0006gs-Jj for ltru@lists.ietf.org; Thu, 29 Nov 2007 11:04:56 -0500 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.222.3; Thu, 29 Nov 2007 08:04:23 -0800 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; Thu, 29 Nov 2007 08:04:56 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Thu, 29 Nov 2007 08:04:54 -0800 Subject: RE: [Ltru] Re: action item: "other" collections in 639 Thread-Topic: [Ltru] Re: action item: "other" collections in 639 Thread-Index: Acgym+3H/o25nJAIQoO12QwZqCfHAQABY5+g Message-ID: References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> In-Reply-To: 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: 08e48e05374109708c00c6208b534009 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="===============2055873838==" Errors-To: ltru-bounces@ietf.org --===============2055873838== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBGcmFuayBFbGxlcm1hbm4gW21haWx0bzpub2JvZHlAeHl6enkuY2xhcmFuZXQuZGVd DQoNCj4gPiBJJ3ZlIHN1Z2dlc3RlZCBpbiB0aGUgcGFzdCB0aGF0IHJlbW92aW5nIGNvbGxlY3Rp b24gSURzIGZyb20NCj4gPiBCQ1A0NyBtaWdodCBub3QgYmUgYSBiYWQgaWRlYSwgYnV0IG9uIHNl dmVyYWwgb2NjYXNpb25zIHBlb3BsZQ0KPiA+IGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSB3aXNo IHRvIGhhdmUgdGhlIGNvbGxlY3Rpb25zIGtlcHQuDQo+DQo+ICJSZW1vdmluZyIgY2FuJ3QgZmx5 LiAgRG8geW91IG1lYW4gIm5vdCBhZGQgbmV3IiAoaW4gdGhlIDQ2NDViaXMNCj4gYnVsayB1cGRh dGUpLCAiZGVwcmVjYXRlIG9sZCIsIG9yIGJvdGggPw0KDQpEZXByZWNhdGUsIGFuZCBub3QgYWRk IG5ldy4NCg0KDQpQZXRlcg0K --===============2055873838== 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 --===============2055873838==-- From ltru-bounces@ietf.org Thu Nov 29 11:12: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 1Ixm0V-0001F9-6d; Thu, 29 Nov 2007 11:12:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixm0U-0001Ei-52 for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixm0T-0001EX-RT for ltru@lists.ietf.org; Thu, 29 Nov 2007 11:12:53 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixm0T-00084y-5U for ltru@lists.ietf.org; Thu, 29 Nov 2007 11:12:53 -0500 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 29 Nov 2007 08:12:19 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Thu, 29 Nov 2007 08:12:52 -0800 From: Peter Constable To: "ltru@lists.ietf.org" Date: Thu, 29 Nov 2007 08:12:51 -0800 Subject: RE: [Ltru] Re: action item: "other" collections in 639 Thread-Topic: [Ltru] Re: action item: "other" collections in 639 Thread-Index: Acgyn94y8HERwju4QjmIYjgxIMoq3AAAfMGw Message-ID: References: <003d01c83254$ddd0cef0$6601a8c0@DGBP7M81> <30b660a20711290752l1461e009h53dce8c0244962cd@mail.gmail.com> In-Reply-To: <30b660a20711290752l1461e009h53dce8c0244962cd@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: 0ff9c467ad7f19c2a6d058acd7faaec8 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="===============1302015061==" Errors-To: ltru-bounces@ietf.org --===============1302015061== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8EANAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8EANAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIGNsYXJpZnkgdGhpcyBzdWItdGhyZWFkOiBJIGhhdmUgcXVlc3Rpb25lZCBpbiB0aGUg cGFzdCB3aGV0aGVyIGxhbmd1YWdlIGNvbGxlY3Rpb24gSUQgb2YgYW55IGtpbmQgYXJlIHVzZWZ1 bCBpbiBJRVRGIGxhbmd1YWdlIHRhZ3MuIFdoZW5ldmVyIEkgbWFkZSB0aGF0IHN1Z2dlc3Rpb24s IHRoZXJlIHdlcmUgb3RoZXJzIGhlcmUgaW5zaXN0aW5nIHRoYXQgdGhleSB3YW50ZWQgdGhlbSBr ZXB0Lg0KDQpJIGFtIG5vdCBwcm9wb3NpbmcgYW55IGNoYW5nZSBpbiB0aGlzIHJlZ2FyZCBhdCB0 aGlzIHRpbWUuIFRoaXMgb25seSBjYW1lIHVwIGJlY2F1c2UgSSBoYWQgcG9vcmx5IHdvcmRlZCBt eSBzdGF0ZW1lbnQgYWJvdXQgZ2V0dGluZyByaWQgb2Yg4oCcKE90aGVyKeKAnSBmcm9tIGxhbmd1 YWdlLWNvbGxlY3Rpb24gbmFtZXMsIGFuZCBEb3VnIHRob3VnaHQgSSB3YXMgc3VnZ2VzdGluZyB0 aGF0IElTTyA2Mzkg4oCcd2l0aGRyYXfigJ0gdGhvc2UgZW50cmllcyDigJMgSSB3YXMgbm90IHN1 Z2dlc3RpbmcgdGhhdC4NCg0KTGV0IG1lIGNsYXJpZnkgd2hhdCBjaGFuZ2UgSSBhbSBwdXJzdWlu ZzogSSBhbSBhc2tpbmcgdGhlIEpBQyB0byByZW1vdmUg4oCcKE90aGVyKeKAnSBmcm9tIHRoZSBu YW1lcyBvZiBsYW5ndWFnZS1jb2xsZWN0aW9uIGVudHJpZXMgdGhhdCBjdXJyZW50bHkgY29udGFp biB0aGF0IHN0cmluZy4gVGhhdCBpcyAqYWxsKiB0aGlzIHRocmVhZCB3YXMgaW50ZW5kZWQgdG8g YmUgYWJvdXQuDQoNCg0KUGV0ZXINCg0KRnJvbTogTWFyayBEYXZpcyBbbWFpbHRvOm1hcmsuZGF2 aXNAaWN1LXByb2plY3Qub3JnXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDA3IDc6 NTMgQU0NClRvOiBGcmFuayBFbGxlcm1hbm4NCkNjOiBsdHJ1QGxpc3RzLmlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0x0cnVdIFJlOiBhY3Rpb24gaXRlbTogIm90aGVyIiBjb2xsZWN0aW9ucyBpbiA2 MzkNCg0KTm9ib2R5IGlzIGNhbGxpbmcgZm9yIHJlbW92aW5nLiBQZXRlcidzIGFjdGlvbiB3YXMg dG8gdGFrZSAiKE90aGVyKSIgb3V0IG9mIHRoZSBuYW1lcywgdGhhdCdzIGFsbC4NCg0KTWFyaw0K T24gTm92IDI5LCAyMDA3IDc6MjUgQU0sIEZyYW5rIEVsbGVybWFubiA8IG5vYm9keUB4eXp6eS5j bGFyYW5ldC5kZTxtYWlsdG86bm9ib2R5QHh5enp5LmNsYXJhbmV0LmRlPj4gd3JvdGU6DQpQZXRl ciBDb25zdGFibGUgd3JvdGU6DQoNCj4gSSd2ZSBzdWdnZXN0ZWQgaW4gdGhlIHBhc3QgdGhhdCBy ZW1vdmluZyBjb2xsZWN0aW9uIElEcyBmcm9tDQo+IEJDUDQ3IG1pZ2h0IG5vdCBiZSBhIGJhZCBp ZGVhLCBidXQgb24gc2V2ZXJhbCBvY2Nhc2lvbnMgcGVvcGxlDQo+IGhhdmUgaW5kaWNhdGVkIHRo YXQgdGhleSB3aXNoIHRvIGhhdmUgdGhlIGNvbGxlY3Rpb25zIGtlcHQuDQoiUmVtb3ZpbmciIGNh bid0IGZseS4gIERvIHlvdSBtZWFuICJub3QgYWRkIG5ldyIgKGluIHRoZSA0NjQ1YmlzDQpidWxr IHVwZGF0ZSksICJkZXByZWNhdGUgb2xkIiwgb3IgYm90aCA/DQoNCiBGcmFuaw0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkx0cnUgbWFpbGlu ZyBsaXN0DQpMdHJ1QGlldGYub3JnPG1haWx0bzpMdHJ1QGlldGYub3JnPg0KaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQoNCg0KLS0NCk1hcmsNCg== --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8EANAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCiAvKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7 fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAg PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+TGV0IG1lIGNsYXJpZnkgdGhpcyBzdWItdGhyZWFkOiBJ IGhhdmUgcXVlc3Rpb25lZCBpbiB0aGUgcGFzdA0Kd2hldGhlciBsYW5ndWFnZSBjb2xsZWN0aW9u IElEIG9mIGFueSBraW5kIGFyZSB1c2VmdWwgaW4gSUVURiBsYW5ndWFnZSB0YWdzLg0KV2hlbmV2 ZXIgSSBtYWRlIHRoYXQgc3VnZ2VzdGlvbiwgdGhlcmUgd2VyZSBvdGhlcnMgaGVyZSBpbnNpc3Rp bmcgdGhhdCB0aGV5DQp3YW50ZWQgdGhlbSBrZXB0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPkkgYW0gbm90IHByb3Bvc2luZyBhbnkgY2hhbmdlIGluIHRoaXMgcmVnYXJkIGF0IHRo aXMgdGltZS4gVGhpcw0Kb25seSBjYW1lIHVwIGJlY2F1c2UgSSBoYWQgcG9vcmx5IHdvcmRlZCBt eSBzdGF0ZW1lbnQgYWJvdXQgZ2V0dGluZyByaWQgb2Yg4oCcKE90aGVyKeKAnQ0KZnJvbSBsYW5n dWFnZS1jb2xsZWN0aW9uIG5hbWVzLCBhbmQgRG91ZyB0aG91Z2h0IEkgd2FzIHN1Z2dlc3Rpbmcg dGhhdCBJU08gNjM5IOKAnHdpdGhkcmF34oCdDQp0aG9zZSBlbnRyaWVzIOKAkyBJIHdhcyBub3Qg c3VnZ2VzdGluZyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+TGV0IG1lIGNs YXJpZnkgd2hhdCBjaGFuZ2UgSSBhbSBwdXJzdWluZzogSSBhbSBhc2tpbmcgdGhlIEpBQyB0bw0K cmVtb3ZlIOKAnChPdGhlcinigJ0gZnJvbSB0aGUgbmFtZXMgb2YgbGFuZ3VhZ2UtY29sbGVjdGlv biBlbnRyaWVzIHRoYXQgY3VycmVudGx5DQpjb250YWluIHRoYXQgc3RyaW5nLiBUaGF0IGlzICo8 Yj5hbGw8L2I+KiB0aGlzIHRocmVhZCB3YXMgaW50ZW5kZWQgdG8gYmUgYWJvdXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+UGV0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQn Pg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gTWFyayBEYXZpcw0KW21h aWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZ10gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBOb3ZlbWJlciAyOSwgMjAwNyA3OjUzIEFNPGJyPg0KPGI+VG86PC9iPiBGcmFuayBFbGxl cm1hbm48YnI+DQo8Yj5DYzo8L2I+IGx0cnVAbGlzdHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtMdHJ1XSBSZTogYWN0aW9uIGl0ZW06ICZxdW90O290aGVyJnF1b3Q7IGNvbGxl Y3Rpb25zIGluDQo2Mzk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5Ob2JvZHkgaXMgY2FsbGluZyBm b3IgcmVtb3ZpbmcuDQpQZXRlcidzIGFjdGlvbiB3YXMgdG8gdGFrZSAmcXVvdDsoT3RoZXIpJnF1 b3Q7IG91dCBvZiB0aGUgbmFtZXMsIHRoYXQncyBhbGwuPGJyPg0KPGJyPg0KTWFyazxvOnA+PC9v OnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+T24gTm92IDI5LCAyMDA3IDc6 MjUgQU0sIEZyYW5rIEVsbGVybWFubiAmbHQ7PGENCmhyZWY9Im1haWx0bzpub2JvZHlAeHl6enku Y2xhcmFuZXQuZGUiPiBub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+UGV0ZXIgQ29uc3RhYmxlIHdyb3RlOjxicj4NCjxicj4NCiZndDsgSSd2 ZSBzdWdnZXN0ZWQgaW4gdGhlIHBhc3QgdGhhdCByZW1vdmluZyBjb2xsZWN0aW9uIElEcyBmcm9t PGJyPg0KJmd0OyBCQ1A0NyBtaWdodCBub3QgYmUgYSBiYWQgaWRlYSwgYnV0IG9uIHNldmVyYWwg b2NjYXNpb25zIHBlb3BsZTxicj4NCiZndDsgaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGV5IHdpc2gg dG8gaGF2ZSB0aGUgY29sbGVjdGlvbnMga2VwdC48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD4mcXVvdDtSZW1vdmluZyZxdW90OyBjYW4ndCBmbHkuICZuYnNw O0RvIHlvdSBtZWFuICZxdW90O25vdA0KYWRkIG5ldyZxdW90OyAoaW4gdGhlIDQ2NDViaXM8YnI+ DQpidWxrIHVwZGF0ZSksICZxdW90O2RlcHJlY2F0ZSBvbGQmcXVvdDssIG9yIGJvdGggPzxicj4N CjxzcGFuIHN0eWxlPSdjb2xvcjojODg4ODg4Jz48YnI+DQombmJzcDtGcmFuazwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxicj4N Cjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KTHRydSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86THRydUBpZXRm Lm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPg0KPGJyIGNs ZWFyPWFsbD4NCjxicj4NCi0tIDxicj4NCk1hcmsgPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0K DQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8EANAEXMSGC117re_-- --===============1302015061== 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 --===============1302015061==-- From ltru-bounces@ietf.org Thu Nov 29 11:21: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 1Ixm9G-0004sF-NT; Thu, 29 Nov 2007 11:21:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixm9F-0004nG-CE for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:21:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixm9E-0004n3-Vn for ltru@ietf.org; Thu, 29 Nov 2007 11:21:57 -0500 Received: from smtp.microsoft.com ([131.107.115.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixm9D-00007A-QT for ltru@ietf.org; Thu, 29 Nov 2007 11:21:56 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 29 Nov 2007 08:21:22 -0800 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Thu, 29 Nov 2007 08:21:54 -0800 From: Peter Constable To: Mark Davis , LTRU Working Group Date: Thu, 29 Nov 2007 08:21:50 -0800 Subject: RE: [Ltru] telecon notes for 2007-11-28 Thread-Topic: [Ltru] telecon notes for 2007-11-28 Thread-Index: Acgyn8DeFVIys2G9Rc2erb7/1hOm/gAAxUeA Message-ID: References: <30b660a20711290751k4265ca66y91dd13c2ee186578@mail.gmail.com> In-Reply-To: <30b660a20711290751k4265ca66y91dd13c2ee186578@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: 65bc4909d78e8b10349def623cf7a1d1 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="===============0987058869==" Errors-To: ltru-bounces@ietf.org --===============0987058869== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8F9NAEXMSGC117re_" --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8F9NAEXMSGC117re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgbGlrZSB0byBtYWtlIGEgY29ycmVjdGlvbiB0byB0aGlzIHJlY29yZDoNCg0KUGxlYXNl IGRlbGV0ZSDigJxQZXRlciBjb3VsZCBkZXZvdGUgaGlzIGRheSBqb2IgdG8gdGhpcy7igJ0NCg0K UGxlYXNlIGNoYW5nZSDigJxOZXZlciBoYWQgaW4gbWluZCB0aGF0IHdlJ2QgYmUgaGF2aW5nIGxh bmd1YWdlIHRhZ3PigJ0gdG8g4oCcVGhlcmUgaGFkIGJlZW4gYXQgc29tZSBwb2ludCBhIHN1Z2dl c3Rpb24gb2YgbGFuZ3VhZ2UgdGFncyBjb25zdHJ1Y3RlZCBoaWVyYXJjaGljYWxseSB1c2luZyBj b2xsZWN0aW9ucywgYnV0IHRoYXQgd2FzIGRyb3BwZWQu4oCdDQoNCg0KRnJvbTogTWFyayBEYXZp cyBbbWFpbHRvOm1hcmsuZGF2aXNAaWN1LXByb2plY3Qub3JnXQ0KU2VudDogVGh1cnNkYXksIE5v dmVtYmVyIDI5LCAyMDA3IDc6NTIgQU0NClRvOiBMVFJVIFdvcmtpbmcgR3JvdXANClN1YmplY3Q6 IFtMdHJ1XSB0ZWxlY29uIG5vdGVzIGZvciAyMDA3LTExLTI4DQoNCkxUUlUgVGVsZWNvbiBOb3Rl cw0KMjAwNy0xMS0yOCBNZWV0aW5nDQpNYXJ0aW4sIEpvaG4sIEFkZGlzb24sIE1hcmssIFBldGVy DQoNCihub3RlcyBhcmUgc29tZXdoYXQgZnJhZ21lbnRlZCwgYXMgc29tZXRpbWVzIHRvbyBpbnZv bHZlZCBpbiB0aGUgY29udmVyc2F0aW9uIHRvIGNvcHkpDQoNCm1lc3NhZ2UgLSBJc3N1ZSBvbiB1 c2FiaWxpdHkgb2YgZXh0bGFuZyAoTm92IDI2KQ0KDQoNCg0KTWFydGluIC0gcmlnaHQgdHJ1bmNh dGlvbiBhc3N1bWVzIHBlb3BsZSBzcGVhayB0aGUgcmlnaHQgbW9zdA0KDQoNCg0KTWFyayAtIHRo YXQncyB0aGUgcmVhc29uIGZvciBkb2luZyBleHRsYW5nLCBiZWNhdXNlIHRoZXkgd291bGQgd29y ayB3aXRoIHRydW5jYXRpb24uIE90aGVyd2lzZSwganVzdCB0cmVhdCB0aGVtIGFzIHVuaXRzOyB5 dWUgaW5zdGVhZCBvZiB6aC15dWUuDQoNCg0KDQpQZXRlciAtIG15IGlkZWEgYm9ybiBvdXQgb2Yg ZGVhbGluZyB3aXRoIHRoZSBtaXNhbGlnbm1lbnQgYmV0d2VlbiB0aGluZ3MgYWxyZWFkeSBpbiAt MiBhbmQgLTMsIHBsdXMgZXhpc3RpbmcgcHJhY3RpY2UgKHpoLWhha2thKS4gVGhhdCB3YXMgdGhl IGlkZWEuIE5vdCBhIGZ1bGx5IGJha2VkIGlkZWEuIE5vIGFuYWx5c2lzIHRvIG1ha2Ugc3VyZSB0 aGF0IGl0IG1ha2VzIHNlbnNlIGZvciBhbGwgb2YgdGhlc2UgY2FzZXMuDQoNCg0KDQpKb2huIC0g bXVzdCBoYXZlIGJlZW4gc29tZSBkZWdyZWUgb2YgYW5hbHlzaXMNCg0KDQoNClBldGVyIC0gdGhl cmUgd2FzIHNvbWUuIFdvdWxkIGxvdmUgdG8gaGF2ZSBoYWQgdGhlIEpBQyBhbmFseXNlIGFuZCBz YXkgd2hpY2ggd29ya2VkIGFuZCB3aGljaCBkaWRuJ3QuIEJ1dCB0aGF0IGRpZG4ndCBoYXBwZW4u IE5vdCByZWFsaXN0aWMgZXhwZWN0YXRpb24uIEluZGl2aWR1YWxzIGRpZG4ndCBoYXZlIHRoZSBl eHBlcnRpc2UuIFBldGVyIGNvdWxkIGRldm90ZSBoaXMgZGF5IGpvYiB0byB0aGlzLiBOZXZlciBo YWQgaW4gbWluZCB0aGF0IHdlJ2QgYmUgaGF2aW5nIGxhbmd1YWdlIHRhZ3MNCg0KDQoNCkpvaG4g LSBkaWQgd2FudCBGcmVuY2ggY3Jlb2xlIHdpdGggdGFncy4NCg0KDQoNClBldGVyIC0tIGRpZG4n dCBoYXBwZW4uIERvbid0IHNlZSB0aGUgdmFsdWUgb2YgaGF2aW5nIGEgaGllcmFyY2h5LiBGb3Ig bGFuZ3VhZ2UgcmVzb3VyY2VzLCB3aGF0IGRvZXMgaXQgYnV5IHlvdS4gSGF2aW5nIGEgdGFnIGZv ciBhbGwgRmlsaXBpbmUgbGFuZ3VhZ2VzIGRvZXNuJ3QgYnV5IHlvdSBhbnl0aGluZy4NCg0KDQoN CkpvaG4gLSBjbGVhciB0aGF0IDYzNi0yIHdhcyBlbXBpcmljYWwsIGJhc2VkIG9uIGxvb2tpbmcg YXQgYm9va3MsIHdpdGhvdXQgZGVlcCBrbm93bGVkZ2UuIEJUVywgaXMgdGhlIG1vdmUgdG8gZ2V0 IHJpZCBvZiAiKE90aGVyKSIgc3RpbGwgYWxpdmUgaW4gNjM5Pw0KDQoNCg0KUGV0ZXIgLSBzdGls bCBhbGl2ZS4gV2lsbCBoYXZlIHRvIHJldmlldy4gUGV0ZXIgdGFrZXMgdGhlIGFjdGlvbi4NCg0K DQoNClBldGVyIC0gdGhlcmUgd2FzIGEgdGhvdWdodCB0aGF0IHlvdSBjb3VsZCBoYXZlIGEgaGll cmFyY2h5LiBXZSBoYWQgY29uc2Vuc3VzIGluIGdlbmVyYWwgdGhhdCB3ZSBkaWRuJ3Qgd2FudCBh IGZ1bGwgaGllcmFyY2h5LiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IGEgbGltaXRl ZCBoaWVyYXJjaHkuICJ6aCIgaXMgdW5pcXVlLiBbZGlzY3Vzc2lvbiBvZiAibm8iIGFuZCAiYXIi XSBHbGFuY2luZyBkb3duIHRoZSBsaXN0LCB0aGVyZSBhcmUgbWF5YmUgMTUgaWYgdGhhdCB3aGVy ZSB0aGUgbWFjcm9sYW5ndWFnZSBoYXMgd2lkZXNwcmVhZCB1c2UuIE5vdCBtdWNoIGVsZWN0cm9u aWMgY29udGVudCB3aXRoIG1hbnkgdGFncy4gVGhlIG1hY3JvbGFuZ3VhZ2VzIGFyZSBub3QgdGhl IHNhbWUuDQoNCg0KDQpKb2huIC0gc29tZSBoYXZlIGRvbWluYW50LCBzb21lIG5vdDsgc29tZSBt YW55IG1lbWJlcnMsIHNvbWUgbm90Lg0KDQoNCg0KQWRkaXNpb24gLS0gbm8gcmVhbCBleGNpdGlu ZyByZXZlbGF0aW9ucy4gV2UgaGF2ZSBjZXJ0YWluIGxhbmd1YWdlcyB3aXRoIGV4aXN0aW5nIHBy YWN0aWNlczsgaG93IGRvIHdlIGRlYWwgd2l0aCBpdCBiZXN0LiBDb3VsZCBmbGlwIGEgY29pbi4N Cg0KDQoNCkFkZGlzb24gLSBzb21ldGhpbmcgaGFzIHRvIGluaGFiaXQgemguIEl0IGNvdWxkIGJl IE1hbmRhcmluIG9yIENhbnRvbmVzZSwgYnV0IGl0IGNhbid0IGJlIGJvdGguIFdoZW4gaXQgaXMg YW4gaW5jb21wYXRpYmxlIHNldCwgaXQgaGFzIHRvIGJlIG9uZSBjaG9pY2UuIElmIHlvdSBkb24n dCB1c2UgZXh0bGFuZywgeW91IGRvbid0IGhhdmUgdG8gaGF2ZSBoYXZlIHNpbmdsZSBjb250ZW50 Lg0KDQoNCg0KSm9obiAtLSB5b3Ugc3RpbGwgaGF2ZSB0aGUgaXNzdWUuDQoNCkFkZGlzaW9uIC0g eWVzLCB0aGUgcHJvYmxlbSBzdGlsbCBleGlzdHMsIGJ1dCBpdCBpc24ndCByZWZsZWN0ZWQgaW4g dGhlIHRhZ3MuDQoNCkpvaG4gLSBhbG1vc3Qgd2lsbGluZyB0byB0aHJvdyBpbiB0aGUgdG93ZWwu IFdlIHdvdWxkIG5lZWQgdG8gZG8gdGhlIGxvb2t1cCBhbGdvcml0aG0uIEJVVCwgYWJzb2x1dGVs eSBvcHBvc2UgbWFraW5nIGl0ZW1zIGVxdWl2YWxlbnQgKHpoID0gY21uKS4NCg0KQWRkaXNvbiAt IG9rLg0KTWFyayAtIG9rLg0KDQpKb2huIC0gc28geW91J3JlIG9rIHdpdGggbm90IGJhbm5pbmcg YXJiLCBjbW4sIGV0Yy4NCg0KQWRkaXNpb24gLSBvaw0KTWFyayAtIG9rDQoNCk1hcnRpbiAtIHNv cnJ5IGZvciBkZWJhdGUsIGJ1dCBob3cgZG8gSSB0YWcgd3JpdHRlbiBDaGluZXNlOyB3aGF0IGlz IHRoZSBhbnN3ZXIgLSB6aCBvciBjbW4/DQoNCkFkZGlzb24gLSBzaG91bGQgdXNlIHpoIGZvciBj b21wYXRpYmlsaXR5DQoNCk1hcnRpbiAtIGluIHRoZSBkb2N1bWVudCwgb3IgZGVwZW5kIG9uIG90 aGVycw0KDQpBZGRpc2lvbiAtIHllcywgaW4gdGhlIGRvY3VtZW50LiBTaW1pbGFyIHRvIHRoZSBl eGFtcGxlcyB3ZSBhbHJlYWR5IGhhdmUuDQoNCkpvaG4gLSB3b3VsZG4ndCBtaW5kIGxvb2tpbmcg dGhyb3VnaCBQZXRlcidzIDE1IHRvIG9mZmVyIHNwZWNpZmljIGFkdmljZS4NCg0KTWFydGluIC0g c28gd2lsbCBoYXZlIHpoIGFuZCBjbW4gdGhhdCBhcmUgYWxtb3N0IHRoZSBzYW1lLg0KDQpKb2hu IC0geWVzLCBidXQgYXMgYSByZXN1bHQgb2YgZW1waXJpY2FsIGZhY3QuIFRoZSBkZW5vdGF0aW9u IGlzIGRpZmZlcmVudC4gSXMgZXJyb3IgdG8gdGFnIG5vbi1tYW5kYXJpbiBhcyBtYW5kYXJpbiwg YnV0IG5vdCBhbiBlcnJvciB0byB0YWcgYXMgemguDQoNCk1hcnRpbiAtIHdoYXQgZG8gd2UgZG8g d2l0aCBzaWduIGxhbmd1YWdlPw0KDQpBZGRpc29uIC0gc2duIG5ldmVyIHBhcnQgb2YgbWFjcm9s YW5ndWFnZQ0KDQpKb2huIC0gcGVyZmVjdGx5IGdsYWQgdG8gZGVwcmVjYXRlIHNnbi1yZWdpb24g LSBHZW5lcmFsIGNvbnNlbnN1cyB0byBkZXByZWNhdGUgdGhpcy4NCg0KDQpHZW5lcmFsIGNvbnNl bnN1cyB0byBkZXByZWNhdGUgZXh0bGFuZywgYW5kIGdyYW5kZmF0aGVyIHRhZ3Mgb2YgdGhhdCBm b3JtLg0KDQotLQ0KTWFyaw0K --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8F9NAEXMSGC117re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCiAvKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmgxDQoJe21zby1z dHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjI0LjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7 fQ0KaDINCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcg MiBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9u dC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0Kc3Bhbi5IZWFkaW5nMUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcg MSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGlu ZyAxIjsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojMzY1RjkxOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu azoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjoj NEY4MUJEOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0 aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5J4oCZZCBsaWtlIHRvIG1ha2UgYSBjb3JyZWN0 aW9uIHRvIHRoaXMgcmVjb3JkOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlBsZWFz ZSBkZWxldGUg4oCcUGV0ZXIgY291bGQgZGV2b3RlIGhpcyBkYXkgam9iIHRvIHRoaXMu4oCdIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+UGxlYXNlIGNoYW5nZSDigJxOZXZlciBoYWQg aW4gbWluZCB0aGF0IHdlJ2QgYmUgaGF2aW5nIGxhbmd1YWdlDQp0YWdz4oCdIHRvIOKAnFRoZXJl IGhhZCBiZWVuIGF0IHNvbWUgcG9pbnQgYSBzdWdnZXN0aW9uIG9mIGxhbmd1YWdlIHRhZ3MNCmNv bnN0cnVjdGVkIGhpZXJhcmNoaWNhbGx5IHVzaW5nIGNvbGxlY3Rpb25zLCBidXQgdGhhdCB3YXMg ZHJvcHBlZC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1hcmsgRGF2aXMNClttYWlsdG86bWFyay5kYXZpc0Bp Y3UtcHJvamVjdC5vcmddIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMjks IDIwMDcgNzo1MiBBTTxicj4NCjxiPlRvOjwvYj4gTFRSVSBXb3JraW5nIEdyb3VwPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtMdHJ1XSB0ZWxlY29uIG5vdGVzIGZvciAyMDA3LTExLTI4PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGgxPkxUUlUgVGVsZWNvbiBOb3RlcyA8bzpwPjwvbzpw PjwvaDE+DQoNCjxoMj4yMDA3LTExLTI4IE1lZXRpbmcgPG86cD48L286cD48L2gyPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5NYXJ0aW4sIEpvaG4s IEFkZGlzb24sIE1hcmssDQpQZXRlcjxicj4NCjxicj4NCihub3RlcyBhcmUgc29tZXdoYXQgZnJh Z21lbnRlZCwgYXMgc29tZXRpbWVzIHRvbyBpbnZvbHZlZCBpbiB0aGUgY29udmVyc2F0aW9uDQp0 byBjb3B5KTxvOnA+PC9vOnA+PC9wPg0KDQo8cD5tZXNzYWdlIC0gSXNzdWUgb24gdXNhYmlsaXR5 IG9mIGV4dGxhbmcgKE5vdiAyNikgPG86cD48L286cD48L3A+DQoNCjxwPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KDQo8cD5NYXJ0aW4gLSByaWdodCB0cnVuY2F0aW9uIGFzc3VtZXMgcGVvcGxlIHNw ZWFrIHRoZSByaWdodCBtb3N0IDxvOnA+PC9vOnA+PC9wPg0KDQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCg0KPHA+TWFyayAtIHRoYXQncyB0aGUgcmVhc29uIGZvciBkb2luZyBleHRsYW5nLCBi ZWNhdXNlIHRoZXkgd291bGQgd29yayB3aXRoDQp0cnVuY2F0aW9uLiBPdGhlcndpc2UsIGp1c3Qg dHJlYXQgdGhlbSBhcyB1bml0czsgeXVlIGluc3RlYWQgb2YgemgteXVlLjxvOnA+PC9vOnA+PC9w Pg0KDQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHA+UGV0ZXIgLSBteSBpZGVhIGJvcm4g b3V0IG9mIGRlYWxpbmcgd2l0aCB0aGUgbWlzYWxpZ25tZW50IGJldHdlZW4gdGhpbmdzDQphbHJl YWR5IGluIC0yIGFuZCAtMywgcGx1cyBleGlzdGluZyBwcmFjdGljZSAoemgtaGFra2EpLiBUaGF0 IHdhcyB0aGUgaWRlYS4gTm90DQphIGZ1bGx5IGJha2VkIGlkZWEuIE5vIGFuYWx5c2lzIHRvIG1h a2Ugc3VyZSB0aGF0IGl0IG1ha2VzIHNlbnNlIGZvciBhbGwgb2YNCnRoZXNlIGNhc2VzLiA8bzpw PjwvbzpwPjwvcD4NCg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPkpvaG4gLSBtdXN0 IGhhdmUgYmVlbiBzb21lIGRlZ3JlZSBvZiBhbmFseXNpcyA8bzpwPjwvbzpwPjwvcD4NCg0KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPlBldGVyIC0gdGhlcmUgd2FzIHNvbWUuIFdvdWxk IGxvdmUgdG8gaGF2ZSBoYWQgdGhlIEpBQyBhbmFseXNlIGFuZCBzYXkgd2hpY2gNCndvcmtlZCBh bmQgd2hpY2ggZGlkbid0LiBCdXQgdGhhdCBkaWRuJ3QgaGFwcGVuLiBOb3QgcmVhbGlzdGljIGV4 cGVjdGF0aW9uLg0KSW5kaXZpZHVhbHMgZGlkbid0IGhhdmUgdGhlIGV4cGVydGlzZS4gUGV0ZXIg Y291bGQgZGV2b3RlIGhpcyBkYXkgam9iIHRvIHRoaXMuDQpOZXZlciBoYWQgaW4gbWluZCB0aGF0 IHdlJ2QgYmUgaGF2aW5nIGxhbmd1YWdlIHRhZ3M8bzpwPjwvbzpwPjwvcD4NCg0KPHA+PG86cD4m bmJzcDs8L286cD48L3A+DQoNCjxwPkpvaG4gLSBkaWQgd2FudCBGcmVuY2ggY3Jlb2xlIHdpdGgg dGFncy48bzpwPjwvbzpwPjwvcD4NCg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPlBl dGVyIC0tIGRpZG4ndCBoYXBwZW4uIERvbid0IHNlZSB0aGUgdmFsdWUgb2YgaGF2aW5nIGEgaGll cmFyY2h5LiBGb3INCmxhbmd1YWdlIHJlc291cmNlcywgd2hhdCBkb2VzIGl0IGJ1eSB5b3UuIEhh dmluZyBhIHRhZyBmb3IgYWxsIEZpbGlwaW5lDQpsYW5ndWFnZXMgZG9lc24ndCBidXkgeW91IGFu eXRoaW5nLiA8bzpwPjwvbzpwPjwvcD4NCg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxw PkpvaG4gLSBjbGVhciB0aGF0IDYzNi0yIHdhcyBlbXBpcmljYWwsIGJhc2VkIG9uIGxvb2tpbmcg YXQgYm9va3MsIHdpdGhvdXQNCmRlZXAga25vd2xlZGdlLiBCVFcsIGlzIHRoZSBtb3ZlIHRvIGdl dCByaWQgb2YgJnF1b3Q7KE90aGVyKSZxdW90OyBzdGlsbCBhbGl2ZQ0KaW4gNjM5PyA8bzpwPjwv bzpwPjwvcD4NCg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPlBldGVyIC0gc3RpbGwg YWxpdmUuIFdpbGwgaGF2ZSB0byByZXZpZXcuIDxiPlBldGVyIHRha2VzIHRoZSBhY3Rpb24uPC9i PiA8bzpwPjwvbzpwPjwvcD4NCg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPlBldGVy IC0gdGhlcmUgd2FzIGEgdGhvdWdodCB0aGF0IHlvdSBjb3VsZCBoYXZlIGEgaGllcmFyY2h5LiBX ZSBoYWQNCmNvbnNlbnN1cyBpbiBnZW5lcmFsIHRoYXQgd2UgZGlkbid0IHdhbnQgYSBmdWxsIGhp ZXJhcmNoeS4gVGhlIHF1ZXN0aW9uIGlzDQp3aGV0aGVyIHdlIHdhbnQgYSBsaW1pdGVkIGhpZXJh cmNoeS4gJnF1b3Q7emgmcXVvdDsgaXMgdW5pcXVlLiBbZGlzY3Vzc2lvbiBvZg0KJnF1b3Q7bm8m cXVvdDsgYW5kICZxdW90O2FyJnF1b3Q7XSBHbGFuY2luZyBkb3duIHRoZSBsaXN0LCB0aGVyZSBh cmUgbWF5YmUgMTUNCmlmIHRoYXQgd2hlcmUgdGhlIG1hY3JvbGFuZ3VhZ2UgaGFzIHdpZGVzcHJl YWQgdXNlLiBOb3QgbXVjaCBlbGVjdHJvbmljIGNvbnRlbnQNCndpdGggbWFueSB0YWdzLiBUaGUg bWFjcm9sYW5ndWFnZXMgYXJlIG5vdCB0aGUgc2FtZS4gPG86cD48L286cD48L3A+DQoNCjxwPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cD5Kb2huIC0gc29tZSBoYXZlIGRvbWluYW50LCBzb21l IG5vdDsgc29tZSBtYW55IG1lbWJlcnMsIHNvbWUgbm90LiA8bzpwPjwvbzpwPjwvcD4NCg0KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPkFkZGlzaW9uIC0tIG5vIHJlYWwgZXhjaXRpbmcg cmV2ZWxhdGlvbnMuIFdlIGhhdmUgY2VydGFpbiBsYW5ndWFnZXMgd2l0aA0KZXhpc3RpbmcgcHJh Y3RpY2VzOyBob3cgZG8gd2UgZGVhbCB3aXRoIGl0IGJlc3QuIENvdWxkIGZsaXAgYSBjb2luLiA8 bzpwPjwvbzpwPjwvcD4NCg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPkFkZGlzb24g LSBzb21ldGhpbmcgaGFzIHRvIGluaGFiaXQgemguIEl0IGNvdWxkIGJlIE1hbmRhcmluIG9yIENh bnRvbmVzZSwNCmJ1dCBpdCBjYW4ndCBiZSBib3RoLiBXaGVuIGl0IGlzIGFuIGluY29tcGF0aWJs ZSBzZXQsIGl0IGhhcyB0byBiZSBvbmUgY2hvaWNlLg0KSWYgeW91IGRvbid0IHVzZSBleHRsYW5n LCB5b3UgZG9uJ3QgaGF2ZSB0byBoYXZlIGhhdmUgc2luZ2xlIGNvbnRlbnQuIDxvOnA+PC9vOnA+ PC9wPg0KDQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHA+Sm9obiAtLSB5b3Ugc3RpbGwg aGF2ZSB0aGUgaXNzdWUuIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5BZGRpc2lvbiAtIHllcywg dGhlIHByb2JsZW0gc3RpbGwgZXhpc3RzLCBidXQgaXQgaXNuJ3QNCnJlZmxlY3RlZCBpbiB0aGUg dGFncy48YnI+DQo8YnI+DQpKb2huIC0gYWxtb3N0IHdpbGxpbmcgdG8gdGhyb3cgaW4gdGhlIHRv d2VsLiBXZSB3b3VsZCBuZWVkIHRvIGRvIHRoZSBsb29rdXANCmFsZ29yaXRobS4gQlVULCBhYnNv bHV0ZWx5IG9wcG9zZSBtYWtpbmcgaXRlbXMgZXF1aXZhbGVudCAoemggPSBjbW4pLjxicj4NCjxi cj4NCkFkZGlzb24gLSBvay48YnI+DQpNYXJrIC0gb2suPGJyPg0KPGJyPg0KSm9obiAtIHNvIHlv dSdyZSBvayB3aXRoIG5vdCBiYW5uaW5nIGFyYiwgY21uLCBldGMuPGJyPg0KPGJyPg0KQWRkaXNp b24gLSBvazxicj4NCk1hcmsgLSBvazxicj4NCjxicj4NCk1hcnRpbiAtIHNvcnJ5IGZvciBkZWJh dGUsIGJ1dCBob3cgZG8gSSB0YWcgd3JpdHRlbiBDaGluZXNlOyB3aGF0IGlzIHRoZSBhbnN3ZXIN Ci0gemggb3IgY21uPzxicj4NCjxicj4NCkFkZGlzb24gLSBzaG91bGQgdXNlIHpoIGZvciBjb21w YXRpYmlsaXR5PGJyPg0KPGJyPg0KTWFydGluIC0gaW4gdGhlIGRvY3VtZW50LCBvciBkZXBlbmQg b24gb3RoZXJzPGJyPg0KPGJyPg0KQWRkaXNpb24gLSB5ZXMsIGluIHRoZSBkb2N1bWVudC4gU2lt aWxhciB0byB0aGUgZXhhbXBsZXMgd2UgYWxyZWFkeSBoYXZlLjxicj4NCjxicj4NCkpvaG4gLSB3 b3VsZG4ndCBtaW5kIGxvb2tpbmcgdGhyb3VnaCBQZXRlcidzIDE1IHRvIG9mZmVyIHNwZWNpZmlj IGFkdmljZS48YnI+DQo8YnI+DQpNYXJ0aW4gLSBzbyB3aWxsIGhhdmUgemggYW5kIGNtbiB0aGF0 IGFyZSBhbG1vc3QgdGhlIHNhbWUuPGJyPg0KPGJyPg0KSm9obiAtIHllcywgYnV0IGFzIGEgcmVz dWx0IG9mIGVtcGlyaWNhbCBmYWN0LiBUaGUgZGVub3RhdGlvbiBpcyBkaWZmZXJlbnQuIElzDQpl cnJvciB0byB0YWcgbm9uLW1hbmRhcmluIGFzIG1hbmRhcmluLCBidXQgbm90IGFuIGVycm9yIHRv IHRhZyBhcyB6aC48YnI+DQo8YnI+DQpNYXJ0aW4gLSB3aGF0IGRvIHdlIGRvIHdpdGggc2lnbiBs YW5ndWFnZT88YnI+DQo8YnI+DQpBZGRpc29uIC0gc2duIG5ldmVyIHBhcnQgb2YgbWFjcm9sYW5n dWFnZTxicj4NCjxicj4NCkpvaG4gLSBwZXJmZWN0bHkgZ2xhZCB0byBkZXByZWNhdGUgc2duLXJl Z2lvbiAtIDxiPkdlbmVyYWwgY29uc2Vuc3VzIHRvDQpkZXByZWNhdGUgdGhpcy48L2I+PG86cD48 L286cD48L3A+DQoNCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+R2VuZXJhbCBjb25zZW5zdXMgdG8gZGVwcmVjYXRlIGV4dGxhbmcsIGFuZCBncmFuZGZh dGhlcg0KdGFncyBvZiB0aGF0IGZvcm0uPC9iPjxiciBjbGVhcj1hbGw+DQo8YnI+DQotLSA8YnI+ DQpNYXJrIDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0K PC9odG1sPg0K --_000_DDB6DE6E9D27DD478AE6D1BBBB83579561B42BB8F9NAEXMSGC117re_-- --===============0987058869== 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 --===============0987058869==-- From ltru-bounces@ietf.org Thu Nov 29 11:30: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 1IxmHy-0000RS-DR; Thu, 29 Nov 2007 11:30:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxmHx-0000RJ-3Q for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:30:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmHw-0000R9-PH for ltru@ietf.org; Thu, 29 Nov 2007 11:30:56 -0500 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxmHw-0001hn-Ae for ltru@ietf.org; Thu, 29 Nov 2007 11:30:56 -0500 Received: from [10.72.73.112] (snvvpn1-10-72-73-c112.corp.yahoo.com [10.72.73.112]) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lATGUZpH007409; Thu, 29 Nov 2007 08:30:36 -0800 (PST) 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=0+m9nBCX7S80468NEK6uN/gKpDKCsefJZ2DCDFsNANU12981+ccQG7ZlekRGh0eN Message-ID: <474EE92A.30209@yahoo-inc.com> Date: Thu, 29 Nov 2007 08:30:34 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: John Cowan References: <20071129143920.GC32134@mercury.ccil.org> In-Reply-To: <20071129143920.GC32134@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org Subject: [Ltru] Fallback vs. Macrolanguage? (was: John Cowan throws in...) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > > IMO we should strongly consider adding a new informative (and mutable) > "Fallback" header in the registry which will inform people about > problematic cases like "cmn" and "arb" (Standard Arabic), instructing > them which language subtag to fall back to in cases of match failure. > These will have to be cherry-picked, like Suppress-Script, but Peter > Constable has estimated that there are no more than 15 such cases > actually in wide use. For some macrolanguages, there is no dominant > variety, and no special consideration is as yet required; if new dominant > varieties come to exist in future, new Fallback headers can be added. > RFC 4647bis can then be revised to explain how this header MAY be used > to enhance matching. > Wouldn't it be easier, more consistent, cleaner, and cherry-free to keep what we've already proposed in draft-09, that is, to include the Macrolanguage field in the registry as informative information (and then note in either 4646bis or 4647bis about possible courses of action in cases of match failure)? 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 Nov 29 11:50: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 1Ixmau-0005cv-4v; Thu, 29 Nov 2007 11:50:32 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixmas-0005cf-Ok for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmas-0005cX-F0 for ltru@ietf.org; Thu, 29 Nov 2007 11:50:30 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixmar-00065L-6n for ltru@ietf.org; Thu, 29 Nov 2007 11:50:30 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1502034rvb for ; Thu, 29 Nov 2007 08:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=21WhJE/gNcl6X+NHKb1OhfEa+MG862JkVEvtYNdqaBk=; b=HkF0mho47tzqZ0hGmTygegiypxpCza5MdPJM4KQJ/73NlpX1Hfj7Fw1NhWimBk6pwByWV9Ru6Mi5bqtJ+B6hjwvf7TUJGIWJLZ2fZnhLHqw2gee2LlGSr486d3LoJVZxnwL5RVOZVc6W+PHMdWk+++d2eB0Ebf2a9y+8ipzQums= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=mKvgIVXgV3X0JAGdr9oTMkFgF0f20COZEBP0vx9fSlCqj37HEXJEsoG9t03J/PpFmVQfRIU074MH5PWtw7qJqstUh7o8i2RRMT9SCiO7/CZWgsA3McCyPCr41IU+ltYeUQi/+5orf/3tShxCTkCRNn5978Fv5sXsJLUEHfwjg1g= Received: by 10.115.54.1 with SMTP id g1mr589899wak.1196355024116; Thu, 29 Nov 2007 08:50:24 -0800 (PST) Received: by 10.114.198.8 with HTTP; Thu, 29 Nov 2007 08:50:24 -0800 (PST) Message-ID: <30b660a20711290850v58dfdae4p434f9d21d0381ab0@mail.gmail.com> Date: Thu, 29 Nov 2007 08:50:24 -0800 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] telecon notes for 2007-11-28 In-Reply-To: MIME-Version: 1.0 References: <30b660a20711290751k4265ca66y91dd13c2ee186578@mail.gmail.com> X-Google-Sender-Auth: aa8a1489273d6dbc X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 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="===============1256827017==" Errors-To: ltru-bounces@ietf.org --===============1256827017== Content-Type: multipart/alternative; boundary="----=_Part_11389_27306441.1196355024104" ------=_Part_11389_27306441.1196355024104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks. My apologies for any miswordings -- the notes were taken hurriedly! Mark On Nov 29, 2007 8:21 AM, Peter Constable wrote: > I'd like to make a correction to this record: > > > > Please delete "Peter could devote his day job to this." > > > > Please change "Never had in mind that we'd be having language tags" to > "There had been at some point a suggestion of language tags constructed > hierarchically using collections, but that was dropped." > > > > > > *From:* Mark Davis [mailto:mark.davis@icu-project.org] > *Sent:* Thursday, November 29, 2007 7:52 AM > *To:* LTRU Working Group > *Subject:* [Ltru] telecon notes for 2007-11-28 > > > LTRU Telecon Notes 2007-11-28 Meeting > > Martin, John, Addison, Mark, Peter > > (notes are somewhat fragmented, as sometimes too involved in the > conversation to copy) > > message - Issue on usability of extlang (Nov 26) > > > > Martin - right truncation assumes people speak the right most > > > > Mark - that's the reason for doing extlang, because they would work with > truncation. Otherwise, just treat them as units; yue instead of zh-yue. > > > > Peter - my idea born out of dealing with the misalignment between things > already in -2 and -3, plus existing practice (zh-hakka). That was the idea. > Not a fully baked idea. No analysis to make sure that it makes sense for all > of these cases. > > > > John - must have been some degree of analysis > > > > Peter - there was some. Would love to have had the JAC analyse and say > which worked and which didn't. But that didn't happen. Not realistic > expectation. Individuals didn't have the expertise. Peter could devote his > day job to this. Never had in mind that we'd be having language tags > > > > John - did want French creole with tags. > > > > Peter -- didn't happen. Don't see the value of having a hierarchy. For > language resources, what does it buy you. Having a tag for all Filipine > languages doesn't buy you anything. > > > > John - clear that 636-2 was empirical, based on looking at books, without > deep knowledge. BTW, is the move to get rid of "(Other)" still alive in 639? > > > > > Peter - still alive. Will have to review. *Peter takes the action.* > > > > Peter - there was a thought that you could have a hierarchy. We had > consensus in general that we didn't want a full hierarchy. The question is > whether we want a limited hierarchy. "zh" is unique. [discussion of "no" and > "ar"] Glancing down the list, there are maybe 15 if that where the > macrolanguage has widespread use. Not much electronic content with many > tags. The macrolanguages are not the same. > > > > John - some have dominant, some not; some many members, some not. > > > > Addision -- no real exciting revelations. We have certain languages with > existing practices; how do we deal with it best. Could flip a coin. > > > > Addison - something has to inhabit zh. It could be Mandarin or Cantonese, > but it can't be both. When it is an incompatible set, it has to be one > choice. If you don't use extlang, you don't have to have have single > content. > > > > John -- you still have the issue. > > > > Addision - yes, the problem still exists, but it isn't reflected in the > tags. > > John - almost willing to throw in the towel. We would need to do the > lookup algorithm. BUT, absolutely oppose making items equivalent (zh = cmn). > > Addison - ok. > Mark - ok. > > John - so you're ok with not banning arb, cmn, etc. > > Addision - ok > Mark - ok > > Martin - sorry for debate, but how do I tag written Chinese; what is the > answer - zh or cmn? > > Addison - should use zh for compatibility > > Martin - in the document, or depend on others > > Addision - yes, in the document. Similar to the examples we already have. > > John - wouldn't mind looking through Peter's 15 to offer specific advice. > > Martin - so will have zh and cmn that are almost the same. > > John - yes, but as a result of empirical fact. The denotation is > different. Is error to tag non-mandarin as mandarin, but not an error to tag > as zh. > > Martin - what do we do with sign language? > > Addison - sgn never part of macrolanguage > > John - perfectly glad to deprecate sgn-region - *General consensus to > deprecate this.* > > > > *General consensus to deprecate extlang, and grandfather tags of that > form.* > > -- > Mark > -- Mark ------=_Part_11389_27306441.1196355024104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks. My apologies for any miswordings -- the notes were taken hurriedly!

Mark

On Nov 29, 2007 8:21 AM, Peter Constable <petercon@microsoft.com > wrote:

I'd like to make a correction to this record:

 

Please delete "Peter could devote his day job to this."

 

Please change "Never had in mind that we'd be having language tags" to "There had been at some point a suggestion of language tags constructed hierarchically using collections, but that was dropped."

 

 

From: Mark Davis [mailto:mark.davis@icu-project.org]
Sent: Thursday, November 29, 2007 7:52 AM
To: LTRU Working Group
Subject: [Ltru] telecon notes for 2007-11-28

 

LTRU Telecon Notes

2007-11-28 Meeting

Martin, John, Addison, Mark, Peter

(notes are somewhat fragmented, as sometimes too involved in the conversation to copy)

message - Issue on usability of extlang (Nov 26)

 

Martin - right truncation assumes people speak the right most

 

Mark - that's the reason for doing extlang, because they would work with truncation. Otherwise, just treat them as units; yue instead of zh-yue.

 

Peter - my idea born out of dealing with the misalignment between things already in -2 and -3, plus existing practice (zh-hakka). That was the idea. Not a fully baked idea. No analysis to make sure that it makes sense for all of these cases.

 

John - must have been some degree of analysis

 

Peter - there was some. Would love to have had the JAC analyse and say which worked and which didn't. But that didn't happen. Not realistic expectation. Individuals didn't have the expertise. Peter could devote his day job to this. Never had in mind that we'd be having language tags

 

John - did want French creole with tags.

 

Peter -- didn't happen. Don't see the value of having a hierarchy. For language resources, what does it buy you. Having a tag for all Filipine languages doesn't buy you anything.

 

John - clear that 636-2 was empirical, based on looking at books, without deep knowledge. BTW, is the move to get rid of "(Other)" still alive in 639?

 

Peter - still alive. Will have to review. Peter takes the action.

 

Peter - there was a thought that you could have a hierarchy. We had consensus in general that we didn't want a full hierarchy. The question is whether we want a limited hierarchy. "zh" is unique. [discussion of "no" and "ar"] Glancing down the list, there are maybe 15 if that where the macrolanguage has widespread use. Not much electronic content with many tags. The macrolanguages are not the same.

 

John - some have dominant, some not; some many members, some not.

 

Addision -- no real exciting revelations. We have certain languages with existing practices; how do we deal with it best. Could flip a coin.

 

Addison - something has to inhabit zh. It could be Mandarin or Cantonese, but it can't be both. When it is an incompatible set, it has to be one choice. If you don't use extlang, you don't have to have have single content.

 

John -- you still have the issue.

 

Addision - yes, the problem still exists, but it isn't reflected in the tags.

John - almost willing to throw in the towel. We would need to do the lookup algorithm. BUT, absolutely oppose making items equivalent (zh = cmn).

Addison - ok.
Mark - ok.

John - so you're ok with not banning arb, cmn, etc.

Addision - ok
Mark - ok

Martin - sorry for debate, but how do I tag written Chinese; what is the answer - zh or cmn?

Addison - should use zh for compatibility

Martin - in the document, or depend on others

Addision - yes, in the document. Similar to the examples we already have.

John - wouldn't mind looking through Peter's 15 to offer specific advice.

Martin - so will have zh and cmn that are almost the same.

John - yes, but as a result of empirical fact. The denotation is different. Is error to tag non-mandarin as mandarin, but not an error to tag as zh.

Martin - what do we do with sign language?

Addison - sgn never part of macrolanguage

John - perfectly glad to deprecate sgn-region - General consensus to deprecate this.

 

General consensus to deprecate extlang, and grandfather tags of that form.

--
Mark




--
Mark ------=_Part_11389_27306441.1196355024104-- --===============1256827017== 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 --===============1256827017==-- From ltru-bounces@ietf.org Thu Nov 29 12:10: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 1Ixmtv-0007Qp-Dp; Thu, 29 Nov 2007 12:10:11 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixmtu-0007PM-IF for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmtt-0007P9-Pz for ltru@ietf.org; Thu, 29 Nov 2007 12:10:09 -0500 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixmtr-0000pD-TY for ltru@ietf.org; Thu, 29 Nov 2007 12:10:09 -0500 Received: (qmail 19184 invoked from network); 29 Nov 2007 11:10:05 -0600 Received: from pool-72-75-10-67.washdc.east.verizon.net (HELO IBM92AA25595C4) (72.75.10.67) by 72.32.229.137 with SMTP; 29 Nov 2007 11:10:02 -0600 From: "Don Osborn" To: "'Addison Phillips'" , "'John Cowan'" References: <20071129143920.GC32134@mercury.ccil.org> <474EE92A.30209@yahoo-inc.com> In-Reply-To: <474EE92A.30209@yahoo-inc.com> Subject: RE: [Ltru] Fallback vs. Macrolanguage? (was: John Cowan throws in...) Date: Thu, 29 Nov 2007 12:09:58 -0500 Message-ID: <004801c832aa$ac53a090$04fae1b0$@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: AcgypTkoZB4mksGgRX+ZrwsBmanRAgABMWNw Content-Language: en-us X-Spam-Score: -0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Some macrolanguage headings might be used also for locales and for = describing orthographies (which in Africa often are defined by country = and not by categories in ISO 639). How would the draft affect such = cases? So in the case of Fula, one would probably be talking about = ff-SN, ff-NE, etc., for at least some purposes, without resort to the = alpha-3 codes introduced in part 3. (Sorry I have not been tracking this as closely as I would like to = have.) Don > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Thursday, November 29, 2007 11:31 AM > To: John Cowan > Cc: ltru@ietf.org > Subject: [Ltru] Fallback vs. Macrolanguage? (was: John Cowan throws > in...) >=20 > John Cowan wrote: > > > > IMO we should strongly consider adding a new informative (and > mutable) > > "Fallback" header in the registry which will inform people about > > problematic cases like "cmn" and "arb" (Standard Arabic), = instructing > > them which language subtag to fall back to in cases of match = failure. > > These will have to be cherry-picked, like Suppress-Script, but Peter > > Constable has estimated that there are no more than 15 such cases > > actually in wide use. For some macrolanguages, there is no dominant > > variety, and no special consideration is as yet required; if new > dominant > > varieties come to exist in future, new Fallback headers can be = added. > > RFC 4647bis can then be revised to explain how this header MAY be > used > > to enhance matching. > > >=20 > Wouldn't it be easier, more consistent, cleaner, and cherry-free to > keep > what we've already proposed in draft-09, that is, to include the > Macrolanguage field in the registry as informative information (and > then > note in either 4646bis or 4647bis about possible courses of action in > cases of match failure)? >=20 > Addison >=20 > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > Chair -- W3C Internationalization Core WG >=20 > Internationalization is an architecture. > It is not a feature. >=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 Nov 29 12: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 1Ixn7f-0003CR-2W; Thu, 29 Nov 2007 12:24:23 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixn7d-0003Bs-K2 for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:24:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixn7d-0003BZ-8p for ltru@ietf.org; Thu, 29 Nov 2007 12:24:21 -0500 Received: from balsa.cetp.ipsl.fr ([193.52.172.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixn7c-0002L2-DQ for ltru@ietf.org; Thu, 29 Nov 2007 12:24:21 -0500 Received: (from porteneu@localhost) by balsa.cetp.ipsl.fr (8.9.3+Sun/8.9.1) id SAA00561; Thu, 29 Nov 2007 18:23:48 +0100 (MET) Date: Thu, 29 Nov 2007 18:23:48 +0100 (MET) From: Elisabeth Porteneuve Message-Id: <200711291723.SAA00561@balsa.cetp.ipsl.fr> To: addison@yahoo-inc.com (Addison Phillips), duerst@it.aoyama.ac.jp (Martin Duers), ltru@ietf.org, mark.davis@icu-project.org (Mark Davis), randy_presuhn@mindspring.com (Randy Presuhn) Subject: Re: [Ltru] Re: draft-ietf-ltru-4646bis-09.txt X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Elisabeth.Porteneuve@cetp.ipsl.fr X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Greetings, First of all - many thanks to Randy for sorting out ltru list problem (not accepting my posts). Below are 3 answers. 1. ================================================================== From: "Doug Ewell" Date: Wed, 28 Nov 2007 22:50:05 -0800 I agree with Elisabeth Porteneuve that we should be referencing the 2006 version of ISO 3166, and not the 1997 version. -- Thanks. 2. ================================================================== From: "Frank Ellermann" Date: Thu, 29 Nov 2007 16:32:38 +0100 Doug Ewell wrote: > we should be referencing the 2006 version of ISO 3166, > and not the 1997 version. Ugh, the approved Netnews RFC also still has 1997. Does the 2006 version already specify an expiration period of at least 50 years ? Frank -- Yes. Quoting the ISO-3166-1:2006 7.5.2 Reallocation period Code elements that the ISO 3166/MA has altered or deleted should not be reallocated during a period of at least fifty years after the change. The exact period is determined in each case on the basis of the extent to which the former code element was used. 3. ================================================================== Date: Thu, 29 Nov 2007 10:33:26 -0500 From: John Cowan Elisabeth Porteneuve scripsit: > Eventually I would stress out that a compilation of language subtags > MUST provide information on date of its ISO's sources, at least as far as > ISO 3166-1 table is concerned. I agree that these editorial issues should be fixed. > Finally the IETF draft makes a provision to synchronise the ISO-3166 tables > with UN M.49 ones, assuming or suggesting that those two organisations does > not check together. The fact is that the ISO 3166-1 table is made, among other, > with alpha-2, alpha-3 and M.49 codes. The point here is that the alpha-2 tags are a very scarce resource, and as countries change names, the alpha-2 tags change with them. Eventually (despite the 50-year delay) tags will have to be reused; since we do not wish to allow this, we make provision for using M.49 codes instead of reusing existing codes. -- Indeed, the alpha-2 tags are a very scarce ressource, but is also used very carrefully: Quoting Gerard Lang's (ISO 3166/MA Chairman) today's, Nov 29th 2007 note: Since ISO 3166-1 was established in 1974, it has made use of the 246 codes currently in force and 25 codes that were in force previously but are no longer used. This means that the standard has effectively used up 246 + 25 = 271/676 = 40.01 % of the theoretical coding capacity and, in practice, 271/633 = 42.81 % of the internal usable coding capacity. Let me add one comment. The world instability was not created by ISO 3166/MA neither by UN, but recorded by both. United Nations are using the geographical distribution which was established as a result of the second world war. The same stands for ISO 3166/MA. All change of the world in Europe in 1990's until the most recent split into Serbia and Montenegro are related to the second world war. To some extent the second war is being finished now. I am optimistic, at least as far as Europe is concerned, to not see much changes in country codes. Concerning languages, I noted the inflation related to the former Yugoslavia split - the Serbo-Croatian, or Yugoslavian, was replicated with N different names. That is of course politically sad, as all people from the former Yugoslavia speaks Yugoslavian, Southern Slavic language (yug=south). But we cannot anything. Eventually, I would be happy to answer any questions related to ISO 3166/MA or ISO 3166-1 tables, or to provide in advance information when changes may arise. Please feel free to ask me directly (I will unsubscribe from ltru list shortly, going back to browsing archives from time to time). Kind regards, Elisabeth Porteneuve _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 12:39: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 1IxnLw-0006n8-Jf; Thu, 29 Nov 2007 12:39:08 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxnLv-0006mw-5Z for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:39:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnLu-0006mo-SH for ltru@lists.ietf.org; Thu, 29 Nov 2007 12:39:06 -0500 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxnLs-0006Ba-JD for ltru@lists.ietf.org; Thu, 29 Nov 2007 12:39:06 -0500 Received: (qmail 28305 invoked from network); 29 Nov 2007 11:39:03 -0600 Received: from pool-72-75-10-67.washdc.east.verizon.net (HELO IBM92AA25595C4) (72.75.10.67) by 72.32.229.137 with SMTP; 29 Nov 2007 11:39:03 -0600 From: "Don Osborn" To: , References: <30b660a20711281605p52608b2bg3a5308caeca6aa05@mail.gmail.com> In-Reply-To: <30b660a20711281605p52608b2bg3a5308caeca6aa05@mail.gmail.com> Date: Thu, 29 Nov 2007 12:39:00 -0500 Message-ID: <004a01c832ae$ba2bcc70$2e836550$@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: AcgyG4BqeE2PofpDSQaeefa0+S9r5QAj51UQ Content-Language: en-us X-Spam-Score: -0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ltru] ISO 639, RFC 464* & African languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Not sure about where is most appropriate to bring this up so will bring = it up on both ltru and ietf-languages (with apologies for the = crossposting).=20 I've been in discussions about a project to facilitate writing of = locales for African languages, and in that discussion I have suggested = that the effort keep notes on the categories of language headings = available in ISO 639 for this purpose. I feel this is a unique opportunity to gather information on application = of these tags in specific work relating to use of a number of African = languages in ICT. I don't expect anything dramatic, but hope this helps = get discussions past the few examples generally circulated (including = ones that some readers may be tired of seeing from me). It may possibly lead to some suggestions re new codes. It might also = lead to other observations re use of existing codes.=20 Two requests: 1) thoughts or guidelines on the above, what specifics to look for, etc. 2) ideal follow-up with the RFC process and its post 464* iterations = if/as indicated; I understand of course about the processes for applying = for new ISO 639 codes, which the event they are necessary (at the very = least I would expect one for Runyakitara) would probably be initiated by = country-level partners Don Osborn Bisharat.net PanAfriL10n.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 13:58: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 1IxoaI-0000fT-Jt; Thu, 29 Nov 2007 13:58:02 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxoaH-0000fH-MM for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 13:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoaH-0000f6-2o for ltru@lists.ietf.org; Thu, 29 Nov 2007 13:58:01 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxoaE-0003tU-T9 for ltru@lists.ietf.org; Thu, 29 Nov 2007 13:58:01 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QavyoCUpULsYrgQ2lLjcOI51uMfBjsl0BSIgkYeCRKRn1mFiUlDuLEJzQ9hZ6CA2; 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.161] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IxoaD-00045V-O0; Thu, 29 Nov 2007 13:57:58 -0500 Message-ID: <07f501c832b9$fedb90c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <30b660a20711281605p52608b2bg3a5308caeca6aa05@mail.gmail.com> <004a01c832ae$ba2bcc70$2e836550$@net> Date: Thu, 29 Nov 2007 10:59:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31aeed6a0406a893089f6d8d162c5deaad8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.34.161 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [Ltru] Re: ISO 639, RFC 464* & African languages X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Don - Information regarding the situation with languages in addition to the ones that have already received intensive discussion would be most welcome. I think that some of the follow-ups to your message will belong on ietf-languages@iana.org, and others on ltru@ietf.org. Here's how I'd recommend dispatching them: - data that would help the extlang / macrolanguage discussion should go to ltru@ietf.org - discussion of registration process, or the types of information that should be included with registration requests or recorded in the registry, should go to ltru@ietf.org - discussion of guidelines to be documented belongs on ltru@ietf.org - requests at add a new code or to modify information associated with some specific subtag should go to ietf-lanaguages@iana.org I hope this will help minimize the need for cross-posting. Randy ltru co-chair ----- Original Message ----- From: "Don Osborn" To: ; Sent: Thursday, November 29, 2007 9:39 AM Subject: ISO 639, RFC 464* & African languages Not sure about where is most appropriate to bring this up so will bring it up on both ltru and ietf-languages (with apologies for the crossposting). I've been in discussions about a project to facilitate writing of locales for African languages, and in that discussion I have suggested that the effort keep notes on the categories of language headings available in ISO 639 for this purpose. I feel this is a unique opportunity to gather information on application of these tags in specific work relating to use of a number of African languages in ICT. I don't expect anything dramatic, but hope this helps get discussions past the few examples generally circulated (including ones that some readers may be tired of seeing from me). It may possibly lead to some suggestions re new codes. It might also lead to other observations re use of existing codes. Two requests: 1) thoughts or guidelines on the above, what specifics to look for, etc. 2) ideal follow-up with the RFC process and its post 464* iterations if/as indicated; I understand of course about the processes for applying for new ISO 639 codes, which the event they are necessary (at the very least I would expect one for Runyakitara) would probably be initiated by country-level partners Don Osborn Bisharat.net PanAfriL10n.org _______________________________________________ Ietf-languages mailing list Ietf-languages@alvestrand.no http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 16:48: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 1IxrFi-0001ih-92; Thu, 29 Nov 2007 16:48:58 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxrFg-0001iE-9u for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 16:48:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrFf-0001hs-WE for ltru@ietf.org; Thu, 29 Nov 2007 16:48:56 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrFe-0006qa-TB for ltru@ietf.org; Thu, 29 Nov 2007 16:48:55 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 29 Nov 2007 13:48:21 -0800 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; Thu, 29 Nov 2007 13:48:51 -0800 From: Peter Constable To: John Cowan , "ltru@ietf.org" Date: Thu, 29 Nov 2007 13:48:51 -0800 Subject: RE: [Ltru] John Cowan throws in the towel on extlangs Thread-Topic: [Ltru] John Cowan throws in the towel on extlangs Thread-Index: AcgylaVYXFYU2TsKRUycOFEc4NQRawAOtYCQ Message-ID: References: <20071129143920.GC32134@mercury.ccil.org> In-Reply-To: <20071129143920.GC32134@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_DDB6DE6E9D27DD478AE6D1BBBB83579561B479B3D8NAEXMSGC117re_" MIME-Version: 1.0 X-Spam-Score: -8.0 (--------) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 --_002_DDB6DE6E9D27DD478AE6D1BBBB83579561B479B3D8NAEXMSGC117re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:cowan@ccil.org] > IMO we should strongly consider adding a new informative (and mutable) > "Fallback" header in the registry which will inform people about > problematic cases like "cmn" and "arb" (Standard Arabic), instructing > them which language subtag to fall back to in cases of match failure. > These will have to be cherry-picked, like Suppress-Script, but Peter > Constable has estimated that there are no more than 15 such cases > actually in wide use. For some macrolanguages, there is no dominant > variety, and no special consideration is as yet required; if new > dominant > varieties come to exist in future, new Fallback headers can be added. > RFC 4647bis can then be revised to explain how this header MAY be used > to enhance matching. I've taken a cut at analyzing macrolanguages in terms of two key factors: w= idespread exposure in ICT (based on support in OSes), and whether there is = a dominant language. (Of course, "dominant" varies on a continuum.) I ended up with 16 considered to have wide exposure. File is attached. Peter --_002_DDB6DE6E9D27DD478AE6D1BBBB83579561B479B3D8NAEXMSGC117re_ Content-Type: text/plain; name="Macrolanguage analysis.txt" Content-Description: Macrolanguage analysis.txt Content-Disposition: attachment; filename="Macrolanguage analysis.txt"; size=4964; creation-date="Thu, 29 Nov 2007 10:33:17 GMT"; modification-date="Thu, 29 Nov 2007 13:37:38 GMT" Content-Transfer-Encoding: base64 TWFjcm9sYW5ndWFnZSBhbmFseXNpcw0KDQpNYWNyb2xhbmd1YWdlcyBhcmUgY2F0ZWdvcml6ZWQg YWNjb3JkaW5nIHRvIHdoZXRoZXIgb3Igbm90IHRoZXkgYXJlIGluDQp3aWRlc3ByZWFkIHVzZSBp biBJQ1QsIGFuZCB3aGV0aGVyIG9yIG5vdCBvbmUgb2YgdGhlIGVuY29tcGFzc2VkIGxhbmd1YWdl cw0KaXMgZG9taW5hbnQuIA0KDQpFYWNoIG1hY3JvbGFuZ3VhZ2UgaXMgbGlzdGVkIHRvZ2V0aGVy IHdpdGggYWxsIGVuY29tcGFzc2VkIGxhbmd1YWdlcy4gVGhlDQphbHBoYS0yIElEIGlzIGFsc28g Z2l2ZW4gaWYgaXQgZXhpc3RzLg0KDQpOb3RlOiAidXNlZCBpbiBJQ1QiIGlzIGJhc2VkIG9uIHdo YXQncyBzdXBwb3J0ZWQgaW4tYm94IGluIE9TZXMuIENMRFIgYW5kDQpXaW5kb3dzIFZpc3RhIGxv Y2FsZXMgYXJlIGFzc3VtZWQgdG8gY292ZXIgdGhpcy4gKElmIHRoZSBsYW5ndWFnZSBpcyBzdXBw b3ItDQp0ZWQgb25seSBpbiBvbmUgb3IgdGhlIG90aGVyLCB0aGlzIGlzIGluZGljYXRlZC4pIE9m IGNvdXJzZSwgZXZlcnkgbWFjcm8tDQpsYW5ndWFnZSBpcyB1c2VkIGluIE1BUkMgYW5kIHN5c3Rl bXMgYmFzZWQgb24gTUFSQyAoYSB2ZXJ0aWNhbCBhcHBsaWNhdGlvbg0Kc3BhY2UpLiANCg0KRm9y IGNhdGVnb3J5IDIsIHRoZSBpbmZvIGZvciBlYWNoIGVudHJ5IGlzIG9yZ2FuaXplZCB0byBzZXBh cmF0ZSB0aGUgDQpkb21pbmFudCBsYW5ndWFnZSBmcm9tIG90aGVyIGxhbmd1YWdlcy4NCg0KVGhl ICIoRTE0Li4uKSIgYW5ub3RhdGlvbiBpbmRpY2F0ZXMgaG93IHRoZSBpdGVtIHdhcyBhbmFseXpl ZCBpbiBwcmUtNjM5LTMgDQp3b3JrLiBJbiBzb21lIGNhc2VzLCB0aGUgRXRobm9sb2d1ZSAxNCBj YXRlZ29yaWVzIG9yIElEcyBjaGFuZ2VkIGluIEUxNSAvIA0KRkRJUzYzOS0zOyBhbm5vdGF0aW9u cyB3aXRoICJFMTUiIHJlZmxlY3QgdGhlIHByZS02MzktMyBhbmFseXNpcyBidXQgaW4gDQp0ZXJt cyBvZiA2MzktMyBjYXRlZ29yaWVzL0lEcy4NCg0KDQoxLiBNYWNyb2xhbmd1YWdlIElEIGRlcHJl Y2F0ZWQNCm5vcglubm8NIG5vYiAgKEUxNDogY29sbGVjdGlvbikgPSBubw0KaGJzCWJvcw0gaHJ2 DSBzcnAgKEUxNDogbWFueS10by1vbmUpID0gc2gNCg0KMi4gTWFjcm9sYW5ndWFnZSBJRCB1c2Vk IGluIElDVCwgYW5kIHRoZXJlIGlzIGEgc2luZ2xlLCBkb21pbmFudCB2YXJpZXR5DQphcmEJKEUx NTogYXJiIGRvbWluYW50KSA9IGFyDQoJYXJiID0gU3RhbmRhcmQgQXJhYmljDQoJLSBhYW8NIGFi aA0gYWJ2DSBhY20NIGFjcQ0gYWN3DSBhY3gNIGFjeQ0gYWRmDSBhZWINIGFlYw0gYWZiDSBhanAN IGFwYw0gYXBkDSBhcnENIGFycw0gYXJ5DSBhcnoNIGF1eg0gYXZsDSBheWgNIGF5bA0gYXluDSBh eXANIGJieg0gcGdhDSBzaHUNIHNzaA0Ka29rCShFMTQ6IGtubiBkb21pbmFudCkNCglrbm4NCgkt IGdvbQ0NCm1zYQkoRTE1OiBtbHkgZG9taW5hbnQpID0gbXMNCgltbHkNDQoJLSBidGoNIGJ2ZQ0g YnZ1DSBjb2ENIGpheA0gbWF4DSBtZW8NIG1mYQ0gbXFnDSBtc2kNIHZrdA0geG1tDQpzd2EJKEUx NTogc3doIGRvbWluYW50KSA9IHN3IChDTERSKQ0KCXN3aCANCgktIHN3Yw0NCnV6YgkoRTE1OiB1 em4gZG9taW5hbnQpID0gdXoNCgl1em4NIA0KCS0gdXpzIA0KemhvCShFMTQ6IGNvbGxlY3Rpb24p ID0gemgNCgljbW4NCgktIGNkbw0gY2p5DSBjcHgNIGN6aA0gY3pvDSBnYW4NIGhhaw0gaHNuDSBt bnANIG5hbg0gd3V1DSB5dWUNCg0KMy4gTWFjcm9sYW5ndWFnZSBJRCB1c2VkIGluIElDVCwgbm8g ZG9taW5hbnQgdmFyaWV0eQ0KYXplCWF6YiBhemogKEUxNDogdW5jbGVhcikgPSBheg0KYWthCWZh dCB0d2kgKEUxNDogbGFuZzpkaWFsZWN0cykgPSBhayAoQ0xEUikNCmlrdQlpa2UNIGlrdCAoRTE0 OiBjb2xsZWN0aW9uKSA9IGl1DQprdXIJY2tiDSBrbXINIHNkaCAoRTE0OiB1bmNsZWFyKSA9IGt1 IChDTERSKQ0KcHVzCXBidA0gcGJ1DSBwc3QgKEUxNDogdW5jbGVhcikgPSBwcw0Kc3FpCWFhZQ0g YWF0DSBhbG4NIGFscyAoRTE0OiB1bmNsZWFyKSA9IHNxDQptb24Ja2hrDSBtdmYgKEUxNDogdW5j bGVhcikgPSBtbg0KcXVlCShFMTQ6IGNvbGxlY3Rpb24pID1xdSANCglxdXogKFdpbmRvd3M6ICJR dWVjaHVhIikNCgljcXUNIHF1Yg0gcXVkDSBxdWYNIHF1Zw0gcXVoDSBxdWsNIHF1bA0gcXVwDSBx dXINIHF1cw0gcXV3IHF1eA0gcXV5DSBxdmENIHF2Yw0gcXZlDSBxdmgNIHF2aQ0gcXZqDSBxdmwN IHF2bQ0gcXZuDSBxdm8NIHF2cA0gcXZzDSBxdncNIHF2eg0gcXdhDSBxd2MNIHF3aA0gcXdzDSBx eGENIHF4Yw0gcXhoDSBxeGwNIHF4bg0gcXhvDSBxeHANIHF4cg0gcXh0DSBxeHUNIHF4dw0KDQo0 LiBNYWNyb2xhbmd1YWdlIElEIHVzZWQgaW4gSUNULCA+MSBkb21pbmFudCB2YXJpZXR5DQpmYXMJ KEUxNDogdW5jbGVhcikgPSBmYQ0KCXBlcyA9IFBlcnNpYW4gKENMRFIgYW5kIFdpbmRvd3MgdXNl IGZhX0lSKQ0KCXBycyA9IERhcmkgKENMRFIgdXNlcyBmYV9BRiwgV2luZG93cyB1c2VzIHByc19B RikNCg0KNS4gTWFjcm9sYW5ndWFnZSBJRCBub3Qgd2lkZWx5IHVzZWQgaW4gSUNULCB0aGVyZSBp cyBhIHNpbmdsZSwgZG9taW5hbnQgdmFyaWV0eQ0KYXltCWF5YyBheXIgKEUxNDogYXljIGRvbWlu YW50KSA9IGF5DQpidWEJYnhtDSBieHINIGJ4dSAoRTE0OiBieHIgZG9taW5hbnQpDQpjaG0JbWhy DSBtcmoNIChFMTQ6IG1ociBkb21pbmFudCkNCgpkb2kJZGdvIHhuciAoRTE0OiBvbmUtdG8tbWFu eSkgLSBEb2dyaSBpcyBhbiBvZmZpY2lhbCBsYW5ndWFnZSBvZiBJbmRpYQ0KZ3JuCWdudw0gZ3Vn DSBndWkNIGd1bg0gbmhkIChFMTQ6IGd1ZyBkb21pbmFudCkgPSBnbg0Ka2F1CWtieQ0ga25jDSBr cnQgKEUxNDoga25jIGRvbWluYW50KSA9IGtyDQprb20Ja29pDSBrcHYgKEUxNDogdW5jbGVhcikg PSBrdg0KbGFoCWhuZA0gaG5vDSBqYXQNIHBocg0gcG11DSBwbmINIHNrcg0geGhlIChFMTQ6IHBu YiBkb21pbmFudCkNCglOb3RlOiBwbmIgPSAiV2VzdGVybiBQYW5qYWJpIjsgcGEvcGFuID0gIkVh c3Rlcm4gUGFuamFiaSI7IHNvbWUgY2xhc3NpZmljYXRpb25zIHNlcGFyYXRlIHRoZXNlIGF0IGEg aGlnaCBsZXZlbCwgc2FtZSBhcyBIaW5kaSwgUm9tYW55IHZzLiBTaW5kaGksIEthc2htaXJpDQpt bGcJKEUxNTogcGx0IGRvbWluYW50KSA9IG1nDQoJYmhyDSBianENIGJtbQ0gbXNoDSBwbHQNIHNr Zw0gdGR4DSB0eHkNIHhtdg0geG13DQptd3IJZGhkDSBtdHINIG12ZQ0gcndyDSBzd3YNIHdyeSAo RTE0OiByd3IgZG9taW5hbnQpDQp5aWQJeWRkDSB5aWggKEUxNDogeWRkIGRvbWluYW50KSA9IHlp DQp6emEJZGlxDSBraXUgKEUxNTogZGlxIGRvbWluYW50KQ0KDQo2LiBNYWNyb2xhbmd1YWdlIElE IG5vdCB3aWRlbHkgdXNlZCBpbiBJQ1QsIG5vIGRvbWluYW50IHZhcmlldHkNCmJhbAliY2MNIGJn biBiZ3AgKEUxNDogdW5jbGVhcikNCmNyZQljcmogY3JrIGNybCBjcm0NIGNzdw0gY3dkIChFMTQ6 IGNvbGxlY3Rpb24pID0gY3INCmRlbAl1bXUgdW5tIChFMTQ6IGNvbGxlY3Rpb24pDQpkZW4Jc2Nz IHhzbCAoRTE0OiBjb2xsZWN0aW9uKQ0KZGluCWRpYiBkaWsgZGlwIGRpdyBka3MgKEUxNDogY29s bGVjdGlvbikNCmZ1bAlmZm0NIGZ1Yg0gZnVjDSBmdWUNIGZ1ZiBmdWggZnVpDSBmdXENIGZ1diAo RTE0OiBjb2xsZWN0aW9uKSA9IGZmDQpnYmEJYmR0DSBnYnANIGdicQ0gZ3lhDSBtZG8gKEUxNDog Y29sbGVjdGlvbikNCmdvbglnZ28NIGdubyAoRTE0OiB1bmNsZWFyKQ0KZ3JiCWdibw0gZ2VjDSBn cmoNIGdydg0gZ3J5IChFMTQ6IGNvbGxlY3Rpb24pDQpoYWkJaGF4DSBoZG4gKEUxNDogY29sbGVj dGlvbikNCmhtbgkoRTE0OiBjb2xsZWN0aW9uKSBibHUNIGhlYQ0gaG1hDSBobWMNIGhtZA0gaG1l DSBobWcNIGhtaA0gaG1pDSBobWoNIGhtbA0gaG1tDSBobXANIGhtcQ0gaG1zDSBobXcNIGhteQ0g aHVqDSBtbXINIG11cQ0gbXd3DQppcGsJZXNpDSBlc2sgKEUxNDogY29sbGVjdGlvbikgPSBpaw0K anJiCWFqdA0gYWp1DSBqeWUNIHloZA0geXVkIChFMTQ6IGNvbGxlY3Rpb24pDQprb24Ja25nDSBr d3kNIGxkaSAoRTE0OiBrbmcpID0ga2cNCm1hbgllbWsNIG1rdQ0gbWxxDSBtbmsNIG1zYw0gbXdr DSBteXEgKEUxNDogbW5rKQ0Kb2ppCWNpdw0gb2piDSBvamMNIG9qZw0gb2pzDSBvancNIG90dyAo RTE0OiBjb2xsZWN0aW9uKSA9IG9qDQpvcm0JZ2F4DSBnYXoNIGhhZQ0gb3JjIChFMTQ6IHVuY2xl YXIpID0gb20NCnJvbQlybWMNIHJtZg0gcm1sDSBybW4NIHJtbw0gcm13DSBybXkgKEUxNDogY29s bGVjdGlvbikNCmtwZQlna3ANIHhwZSAoRTE0OiB1bmNsZWFyKQ0KcmFqCWJncQ0gZ2RhDSBnanUN IGhvag0gbXVwDSB3YnIgKEUxNDogY29sbGVjdGlvbikNCnNyZAlzZGMNIHNkbg0gc3JjDSBzcm8g KEUxNDogY29sbGVjdGlvbikgPSBzYw0Kc3lyCWFpaQ0gY2xkIChFMTQ6IHN5YykNCnRtaAl0YXEN IHRodg0gdGh6DSB0dHEgKEUxNDogY29sbGVjdGlvbikNCnphcAkoRTE0OiBjb2xsZWN0aW9uKSB6 YWENIHphYg0gemFjDSB6YWQNIHphZQ0gemFmDSB6YWkNIHphbQ0gemFvDSB6YXENIHphcg0gemFz DSB6YXQNIHphdg0gemF3DSB6YXgNIHpjYQ0gem9vDSB6cGENIHpwYg0genBjDSB6cGQNIHpwZQ0g enBmDSB6cGcNIHpwaA0genBpDSB6cGoNIHpwaw0genBsDSB6cG0NIHpwbg0genBvDSB6cHANIHpw cQ0genByDSB6cHMNIHpwdA0genB1DSB6cHYNIHpwdw0genB4DSB6cHkNIHpweg0genNyDSB6dGUN IHp0Zw0genRsDSB6dG0NIHp0bg0genRwDSB6dHENIHp0cw0genR0DSB6dHUNIHp0eA0genR5DSAN CnpoYQljY3gNIHpoZA0gemhuDSB6eWcNIHp5bg0genpqIChFMTQ6IHVuY2xlYXIpID0gemENCg0K Ny4gTWFjcm9sYW5ndWFnZSBJRCBub3Qgd2lkZWx5IHVzZWQgaW4gSUNULCA+MSBkb21pbmFudCB2 YXJpZXR5DQpiaWsJYmNsDSBiaGsNIGJsbg0gYnRvDSBjdHMgKEUxNTogYmNsLCBiaGsgZG9taW5h bnQpDQo= --_002_DDB6DE6E9D27DD478AE6D1BBBB83579561B479B3D8NAEXMSGC117re_ 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 --_002_DDB6DE6E9D27DD478AE6D1BBBB83579561B479B3D8NAEXMSGC117re_-- From ltru-bounces@ietf.org Thu Nov 29 17:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrSK-0005Vm-1R; Thu, 29 Nov 2007 17:02:00 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxrSH-0005OZ-U2 for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 17:01:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrSH-0005Nw-Ie for ltru@ietf.org; Thu, 29 Nov 2007 17:01:57 -0500 Received: from 113166.kabissa.org ([72.32.199.201] helo=kabissa.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrSG-0007F7-W1 for ltru@ietf.org; Thu, 29 Nov 2007 17:01:57 -0500 Received: (qmail 16135 invoked from network); 29 Nov 2007 16:01:56 -0600 Received: from pool-72-75-10-67.washdc.east.verizon.net (HELO IBM92AA25595C4) (72.75.10.67) by 72.32.229.137 with SMTP; 29 Nov 2007 16:01:55 -0600 From: "Don Osborn" To: "'Peter Constable'" , "'John Cowan'" , References: <20071129143920.GC32134@mercury.ccil.org> In-Reply-To: Subject: RE: [Ltru] John Cowan throws in the towel on extlangs Date: Thu, 29 Nov 2007 17:01:53 -0500 Message-ID: <007601c832d3$73a6d220$5af47660$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgylaVYXFYU2TsKRUycOFEc4NQRawAOtYCQAACb4YA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Apologies in advance if this is a non-sequiteur to this particular thread, but is there provision for new macrolanguages. A while back there was a suggestion that we know them all, but I could suggest other possibilities such as Runyakitara (aready mentioned), Oshiwambo, possible new mix for Manding languages. This may be ISO 639 territory, but also would relate to use of tags. Don > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: Thursday, November 29, 2007 4:49 PM > To: John Cowan; ltru@ietf.org > Subject: RE: [Ltru] John Cowan throws in the towel on extlangs > > > From: John Cowan [mailto:cowan@ccil.org] > > > IMO we should strongly consider adding a new informative (and > mutable) > > "Fallback" header in the registry which will inform people about > > problematic cases like "cmn" and "arb" (Standard Arabic), instructing > > them which language subtag to fall back to in cases of match failure. > > These will have to be cherry-picked, like Suppress-Script, but Peter > > Constable has estimated that there are no more than 15 such cases > > actually in wide use. For some macrolanguages, there is no dominant > > variety, and no special consideration is as yet required; if new > > dominant varieties come to exist in future, new Fallback headers can > > be added. > > RFC 4647bis can then be revised to explain how this header MAY be > used > > to enhance matching. > > I've taken a cut at analyzing macrolanguages in terms of two key > factors: widespread exposure in ICT (based on support in OSes), and > whether there is a dominant language. (Of course, "dominant" varies on > a continuum.) > > I ended up with 16 considered to have wide exposure. File is attached. > > > Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 17:39: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 1Ixs33-0006ZF-3V; Thu, 29 Nov 2007 17:39:57 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Ixs31-0006Xg-Fm for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 17:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixs31-0006XY-1w for ltru@ietf.org; Thu, 29 Nov 2007 17:39:55 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixs30-00005L-Lt for ltru@ietf.org; Thu, 29 Nov 2007 17:39:55 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1Ixs2t-0000Ro-KK; Thu, 29 Nov 2007 17:39:47 -0500 Date: Thu, 29 Nov 2007 17:39:47 -0500 To: Don Osborn Subject: Re: [Ltru] John Cowan throws in the towel on extlangs Message-ID: <20071129223947.GI20488@mercury.ccil.org> References: <20071129143920.GC32134@mercury.ccil.org> <007601c832d3$73a6d220$5af47660$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007601c832d3$73a6d220$5af47660$@net> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Don Osborn scripsit: > Apologies in advance if this is a non-sequiteur to this particular thread, > but is there provision for new macrolanguages. A while back there was a > suggestion that we know them all, but I could suggest other possibilities > such as Runyakitara (aready mentioned), Oshiwambo, possible new mix for > Manding languages. This may be ISO 639 territory, but also would relate to > use of tags. In principle, 639-3/RA may create them at any time. So far they have not been asked to do so. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The known is finite, the unknown infinite; intellectually we stand on an islet in the midst of an illimitable ocean of inexplicability. Our business in every generation is to reclaim a little more land, to add something to the extent and the solidity of our possessions. --Thomas Henry Huxley _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Nov 29 17:53: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 1IxsGZ-0002vX-7z; Thu, 29 Nov 2007 17:53:55 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxsGY-0002vG-Cp for ltru-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 17:53:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxsGY-0002v0-2c for ltru@ietf.org; Thu, 29 Nov 2007 17:53:54 -0500 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxsGX-0003bi-IM for ltru@ietf.org; Thu, 29 Nov 2007 17:53:53 -0500 Received: from [172.21.232.184] (wlanvpn-abc-232-184.corp.yahoo.com [172.21.232.184]) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lATMrduo082433; Thu, 29 Nov 2007 14:53:39 -0800 (PST) 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=XapaTGiW8DtYvnFss9QqxYKlhROy7ZRatHNVKME1No+3qxgAulLRKlOghm9mVTSu Message-ID: <474F42F3.7010404@yahoo-inc.com> Date: Thu, 29 Nov 2007 14:53:39 -0800 From: Addison Phillips User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] John Cowan throws in the towel on extlangs References: <20071129143920.GC32134@mercury.ccil.org> <007601c832d3$73a6d220$5af47660$@net> <20071129223947.GI20488@mercury.ccil.org> In-Reply-To: <20071129223947.GI20488@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Don Osborn scripsit: > >> Apologies in advance if this is a non-sequiteur to this particular thread, >> but is there provision for new macrolanguages. A while back there was a >> suggestion that we know them all, but I could suggest other possibilities >> such as Runyakitara (aready mentioned), Oshiwambo, possible new mix for >> Manding languages. This may be ISO 639 territory, but also would relate to >> use of tags. > > In principle, 639-3/RA may create them at any time. So far they have not been > asked to do so. > Further, if John's towel stays thrown, it wouldn't impact RFC 4646bis. It *would* potentially require new information be placed into the registry (fallback or macrolanguage fields) and thus might influence various tagging choices. Note that there is no difference between extlang and no-extlang on this: most enclosed languages would already be in the registry as primary language subtags and thus could not become extlang subtags after the fact. 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 Nov 30 01:22: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 1IxzGq-0004by-5h; Fri, 30 Nov 2007 01:22:40 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxzGn-0004TV-WC for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:22:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzGn-0004MX-6A for ltru@ietf.org; Fri, 30 Nov 2007 01:22:37 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxzGm-0005y2-Nr for ltru@ietf.org; Fri, 30 Nov 2007 01:22:37 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IxzGf-0008Nn-M9; Fri, 30 Nov 2007 01:22:29 -0500 Date: Fri, 30 Nov 2007 01:22:29 -0500 To: Addison Phillips Message-ID: <20071130062229.GG32134@mercury.ccil.org> References: <20071129143920.GC32134@mercury.ccil.org> <474EE92A.30209@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474EE92A.30209@yahoo-inc.com> 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 Subject: [Ltru] Re: Fallback vs. Macrolanguage? (was: John Cowan throws in...) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Wouldn't it be easier, more consistent, cleaner, and cherry-free to keep > what we've already proposed in draft-09, that is, to include the > Macrolanguage field in the registry as informative information (and then > note in either 4646bis or 4647bis about possible courses of action in > cases of match failure)? I don't think it's necessarily appropriate to fall back in all cases of macrolanguages (as Peter's list shows), and it may well be appropriate to fall back in some cases that aren't macrolanguages at all (Breton -> French is the example we've talked about a lot). Using a different name lets us decouple from 639-3's particular choices. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Half the lies they tell about me are true. -- Tallulah Bankhead, American actress _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 30 01:24: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 1IxzIk-000642-DM; Fri, 30 Nov 2007 01:24:38 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxzIi-00063j-R6 for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:24:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzIi-00063b-C0 for ltru@ietf.org; Fri, 30 Nov 2007 01:24:36 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxzIh-0002CF-TR for ltru@ietf.org; Fri, 30 Nov 2007 01:24:36 -0500 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 <20071130062435.ISCI3502.mta9.adelphia.net@DGBP7M81> for ; Fri, 30 Nov 2007 01:24:35 -0500 Message-ID: <001301c83319$accd6500$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 29 Nov 2007 22:24:33 -0800 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: c1c65599517f9ac32519d043c37c5336 Subject: [Ltru] Re: John Cowan throws in the towel on extlangs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > In practical terms, this means that (unless someone else wants to take > up the cause on the LTRU mailing list and see Bonnie Prince Charlie > come into his own again) that we will allow all 639-3 code elements to > be language subtags, and deprecate all the grandfathered forms like > "zh-yue" (Cantonese) in favor of just 'yue'. Similarly, the currently > redundant sign languages like "sgn-US" will be deprecated in favor of > 'ase' and friends. The existing language tags representing > macrolanguages of course remain intact. Since I've been under the impression that extlangs were the only serious remaining issue, I hope we will soon see a draft-4646bis-10 that codifies the no-extlang decision and is otherwise as close as possible to WGLC-ready. I need to do another 4645bis draft that reflects this decision and the (apparently unstoppaable) addition of EU and friends, and Id like that draft to be WGLC-ready as well. It's almost December; enough is enough. > IMO we should strongly consider adding a new informative (and mutable) > "Fallback" header in the registry which will inform people about > problematic cases like "cmn" and "arb" (Standard Arabic), instructing > them which language subtag to fall back to in cases of match failure. > These will have to be cherry-picked, like Suppress-Script, but Peter > Constable has estimated that there are no more than 15 such cases > actually in wide use. For some macrolanguages, there is no dominant > variety, and no special consideration is as yet required; if new > dominant varieties come to exist in future, new Fallback headers can > be added. RFC 4647bis can then be revised to explain how this header > MAY be used to enhance matching. As much as I appreciate the rationale for this idea -- the difference between the two classes of macrolanguage are well-known -- I'm concerned about any additional cherry-picking. We've seen too much controversy already over Suppress-Script, a feature that exists to help prevent taggers from making bad tagging decisions. I feat there might be even less support for a feature that is meant to help tag recipients make better matching decisions. I keep hearing that people will want to tailor their own fallback (Breton to French, etc.) independently of what the Registry says. If we add this field, will anyone use it? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Fri Nov 30 01:30: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 1IxzOs-0002rK-W6; Fri, 30 Nov 2007 01:30:59 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxzOr-0002cu-EJ for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:30:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzOq-0002aR-NS for ltru@ietf.org; Fri, 30 Nov 2007 01:30:56 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxzOq-0003qJ-Bv for ltru@ietf.org; Fri, 30 Nov 2007 01:30:56 -0500 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 <20071130063055.GNLO24109.mta13.adelphia.net@DGBP7M81> for ; Fri, 30 Nov 2007 01:30:55 -0500 Message-ID: <001c01c8331a$8f887470$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 29 Nov 2007 22:30:54 -0800 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ltru] Re: action item: "other" collections in 639 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I apologize for misinterpreting Peter's original comment and starting this whole thread. I understand that what he proposes is to remove the word "(Other)" from existing collection codes, thereby expanding their scope so that, for example, "art" would now refer to all artificial languages, including ones like Esperanto and Ido that have their own codes. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Fri Nov 30 01:41: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 1IxzZK-0002cm-1j; Fri, 30 Nov 2007 01:41:46 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IxzZI-0002cL-Ss for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 01:41:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzZI-0002cA-JR for ltru@ietf.org; Fri, 30 Nov 2007 01:41:44 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxzZG-0002Ic-EV for ltru@ietf.org; Fri, 30 Nov 2007 01:41:44 -0500 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 <20071130064141.JWRG3502.mta9.adelphia.net@DGBP7M81> for ; Fri, 30 Nov 2007 01:41:41 -0500 Message-ID: <002401c8331c$10ae7a30$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 29 Nov 2007 22:41:40 -0800 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: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Re: John Cowan throws in the towel on extlangs X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 wrote: > Apologies in advance if this is a non-sequiteur to this particular > thread, but is there provision for new macrolanguages. A while back > there was a suggestion that we know them all, but I could suggest > other possibilities such as Runyakitara (aready mentioned), Oshiwambo, > possible new mix for Manding languages. This may be ISO 639 territory, > but also would relate to use of tags. This is unquestionably ISO 639 territory; "macrolanguage" is their word and their concept. The only business LTRU and ietf-languages should have in this regard is to use the macrolanguage definitions from ISO 639-3 (or none at all), and to lobby the ISO 639-3 people to make whatever changes we feel need to be made. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Fri Nov 30 03: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 1Iy1Q8-0006H0-Id; Fri, 30 Nov 2007 03:40:24 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iy1Q7-00066u-3L for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 03:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1Q6-00066V-PV for ltru@ietf.org; Fri, 30 Nov 2007 03:40:22 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy1Q5-0005rT-9U for ltru@ietf.org; Fri, 30 Nov 2007 03:40:22 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A97C51C0119; Fri, 30 Nov 2007 09:40:20 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id A49851C0074; Fri, 30 Nov 2007 09:40:20 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 97EF058ECBE; Fri, 30 Nov 2007 09:40:20 +0100 (CET) Date: Fri, 30 Nov 2007 09:40:20 +0100 From: Stephane Bortzmeyer To: John Cowan Message-ID: <20071130084020.GA17644@nic.fr> References: <20071129101709.GA25814@nic.fr> <20071129132111.GB32134@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129132111.GB32134@mercury.ccil.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org Subject: [Ltru] Re: Language tags in the future version of HTTP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Thu, Nov 29, 2007 at 08:21:11AM -0500, John Cowan wrote a message of 20 lines which said: > Since you're on that list, could you persuade them to use "BCP 47" > as the reference rather than "RFC 4646"? That's a difficult issue. What some people want, at this time, is to *include* RFC 4646 ABNF in RFC 2616bis, in order to make it self-sufficient (anyone knows if there are general IETF guidance here? about cross-RFC references?) The httpbis WS is chartered to make a *compatible* protocol, so referring to a moving target (BCP 47) may scare them. Do note that RFC 4930 still references RFC 3066 (while it was issued after RFC 4646) for precisely this reason (staying compatible with old sofwtare) and that was on purpose. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 30 10:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7wP-0007xk-SR; Fri, 30 Nov 2007 10:38:09 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1Iy7wO-0007xK-EK for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 10:38:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7wO-0007x9-3B for ltru@ietf.org; Fri, 30 Nov 2007 10:38:08 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy7wN-0000Sb-Iv for ltru@ietf.org; Fri, 30 Nov 2007 10:38:08 -0500 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; Fri, 30 Nov 2007 07:37:33 -0800 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; Fri, 30 Nov 2007 07:38:06 -0800 From: Peter Constable To: "ltru@ietf.org" Date: Fri, 30 Nov 2007 07:38:00 -0800 Subject: RE: [Ltru] John Cowan throws in the towel on extlangs Thread-Topic: [Ltru] John Cowan throws in the towel on extlangs Thread-Index: AcgylaVYXFYU2TsKRUycOFEc4NQRawAOtYCQAACb4YAAIxBfQA== Message-ID: References: <20071129143920.GC32134@mercury.ccil.org> <007601c832d3$73a6d220$5af47660$@net> In-Reply-To: <007601c832d3$73a6d220$5af47660$@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: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Don Osborn [mailto:dzo@bisharat.net] > Apologies in advance if this is a non-sequiteur to this particular > thread, It is not. > but is there provision for new macrolanguages. A while back there was a > suggestion that we know them all, but I could suggest other > possibilities > such as Runyakitara (aready mentioned), Oshiwambo, possible new mix for > Manding languages. This may be ISO 639 territory, but also would relate > to use of tags. New macrolanguage entries can be added to ISO 639. If RFC4646bis were to use extlang subtags prefixed by macrolanguage subtags= , then new macrolanguage IDs could not be prefixed to existing language IDs= . The macrolanguage ID could be used on its own, though; it could mean need= ing data in the LSR to support matching a macrolanguage ID against IDs for = the encompassed languages (as would be done if extlangs are not used). For example, if none of zh, cmn and yue were registered today, they could b= e added tomorrow and extlang subtags zh-cmn or zh-yue could be used. If, on= the other hand, cmn and yue were registered today but zh was not, zh could= still be added tomorrow, but cmn and yue would already be used as primary = subtags, so zh could not be prefixed. It could still be used as a primary s= ubtag, without extlang subtags; we would just need to allow for possible ne= ed to match content tagged "cmn" or "yue" with a request for "zh", or vice = versa. (Btw, the possibility of new macrolanguages encompassing pre-registered lan= guages forms one of the arguments against extlang: you end up needing to su= pport approaches to matching that would be needed without extlangs anyway.) Now, in the kinds of scenarios you have in mind, it's not clear to me if ma= crolanguage is the appropriate scope for new entries that might be requeste= d. Keep in mind that the macrolanguage has a measure of ambiguity: it is no= t one specific variety, but rather one of several distinct varieties. For i= nstance, either Mandarin and Cantonese content can be labeled "Chinese", an= d content labeled "Chinese" could well be either of those (or any of the ot= her Chinese languages). If Kwanyama and Ndonga are distinct languages and if "Oshiwambo" can refer = to either and is in some contexts used as though it were a single language = rather than a collection, then it can be considered a macrolanguage. But if= Oshiwambo refers to a distinct variety that is not the same as either Kwan= yama or Ndonga but is used or coming into use by speakers of both Kwanyama = and Ndonga communities, then it might make more sense to consider Oshiwambo= an individual language. (I don't know which situation applies to Oshiwambo, and I'm not intending t= o steer discussion in that direction -- which would be off topic.) There are cases in which language differentiation has occurred so that, ove= r some extended period of time, a single language community has descendents= speaking multiple distinct languages; but in which a unifying process has = occurred (whether naturally or engineered) with a single language emerging = that is used by speakers of the various languages. An example of an enginee= red case is Filipino; I gather that N'Ko is somewhat an example of natural = evolution on this type. These are individual languages, not macrolanguages.= E.g. "Filipino" would not be an appropriate label for Cebuano content. Peter _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 30 12:50: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 1IyA07-0007yz-J8; Fri, 30 Nov 2007 12:50:07 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IyA06-0007tb-70 for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyA05-0007tO-TT for ltru@ietf.org; Fri, 30 Nov 2007 12:50:05 -0500 Received: from mail-dub.bigfish.com ([213.199.154.10] helo=mail145-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyA05-0007Di-Jh for ltru@ietf.org; Fri, 30 Nov 2007 12:50:05 -0500 Received: from mail145-dub (localhost.localdomain [127.0.0.1]) by mail145-dub-R.bigfish.com (Postfix) with ESMTP id 182F9F18A7E; Fri, 30 Nov 2007 17:50:05 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 64.14.251.196; Service: EHS Received: by mail145-dub (MessageSwitch) id 1196445003891788_23490; Fri, 30 Nov 2007 17:50:03 +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 mail145-dub.bigfish.com (Postfix) with ESMTP id 9D6AE17C0075; Fri, 30 Nov 2007 17:50:03 +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 2007113009500054-59356 ; Fri, 30 Nov 2007 09:50:00 -0800 In-Reply-To: To: Peter Constable Subject: RE: [Ltru] John Cowan throws in the towel on extlangs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 CCH7 December 15, 2006 From: Karen_Broome@spe.sony.com Message-ID: Date: Fri, 30 Nov 2007 09:47:23 -0800 X-MIMETrack: Serialize by Router on USMAIL02/SVR/SPE(Release 6.5.5FP1|April 11, 2006) at 11/30/2007 09:47:25, Serialize complete at 11/30/2007 09:47:25, Itemize by SMTP Server on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2007 09:50:00 AM, Serialize by Router on USCCiMTA02/SVR/SPE(Release 6.5.5|November 30, 2005) at 11/30/2007 09:50:03 AM, Serialize complete at 11/30/2007 09:50:03 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -1.0 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Just a couple points from my perspective on the Chinese languages and extlang. 1) We use "zh" today to indicate either Mandarin or Cantonese audio or written language that has not yet been verified to be either Cantonese or Mandarin. This is one use of the tag. 2) We tag audio content with the "zh" tag. 3) The audio content we tag with the "zh" tag is sometimes Cantonese. 4) We need a tag for written Cantonese used in subtitles, and today we use "zh-yue." I apologize for not being able to join any of the conference calls. I am OK with whatever the committee decides, but some of the premises seemed off based on our usage. Regards, Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 30 18:33: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 1IyFLn-000208-Ck; Fri, 30 Nov 2007 18:32:51 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IyFLl-0001zW-BA for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 18:32:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFLl-0001zM-17 for ltru@ietf.org; Fri, 30 Nov 2007 18:32:49 -0500 Received: from earth.ccil.org ([192.190.237.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyFLk-00008g-MV for ltru@ietf.org; Fri, 30 Nov 2007 18:32:49 -0500 Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1IyExZ-0007ol-5q; Fri, 30 Nov 2007 18:07:49 -0500 Date: Fri, 30 Nov 2007 18:07:49 -0500 To: Karen_Broome@spe.sony.com Subject: Re: [Ltru] John Cowan throws in the towel on extlangs Message-ID: <20071130230749.GM20488@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: 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 Karen_Broome@spe.sony.com scripsit: > 1) We use "zh" today to indicate either Mandarin or Cantonese audio or > written language that has not yet been verified to be either Cantonese or > Mandarin. This is one use of the tag. No problem. > 2) We tag audio content with the "zh" tag. No problem. > 3) The audio content we tag with the "zh" tag is sometimes Cantonese. No problem. When you know it is Cantonese, you'd be encouraged to switch to "yue". When you know it is Mandarin, you may use "cmn", but that might cause interop problems with applications that don't know that tag. > 4) We need a tag for written Cantonese used in subtitles, and today we > use "zh-yue." That will still be valid, but deprecated; you'd be encouraged to switch to "yue". -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Nov 30 23:39: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 1IyK86-0003LK-NC; Fri, 30 Nov 2007 23:39:02 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IyK85-0003LA-CQ for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 23:39:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyK84-0003L0-Qp for ltru@ietf.org; Fri, 30 Nov 2007 23:39:00 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyK84-0003Ux-8p for ltru@ietf.org; Fri, 30 Nov 2007 23:39:00 -0500 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 <20071201043859.ZCUW20104.mta10.adelphia.net@DGBP7M81> for ; Fri, 30 Nov 2007 23:38:59 -0500 Message-ID: <001301c833d4$17585f50$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 30 Nov 2007 20:38:58 -0800 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: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] Re: Fallback vs. Macrolanguage? (was: John Cowan throws in...) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> Wouldn't it be easier, more consistent, cleaner, and cherry-free... > > I don't think it's necessarily appropriate to fall back in all cases > of macrolanguages (as Peter's list shows), and it may well be > appropriate to fall back in some cases that aren't macrolanguages at > all (Breton -> French is the example we've talked about a lot). Using > a different name lets us decouple from 639-3's particular choices. We can keep the Macrolanguage name and follow the ISO 639-3 mappings exactly, or we can give this field a new name (such as John's suggestion, "Fallback") and cherry-pick the ones like Chinese and Arabic where one variety dominates. I think it would be too confusing to have both, as I said before about having both a Macrolanguage field and extlangs. However, I strongly oppose any efforts to add our own, non-ISO 639 mappings to the Registry, even seemingly obvious ones like Breton -> French. That way lies complete madness. We will never come anywhere close to getting all of them, and we will be reviled for "ignoring" the ones we miss, and every decision to either include or not include some mapping will be viewed by someone as an intentional slight or attempted subjugation of one of the languages involved. Please, let's leave this kind of mapping up to each application. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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 Fri Nov 30 23:51: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 1IyKK9-0005m2-Pk; Fri, 30 Nov 2007 23:51:29 -0500 Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IyKK8-0005ls-Kx for ltru-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 23:51:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyKK8-0005lg-Aj for ltru@ietf.org; Fri, 30 Nov 2007 23:51:28 -0500 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyKK7-0007Al-VO for ltru@ietf.org; Fri, 30 Nov 2007 23:51:28 -0500 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 <20071201045127.FHXO24109.mta13.adelphia.net@DGBP7M81> for ; Fri, 30 Nov 2007 23:51:27 -0500 Message-ID: <001701c833d5$d4f473e0$6601a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 30 Nov 2007 20:51:26 -0800 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: Language tags in the future version of HTTP X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > That's a difficult issue. What some people want, at this time, is to > *include* RFC 4646 ABNF in RFC 2616bis, in order to make it > self-sufficient (anyone knows if there are general IETF guidance here? > about cross-RFC references?) Cross-references like that are generally considered a good thing, aren't they? They reduce the chances of introducing a typo that changes the ABNF, and serve to discourage each application from adopting their own, slightly different syntax. "Self-sufficiency" should be a complete non-goal. How many modern RFCs seek to define MUST and SHOULD independently of RFC 2119, or the format of a mail message independently of RFC (2)822? -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 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